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 ^.^). However, I can see how you'd like the Reason syntax better, but do not discount the OCaml syntax. The nice thing about the OCaml raw syntax is it is not only blazing fast for the compiler to parse, but also for a human to parse as well, you know what things will be once you learn it, and it is very simple. On Wednesday, January 11, 2017 at 10:43:11 PM UTC-7, GordonBGood wrote: > I understand that if I were able to install it, by "working seamlessly > with BuckleScript", you mean that the "bsb" command will just take the > output of the previous ReasonML build as its input to produce JavaScript? > Actually Reason's build system can choose bucklescript as its output directly, it has first-class support. However you could indeed translate reason -> ocaml -> bucklescript pretty easy anyway. 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 person, 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. However yes the array's are more efficient, and it matches what OCaml itself does (array's of bytes to store data). 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. 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. -- 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.
