> The current proposal does not replace even the implementations of
compare/2 within the language itself (which is within the calendar types).
So if accepted, we will end-up with three mechanisms for comparing a date
(one of them being the wrong one). And some data types may require yet
another one, for example if we want to compare between Decimal and Ratio.
The only reason I do not propose to remove the `compare/2` that already
exist within the (Naive)(Date)(Time) modules is to maintain backwards
compatibility. I have not come across in practice any situation in which I
found it convenient to directly compare one date/time version with another,
throwing away precision in the process. This kind of downcasting is
implicit and therefore I do not want to burden readers of my code with it.
The proposal does not try to solve all possible uses of comparisons,
exactly because having something that both is a washing machine and a
dishwasher makes for something that does not really excel at either of
those tasks. Instead, the major use case of comparing two things of the
same type, without upcasting or downcasting, is what this proposal tries to
add.
> Yes but those [data types and algorithms] may also be OK with a
Structural Ordering, which will certainly be faster, or may require a
custom ordering. So the solution is not in adopting yet another limited
implementation for ordering (because we already have one) but making sure a
common return type is accepted, which as mentioned above, can be achieved
through other ways.
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.
Right now we are forced to either use Structual Ordering, or to re-create
the desired algorithms and data types each time for every type that could
have a Logical Ordering.
On Saturday, June 17, 2017 at 3:30:59 PM UTC+2, José Valim wrote:
>
> I am not really following your reasoning here. It seems like you state
>> that not being able to handle struct<->struct coercions is a flaw of the
>> proposal, but then you go on saying that having an intermediate
>> representation is always better, meaning that coercion in these cases is
>> not relevant.
>>
>
> Exactly. The final point is the solution proposed is not going to be
> enough for many cases, with or without coercion.
>
> The current proposal does not replace even the implementations of
> compare/2 within the language itself (which is within the calendar types).
> So if accepted, we will end-up with three mechanisms for comparing a date
> (one of them being the wrong one). And some data types may require yet
> another one, for example if we want to compare between Decimal and Ratio.
>
> If the main goal of this proposal is standardization of return types, then
> I would rather achieve it through other mechanisms, such as adding uses of
> compare/2 in the language, which we have already done with
> (Naive)(Date)(Time).compare/2, and by adding :lt | :eq | :gt based
> comparison functions to Enum. Those would be necessary anyway if this
> proposal is accepted.
>
>
>> The main reason why I believe that this should be integrated into the
>> language is for the same reason that the (Naive)(Date)(Time)-structs were
>> made part of the language: Consistency and therefore Interoptability
>> between libraries.
>>
>
> Those are fairly different scenarios:
>
> * the (Naive)(Date)(Time) structs did not overlap with any existing
> concept in the language and effectively unified all uses of those structs
> in the community
> * translation between calendar data types is much more complicated than
> the translation of compare results
> * calendar types were always planned to be part of the language
>
> Ergo, this would mean that there would be a `comparable` library, and the
>> 'compatibility-layer' libraries: `comparable_timex`, `comparable_decimal`,
>> `comparable_ratio`, etc... And then finally libraries like `priority_queue`
>> that are built on top of `comparable`. However, using these libraries that
>> are built on top of
>> `comparable` is not so nice, because the responsibility of making sure
>> that the proper 'compatibility-layer' is loaded as a dependency shifts to
>> the end user.
>>
>
> Ideally, coordination between community members would happen to define
> protocols that are useful between libraries. However, I am still not
> convinced this protocol would be the correct choice for libraries such as
> Decimal and Ratio. In any case, that's why protocols are beautiful, because
> it allows any of the scenarios above.
>
>
>> There are many algorithms and data structures that would want to work
>> with a Logical Ordering (rather than the Erlang Term Ordering). Including
>> but not limited to:
>>
>> - Sorting algorithms
>> - Searching algorithms
>> - Sets
>> - Multisets
>> - Maps
>> - Multimaps
>> - Trees (of which there are of course many shapes and kinds)
>> - Graphs and their related structures.
>> - Pathfinding algorithms.
>> - Permutation manipulation algorithms.
>>
>
> Yes but those may also be OK with a Structural Ordering, which will
> certainly be faster, or may require a custom ordering. So the solution is
> not in adopting yet another limited implementation for ordering (because we
> already have one) but making sure a common return type is accepted, which
> as mentioned above, can be achieved through other ways.
>
>
--
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/73706310-eba5-466f-813e-776dc2903fe2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
