> > 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/CAGnRm4%2BFTzC9fc7UbZwE8%2B6UCVw9ibb_U0ZMArXV6ZWDTcePmg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
