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 = Int + Auto -- is this a type or a type alias, I'm not sure margin : LengthOrAuto -> Style Handwaving type checking rules would require that a type passed to something that was expecting a union type needs to cover a subset of that union type. Case statements would be used to do the discrimination. The potentially interesting things that come out of something like this are that one could imagine a union of Maybe and Result which would allow for a value or an error or nothing. This has got to have been explored somewhere before. I have no idea what sort of problems it might create for the type system. Mark On Thu, Apr 27, 2017 at 10:53 AM, OvermindDL1 <[email protected]> wrote: > 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. > -- 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.
