It seems like a minor detail that may come as a matter of course, but I'd
like to request that Bool's should also be comparable. If Bools are not
comparable but you embed a Bool inside a tuple or a List or a Record, that
makes the larger type also not comparable. Unless you decide to ignore the
Bool's but I think that is a less useful design choice IMO.
Another general issue is what happens if the programmer does not like the
ordering provided by default for a particular type? Ie. if we are in a
world where False < True, but I would prefer to use True < False, what do I
do. Can there be a special function name ("compare" would be the most
obvious choice) such that if I define my own version of that function for
any given type, then it is used rather than the native default? I think
that would be especially useful if you don't want to compare records
alphabetically by field name.
Eg. I want to sort records by name first and age second -- records of the
type { name: String, age: Int }. I don't want to have to force myself to
rename them creatively to get the sort I want eg: { appelation: String,
maturity: Int } or worse {aName: String, zAge: Int}.
In this instance the ability to override the sort order by defining a
compare function would be helpful.
Alternatively for records, one could use the fact that the listing order
otherwise carries no information, and have the sort order for
records be implied by the listing order. Just like unions in Haskell. So:
{name: String, age: Int}
would sort automatically by name first and age second. But it would remain
legal to write {age = 22, name="Bob"}. This is controversial because it
retains the fact that by definition the ordering of fields in the record is
irrelevant, and yet partially gives them meaning under special
circumstances. There might also be issues if
you define the record one way, and persist the data somehow, and then read
the data back in after compiling with a source code which changes the
listing order of
the fields. Nothing should change. Yet, this solution will cause changes
in sorting behavior.
All things considered, it might be better to allow the programmer to define
a compare function and have that used automatically for Sets and Dicts.
Kind of typeclass-ish, but it may not necessarily require typeclasses to
be exposed in the language. And let the listing order of the field names
in the source code have no significance.
On Friday, August 4, 2017 at 11:04:07 AM UTC-4, Richard Feldman wrote:
>
> Having a deriving-esque way to generate encoders and decoders
>> automagically would be great, and would go a long way in solving the
>> hassle. (2) would also make my life easier.
>> 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.
>>
>
> Oh yeah - worth noting that this implementation already exists for
> records. Ports do it. If you send a record out a port, or bring it in
> through a port, under the hood what's happening is an encoder (or decoder,
> respectively) gets generated automatically from the type.
>
> Doing it for union types as well would largely be a matter of designing a
> nice serialization and deserialization format; the type information is just
> as easy to access as it is for records. 😉
>
--
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.
