lpw25

vor 3 Jahrendiscuss

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/

lpw25

vor 3 Jahrendiscuss

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/

lpw25

vor 3 Jahrendiscuss

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.

lpw25

vor 10 Jahrendiscuss

> OCaml (concurrency isn't the best)

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

lpw25

vor 10 Jahrendiscuss

Modularity

lpw25

vor 10 Jahrendiscuss

> 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.

lpw25

vor 10 Jahrendiscuss

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.

lpw25

vor 10 Jahrendiscuss

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.

lpw25

vor 11 Jahrendiscuss

> 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.

lpw25

vor 11 Jahrendiscuss

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.

lpw25

vor 11 Jahrendiscuss

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.

lpw25

vor 11 Jahrendiscuss

Functors => higher-kinded types

lpw25

vor 11 Jahrendiscuss

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

lpw25

vor 11 Jahrendiscuss

> 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.

lpw25

vor 11 Jahrendiscuss

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

lpw25

vor 11 Jahrendiscuss

> 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).

lpw25

vor 11 Jahrendiscuss

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...

lpw25

vor 11 Jahrendiscuss

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.

lpw25

vor 11 Jahrendiscuss

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

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

lpw25

vor 11 Jahrendiscuss

> 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.

Submissions

Simplifying 0install's solver with OCaml's functors

H.261 decoder in OCaml, compiled to JavaScript

comments