On Saturday, June 17, 2017 at 12:01:33 PM UTC-6, José Valim wrote:
>
> When these structures use Structual Ordering, they will work differently
>> from when using Logical Ordering.
>> An example: If I want to keep a top ten of highscores, I only want to
>> order %HighScore{}'s based on their score, and not on the user that
>> archieved the score or on the time the score was arrived at. A 'custom
>> ordering' is exactly what this proposal wants to allow to be made.
>>
>
> If you want custom ordering, then a protocol is not the solution because
> they are global. Imagine you have a collection of users. Sometimes you want
> to order them by age, sometimes by name. Sure, you can implement the
> Comparable protocol for %User{} in a way that makes sense most times, but
> that doesn't exclude the fact you still want custom ordering via functions.
>
This is precisely the case where Implicit Witness Modules are significantly
better than the Data style uses that Haskell does (and that the proposed
style here models). You have an implicit default based on the type or can
pass an explicit variant (OCaml is currently explicit for example, Scala is
implicit and explicit, Elixir would have to be explicit like OCaml is since
Elixir lacks types, though a typing library could fix that later), and the
explicit version can be an entirely different implementation.
I'd really think the witness version would be far more powerful and more in
line with how Elixir does it already, except you'd make it more generic and
baked in (and `@behaviour`s would see a lot more use then too, no protocols
needed and the dispatching is faster!). It would have a similar cognitive
load to how Elixir handles these already.
On Saturday, June 17, 2017 at 12:01:33 PM UTC-6, José Valim wrote:
> In fact, using a ordering that does not work across types would be
> detrimental in Elixir, since we do allow a list to have any data type. For
> example, if Enum.sort/1 used the proposed protocol, it would be unable to
> work on heterogeneous collection by default. If tree data types used that
> as well, we would be unable to have heterogenous trees, etc.
>
> My point is: we already have an ordering mechanism. Sure, it has flaws,
> but there is little benefit in replacing it by a version that is slower and
> works only on homogenous collections. The answer is to continue supporting
> custom ordering functions. If we want to standardize the use of :eq | :lt |
> :gt, then let's do that by providing functions that work on those types.
> The answer is not a Comparable protocol.
>
Well how about a Witnesses style instead of a Data style? I could make up
a proposal with the awesome Qqwy based on them if you want to see that
style considering it is similar to how Elixir does things already?
--
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/f81be64a-e818-4cbc-9e1d-0d9fe3e296fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
