ReasonML about alpaca HOT 4 OPEN

Not explicitly tbh. I'm not particularly opposed to either but it will depend on which way we jump/how we implement things like algebraic effects and a signature-module system. I think both of those are pretty important to include at some point and I would be reluctant to restrict or contort our syntax for the sake of compatibility. My prolonged inactivity here is mostly due to me struggling with the related papers for these things (and probably getting too lost in some details, if I'm honest 😄 )

Having said that, it would probably be relatively simple to make a ReasonML parser that outputs Alpaca's AST. Messages and processes might be a bit of a wrinkle but maybe not severe? (I may be underestimating the required effort)

from alpaca.

It would take more than adopting the syntax, OCaml/Reason and Alpaca are semantically different languages.

If I were to put OCaml on the BEAM I'd probably go down the path that Bucklescript did with OCaml -> Javascript and write a new backend for the compiler that compiles the Lambda intermediate representation into Erlang or Core Erlang. I had a little play with this here, but I really needed more OCaml knowledge to make good progress -> https://github.com/lpil/erlcaml

from alpaca.

js_of_ocaml takes the bytecode representation and converts it to Javascript, thus it's method is lower level and generates ugly code, but it can generate fast code while being able to handle anything and everything regardless of PPX's and all.

Bucklescript, on the other hand, uses a mixed-representation (and because of that it has to rewrite parts of the compiler instead of just being a plugin to it) that allows it to retain some typed information, but it also means that some PPX's cannot be used.

js_of_ocaml's method might be too low level, as by the time of bytecode the type information is gone and it is handling direct access of things like byte arrays.

Bucklescript's method is way too far in my opinion, it could still be done by a middle-layer PPX compiler plugin, though depending on the level you choose is a balance between full PPX support or full Type information.

It 'might' be possible to bytecode level to the BEAM, easier so if you happen to exempt a construct or two as well... >.>

from alpaca.

https://github.com/kjnilsson/fez is similar attempt but with F# as source language.

from alpaca.