The golden rule is missing:
> Don't try to understand the error message except if you have no other choice.
What I wish I knew when learning OCaml (2018)
41–50 of 88 posts
Re: What I wish I knew when learning OCaml (2018)
#42Earlier quoted context omitted.
I think both of these points can be alleviated with certain coding habits that come with practice. For instance, adding type annotations in some places will help with error messages. And using "assert false" (which has type 'a) will let you run an incomplete/broken program. As for the error messages requiring expertise in type theory, it sounds as an exaggeration, esp. when not using advanced features.
Hey, thanks for that "assert false" trick! I never knew that! I don't know much about type theory but I did eventually manage to learn to interpret OCaml's type errors well enough to get things to compile. It still feels like driving a car by scraping it along a highway guardrail but it's often better than testing. I have to write twice as much code as in Python, it takes me longer to get it to run, and I still can't…
OCaml also has a built in function failwith: string -> ‘a, so you can print an error in those cases. If it’s a code path you ever think will execute, failwith “some error here” is probably better than assert false
Re: What I wish I knew when learning OCaml (2018)
#43A good list. ML languages push you (kicking and screaming) into the pit of success.
Kicking and screaming? ML dialects, or at least F#, are usually a pleasure.
Re: What I wish I knew when learning OCaml (2018)
#44Earlier quoted context omitted.
A list is either the empty list [] or Two pieces of data (with the constructor ::) with 1 being the head of the list (type 'a) and one being the tail of the list (type 'a list, a recursive definition). :: is an allowed identifier in oCaml. If that is not allowed, the typical names are Cons for :: and Nil for []
Thanks. I had not understood it could be recursive. Do you know Cons' meaning ? Also why does :: act as a separator... ? Is that something you ca do with any Data constructor, I mean can I write type 'a = 'a Cons of 'a | Nil of 'a ?
You would write something like List a = Cons a (List a) | Nil
As :: doesn't start with a letter, it's infix by default. But basically a binary constructor. If you want to create the List [1,2,3] in the prefix notation you might be used to: ::(1,::(2,::(3,[])))
Re: What I wish I knew when learning OCaml (2018)
#45TIL that Ocaml/SML are compiled into lambda expressions... I literally thought lambda calculus is only used in CS classes. OCaml's syntax is pretty annoying but type inference is actually amazing.. I changed my mind over it, as previously I thought explicit type annotations are simpler. Turns out, it would be humanly impossible to explicitly annotate every piece of OCaml, just let the compiler do it for you
Did you learn that from some other article? I couldn't find "lambda" in this page. I think it's too much to say that all Standard ML compilers work or one way or another. There are 6 major compilers and a number of minor ones. They don't really follow the same approaches in general.
One of the intermediary representation used by the OCaml compiler is a lambda calculus (https://github.com/ocaml/ocaml/blob/trunk/lambda/lambda.mli#...). But yes, this is only the OCaml compiler.
Re: What I wish I knew when learning OCaml (2018)
#46Earlier quoted context omitted.
I wonder why this is the case. Ocaml syntax doesn't seem very arcane, it is not hell-bent on functional purism and pragmatically allows for imperative code. Performance seems quite reasonable. What does it lack that prevented it from gaining wider acceptance? Surely buy-in from a large company was an issue, but even F# hasn't seen any significant uptake. Is it really the lack of curly brackets? That didn't stop Pytho…
The syntax is not great, the standard library is very sparse, and the error messages from the compiler and interpreter are terrible (and used to be worse). The OCaml team used to treat the native code compiler (ocamlopt) as a second-class citizen, but it's the implementation that matters for performance. Since the end of Dennard scaling about 15 years ago, OCaml's lack of multithreading has also been a pain point, on…
Why do you think that the native compiler was treated as a second class citizen? This is quite strange take from my point of view. For instance OCaml native compiler was available on the M1 Macs two months after the M1 release. Similarly, all major CPU architectures (x86, ARM, PowerPC, RISC-V, s390x) have been supported for years.
Re: What I wish I knew when learning OCaml (2018)
#47TIL that Ocaml/SML are compiled into lambda expressions... I literally thought lambda calculus is only used in CS classes. OCaml's syntax is pretty annoying but type inference is actually amazing.. I changed my mind over it, as previously I thought explicit type annotations are simpler. Turns out, it would be humanly impossible to explicitly annotate every piece of OCaml, just let the compiler do it for you
What do you not like about the syntax? I hear this often, and I vaguely remember not liking it myself at one point. But it was also my first ML and now I can't remember what specifically I found unpleasant.
I do think I've partially ascended into senior dev galaxy brain around syntax though. For the most part I think they're all fine and also all bad and also don't matter very much at all.
Re: What I wish I knew when learning OCaml (2018)
#48Earlier quoted context omitted.
> Ocaml is a strongly typed static language. As such your code has to respect type constraints. It’s very much a feature not a bug. That's reasonable if the error message were "This expression is of type X but an expression was expected of type Y ". But the worst error message in the OCaml interactive toplevel is when they're the same. This happened when you defined a new type named X (which, incidentally, must be lo…
Yeah if you did this now you’d get something like “this expression is of type t/1 but an expression of type t/2” to disambiguate.
And the REPL should warn you that if you have a value of type "t/n" it is probably a left-over from a previous definition of type t in the session.
Re: What I wish I knew when learning OCaml (2018)
#49Earlier quoted context omitted.
Yeah if you did this now you’d get something like “this expression is of type t/1 but an expression of type t/2” to disambiguate.
The fact that this problem took 25 years to fix is maybe the more damning thing. It wasn't a bug , exactly; it was a usability problem. Clearer demonstrations of development priorities could hardly be given.
That was mostly a man-power issue. The good news is that nowadays such nonsensical error messages are near the top of my personal development priority for OCaml.
Re: What I wish I knew when learning OCaml (2018)
#50Earlier quoted context omitted.
The fact that this problem took 25 years to fix is maybe the more damning thing. It wasn't a bug , exactly; it was a usability problem. Clearer demonstrations of development priorities could hardly be given.
That was mostly a man-power issue. The good news is that nowadays such nonsensical error messages are near the top of my personal development priority for OCaml.
During those 25 years OCaml gained native-code compilers for new architectures, labeled arguments, and polymorphic variants, among other things. How could it be mostly a manpower issue?