<dh`>
using the yaml package is apparently causing an "Unsigned" module I didn't ask for to appear, but I can't figure out where it's actually coming from or what it is
<dh`>
in particular nothing matches [Uu]nsigned in ~/.opam
<dh`>
(and it's conflicting with my own Unsigned module, which is annoying)
<dh`>
(a) any suggestions on where it's hiding, and (b) is there any way to suppress it?
<discocaml>
<hockletock> looks like yaml depends on ctypes depends on integers
<dh`>
hmm and now I can find it in ~/.opam after all, must have flubbed that somehow
<dh`>
thanks
<dh`>
I suppose that means there's no useful way to mask it
<discocaml>
<hockletock> you can supersede it within your own modules
<dh`>
yes, but only at the cost of doing so explicitly everywhere
<dh`>
whereas massrenaming to Uint took only a moment
szkl has joined #ocaml
Anarchos has quit [Quit: Vision[]: i've been blurred!]
waleee has quit [Ping timeout: 248 seconds]
mima has quit [Ping timeout: 248 seconds]
Anarchos has joined #ocaml
chrisz has quit [Ping timeout: 260 seconds]
chrisz has joined #ocaml
Anarchos has quit [Quit: Vision[]: i've been blurred!]
Anarchos has joined #ocaml
Anarchos has quit [Quit: Vision[]: i've been blurred!]
Anarchos has joined #ocaml
Anarchos has quit [Quit: Vision[]: i've been blurred!]
szkl has quit [Quit: Connection closed for inactivity]
azimut has quit [Ping timeout: 246 seconds]
szkl has joined #ocaml
bartholin has joined #ocaml
bgs has joined #ocaml
wingsorc has quit [Ping timeout: 245 seconds]
greenbagels has quit [Ping timeout: 244 seconds]
Serpent7776 has joined #ocaml
mima has joined #ocaml
azimut has joined #ocaml
greenbagels has joined #ocaml
bgs has quit [Remote host closed the connection]
xd1le has joined #ocaml
ursa-major has quit [Quit: WeeChat 4.0.3]
bartholin has quit [Quit: Leaving]
amk has quit [Ping timeout: 256 seconds]
amk has joined #ocaml
<discocaml>
<loves_curry> is it possible to change ocaml to use commas for arrays and ; for tuples?
azimut has quit [Ping timeout: 246 seconds]
Hammdist has joined #ocaml
Hammdist has quit [Client Quit]
SquidDev has quit [Quit: Ping timeout (120 seconds)]
SquidDev has joined #ocaml
<discocaml>
<Kali> not without writing your own preprocessor
<discocaml>
<Kali> this would reduce readability significantly
<discocaml>
<loves_curry> thanks!
SquidDev has quit [Quit: Ping timeout (120 seconds)]
SquidDev has joined #ocaml
<discocaml>
<deepspacejohn> That would conflict with tuples where parentheses are optional. `let a, b = c` vs `let a; b = c` would be ambiguous
<discocaml>
<Kali> would it be, if all were flipped?
<discocaml>
<Kali> oh, no, that's right
<discocaml>
<deepspacejohn> It might work if you just always required parentheses, I think?
ursa-major has joined #ocaml
ursa-major has quit [Quit: WeeChat 4.0.3]
<discocaml>
<holmdunc> SML, OCaml's more attractive sibling, uses commas for both lists and tuples, and has mandatory parenthesis for tuples
azimut has joined #ocaml
uncomfy has joined #ocaml
szkl has quit [Quit: Connection closed for inactivity]
<companion_cube>
that doesn't sound so great
<companion_cube>
it also has a `end` after `let` which means you can't as easily nest `let` :/
uncomfy has quit [Remote host closed the connection]
<discocaml>
<cemerick> the no-semicolons bit is SML's biggest (only?) win over OCaml IIRC
<discocaml>
<Kali> i don't really mind semicolons so much when making lists of tuples
<discocaml>
<Kali> otherwise it's just a small oddity
<discocaml>
<tym972> Hello, I would need to interrupt the call of a function if the execution time exceeds a certain threshold. Is it possible?
<discocaml>
<masterbuilder> personally I'm a big fan of the function definition syntax, I really wish OCaml had that
<discocaml>
<contificate> but the `let` form is more involved, so the nesting you see with OCaml doesn't typically happen in SML (as it'd just be `let val x = ... val y = ... in e end`)
<companion_cube>
oh and how would that jive with let operators? :)
<companion_cube>
(also, I hate `let() = …` instead of `;`)
<discocaml>
<cemerick> What part? That there's a separate `fun` instead of just using let? Parens for params?
<discocaml>
<cemerick> (caveat, I'm years away from my last contact with SML)
<discocaml>
<masterbuilder> you can provide a set of definitions with pattern matching in the parameters directly, similar to Haskell
<discocaml>
<masterbuilder> instead of having to use `function` and match on a tuplee
<discocaml>
<masterbuilder> instead of having to use `function` and match on a tuple
<discocaml>
<masterbuilder> I think that's really nice personally
Hammdist has joined #ocaml
<discocaml>
<cemerick> oh, I didn't actually know that. Yes, I miss that from haskell regularly.
<pkal>
I'm having trouble with using "ocamlfind ocamlc" to compile a program with a dependency (ELPI) I got from OPAM. I get this message: Wrong link order: Elpi_util__Util depends on Unix, Elpi_util__Util depends on Unix, Elpi_util__Util depends on Unix.
<pkal>
ocaml-lsp doesn't work either, no dependencies are recognised. It is possible that I didn't install the library the right way (opam install elpi)?
<discocaml>
<contificate> meh, one could envision a new binding construct in SML that works the same as `let`-operators in OCaml etc. and SML has semicolon
<discocaml>
<contificate> SML just has lots of silly things (eqtype) and a worse module system (for separate compilation, at least), and in practice I'd say is actually uglier syntactically.. its biggest contribution is probably the work that came out of MLton, CML, etc. rather than itself as a language
<discocaml>
<contificate> the choice really comes down to whether you wish to be portrayed as a crude drawing of a builder or a crude drawing of a scientist on Chlipala's webpages http://adam.chlipala.net/mlcomp/
<companion_cube>
there should be a long list of additional entries for things OCaml has that SML doesn't :)
tomku has joined #ocaml
<discocaml>
<cemerick> it's easier to enumerate the inverse ofc
<companion_cube>
I mean there are important changes, even beyond just the type system
<companion_cube>
I'd hate to write OCaml without: inline records, let-with-exception, let operators (for a start)
bgs has joined #ocaml
<discocaml>
<._null._> let-with-exception ?
<companion_cube>
err, match-with-exception sorry
<companion_cube>
match x with foo -> … | exception Oh_no -> …
<companion_cube>
it's _semantically_ different, and more general, than just `try … with …`
<discocaml>
<._null._> That I know about
<discocaml>
<._null._> Different from `try match <e> with <pats -> e> with <exceptions -> e>` ?
<discocaml>
<sim642> Yes, because the `try` is only around the matched expression, not all the match cases. If an exception is raised from any of those, that isn't caught by this
<discocaml>
<._null._> Right
<companion_cube>
in particular match-with-exception works well in tail-recursive code
<octachron>
I think the most relevant aspect of this comparison is that it is comparing OCaml 3.09 with SML, and that only one side would need to be updated in term of features.
<companion_cube>
3.09… damn
<discocaml>
<Et7f3 (@me on reply)> Isn't the opposite match try <e> with ...
<discocaml>
<._null._> It would behave correctly wrt. to what exceptions are caught, but your handler returns something of a different type
<discocaml>
<._null._> You can make an equivalent using an option, but it would be more expensive
bartholin has joined #ocaml
<discocaml>
<._null._> You can make an equivalent using an encoding through an* option, but it would be more expensive
<discocaml>
<._null._> Wait, not an option, you need an `Either.t`
<discocaml>
<loves_curry> Oh interesting ive never tried SML but have heard of it. Thanks for sharing
dhil has joined #ocaml
<discocaml>
<holmdunc> unfortunately it's virtually dead so the library ecosystem is close to non-existent
<discocaml>
<cemerick> it was intentionally ascetic 15 years ago, nvm vs. modern standards
<discocaml>
<masterbuilder> yeah writing sml is rough, not a good time
<discocaml>
<cemerick> the R4RS of MLs
<discocaml>
<contificate> it's one of those languages that seems to have aesthetic appeal, so you go about writing a small project in it
<discocaml>
<contificate> then, like C, the delusional eventually wears off and you're left going "should've just used OCaml"
<discocaml>
<contificate> just need to know when to cut your losses with experimenting with ML family members
<discocaml>
<contificate> like, don't start compiling Caml Light for internet points y'know
<discocaml>
<loves_curry> Haha
<discocaml>
<loves_curry> Im pretty new to ocaml so idk how different it is from haskell besides some syntax
<discocaml>
<contificate> it's very different
Tuplanolla has joined #ocaml
<discocaml>
<myrkraverk.> What physical book do the cool kids use to learn Ocaml these days?
<discocaml>
<hockletock> bold of you to assume basically that whole premise
<discocaml>
<Kali> quite different, the most notable being
<discocaml>
<Kali> - syntax (as you mentioned)
<discocaml>
<Kali> - discouragement towards using operators vs alphanumeric functions
<discocaml>
<Kali> - a very strong module system rather than typeclasses
<discocaml>
<Kali> - mutability and arbitrary side-effects are permitted although not recommended for except for debugging/performance reasons
<discocaml>
<Kali> - by far a smaller stdlib (although there are replacements such as Base/Batteries/etc.)
<discocaml>
<contificate> a notable one is that Haskell is lazy, whereas OCaml is strict
<discocaml>
<Kali> oh, yes, that too
<discocaml>
<Kali> the ocaml compiler is incredibly fast and small compared to ghc too
<discocaml>
<Kali> isn't the ghc compiler set like 500mb total?
waleee has joined #ocaml
<discocaml>
<Kali> ocaml compiler, interpreter, toplevel, parser/lexer generator, debugger, and a bunch of other things fit in half that
<discocaml>
<Kali> ocaml's
<discocaml>
<myrkraverk.> Assuming you're replying to me. I'm not new to programming, so any book should do the trick.
<discocaml>
<myrkraverk.>
<discocaml>
<myrkraverk.> I think I already started this one online, and it's nice.
<discocaml>
<myrkraverk.>
<discocaml>
<myrkraverk.> However, now I'm looking for a physical copy, so I can get any book at all.
<discocaml>
<contificate> Real World OCaml is a physical book but also somewhat Jane Street-ified in places.
<discocaml>
<myrkraverk.> Jane Street-ified?
<discocaml>
<anurag_soni> @myrkraverk. This one doesn't get a lot of love here, but "Real World OCaml" has a new 2nd edition out now and is avaiable as a physical copy too. I used it to learn OCaml, and have seen that book be useful to multiple other engineers at my previous employers for getting up to speed with OCaml.
<companion_cube>
it uses the Janestreet subset of the ecosystem, @myrkraverk, is what it means
<discocaml>
<myrkraverk.> Cool, I think I'll give it a try, next book purchase.
<discocaml>
<contificate> Yeah, like certain chapters are just full of usage of Jane Street libraries etc. as I recall. It has good treatment of other general topics though.
<discocaml>
<myrkraverk.> Fair enough, though at the moment, I have no clue what that means C:
<discocaml>
<Kali> yes, almost all examples have `open Base` prefixing them
<discocaml>
<Kali> (Base is JS's stdlib replacement)
<discocaml>
<myrkraverk.> Does Ocaml have a "spec" like SML, and Haskell (1998) ?
<discocaml>
<contificate> The interesting thing about OCaml and SML is that, with some basic background, you can actually learn from basically any book about it. For example, if you happen to speak French, you can learn basic type inference from "Le Language Caml". If you happen to know some basic SML and OCaml, Modern Compiler Implemntation in ML is sufficient. Same thing goes for projects in ML for the working programmer etc.
<discocaml>
<hockletock> it is 198MB compressed if that's what you're comparing
<discocaml>
<Kali> is that including all the extra bytecode versions of them?
<discocaml>
<myrkraverk.> I know a bit of SML, but not much. Got into some trouble with it, when trying to learn it by doing a project. Nowadays I might retry using a book to start with.
<discocaml>
<contificate> OCaml is easier to love than SML.
<discocaml>
<myrkraverk.> But, I also want to learn Ocaml, and since I can mostly read French [enough to get by most programming texts I've come across] I can try _Le Language Caml_ too.
<discocaml>
<contificate> The core language is pretty small. I wouldn't even bother with a book.
<discocaml>
<Kali> it is including the bytecode ones, which are not really necessary are they?
<discocaml>
<Kali> you could easily strip a few hundred just by not building those ones
<discocaml>
<myrkraverk.> That's all well and good, but sometimes I just want to get away from the screen -- even an ereader -- and still "learn." Hence why I've started collecting physical books.
<discocaml>
<contificate> Understandable, I've started cropping PL-related PDFs to read on my Kindle.