I am not at all sure how a Witness-style proposal would look (The concept
of witnesses is still a bit vague to me; I understand them as 'extra
information passed to dispatch between implementations', but that would be
very similar to the approach of just passing a comparison function
directly). Please do go ahead and explain it in more detal! :-)
@Josevalim I have given the 'explicit comparison function' some thought.
Indeed this seems like a more general and even less invasive 'solution' to
the current problem. (Especially because we indeed always still want custom
ordering via functions).
I think this will mean that frequently, data structures will contain the
function that is used as comparison function internally. Which I think is
fine, since functions even survive e.g. erl2bin -> bin2erl procedures.
Is it maybe helpful to create a `Comparable` behaviour containing
`@callback comparable(a, b) :: :lt | :eq | :gt`, to set this design
decision in stone (and thus give library developers a clear direction on
which way to take)?
~Wiebe-Marten/Qqwy
On Monday, June 19, 2017 at 6:11:27 PM UTC+2, OvermindDL1 wrote:
>
> 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/3fa459ac-175c-4868-b8c2-5533920bebe7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
