That is actually why I think Elm should compile to a a different back-end, like ocaml/bucklescript or so. The syntax is uniform enough that making an elm->ocaml/bucklescript transpiler would be just a matter of re-using most of the existing parser in OCaml, which is already beyond blazing fast in comparison. It would significantly reduce elm's compiling time, it would get it to a back-end that has far far more optimizing passes than elm itself does while being substantially better tested, and it would give a method of being able to compile elm to bare-metal for very fast server-side page generation. I'm actually using my elm'y library that I built on bucklescript in my work project (recompilations taking ~100ms compared to the elm project taking over 40s for the same code was the big reason why, reduced turn-around time substantially), but it would be much nicer just to use elm itself built on such a better compiler instead.
And for note, OCaml's compiler is pluggable, you can plug in to many steps during compilation, bucklescript just plugs in to part of that pipeline, reason plugs into a higher part. The highest part is called a 'pp' (pre-processor, bucklescript is a 'ppx' for comparison, reason is a 'pp'), and elm could easily be such an OCaml pre-processor, taking the elm code and massaging it to OCaml's, the whole infrastructure is built for such things, and that combined with elm's versioning (the ocaml compiler can even output interface definitions for files to make calculating this to be trivial) and packaging system would absolutely blow everything else away, especially if you could fall back to OCaml code for things that are difficult or impossible to do on the Elm side. ^.^ On Thursday, January 12, 2017 at 9:25:34 PM UTC-7, GordonBGood wrote: > > On Thursday, 12 January 2017 22:42:05 UTC+7, OvermindDL1 wrote: >> >> On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote: >>> >>> On your advice, I've reread the ReasonML documents as I got mislead by >>> looking at ReasonML/Rebel and that is at too early a stage for me to >>> consider (also support for BuckleScript is currently broken). I liked the >>> ReasonML syntax much better than OCaml as it is more consistent, although >>> it still has curly brackets and semicolons instead of white space delimited >>> block, I can live with that as long as I have before as long as it is >>> consistent. Unfortunately, I can't get the ReasonProject to install on my >>> machine (Windows 10 64-bit) and I am not likely to pursue it at this time >>> as it isn't *that* important to me. >>> >> >> I'm actually not a fan of the Reason syntax myself, I consider it >> horribly verbose and noisy, but then again I've been comfortable with >> OCaml/SML syntax for over a decade now. However correct, Reason has no >> Windows support 'yet' (it is on their roadmap), however bucklescript works >> perfectly with its HEAD right now elsewhere (most of the windows issues >> are, oddly enough, because of npm stupidity actually). Bucklescript itself >> supports windows absolutely perfectly though (I was noisy about it at first >> when it was not ^.^). >> > > Thanks for the input on ReasonML - that explains why I wasn't able to > install it on Windows, and if it is so "noisy" then I probably don't really > want it anyway. Unlike you, I don't have 10 years with OCaml, although I > do have many years with F# pretty much since its beginning which I likely > why I find Ocaml a bit archaic as F# modernized it. Anyway, > Ocaml/BuckleScript is usable to me, and as Hongbo says, will get better. > > >> On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote: >> >>> BTW, I see one of the reasons that BuckleScript produces JavaScript that >>> is so much faster than that produced by Elm: you use JavaScript Array's as >>> the base for almost all of the data structures whereas Elm uses tagged >>> objects, which are very slow (at least on Google Chrome V9/nodejs); it >>> almost seems like the Elm compiler just outputs dynamically typed code with >>> the "all data is just one type - an object with tags" model, although it >>> does recognize that numbers, characters, and strings will be picked up by >>> JavaScript and don't need to be wrapped in a tagged wrapper object. >>> >> >> That is one reason, but not the only one. A bigger reason is that >> bucklescript 'types' the javascript code, such as by putting `| 0` on >> integer operations and such, which allow most javascript VM's (V8 and >> especially Firefox's) to pre-JIT them significantly more efficiently. >> However it has more 'typing' that it can do, which I expect over time. >> > > Yes, I saw the hints BuckleScript adds for the JIT compiler, which have > become a somewhat standard ooutput of transpilers to JavaScript. > > On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote: >> >>> Its too bad you can't apply your compiler optimizations to Elm. Perhaps >>> they could be, as Elm does produce an AST and is a very simple language so >>> presumably the AST is fairly simple too. >>> >> >> Bucklescript does not do the optimizations itself (well it does some >> javascript-specific one like higher arity functions and so forth), most of >> it is OCaml. *However*, you could write an Elm compiler that compiles to >> OCaml (which then could be compiled to native or to >> javascript-via-bucklescript), but the syntax's are so close as it is that >> it would be easier to just write an elm-like library for OCaml instead. >> > > That is something like what Fable has done with its Arch and Elmish > libraries. Personally, I don't have much interest in this as I see using > BuckleScript only as a stop gap to fill in where Elm lacks, primarily for > writing particular kinds of modules where Elm produces code that is too > slow; I would prefer to use Elm as the front end with the promise that > eventually it will produce code fast enough so that the use of BuckleScript > is not necessary other than for the occasion use to write libraries that > need pure JavaScript to work. > > >> On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote: >> >>> As an aside, have you ever looked at using an asm.js back end as current >>> mainline browsers mostly support it, and if so did it make any different to >>> speed? >>> >> >> Actually that is what the typing stuff I mentioned above is, it is the >> asm.js decorations (though not full asm.js, things like '|0' is pretty >> universally supported, plus it is all backwards compatible). I could >> imagine OCaml compiling directly to webassembly later anyway, but for >> working with javascript being able to see the (very readable) output >> javascript via bucklescript is unmatched in usefulness. >> > > Oh, I don't want to dump the JavaScript output as it is very useful to be > able to easily read what the compiler has done; I am just suggesting that > in the future there might be an option for BuckleScript to output pure > asm.js (and even later wasm, of course) and I wonder if there have been any > experiments to show what the gains in speed might be for full asm.js. > > Further to that and improving the Elm output as mentioned above, I don't > quite see why it is such a "huge project" to improve Elm's code generator, > given that the Elm AST preserves type information. The current code > generator is only a couple of thousand lines of Haskell code, and it > wouldn't take that long to re-write the whole thing (a month or two?). One > of the things that make it relatively easy to do this for Elm is that there > are so few allowed types and so few allowed type classes (which can't be > expanded): the type keyword only defines new tagged unions and has no > other use - no classes, no interfaces, thus no methods an all that OOP > complexity, etc. The nice thing about working on the code generator is > that it doesn't affect any other work going on - Drop in a well-tested new > code generator which might produce completely different JavaScript > including a completely different memory model and it doesn't affect any > other module or library. Also, having such a code generator as a model > would get much closer to being able to output pure asm.js or wasm in the > future. > -- 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
