Yep, that is all trivial with Polymorphic Variants if you want them shared.
In essence, you know how a normal variant is, like this (in OCaml syntax
since that is what I'm more comfortable with, but it's close enough to Elm,
'almost' identical)
```ocaml
type Vwoop =
| Infinite
| Int of integer
Maybe this is covered in OCaml's polymorpic variants — I couldn't tell from
a quick skim — but another feature that would cover this without
introducing type classes is support for more arbitrary union/sum types.
That way, one could write something like:
type Auto = Auto
type alias LengthOrAuto
Actually this sounds to exactly like the use-case for OCaml's Polymorphic
Variants. In OCaml you could easily use just `Hidden for both of your
examples, fully type checked, type safe, etc... etc... Polymorphic
Variants are just global Variants that are unnamed. A function can take a
Hi Joey,
Indeed, basic ADTs are one way to model the DSL. The problem then arises when
you want to reuse the name "auto" for another key.
I may not have been clear, so I'll try to summarize my post here. How might
elm-css look if there were different features in Elm? As it stands, the library
I might be misunderstanding, but in your use case, you probably want a
tagged Union, what Haskell calls data, instead of type classes. Basically,
they're always preferable when you have a fixed number is variants you
want. Your margin function would then just pattern match.
type Margin = Auto |
Hello all! I am a (very) beginner Elm programmer, but I know a fair bit of
Haskell. I listened to the most recent Elm Town podcast and was especially
intrigued by the discussion around a novel use of record types to solve a
real-world problem - embedding a nice CSS DSL directly into Elm.
