-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ReasonML #249
Comments
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) |
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 |
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... >.> |
https://github.com/kjnilsson/fez is similar attempt but with F# as source language. |
Any integration point in the future? If Alpaca mirrored ReasonML or Ocaml syntax, Bucklescript would also become a compile-to target alongside BEAM.
The text was updated successfully, but these errors were encountered: