I see that BuckleScript would work fine for JavaScript output and OCaml can be fast, but wouldn't int64 with two int's be a bit slow? It's just that i prefer Haskell syntax and capabilities more than OCaml as it just feels like a more modern language. I do like F# (and thus probabably Fable), but it isn't as pure a language as Haskell. I think I'll see what GHCJS can do for me, once I can get it installed.
On Saturday, 31 December 2016 23:09:18 UTC+7, Bob Zhang wrote: > > For the JS backend, `int` is always int32, we have int64 too which is > simulated by using two `int`. in OCaml float is always double which is > exactly the same as js number. > The cool thing is that OCaml already has a very optimized native backend, > and its type system is much more expressive (on par with Haskell) > > On Saturday, December 31, 2016 at 8:35:28 AM UTC-5, GordonBGood wrote: >> >> On Saturday, 31 December 2016 11:44:10 UTC+7, Bob Zhang wrote: >>> >>> >>> Just for fun, I pasted the same code under BuckleScript playground: >>> >>> >>> https://bloomberg.github.io/bucklescript/js-demo/?gist=efaf57aef9b37a38785681ded0ba35a9 >>> >>> The generated code is below >>> >>> ```js >>> function testProg(n) { >>> var lmt = Pervasives.min(n + 100000000 | 0, 1000000000); >>> var _i = n; >>> while(true) { >>> var i = _i; >>> if (i >= lmt) { >>> return i; >>> } >>> else { >>> _i = i + 1 | 0; >>> continue ; >>> >>> } >>> }; >>> } >>> ``` >>> Note that BuckleScript compiler is able to do type specialization for >>> generic comparison, also it heavily optimized curried calling convention >>> >> >> That's interesting; Ocaml is quite a good syntax; this main thing I have >> found wrong with it in the past is how few primitive types it has, as int >> Int is 32 bits on 32-bit platforms and 64-bits on 64-bit platforms; >> actually less then these as there are tag bits. Going by the try site, >> this is still true true; this might not affect it's use for BockleScript so >> much as most things are going to get converted to JavaScript Number's >> anyway, but one might be forced to use floating types more often then >> really required and there still is no way to represent primitive unboxed >> 32/64 bit integers natively. >> >> On Monday, December 26, 2016 at 12:44:49 PM UTC-5, GordonBGood wrote: >>>> >>>> *Synopsis:* Some, including Evan, maintain that Elm can be "faster >>>> than JavaScipt". While that may be true for some use cases including use >>>> of perhaps more efficient UI updates due to compartmentalized use of >>>> VirtualDOM, the actaul Javascript code generated by the compiler is not >>>> very efficient for many/most tight code cases. The reason is often >>>> unnecessary nested function calls that could easily be eliminated by >>>> making >>>> full use of the type information that the Elm compiler has. >>>> >>>> Part I >>>> >>>> *An example;* The following tight loop doesn't really do anything, so >>>> should therefore compile into the very tightest of code (and I'm not >>>> expecting the Elm compiler to recognize that the result is actually known >>>> at compile time): >>>> >>>> range : Int >>>> range = 1000000000 >>>> >>>> testProg : Int -> Int >>>> testProg n = -- do some work >>>> let lmt = min (n + 100000000) range in >>>> let loop i = >>>> if i >= lmt then i else >>>> loop (i + 1) in loop n >>>> >>>> which compiles to the following JavaScript: >>>> >>>> var _user$project$Temp1482759649866537$range = 1000000000; >>>> var _user$project$Temp1482759649866537$testProg = function (n) { >>>> var lmt = A2(_elm_lang$core$Basics$min, n + 10000000000, >>>> _user$project$Temp1482759649866537$range); >>>> var loop = function (i) { >>>> loop: >>>> while (true) { >>>> if (_elm_lang$core$Native_Utils.cmp(i, lmt) > -1) { >>>> return i; >>>> } else { >>>> var _v0 = i + 1; >>>> i = _v0; >>>> continue loop; >>>> } >>>> } >>>> }; >>>> return loop(n); >>>> }; >>>> >>> -- 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.
