On Wednesday, October 4, 2017 at 3:19:45 PM UTC+1, Rémi Lefèvre wrote:
>
> When I try to build this code:
>
> type alias Named a =
> { a | name : Maybe String }
>
> getName : Named a -> Maybe String
> getName { name } =
> name
>
> type Element
> = AnElement { name : Maybe String }
> | AnotherElement { name : Maybe String }
>
> mapNamed : (Named a -> b) -> Element -> b
> mapNamed func element =
> case element of
> AnElement e ->
> func e
>
> AnotherElement e ->
> func e
>
> getElementName : Element -> Maybe String
> getElementName e =
> mapNamed getName e
>
The Element type here is analogous to object oriented programming - you
have a parent type Element, with 2 sub-types AnElement and AnotherElement.
Your 'mapNamed' function is like a virtual method - it knows just enough
about the overall type of Element to work with all 'sub-types' of it.
As Ilias points out, the type of the records within the Element type is
'Named {}' but the function is of type 'Name a -> b'. So you are thinking
that the 'a' variable should get bound to {} when this function is invoked?
This would work in an object oriented language, but not Elm. The reason is
that Elm does not support sub-typing at all. Elm has type inference - it
looks at the type of function you wrote and deduced that the type of 'func'
should be 'Named {} -> b' and finds that it does not match with what you
specified in the type signature, so it fails the type checking.
'Named {}' is a sub-type of 'Named a' in languages that support sub-typing.
It makes sense because anywhere you can use a 'Named a', you should also be
able to use a more specific type such as 'Named {}' or 'Named Int' or
whatever.
Elm has type inference and type inference does not work with sub-typing.
The typing problem is semi-decidable. This means that given the type of an
expression, it is possible to decide whether or not that is the correct
type of the expression. Going the other way, given an expression it is not
possible to deduce what the type of that expression should be when
sub-typing is allowed in the type system.
It is easy to mistake Elms extensible records for sub-typing, especially if
you come from an OO back-ground. It is generally not worth trying to use
extensible records at all for data modelling in Elm, because they tend to
lead you down this blind alley very quickly. Their use case is for
narrowing the exposure of a function to parts of a record it does not care
about. I reference Richard Feldman's 2017 Elm Europe talk as a good
resource to learn more about this:
https://www.youtube.com/watch?v=DoA4Txr4GUs
The moral of the story is - don't try and do OO programming in Elm, it
won't work.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
