Why are Enums and Tuples implemented with objects?

[Robin Heggelund Hansen]

I see that tuples and enums are implemented using javascript objects. I'm trying to understand why this is. I assume an array would both produce less code and be faster.

Just x is currently compiled down to: {ctor: "Just", _0: 0}

But could just as well have been compiled down to: ["Just", 0]

Same with tuples: ["Tuple2", 0, 0]

I assume there is a good reason that I'm not thinking of yet, given the high level of quality otherwise found in Elm.

[Ryan Rempel]

An interesting question!

I don't know the answer.

However, I do think your alternative would (without more) make it more difficult to implement `toString` and `eq` in `Native.Utils`. That's one of the few places where Elm does rely on just a little bit of deduction about types at run-time. For instance, those functions treat `Json.Encode.Value` differently than a tagged union type. Whereas in your alternative, you couldn't really tell at run-time between the two. Of course, normally you don't need to know anything about types at run-time (because functions will be given the types they expect). However, `eq` and `toString` are (rare) examples where it does make a difference.

Of course, it's not an insoluble problem, but the strategy for `eq` and `toString` would at the very least need to change.   

[Richard Feldman]

I would not be surprised if this implementation has better performance. I remember assuming that JS arrays would be a better representation for tuples in a past project (circa 2012), went way out of my way to use arrays instead of objects, and was subsequently very embarrassed to find out that I would have saved myself a lot of time AND improved perf by using objects instead.

--
You received this message because you are subscribed to the Google Groups "elm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/e71eaca3-c9fc-445b-b01f-f5da1007c99b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Evan Czaplicki]

I believe in the olden times, I did use an array because I just assumed it'd be fast. I later ran some benchmarks and was totally wrong, objects were a lot faster. So I switched everything.

Not sure if things have changed since then, but I suspect not knowing what I know about JIT'ing code.

Also, if you are concerned about size, I would kind of expect "{ ctor:" to be caught by a quality compression algorithm as "a thing that appears a lot" though this is way not my area of expertise. I've seen silly XML get crushed by gzip and such, so I'd wonder if it is actually a big deal in the end anyway.

To view this discussion on the web visit https://groups.google.com/d/msgid/elm-dev/CAORaYgbEBmwe3rXJN7Qzj0XOKD5u1mx6GTrG_1_69nNZdL5m8w%40mail.gmail.com.

[Robin Heggelund Hansen]

Ahh ok. I just assumed arrays would be faster, but in the age of the jit, trust the benchmarks.

Thanks for answering.