Definitely the big reason from my perspective to make more things comparable is to allow their use with dictionaries and sets. For that usage, the comparison could even be compiler dependent (or even execution dependent) but I'm sure that someone would build code that depended on properties of some particular implementation.
Mark P.S. Since this forum likes examples, rather than passing around naked strings, I pass around type AccountID = AccountID String. This is great from a type-checking perspective but means that I can't have a dictionary keyed by AccountID and instead I need to unwrap the value to get the underlying string. That's not too bad, but I recently had need to fold over such a dictionary and so found myself faced with either having a function to force convert a String into an AccountID or storing the original wrapped AccountID along with the value. Neither solution was particularly pretty — one because it is a temptation to undermine type-safety and one because it complicates the dictionary for all other uses. On Fri, Aug 4, 2017 at 7:54 AM, Richard Feldman <richard.t.feld...@gmail.com > wrote: > The problem I see with both deriving-esque auto coders (DEAC, patent >> pending) and comparable union types, is the difficulty of implementation. >> DEAC's seem like an advanced language feature that will take a while to get >> into the language. >> > > Having talked to Evan about it, it seems like the design work is what's > hard. The implementation is actually not a ton of work, apparently. > > That said, the design work *is* hard. 😉 > > Does a union type require that all fields/members are comparable as well? >> > > I think that'd necessarily be true, yeah. But if union types and records > are comparable (assuming they hold only comparable types), I *think* you > end up with something like "functions aren't comparable, nor are > Kernel-implemented values such as Value, Task, Cmd, and Html, but > everything else is." > > >> As a reader, how easy is it to tell if a union type is comparable >> > > Probably not easy, would be my guess. It's unclear to me how big of a deal > that would be though. > > >> and is it obvious when one is lesser than another? >> > > Apparently the way Haskell does this is by using the order of the tags > (e.g. for type Maybe a = Just a | Nothing, we could say that Just "foo" > > Nothing because Just came before Nothing in the type declaration), which > seems fine to use since that ordering is currently arbitrary and > meaningless. Similarly, record fields could be compared alphabetically by > field name (since record fields definitionally have no ordering; if you > needed them to be compared in a certain order, you could use a union type). > > Considering the main (only?) reason people want them to be comparable is > so they can be used in Sets and Dict keys, it doesn't seem hugely important > how they compare, so long as they can be for purposes of internal data > structure implementation details. I could be missing something though! > > It's not straight forward from a design perspective. >> > > I totally agree! 😄 > > -- > 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 elm-discuss+unsubscr...@googlegroups.com. > 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
