lpw25

This is part 3 of a series, the previous posts were:

1. Locality: https://blog.janestreet.com/oxidizing-ocaml-locality/ (Discussion: https://news.ycombinator.com/item?id=36094799)

2. Rust-style ownership: https://blog.janestreet.com/oxidizing-ocaml-ownership/

These are the posts the article is referring to:

Part 1: https://blog.janestreet.com/oxidizing-ocaml-locality/

Part 2: https://blog.janestreet.com/oxidizing-ocaml-ownership/

Our long term aim is to upstream all of our work from our branch of the OCaml compiler. Of course, that is contingent on the ideas we’re developing there being accepted by the community. There are two main reasons we work on our own branch:

1. Language design is hard. At Jane Street we have a great opportunity to design new features, test them extensively in a realistic environment, and then change them. Because we have access to the entire code base where the features are deployed, we can even change concrete syntax relatively easily. So by developing internally, releasing internally, and then upstreaming with experience, we can be more confident that the feature design is correct.

2. We get a faster turnaround between idea conception and internal deployment. Working solely with upstream, we would develop an idea, go through a long design discussion with upstream, implement, merge, wait for release, wait for the rest of Jane Street to be ready to upgrade, and upgrade. Now, we can implement an idea in parallel with its design, rolling it out internally in stages (as appropriate), and then upstream later. This is a big win for us, and well worth the extra time spent moving changes back and forth.

> Why choose such an obscure word as `exclave`

We discussed a lot of possible choices and eventually decided this was the best one. I personally think names should either be self-explanatory or memorable -- so that once they have been explained they aren't forgotten -- here we went with memorable. As a word, exclave also captures what is going on in terms of part of the parent region being contained within the child region. `return local` was a strong contender, but it implies that `exclave` is always about functions -- whereas the actual feature is a bit more general than that. It is also a bit easier, when adding new keywords, if you pick a word that isn't used much, and `return` is used a lot.

> OCaml (concurrency isn't the best)

Pet peeve: OCaml's concurrency is pretty good, it's parallelism that it struggles with.

Modularity

> Is there any place in the official OCaml repository / issue tracking system / wiki etc where one could check the status?

You can see some things on:

  https://github.com/ocamllabs/ocaml-modular-implicits

but you shouldn't take a lack of activity on there as a sign nothing is happening. For instance, Frederic is actively hacking on the prototype at the moment but hasn't pushed anything to that repo.

The size of Core executables is mostly addressed by module aliases. Unfortunately the public release of Core still uses packing instead of module aliases because oasis/ocamlbuild don't easily support them.

It's being very actively worked on. No solid ETA yet but I would expect the coming version or the one after to work out of the box.

> I still serve on program committees and review articles for journals and the like.

Judging academia from your experience on program committees is like judging the entertainment industry from watching Britain's Got Talent.

It is, but it is worth noting that when OCaml or Haskell programmers talk about type inference they are usually referring to global type inference which allows an argument's type to be inferred from its uses. For example:

  let f x = x + x

will be inferred as int -> int.

Just a quick note to say that jdh hasn't been an active OCaml user for years. He trolls on behalf of F# these days.

Functors => higher-kinded types

You need at least one module that does something at top-level, otherwise your program won't do anything.

> Mind naming any fundamentally new concepts introduced by Haskell or OCaml?

For OCaml:

- row polymorphism (in particular polymorphic variants)

- higher-order and applicative functors (not the Haskell thing).

- first-class modules

For both:

- Higher-rank polymorphism

For Haskell (and now in both):

- GADTs

By introduced here, I'm ignoring them being implemented in toy languages first (since that is simply the first step of introducing them to programming). Similarly, it is not reasonable to say that F-omega or a dependently typed calculus already had such features, because that ignores issues of type inference and efficient implementation.

OCaml has had type-directed record disambiguation for a few versions now. So you can quite easily reuse field names these days.

> Anecdotally, the runtime also falls down when you need to use large arrays or strings, or do lots of floating-point calculations.

Anecdotally from one specific well-known troll. (I'm not saying it is or isn't true, just that almost all of these claims originate from a single individual with an axe to grind).

Indeed classes are great for these kinds of encodings. It is one of the use cases for which classes are the nicest approach in OCaml.

For example, see this section of Real World OCaml:

https://realworldocaml.org/v1/en/html/classes.html#open-recu...

I think I disagree with this. Your functors should generally be pure, and for pure functors applicative is a nicer semantics.

Consider the case of a set implemented as a binary tree. The type of such a set should be parametrised by the type of the elements and the ordering used. With applicative functors this is the case as your set type will be `Set(O).t` where `O` is a structure containing the type and the ordering. With generative functors each individual set type is abstract -- so the type itself is not parameterised by the ordering.

You could consider this to be just an example of what you are calling "Modular Type Classes", but there doesn't need to be a system of implicit module parameters for it to be useful.

Multicore: https://github.com/stedolan/ocaml

Modular implicits: https://github.com/ocamllabs/ocaml-modular-implicits

> the languages that compile to javascript are a poor substitute (bloated code sizes, interop issues, poor runtime performance, etc)

js_of_ocaml has good code size and performance in my experience. Interop with js is variable -- some js libraries are inherently typed and are easy to bind to in a well typed way, others use very dynamic typing and those are difficult to bind.

> The kind of mistakes that good programmers make are not normally caught in code reviews. That's pretty much the definition of a good programmer; their mistakes are rare and subtle.

I think the opposite is true. Good programmers know where the risks of subtle bugs are, and will use the appropriate tools (e.g. good use of a decent type system, well documented code with well designed abstractions) to make completely sure they don't exist.

This just leaves simple stupid bugs in the parts of the code where any such bug will manifest itself quickly and obviously, exactly the kind of thing caught by code review.

Another way to put it would be: good programmers design their code in such a way that all bugs are catchable by code review.

> Also, has anyone ever used gadts to implement type safe syntax trees like that?

I believe the main use is for embedded DSLs. I'm afraid I don't have any practical examples on hand to link to.

> I would say F# is an implementation that includes all the good parts of Ocaml the language

I like F#, but this just isn't true:

- Polymorphic variants

- GADTs

- Module system

The last one, in particular, is one of the best features of OCaml.

Actually OCaml does support recursive types. Recursion through objects and polymorphic variants is always supported, and full recursive types can be turned on with the `rectypes` command-line option.

OCaml has excellent compile-to-JavaScript support. Facebook use this to compile their Hack type-checker for an in-browser IDE. I imagine they do something similar for Flow.

They both seem to produce a new version about once a year, so there's not much difference there.

> This is why unsafePerformIO is unsafe: it’s completely foreign to the programming model

Maybe, although it is also not type safe because Haskell doesn't have a value restriction for polymorphism. (or looked at another way Haskell's value restriction assumes that function application is a value).

Most of these things seem nice but are actually a bad idea. Many of the rest are already implemented or in the process of being implemented. A couple of them are good ideas which are awkward to implement due to politics (e.g. the licence) or backwards compatibility.

Still, I enjoyed reading the post, and it is good to see people looking to improve OCaml and make suggestions.

OCaml's object/class system is actually pretty good. It isn't used very often in OCaml because most of what OO gives you can be more naturally expressed in other parts of the language, but that doesn't mean that it's bad. In particular, classes are still the best mechanism for open recursion in OCaml, and should be used when that is what is required.

I think all the pieces are there to do that (e.g. cohttp, yojson, atdgen, PG'OCaml), although perhaps not in a single easy to use framework.

Maybe http://rgrinberg.com/blog/2014/04/04/introducing-opium/ is relevant.