search

leostera / caramel

:candy: a functional language for building type-safe, scalable, and maintainable applications
https://caramel.run
Apache License 2.0
1.05k stars 25 forks source link

Support Reason syntax too #18

Closed leostera closed 3 years ago

leostera commented 3 years ago

That's it. Just bring in the Reason parse transform onto the pipeline.

nicobao commented 3 years ago

As mentioned on Discord, I start looking at it!

nicobao commented 3 years ago

I am working on using refmt programmatically to convert reason source code to ocaml before proceeding to compile it to Erlang.

However, I am wondering how that can work out with Reason-flavored Caramel IDE support.

How can we provide decompiling tooling referencing the original source code if we lost this information in the first place by using refmt?

I mean, for regular Reason support, we can rely on standard Merlin and the OCaml/Reason LSP.

However, what about supporting seamlessly usages of Erlang code in Reason-flavored Caramel (find-references, go-to-definition)?

If necessary, Reason also compiles to the very same parsetree representation, so we could use that.

EDIT: indeed, even for regular reasonML support, Merlin wouldn't be sufficient. Caramel is a subset of OCaml/Reason, so when using unsupported native OCaml/Reason functionalities, the user should see warnings telling him the code cannot be compiled to Erlang and would be compiled natively and run as NIF/Port instead (or just an error if that fallback option is also not possible).

EDIT 2 : I am uncertain how Reason is compiled to parsetree at this point. Is it parsed back to OCaml before being compiled? From what I've read, it seems not.

leostera commented 3 years ago

Hej @nicobao, it'd be useful if you could open a draft PR and we can look at some code together there as well.

Keep in mind that we want to ship a single executable that has no dependencies, so we will need to use the reason opam library instead of calling out to any binaries. My guess is that there is a string -> (parsetree, error) result function in there that we should use, and that function will error on syntax errors and know to present feedback to the user.

This of course means errors will be uncontrolled right now, but that's okay for now.

Regarding tooling support, I've opened #41 so we can star tracking a few things more cleanly there.

nicobao commented 3 years ago

Hi @ostera!

Of course, that is what I am doing (reason dependency) :). I will send a draft PR whenever I have something workable!

Nicolas

Le jeu. 21 janv. 2021 à 23:27, Leandro Ostera notifications@github.com a écrit :

Hej @nicobao https://github.com/nicobao, it'd be useful if you could open a draft PR and we can look at some code together there as well.

Keep in mind that we want to ship a single executable that has no dependencies, so we will need to use the reason opam library instead of calling out to any binaries. My guess is that there is a string -> (parsetree, error) result function in there that we should use, and that function will error on syntax errors and know to present feedback to the user.

This of course means errors will be uncontrolled right now, but that's okay for now.

Regarding tooling support, I've opened #41 https://github.com/AbstractMachinesLab/caramel/issues/41 so we can star tracking a few things more cleanly there.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AbstractMachinesLab/caramel/issues/18#issuecomment-764981754, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALBYMI6USL7HVI3BQ73JNG3S3CS5XANCNFSM4SYHJQZQ .

nicobao commented 3 years ago

Question: shall I support both reason -> erlang (AST) and reason -> Core Erlang? Are we decided onto one path to compile to Erlang? I have 0 experience regarding this so obviously, it's your call @ostera. I am curious about your experience. I read this https://github.com/rvirding/lfe/issues/361 and that https://elixirforum.com/t/whats-the-main-reason-that-elixir-chooses-to-compile-to-abstract-format-rather-than-core-erlang/36370/3 so I guess the way to go is Erlang abstract format, which is reason -> erlang in caramel, isn't it?

nicobao commented 3 years ago

Also, for .mli files, native OCaml compilation is currently used: Optcompile.interface as seen here https://github.com/AbstractMachinesLab/caramel/blob/main/caramel/compiler/compiler.ml#L52 I suppose, I'd just use the equivalent method for reason rei files, as of now? What does Optcompile.interface do actually? I still haven't found the exact Reason equivalent.

leostera commented 3 years ago

Sorry, I missed these comments. 🙈

We should get one path up first, so Reason -> Parsetree -> Typedtree -> Erlang AST should work fine.

Once you have the Typedtree, the Optcompile.interface will be the same for .rei and .mli -- this function creates the .cmi files that OCaml uses for type-checking.

re: the quotes & core erlang support, it is likely we'll have to invest more time into that later on if we want to generate code that can be idiomatically used both from Erlang and Elixir. Or eventually provide an Elixir compilation target! I'd prefer if we didn't, so that we could also find nice ways to interop with Gleam that don't require generating Gleam code.

Caramel just can't afford to generate code in all beam languages after all