I just came across this issue myself. What I find weird about it is that
the syntax for creating a record type is no different whether or not it's
extendible. By that I mean in the following example:
type alias Foo f = { f | foo : String }
type alias Bar = Foo { bar : String }
type alias Baz = { baz : String }
The only difference is the fact that I pass one through a type constructor
and the other I don't. Since the latter example will produce its own
constructor I had no real indicator here that the former one wouldn't. To
me it seemed like the "type alias" keyword is what was generating the
constructor. Based on my reading in this thread, the compiler does some
magic based on what's on the right side of the equals to determine whether
or not to create a constructor?
I would have expected it Bar to have a type constructor that just takes the
parent properties first, followed by the child properties. As it is, in
order to use this with functions that I can pass the constructor into (like
the Json.Decode.object* variants) I now have to create my own function to
serve as the flattened constructor like:
mkFoo foo bar =
{ foo = foo
, bar = bar
}
which isn't a big deal for an object like this, but in real life objects
tend to be much larger; in my app I'm now adding:
mkBox position size label originalLabel key isEditing isSelected isDragging
selectedIndex borderSize =
{ position = position
, size = size
, label = label
, originalLabel = originalLabel
, key = key
, isEditing = isEditing
, isSelected = isSelected
, isDragging = isDragging
, selectedIndex = selectedIndex
, borderSize = borderSize
}
This is a lot of repetition and mental overhead the next time my types
change.
Is my suggestion of using the order the parents are specified to determine
parameter order a good workaround? Or this just too hard to do right now?
Post by Evan CzaplickiIt's not a bug. Record constructors are only generated when you are
defining a record directly. This has come up on the list before I believe.
As it is, you can generate the code necessary just from the syntax. Base
takes these fields in this order, and maybe it can be extended. It's not
totally obvious to me how the order of arguments would work otherwise.
Longer term, there is the type-directed macros proposal which may be the
principled solution to this.
Post by Max GoldsteinThis has to do with how record type aliases *in the type language* become
constructor functions *in the term language*.
type alias Base a = { a | x : Int }
type alias Sub = Base { y : Int }
f : Int -> a -> { a | x : Int }
f = Base
This compiles. What's slightly confusing is that Base the term takes the
Int first and the extendable part second; Base the type takes the type
parameter immediately. The other confusing thing is, just looking at the
second line, Base could be a tag (union type, ADT until this week). But
it's actually an extendible record type. It's possible that's confusing the
parser as well as me. If Base *was* a tag, you would expect it to *not* be
a valid term.
But as it stands, we'd expect Sub to take the x and then the y. So I
think I've convinced myself this is a bug, too.
--
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
For more options, visit https://groups.google.com/d/optout.
--
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.