On Wednesday, 11 January 2017 23:20:24 UTC+7, Bob Zhang wrote:
>
> Hi Gordon, thanks for your summary.
>     Just want to add that BuckleScript compiler is only developed for one 
> year, now I almost work full time on it (thanks to my employer), so you 
> would expect more performance boost coming soon.
>

Hi Hongbo, That you've gotten this far in only a year is incredible; the 
project should be amazing after another year!
 

>     Personally, I don't  mind any syntax, I am a huge fan of common lisp 
> so you can tell. But I understand syntax does matter to quite a lot of 
> people, so you may be interested in checking out ReasonML by Facebook(a 
> more familiar syntax for OCaml). OCaml is a very modular compiler which has 
> 7 IRs,  ReasoML compiles to IR 0, while BuckleScript takes it from IR 4, so 
> the combination of ReasonML and BuckleScript is seamless.
>

 I used Scheme for a year but stopped because I grew to dislike dynamic 
typing even more intensely than I did before for anything other than quick 
one-off projects; I got used to block brackets, but that is not to say I 
ever liked them!

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 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?

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.

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.

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?

Regards, Gordon

-- 
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.

Reply via email to