So the definition of List might look like:

type List a
= Nil
| Cons a (List a)

That’s exactly how the definition of List would look like if it didn’t have
a native implementation.

So it seems you already know everything.
​

2016-09-20 17:25 GMT+02:00 'Rupert Smith' via Elm Discuss <
[email protected]>:

> Some more questions about types. I just ran into the recursive 'type
> alias' issue:
>
> https://github.com/elm-lang/elm-compiler/blob/0.17.1/
> hints/recursive-alias.md
>
> which is clear enough. It seems a bit of a shame that some of this
> documentation is a bit buried away - it really feels like this should be in
> the syntax guide (or whatever chapter comes after the syntax guide).
> Anyway, the other questions:
>
> Can type definitions be recursive? as per ML, I think the answer is yes.
>
> type Expression
>   = Integer Int
>   | Sum Expression Expression
>
> for a simple syntax tree representing expressions over integers and
> addition.
>
> I have seen some type definitions like this:
>
> type Cmd msg = Cmd
>
> but I am more used to seeing type definitions that look like this:
>
> type Msg
>   = SomeMsg String
>   | ...
>
> What does the 'msg' parameter on this type do? Does it just mean that the
> type is polymorphic and the 'msg' is the type parameter? So the definition
> of List might look like:
>
> type List a
>  = Nil
>  | Cons a (List a)
>
> --
> 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.
>

-- 
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.

Reply via email to