On Friday, January 13, 2017 at 8:40:07 AM UTC-7, Rupert Smith wrote: > > All that this would take would be to write an Elm parser into the first > stage of the OCaml pipeline? You'd also need to compile the Native modules, > is there already some way to feed them into the Ocaml pipeline? >
There are 2 first stages depending on how you look at it. The real first-first stage is not so much as a compiler plugin as it is just a generic pre-processor, things like Caml4p(sp?) are this, in a high level over-view: ```sh ocamlc -pp myPP ... ``` Although using a normal build system (bucklescript 'bsb' is fantastic!), but think of `myPP` just as a normal binary, you pass in file contents (source code) via STDIN and it passes back out changed text via STDOUT. It is basically the same as preprocessing each file to another directory then compiling 'those' with ocamlc (except faster since ocamlc gets information from it and keeps it loaded. A 'ppx' is an actual compiler plugin, passed the same way: ```sh ocamlc -ppx myPPX ``` It is also basically a binary that operates in the same way as above, except it operates on the OCaml AST at various stages in the pipeline (whatever hooks you register, you can have multiple), it translates the AST and returns the altered AST so the compiler continues on. Bucklescript plugs late in the compiler to take the AST and output it to javascript for example. Reason is a preprocessor only as it uses non-ocaml syntax (it outputs OCaml syntax). Elm on OCaml would just be a preprocessor as well (potentially with some ppx's as well if you want to add some compilation pass stuff), all of which would be handled by the build system of course. Basically bucklescript as an example has a few files like 'bsc' and 'bsdep' and 'bsppx' and such, the bsppx is the actual ppx that handles some pass transformation, bsc is the actual compiler (which just wraps the ocaml compiler while adding bucklescript transformers), etc... The file 'bsb' is the build system (built using the fast Ninja build system) that handles the json file that defines a bucklescript project to automatically handle everything as a build system should (its version of elm-make you can think of it as). Elm could comparatively easily become a preprocessor with its own wrappers to handle its building, the interaction with elm would remain the same, it would just become significantly faster in compilation and execution speed while opening it up to native compilation as well (or if you use node just compile out via bucklescript to node as normal there as well). This way elm remains the tight, highly focused language specific for this purpose, but you could even make normal OCaml code that calls into Elm or vice-versa (an elm layer could enforce that any function that elm code calls out to is 'pure' for example, or not, whatever). -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
