Interoperability with Reason (ReasonML)

[dannywillems]

Some months ago, Facebook released Reason which aims to easily switch to OCaml by implementing a syntax extension close to other popular languages and it gains rapidly in popularity. To compare to OCaml, since the realease, they are more stars on the Reason GitHub (more than 1800) than OCaml (around 1000) and Reason has a very huge community.

And the entire Ocsigen project (Eliom, TyXML, JSOO, Ocsigen-start, ...) must have a place in this community. The Ocsigen framework has a lot of concepts which are implemented in any other languages.

I think a collaboration between the Ocsigen and the Reason teams will be a great opportunity and a chance for both, and for both communities.

@balat Yesterday, you said you wanted more ocsigen-start users: it's a real opportunity, even for Be Sport (because more collaborators).

I hope this issue can be a place to discuss about it and begin a collaboration to make Ocsigen and Reason better.

[Drup]

cc @chenglou @jordwalke :p

Would be interesting to have a rebuild-ocsigen thingy. The build aspect has always been a mess in eliom, that could help quite a bit.

The other point is the various syntax extensions we have (in particular the eliom one) but afaik, ppx works just fine in reason, so that should not be an issue.

[dannywillems]

Maybe also cc @sanderspies and @yunxing (based on contributions)?

[jordwalke]

Cool idea. All ppx extensions should work in Reason, and if you find any that don't, it's a bug and should be fixed.

Is there a place for Reason's new (but experimental) JSX implementation? It allows concrete syntax of XML - which merely translates into named argument function calls.

<thisRightHere argOne="hi"> <child /> </thisRightHere >

Becomes:

thisRightHere argOne::"hi" [child]

Or OCaml's

thisRightHere ~argOne:"hi" [child]

[Drup]

As you know, we already have an html api (https://github.com/ocsigen/tyxml/) and an associated PPX. The API looks like this:

element ~a:[attr] [child]

There are various typing reasons for having this a argument for all the attributes, and changing it would break compat with a lot of things, so that's not really reasonable. We could have an overlay to expose an API such that JSX works. That would be a lot of work though.

[jordwalke]

We can also change JSX as well, if needed -I'm just curious if one approach is fundamentally better than the other. If tyxml is doing something better, we could change JSX to match. But as it stands, I really enjoy named arguments for things you'd normally use "XML" syntax to represent, because it prevents passing an attribute twice. Aren't OCaml's labeled arguments also optimized such that (unless using the partial application), it calls the function immediately without going through all the intermediate partial applications/allocations?

I think in the case of HTML, it might end up being more efficient to do it via the Tyxml way because 95% of all the arguments are never specified, so the functions would end up being invoked with a bunch of None None None None ... arguments for all the attributes not specified. I think the JSX approach works better for custom components (like <MyWidget user=joe />) which typically accept far fewer "attributes".

I'm just trying to get your thoughts on which is better and in which cases.

[Drup]

Tyxml can be seen as a (generic) typed overlay over untyped arbitrary XML implementations. The goals are 1) type safety 2) genericity 3) low overhead over the XML implementation. Keeping that in mind:

• Named argument would make the implementation a lot larger (and it's already far too large). Currently, we can drop to the untyped implementation of star (Xml.attr list -> Xml.elt list -> Xml.elt) for most elements directly, and when we can't, the code is short and simple. Having named argument would mean we have to coalesce attributes into a list, being mindful of absent attributes. It's not complex, just requires some code (and it would be more costly too).
• The treatment of elements would be less generic. If you look at tyxml, you can see elements split in 3 categories. Given we can't really talk about arbitrary variadic functions (especially not labeled one ..) in OCaml, that would be difficult.
• Attributes are first class in tyxml (you have a type 'a attrib and can get values of it). This is occasionally very useful. In particular you can make arbitrary attributes reactive with combinators like Tyxml_js.R.filter_attrib.
• As a general rule, labeled and in particular optional argument work very very badly with high order functions.

So, what I'm saying is that it would be a lot more effort to make tyxml with optional arguments, and tyxml is complicated enough. :p The flip side of all that, of course, is that the API is less convenient/more verbose, as you said.

Aren't OCaml's labeled arguments also optimized such that (unless using the partial application), it calls the function immediately without going through all the intermediate partial applications/allocations?

If you mean optional arguments, no they are not, it uses an option type underneath. If you mean regular labels, it's exactly equivalent to function application.

[Drup]

Side note: I didn't made that choice, it was already like that when I started working on ocsigen. I just think that, given the constraints, it's a decent choice :)

[jordwalke]

If you mean optional arguments, no they are not, it uses an option type underneath.

No I just meant labeled arguments in general. I understand that the optional ones become None/Some x.