On 17-10-2019 22:34, José Valim wrote: > I have put more thoughts into this. > > If our goal is to have something that can be easily sortable, computed > a max and a min, etc, then the best option is to introduce a sortable > function: > > sortable(date) :: term() > > The goal of this function is to return a sortable term, according to > Erlang Term Ordering.
I believe that having something that would work with Erlang's Term
Ordering was why in the distant past there was a proposal to return
`:<`, `:=` or `:>` as return type of Date.compare (and variants).
However, if I remember correctly, it was deemed less readable than
`:lt`, `:eq` :gt` and that was considered more important.
>
> The only downside of this implementation is that it may not be as
> efficient because we will have to convert to iso days so they are
> sortable across calendars.
>
Yes. And of course for incompatible calendars it will fail at some
point. To properly work with calendars that might or might be
incompatible, we'd need to not only remember the ISO day (and time) but
also e.g. the offset since midnight.
> ===
>
> There is a longer discussion here about introducing a new protocol,
> called Ordered, and an Enum.order/1 function. Then Enum.order(dates)
> would automatically work, because it would dispatch to a protocol
> which is always correct. This is all good on paper but I can foresee
> two downsides:
>
> 1. We would need to introduce an "Ordered" version of min/max. Perhaps
> something like order_first/order_last or order_min/order_max.
>
> 2. I am not aware of any prior art on this. Most of the
> protocols/typeclasses/interfaces I know for ordering build them based
> on comparisons. Is anyone aware of a reference on the topic?
I believe this technique (which is essentially what `Enum.sort_by`
already does) is frequently called a 'Schwartzian Transform':
-Take a collection of things
- For each collection transform it into a pair of {sortable_key,
element} where `sortable_key` is part of a total ordering with all other
`sortable_keys` in the collection (in our case: the Erlang Term Ordering).
- Sort this collection of pairs.
- Drop all the first elements of the pairs again.
> Thoughts?
Not a bad idea.
I do wonder about your follow-up: Why would it not work for integers?
(and float and decimals)? At least as long as we are comparing
collections of /only/ integers or /only/ floats or /only/ decimals, the
result would be sensible.
If we want to make Ordered work between them, well, then it becomes a
bit more difficult: In that case we probably would need to 'upcast' all
of them into some kind of more general tuples-of-integers-and-strings form.
Hmm, interesting problem!
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/3467322a-679f-c8c9-45d5-52407c38b5fe%40resilia.nl.
signature.asc
Description: OpenPGP digital signature
