Open non opened 9 years ago
we've been making macros for these cases. I assume the macros offer better performance, but maybe I'm wrong. Certainly better usability.
I can see adding these "generalization over case class" instances being something we have standard macros for in many of our cases: Semigroup, Monoid, Group, Ring (but not Field), Order, Eq, PartialOrder, and probably more.
I would be happy to use macros. I agree that the performance will be much better when function literals are used (they can be inlined into the code you would explicitly write, more-or-less).
I bet if we are careful, we can get a lot of code reuse between the different typeclasses over case-classes.
Something that I've received requests for is an easier way to define these instances.
Here's an example of what I mean (assume we can't automatically derive instances for case classes/products):
The logic in both cases is that the first function is used -- and if the items are equal, the next one is used, otherwise the result returns immediately. If after the last function runs they are equal, then 0/EQ is returned.