Feature Request: Arbitrary (First-order) Datatypes in Ports

[maxsnew]

This seems pretty simple to implement:

data Foo a = Bar String
           | Baz (Foo a) Int
x = Bar "bleh"
y = Baz x 7

then x and y could be serialized to the following javascript (field names could easily be something else):

var x = { _ctor: "Bar", _0: "bleh" }
var y = { _ctor: "Baz", _0: x, _1: 7 }

The only problem I see with this is that the serialization of Maybe would be inconsistent with this.

Right now it's actually impossible to serialize a Sum type. Even if we're unsure about doing this in general, we definitely need to at least support the Either type. Currently I'm doing the following to get around this limitation

type Either' a b = (Maybe a, Maybe b)

where I ignore the 2nd value if the first one is non-null, but this is obviously suboptimal.

[johnpmayer]

Totally support this and I've already given it some thought, so just some
comments:

First, in
https://github.com/johnpmayer/Elm/blob/master/compiler/Generate/JavaScript/Ports.hs,
the code path currently only knows that it's dealing with a Foo, but it
doesn't know that Foo is made up of Bars and Bazs. This "ADT shape
information" isn't available to this part of the program (at least it
wasn't obvious to me where that would be found), and it will have to be
made available. I defer to Evan on the actual implementation challenges of
wiring through this information.

Personally, I don't like the fact the null equates with Maybe. I would
remove that compatibility in favor of arbitrary ADT serialization.

As far as the serialization scheme, I noticed that you essentially chose
the native representation of Elm types. I agree that this is a nice way to
do it; browsers are pretty efficient at JSON.parse and JSON.toString, so it
leads to an implementation that is both simple and fast. However, I would
drop the {_ctor,_0,_1,_2} pattern in favor of {_ctor,_params}, where
_params is a list of arguments, as this is compatible with existing code in
Haskell's Data.Aeson.TH. If _params is a list, then ADTs are simply sum
types with product types, and our basic product types (tuples) are already
implemented as lists, so that's a nice property.

On Wed, Feb 5, 2014 at 6:51 PM, Max S. New notifications@github.com wrote:

This seems pretty simple to implement:

data Foo a = Bar String
| Baz (Foo a) Intx = Bar "bleh"y = Baz x 7

then x and y could be serialized to the following javascript (field names
could easily be something else):

var x = { _ctor: "Bar", _0: "bleh" }var y = { _ctor: "Baz", _0: x, _1: 7 }

The only problem I see with this is that the serialization of Maybe would
be inconsistent with this.

Right now it's actually impossible to serialize a Sum type. Even if we're
unsure about doing this in general, we definitely need to at least support
the Either type. Currently I'm doing the following to get around this
limitation

type Either' a b = (Maybe a, Maybe b)

where I ignore the 2nd value if the first one is non-null, but this is
obviously suboptimal.

Reply to this email directly or view it on GitHubhttps://github.com//issues/490
.

[johnpmayer]

My overall feeling on this are that, because elm is a strict language, all non-lambda types should have default serialization built in, and thus could all be used in ports.

[johnpmayer]

One small problem I see in your example: Without type annotations, the type variable a, in both the type of x and the type of y, is indeterminate. I point this out mainly to say that, if there are free variables in a type, then that type should not be serializable.

[maxsnew]

Oh woops, I meant to use the a.
Given

data Foo a = Bar a
           | Baz (Foo a) Int

This should work:

port out : Signal (Foo String)
port out = constant <| Bar "Work!"

producing

{ _ctor: "Bar", _0: "Work!" }

but this should obviously be an error:

port out : Signal ([a] -> a)
port out = contant head

This is already handled to some extent since Maybe/List are serializable.

[evancz]

I'd be more inclined to use the _0, _1, etc style. I currently think it is easier to use (and should generally have better performance). Either way, I think the leading underscore for _ctor and _params is not adding any value, and I believe it is ctor in the compiler now?

Let's do some examples to see on how it looks:

switch(value.ctor) { ... }
switch(value.constructor) { ... }  // collides with built-in JS name?

value._0

// I feel like this is not a thing that is named, but
value.params[0]
value.values[0]

// or maybe
value.v0
value.p0
value.a0
value[0] // you can use numbers as field names! :O

No idea!

As it is, you don't need to have a full list of constructors to do any of this. Although, it could be very valuable to have such a list because generated JS could switch on integers instead of strings, which should be significantly faster:

switch (x.ctor) {
case "Just":
case "Nothing":
}

// possibly faster version
switch (x.ctor) {
case 0:
case 1:
}

I think this kind of optimization is not a good idea right now. No one will notice speed gains in this realm, and it'll make things harder to maintain and make generated code harder to read.

[JohnNilsson]

Why not just use an array, using the first element for ctor?
["Baz", x, 7]
On Feb 6, 2014 2:35 AM, "John P Mayer, Jr" notifications@github.com wrote:

Totally support this and I've already given it some thought, so just some
comments:

First, in

https://github.com/johnpmayer/Elm/blob/master/compiler/Generate/JavaScript/Ports.hs
,
the code path currently only knows that it's dealing with a Foo, but it
doesn't know that Foo is made up of Bars and Bazs. This "ADT shape
information" isn't available to this part of the program (at least it
wasn't obvious to me where that would be found), and it will have to be
made available. I defer to Evan on the actual implementation challenges of
wiring through this information.

Personally, I don't like the fact the null equates with Maybe. I would
remove that compatibility in favor of arbitrary ADT serialization.

As far as the serialization scheme, I noticed that you essentially chose
the native representation of Elm types. I agree that this is a nice way to
do it; browsers are pretty efficient at JSON.parse and JSON.toString, so it
leads to an implementation that is both simple and fast. However, I would
drop the {_ctor,_0,_1,_2} pattern in favor of {_ctor,_params}, where
_params is a list of arguments, as this is compatible with existing code in
Haskell's Data.Aeson.TH. If _params is a list, then ADTs are simply sum
types with product types, and our basic product types (tuples) are already
implemented as lists, so that's a nice property.

On Wed, Feb 5, 2014 at 6:51 PM, Max S. New notifications@github.com
wrote:

This seems pretty simple to implement:

data Foo a = Bar String
| Baz (Foo a) Intx = Bar "bleh"y = Baz x 7

then x and y could be serialized to the following javascript (field names
could easily be something else):

var x = { _ctor: "Bar", _0: "bleh" }var y = { _ctor: "Baz", _0: x, _1: 7
}

The only problem I see with this is that the serialization of Maybe would
be inconsistent with this.

Right now it's actually impossible to serialize a Sum type. Even if we're
unsure about doing this in general, we definitely need to at least
support
the Either type. Currently I'm doing the following to get around this
limitation

type Either' a b = (Maybe a, Maybe b)

where I ignore the 2nd value if the first one is non-null, but this is
obviously suboptimal.

Reply to this email directly or view it on GitHub<
https://github.com/evancz/Elm/issues/490>
.

Reply to this email directly or view it on GitHubhttps://github.com//issues/490#issuecomment-34283540
.

[evancz]

@JohnNilsson, that's actually how things were represented early on in the generated code :) I think it was slower, but I don't think that's the point of this API.

switch(foo[0]) {
case "Baz":
  return foo[1] + foo[2];
case "Bar":
}

Any opinions on the looks of this? (with your JS cap on)

[evancz]

Maybe we should have a more realistic example and do a bunch of gists?

[maxsnew]

Here is the code for the program I was writing: https://gist.github.com/maxsnew/8855176 .

[johnpmayer]

I'm really just hoping for ADT compatibility with Data.Aeson.TH, which
automatically generates JSON serialization in Haskell. I know this isn't a
priority for everybody, but I feel like it's certainly something to consider,
at least as prior art.

Let's say we have:

data Foo = Bar Int String
x = Bar 5 "baz"

Elm internals currently look like { "ctor" : "Bar", "_0" : 5, "_1" : "baz" }

Data.Aeson.TH has three modes for ADTs.

TaggedObject looks like { "tag" : "Bar", "contents" : [ 5, "baz" ] }

ObjectWithSingleField looks like { "Bar" : [ 5, "baz" ] }

TwoElemArray looks liks [ "Bar", [ 5, "baz" ] ]

On Thu, Feb 6, 2014 at 7:15 PM, Max S. New notifications@github.com wrote:

Here is the code for the program I was writing:
https://gist.github.com/maxsnew/8855176 .

Reply to this email directly or view it on GitHubhttps://github.com//issues/490#issuecomment-34391435
.

[evancz]

Cool, @maxsnew that examples helps me :) I like the names "tag" and "contents" a lot! That is much more intuitive for me when I think of them as JS data structures.

I think the ObjectWithSingleField always seems like a cool and great idea until you actually try to use it in JS and find that it's a decent pain in the ass (this is the key problem with the type format in generated documentation).

So I would currently lean towards the TaggedObject style.

[evancz]

As for the issue of "should Maybe Int represent the set of all integers and null or be serialized to this format?"

It may make sense to have a type alias type Nullable a = Maybe a that has the different behavior. I'm not sure though. I think this is a particular case where it makes sense to have a special case. Ports are about writing natural and colloquial code in both Elm and JS, not forcing an approach on JS people.

[johnpmayer]

Yes I agree that TaggedObject is the nicest pattern. I don't think there
would be any significant performance hit.

I've backtracked on my opinion of Maybe; I think it does make sense to have
something to handle nulls in JS. Maybe is the natural candidate, and that's
how Aeson handles null as well.

On Sat, Feb 8, 2014 at 10:19 AM, Evan Czaplicki notifications@github.comwrote:

As for the issue of "should Maybe Int represent the set of all integers
and null or be serialized to this format?"

It may make sense to have a type alias type Nullable a = Maybe a that has
the different behavior. I'm not sure though. I think this is a particular
case where it makes sense to have a special case. Ports are about writing
natural and colloquial code in both Elm and JS, not forcing an approach on
JS people.

Reply to this email directly or view it on GitHubhttps://github.com//issues/490#issuecomment-34546381
.