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.
This process seems to intentionally cut off upstream from having input into the design of the features during development when there's still a chance to change it. What happens when you implement something that you like, release it internally, but then it turns out upstream doesn't like it or wants it a different way? Will you maintain your feature on your fork forever (thus JaneStML), or will you abandon your feature? Is the thought that, honestly, this will never happen given Jane Street's track record in the community and the level of battle testing that this process brings to the design process?
Another possibility is to change the design based on upstream feedback and adjust the internal codebase to it.
By parent’s description, those codebase adjustments are done during the iterative process of feature development too. Upstreaming would just be the last iteration.
As someone from the community, I absolutely love this design (and blog post). It would be especially great for returning options, tuples, results, etc. with no overhead at all.
I suppose it could also be useful to allocate int64, floats, and maybe even bigints on the data stack? I suppose it's more difficult to put C blocks like bigints or bigarrays in a region.
> should either be self-explanatory or memorable -- so that once they have been explained they aren't forgotten
For years I've had a pet, personal theory on the hierarchy of naming; and these were my first 2 "levels". I never heard anyone else ever blurt it out in these terms. (My thought was that I was weird, or it was just so obvious that no one ever needed to.)
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.
Will we also get dead code elimination generally speaking in the compiler? I remember a mailing post where one of the flambda devs announced he managed to generate standalone hello world of 43k but that was just a PoC.
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:
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/