Skip to content
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

Open
khoerling opened this issue May 14, 2018 · 4 comments
Open

ReasonML #249

khoerling opened this issue May 14, 2018 · 4 comments

Comments

@khoerling
Copy link

Any integration point in the future? If Alpaca mirrored ReasonML or Ocaml syntax, Bucklescript would also become a compile-to target alongside BEAM.

@j14159
Copy link
Collaborator

j14159 commented May 14, 2018

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)

@lpil
Copy link
Contributor

lpil commented May 15, 2018

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

@OvermindDL1
Copy link

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... >.>

@kamilchm
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants