
A set of efficient persistent immutable data structures for Reason and OCaml - gfosco
https://facebookincubator.github.io/immutable-re/
======
Drup
Oh, great, yet another library of data structures that introduce incompatible
abstractions with both the standard library and the 3 other big libraries of
data structures[1,2,3], that is exactly what the OCaml ecosystem needs! :D

More seriously, though, at least the naming convention is consistent. It looks
a bit heavy on signature-indirection. I would really prefer if they used a
standard iterator (gen[5] and sequence[6], for example, or the future one in
the stdlib[7]) and settled for one serialization method (such as sexp) and get
formatters everywhere.

Also, please use ocamldoc or odoc[4] for your documentation. The one generated
here is really terrible, even for OCam^W Reason standards.

[1]: [https://github.com/c-cube/ocaml-
containers/](https://github.com/c-cube/ocaml-containers/) [2]:
[http://batteries.forge.ocamlcore.org/](http://batteries.forge.ocamlcore.org/)
[3]: [https://github.com/janestreet/base](https://github.com/janestreet/base)
[4]: [https://github.com/ocaml-doc/odoc/](https://github.com/ocaml-doc/odoc/)
[5]: [https://github.com/c-cube/gen/](https://github.com/c-cube/gen/) [6]:
[https://github.com/c-cube/sequence/](https://github.com/c-cube/sequence/)
[7]:
[https://github.com/ocaml/ocaml/pull/1002](https://github.com/ocaml/ocaml/pull/1002)

~~~
bordoley
Hi Drup,

The intent of Immutable-re is to provide a complete set of persistent
immutable collections that complement the standard library and core. The
initial release is limited to common Map, Set, and Vector types, but we have
intent to add additional collections such as BiMaps, Multisets, and Multimaps.
There is of course some overlap with the stdlib collections (SortedSet vs.
OCaml Set, SortedMap vs. OCaml Map) but even in these cases, the Immutable-re
implementations have slightly different characteristics from their stdlib
counterparts, which provide added value.

The public API is designed to be very Reason like, and familiar to web
developers with experience in JavaScript, Java and C#, hence the naming
conventions and camlCase. I've also considered adding an OCaml compatibility
layer, which provides a more familiar API for OCaml developers. While the
public API itself is heavily dependent upon signature indirection, these
signatures are purely for documentation and not heavily depended upon within
the implementation, which means the OCaml compat API may not include them at
all.

Regarding the choice of APIs for sequences, the current Sequence type is
intentionally opaque and is internally designed to be compatible with the
proposed standard OCaml Sequence
([https://github.com/ocaml/ocaml/pull/1002](https://github.com/ocaml/ocaml/pull/1002)).
If/when, that PR lands, we will switch our internal implementation to be
compatible with OCaml's while maintaining the same public API.

Finally you are completely correct regarding documentation generation.
Unfortunately refmt does not currently support outputting OCaml mli files
including comments. This left me with the choice of hand rolling docs as I did
or shipping ocamldocs lacking any comments explaining the types and functions.
I chose the former.

Thanks for your feedback.

~~~
Drup
Well, multisets, multimaps and a lot of other things are also provided in
containers and core. It's nice that you (already!) adopted that style of
iterator.

I'm not sure what an "OCaml compatibility layer" would mean. It's already
OCaml-y: it's referentially transparent and full of functors and signatures!
The main weird thing is that the type of compare is not the same (I understand
why, but I find compatibility more valuable). The naming convention matters
little, as long as it's clear, readable and consistent (OCamlers are not going
to boycott a library because it uses camlCase).

I don't think the signature indirection is a real problem, you just need a
good tool for documentation generation that inlines signatures. You can ask
the odoc people, I'm sure they would be happy to help you. I'm surprised there
is no "reasondoc" tool just yet. :)

------
kornish
Question for jordwalke or any Facebookers around: how's Reason's adoption
inside of Facebook relative to OCaml? The hypothesis around the syntax seems
to be that it's more approachable for Javascript programmers – are you noting
a significantly faster onboarding time?

~~~
jordwalke
The feedback we've gotten from web developers is that it's easier to learn,
and the integration that we've done for web makes it much easier to be
instantly productive. Many say they would have not even taken a look at OCaml
if there wasn't a group of developers caring about improving the overall
ergonomics and front end experience.

"relative to OCaml".

Many people don't know, but a ton of Facebook's critical infrastructure has
been developed on OCaml for a long time: projects such as Infer, Hack, Flow
and many others. So there's a ton of existing projects that might be hard to
catch up to in the short term and thats okay in my mind, because those
projects are using the right tool for the job at hand. Even though the syntax
they use might be a little more off-putting to new contributors, I think
they're getting the big things right. One benefit to Reason is that it stands
to make sure that more developers who are starting new projects, get the big
things right - syntax is just one of many means to that end.

We want to fully interop with the OCaml ecosystem and we go through great
lengths to ensure that Reason can be used with any OCaml project. I would love
to focus even more on that once the ReactJS story is in a really good place.

~~~
jordwalke
The most common (constructive) feedback we currently receive is that once
people want to dive into some advanced stuff, they need more material than the
brief tutorials, and the primary book is written in OCaml syntax / toolchain.
I would love it if we could have custom Real World OCaml "renditions" that
allow custom automated presentation of syntax in the online book, as well as
some focus on web development workflows.

~~~
tekknolagi
Isn't there a Chrome extension that automatically converts OCaml snippets to
Reason syntax?

~~~
jordwalke
I believe so, but IIRC, it's not possible to use it on Real World OCaml. Also,
for something as core as a book, it's worth being able to custom tailor some
things including the code generation, and some extensions to the book that
focus on specific use cases like getting setup for web development etc.

~~~
Flow
Maybe they'll consider forking the book into "Real World Reason"? It's quite a
great name for a book.

------
ubercow
Is anyone here using Reason in any meaningful way? Even just a side project.

If so, what are you using it for and how do you like it.

~~~
kornish
Not using it, but jumping in to share an anecdote –

I saw the Reason announcement months and months ago and decided to use it as a
jumping-off point into the OCaml ecosystem. It took about a week of writing
Reason before I realized I was spending so much time reading OCaml (all the
libraries were written in it) before I just switched to OCaml proper. Haven't
looked back - the syntax takes a few days to pick up, but is hardly the most
difficult part of writing a program.

Hopefully they can capitalize on the "Build" and "Share" part of their value
prop [0] because "Syntax" appears (to most) to be the least valuable
improvement. As a disclaimer, I could be totally wrong, never having worked at
a FB-size organization – that onboarding time probably adds up quickly.

Come to think of it: can anyone think of a successful transpiled language that
doesn't actually provide new semantics? Coffeescript is the closest thing that
comes to mind, but it's dying out as ECMAScript absorbs its most appealing
features.

[0]:
[http://facebook.github.io/reason/#reason](http://facebook.github.io/reason/#reason)

Edit: forgot about Elixir, which seems to be doing quite well – but that
introduces new semantics like homoiconicity + macros and protocols.

~~~
cies
There's some neat stuff in the Reason syntax, apart from the make-it-less-
weird-for-those-coming-from-JS/Java/C#/etc., for instance: JSX[0] and named
curried functions[1]. Both are fitting in really nice when doing FE dev't like
with `react-reason`[2].

If you are interested in this, I recommend some talks. First one by Cheng Lou,
a main contributor of Reason and FB employee on React Conf 2017[3]. And a talk
by Sean Grove[4] on Reason in general.

With the power of FB behind this new techonolgy (they have currently written
25% of messenger.com in Reason), this might well become very big. A general
purpose strongly typed functional prog lang, that has a vast ecosystem, now an
approachable syntax, and compiles to both native and JS. Sounds good nuh?

[0]: [https://facebook.github.io/reason/#diving-deeper-
jsx](https://facebook.github.io/reason/#diving-deeper-jsx)

[1]: [https://facebook.github.io/reason/#diving-deeper-curried-
fun...](https://facebook.github.io/reason/#diving-deeper-curried-functions)

[2]: [https://github.com/chenglou/reason-react-
example/blob/master...](https://github.com/chenglou/reason-react-
example/blob/master/src/todomvc/app.re)

[3]:
[https://www.youtube.com/watch?v=_0T5OSSzxms](https://www.youtube.com/watch?v=_0T5OSSzxms)

[4]:
[https://www.youtube.com/watch?v=8LCmLQ1-YqQ&t=517s](https://www.youtube.com/watch?v=8LCmLQ1-YqQ&t=517s)

~~~
thedufer
Can you explain how named curried functions differ from ocaml's named
arguments? It looks exactly the same, other than the syntax.

~~~
chenglou
They are the same. I don't think cies was implying they were different.

~~~
thedufer
The wording seems to pretty clearly say otherwise, but I appreciate the
confirmation that I'm not missing anything.

