4 ms·

Structural row typing I hadn't heard about. Elm is on my to-learn list, so I'll look it up separately, but... Coming from Haskell, what's the elevator pitch fo

Structural row typing I hadn't heard about. Elm is on my to-learn list, so I'll look it up separately, but... Coming from Haskell, what's the elevator pitch for it?

willtim 8y ago
IMHO, structural types are a better starting point. Nominal types can always be created by wrapping a structural type, but it is difficult to go the other way round. A language with row types can give a type to a query or have named function arguments. Extensible row types allow even more forms of composition, for example functions that require the presence of certain fields but will ignore others, very similar to subtyping.
- ufo 8y ago
  structural vs nominal typing is orthogonal to row polymorphism vs subsumption rule.
  - deleted 8y ago
    [deleted]
  - willtim 8y ago
    Well not really as row polymorphism is a form of structural typing.
always_good 8y ago
The elevator pitch for Elm is that it helps you build UIs which is just never easy. And mostly prescribes its own architecture instead of having you picking between vanilla React, Redux, Mobx, etc. I never knew how amazing "if it compiles, it works" could be when building a UI.
ufo 8y ago
In a system with subtyping {x:int, y:int} is a subtype of {x:int}. You can have a function that receives {x:int} and you can pass a {x:int, y:int} to it. The subtype can be freely used whenever the supertype is expected. With row typing instead of subtyping you have "row variables". That function that would receive a {x:int} is typed as "forall p. {x:int; p}". You can pass the function a {x:int, y:int} because it unifies p with {y:int}. But you cannot freely convert a {x:int, y:int} to a {x:int}, it is all based around parametric polymorphism. This system with row variables works much better with hindley-milner type inference but it is a bit more restrictive. For example, you cannot use subtype polymorphism to have a heterogeneous list of objects. If you have a function that receieves a "forall p. [{x:int; p}]" you can have a list of {x:int} or a list of {x:int, y:int} but every element of the list must have the same type.
- willtim 8y ago
  > you cannot use subtype polymorphism to have a heterogeneous list of objects You can by using an existential type parameter, which 'forgets' the types in much the same way as an upcast. [exists p. {x:int; p}]

Structural row typing I hadn't heard about. Elm is on my to-learn list, so I'll look it up separately, but... Coming from Haskell, what's the elevator pitch for it?

willtim 8y ago

IMHO, structural types are a better starting point. Nominal types can always be created by wrapping a structural type, but it is difficult to go the other way round. A language with row types can give a type to a query or have named function arguments. Extensible row types allow even more forms of composition, for example functions that require the presence of certain fields but will ignore others, very similar to subtyping.

ufo 8y ago
structural vs nominal typing is orthogonal to row polymorphism vs subsumption rule.
- deleted 8y ago
  [deleted]
- willtim 8y ago
  Well not really as row polymorphism is a form of structural typing.

always_good 8y ago

The elevator pitch for Elm is that it helps you build UIs which is just never easy. And mostly prescribes its own architecture instead of having you picking between vanilla React, Redux, Mobx, etc. I never knew how amazing "if it compiles, it works" could be when building a UI.

ufo 8y ago

In a system with subtyping {x:int, y:int} is a subtype of {x:int}. You can have a function that receives {x:int} and you can pass a {x:int, y:int} to it. The subtype can be freely used whenever the supertype is expected. With row typing instead of subtyping you have "row variables". That function that would receive a {x:int} is typed as "forall p. {x:int; p}". You can pass the function a {x:int, y:int} because it unifies p with {y:int}. But you cannot freely convert a {x:int, y:int} to a {x:int}, it is all based around parametric polymorphism. This system with row variables works much better with hindley-milner type inference but it is a bit more restrictive. For example, you cannot use subtype polymorphism to have a heterogeneous list of objects. If you have a function that receieves a "forall p. [{x:int; p}]" you can have a list of {x:int} or a list of {x:int, y:int} but every element of the list must have the same type.

willtim 8y ago
> you cannot use subtype polymorphism to have a heterogeneous list of objects You can by using an existential type parameter, which 'forgets' the types in much the same way as an upcast. [exists p. {x:int; p}]