They discourage it through their design guidelines, preferring “opaque” types, since constructors are the internal representation of a type, so if you expose it as an API then the internal representation and external API are coupled, which can be annoying if you want to change either.
http://package.elm-lang.org/help/design-guidelines#keep-tags-and-record-constructors-secret
The big downside is that you can only pattern match on constructors, so I have mixed feelings…
But it does encourage things like, for example, having two different “views” of a datatype, as shown in the article, where a non-empty list Cons a can be thought of either as (a, List a) or (a, Maybe (Cons a)) and you don’t need to know or care which one the internal representation is actually using.
Why does Elm discourage exposing type constructors? And how do they go about doing so?
They discourage it through their design guidelines, preferring “opaque” types, since constructors are the internal representation of a type, so if you expose it as an API then the internal representation and external API are coupled, which can be annoying if you want to change either. http://package.elm-lang.org/help/design-guidelines#keep-tags-and-record-constructors-secret
The big downside is that you can only pattern match on constructors, so I have mixed feelings…
But it does encourage things like, for example, having two different “views” of a datatype, as shown in the article, where a non-empty list
Cons acan be thought of either as(a, List a)or(a, Maybe (Cons a))and you don’t need to know or care which one the internal representation is actually using.