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.
