On Monday, 16 January 2017 21:09:43 UTC+7, Rupert Smith wrote: > > On Saturday, January 14, 2017 at 1:51:39 AM UTC, GordonBGood 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? >>> >> >> Elm "Native" libraries are JavaScript, and that is what BuckleScript >> does: as well as output JS code, it also has JS FFI to allow BuckleScript >> code to call to/receive calls from JS code. I think this would be handled >> by an Elm PP just as OCaml handles FFI references - leaving FFI blanks to >> be later "filled in" by later passes. >> > > Yes, that is what I was getting at. If you compile Elm -> Ocaml -> > Javascript, then the Native stuff in Elm just gets copied into the output > javascript directly (unless of course passing it through Ocaml is > worthwhile and can optimize it). But if you are going Elm -> Ocaml -> > native x86_64 binary, then the javascript needs to be compiled through > Ocaml. So I was just wondering if the Ocaml tool-chain already has a > javascript front-end for it? >
BuckleScript is an OCaml to JavaScript back end, and we were talking about the possibility of an Elm pre-parser/front end to OCaml in order to get more efficient JavaScript code from Elm source than the current Elm compiler can produce; although this is possible, it would still take up to a year for someone to code and test it. Even though somewhat time consuming, the above isn't that hard because Elm is both a simpler language than OCaml and its features are generally just simpler subsets of OCaml features. Writing a JavaScript front end for OCaml would be an ambitious undertaking because JavaScript does not resemble OCaml in the least and there wouldn't seem much point: One would have the slow compile speeds of Elm plus the compilation of JavaScript to OCaml to more efficient JavaScript through BuckleScript As to the possibility of generating machine code output, again there doesn't seem to be much point as that is not Elm's purpose and one would be better to use OCaml or some other similar language directly. In general, compiling a statically typed language such as Elm or OCaml to a dynamically typed language like JavaScript isn't so hard as the compiler front end just enforces static type checking and lets the dynamic language run time do its dynamic typing again but going the other way wouldn't make much sense, so I doubt there is a JavaScript front end for OCaml. The ReasonML front end/pre-parser also just takes OCaml-like code that is more consistent and perhaps more easily readable and turns it into OCaml code, but that it relatively easy as they are similar. However, even that has taken about a year thus far. -- 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.
