Joachim, you may be right about sum and product; I really don't know. Henning: this doesn't change the Data.Foldable API at all. Data.Foldable already exports all of these functions, and the class would give each of them a valid default implementation. I thoroughly agree with you about the peril of using RULES to specialize a function to a typeclass instance. As well as being hard to predict, potentially perilous, and inapplicable to polymorphic recursive situations, RULES also privilege "built-in" types over identical user-defined ones.

On Fri, Sep 19, 2014 at 4:29 PM, Henning Thielemann <lemming@henning-thielemann.de> wrote:

On Fri, 19 Sep 2014, Joachim Breitner wrote:

Slightly off topic: Wouldn’t it be nice if we would not have to have to
add these methods to provide optimized behavior, but rather have the
user write "sum . toList" or some other idiomatic code (maybe suggested
in the docs), and RULES provided by the container implementer would
reliable replace this with the optimized version. Wouldn’t help in
polymorphic code, but I doubt that much performance critical code is
polymorphic in the container.

But then he could simply provide a sumTree or sumSet or something
else... I should stop mumbling in circles.

I am also worried about extending the classes more and more. Where to stop? At which point the API will be stable? A way to optimize non-methods for certain instances would be nice. Unfortunately, it is not only hard to predict when RULES fire, a RULES based solution is also dangerous. If a default method implementation and an actual instance implementation do different things, that's ok. In contrast, if a function is replaced by different functionality via RULES, that's very bad.
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries