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 bounded or unbounded set of them and are perfectly suited for an abstract CSS DSL while being readable in both usage and implementation.
And yes, I agree about type classes, they are extremely over-used in Haskell where something like OCaml's Implicit Modules would be such a significantly better fit for... On Thursday, April 27, 2017 at 6:21:22 AM UTC-6, Mitchell Rosen wrote: > > 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 seems to be fighting hard against the language, and the result > far from beginner-friendly. > > Type classes are one such extension, and I sketched out how one might > implement this library using them. As you mentioned, ADTs are another. > > In this particular case, type classes, as flawed as they are, seem vastly > superior to the row-types approach. But, I'm definitely open to having my > mind changed! I'm just not comfortable enough with row types as a language > feature to really have an intuitive understanding of when to use them, and > when to not. > > But, anyways, I totally agree that keeping it simple with ADTs is what you > should do most of the time. It's only when you're writing library code to > be used by the community that you should start obsessing over the > ergonomics. > > -- 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.
