,
12 tweets,
3 min read
Read on Twitter
I'm a lisper who has spend a little over six months getting up to speed in OCaml, and it's been really interesting. It's been unlike anything I've used before. Thread.
OCaml's syntax is pretty exotic, even if you've done some Haskell.
[1,2] is legal but it's not a list of numbers. Precedence (esp , and ;) is surprising [let y = 2 in y; 3]. Nesting match statements (common) can end up with a type error on bad usage.
[1,2] is legal but it's not a list of numbers. Precedence (esp , and ;) is surprising [let y = 2 in y; 3]. Nesting match statements (common) can end up with a type error on bad usage.
Fortunately, the #ocaml channel on Freenode is really helpful when you get stuck. Another great trick is to run ocamlformat on your code: it often adds parentheses to examples that are harder to parse, e.g. (x, y as z).
The module system is neat, but if you squint it looks like a Java style interface. It's more general than that, but I found it a helpful mindset when starting out.
Some other design features are more old school. OCaml has a C++ style header system, where .ml files have implementation and .mli just have signatures.
Scheme requires you to opt-in to nested binding with let*/letrec, whereas newer lisps like Clojure have the let* by default.
OCaml similarly requires recursive functions (even if there's only one in a `let ... and ...`) to use `rec`. It's an unusual default today.
OCaml similarly requires recursive functions (even if there's only one in a `let ... and ...`) to use `rec`. It's an unusual default today.
One awesome default is that mutable variables require more typing: let x = 1` versus `let x = ref `. It's still easy to have tons of mutable state, but OCaml makes it explicit.
OCaml's type system is *wild* though.
Type signatures are completely optional, and the checker looks at your whole program.
This can produce spooky effects. If you call a function inconsistently, OCaml ca assume the first type was correct, even if that produces 100s of errors!
Type signatures are completely optional, and the checker looks at your whole program.
This can produce spooky effects. If you call a function inconsistently, OCaml ca assume the first type was correct, even if that produces 100s of errors!
OCaml can even say "no, your _type signature_ is wrong!" when a function body and signature disagree. Type signatures are great for narrowing down mistakes, but it's a weird experience. Many newer languages assume the type signature is always correct.
The type system uses structural subtyping, which is also a rare experience today. It's very flexible, but it makes error messages challenging. When type A (an object with 10 methods) differs from type B (an object with 11 methods) it's hard to diff the signatures.
Merlin (essentially LSP for OCaml) has a superpower here! It has a notion of _type verbosity_. If you repeatedly ask for the type of an expression, it will expand type aliases, allowing you to drill in to type aliases and see what data you have.
OCaml has been eye-opening and I've learnt a ton. Its bias towards total functions means it's close to "if it compiles, it works". Make sure you set up the tooling, and it's a fun language to work with. /end
