On Monday, January 23, 2017 at 6:27:47 PM UTC-7, GordonBGood wrote:
>
> The reason is that BuckleScript proves that Arrays are faster than
> "string" tagged objects and I have tried benchmarking it myself. In fact,
> I have gone further and manually substituted the use of Arrays rather than
> the string tagged objects in the generated Elm code to show that is the
> reason. The problem isn't so much the use of Array's versus
> objects/records, but the string tags, which as the Elm JS output doesn't
> preserve type information except by these tags, are continuously requiring
> string processing to determine the type of object at run time. Elimination
> of these strings by using the type information the compiler already has
> would greatly speed things even if objects are used, with the further
> advantage of Arrays being that their indices are numeric for slightly less
> processing (depending on the browser engine used).
>
That should not actually be a big difference. String comparisons in
javascript on V8 (and I think Firefox's and Edge's) javascript engine(s)
using `===` are pointer comparisons, and as strings are interned that makes
it very fast, a pointer comparison in the general post-JIT case, which
should be equal to integer comparisons. What is different is using an
array instead of an object, most JIT's will allocate it a tiny bit faster,
but again in the general case there is not much difference.
On Monday, January 23, 2017 at 6:27:47 PM UTC-7, GordonBGood wrote:
> Yes, Elm is fast enough for many purposes. Tree shaking programs such as
> the Google Compiler reduce code size. Compile time is currently adequate
> for many uses, although slow compared to something like OCaml/BuckScript
> that has been expressly optimized for compile speed.
>
Actually tree shaking will do absolutely nothing for Elm code as Elm
compiles everything into a single module that all highly indirectly
references itself. It would help with bucklescript as it outputs modules,
but bucklescript already tree-shakes as part of its compiler optimizations
anyway.
On Monday, January 23, 2017 at 6:27:47 PM UTC-7, GordonBGood wrote:
> I am not really promoting the use of OCaml/BuckleScript which has its own
> warts (currently) although Hongbo has done an incredible job with it: I
> dislike Ocaml except as it closely resembles Elm/Haskell/F#. My point is
> that for those of us that need speed - at least a few that have chimed in
> on this thread - if it isn't addressed with the Elm compiler then Elm might
> migrate to a front end to OCaml which would schism development efforts and
> possibly hurt the language.
>
Well, as a language I like a lot of things in OCaml, doing a 'plugin'
system, as was in my old project, in it is trivial and simple by using
things like polymorphic variants, where-as doing the same in Elm was...
highly painful and excessive in code. ^.^
Overall Elm's simplicity is nice, and for example I'd never want OCaml's
object system in it, although having OCaml's module system (with built-in
implicit module support) would be fantastic for abstracting things better
(and it compiles significantly faster than typeclasses or HKT's). :-)
On Monday, January 23, 2017 at 6:41:55 PM UTC-7, GordonBGood wrote:
>
> On Tuesday, 24 January 2017 01:26:49 UTC+7, OvermindDL1 wrote:
>>
>> Bucklescript de-curries as much as possible, however you can also force
>> it in the type system explicitly by adding the annotation type of `[@bs]`
>> to a function (type) definition, that enforces uncurrying at the type level
>> and will even propagate in usage as expected to make sure accidental
>> currying of it is not done (though you can still explicitly curry it by
>> wrapping it in a curried type). In most cases it de-curries very well and
>> you never need to use `[@bs]` (the only real time I've used it is on DOM
>> callback registrations with more than one argument to make sure I do not
>> accidentally pass a curried version to one, never used it in 'user' code as
>> of yet).
>>
>
> Yes, I've used the {@bs} notation, usually on very low-level code to force
> no currying (or passing of any arguments); as you say BuckleScript is very
> good of determining an appropriate use of currying. If one were to use an
> Elm front end to OCaml/BuckleScript, it would be nice to add the ability to
> inject these macro-type annotations into the code, probably as a specially
> formed comment, so that in effect we could write all the Native code
> modules in the high level environment, which works very well in
> BuckleScript.
>
It would not be hard, however I'd think it would also be entirely
unnecessary. Leaving currying between those layers would allow for more
optimizations.
On Monday, January 23, 2017 at 6:41:55 PM UTC-7, GordonBGood wrote:
> One thing that BuckleScript does by default that breaks type safety is not
> do array bounds checks, but that wouldn't be a problem for an Elm front end
> as Elm does not use (mutable) arrays directly.
>
The `Array` calls do bound checks, just OCaml is an exception'y language
(the `option` type is newer than the language itself, and `Array` has been
in since the start) so they will throw an exception if out of bounds.
There are option variants of those calls that you can use though. And
using the 'list' type over the 'array' type is what most people would
always do anyway.
--
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.
