Proposal: Add a few extra members to Foldable and Traversable classes

[Edward Kmett]

The problem with rules here is if the user is working polymorphically then when their code does or doesn't inline then you get varying semantics. You can see this in code that uses realToFrac but doesn't get inlined to specialize to Float/Double today in behavior around NaN.

Let's not double down on a design that causes flaky behavior that doesn't scale.

Sent from my iPhone

> On Sep 19, 2014, at 4:59 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> 
> Am Freitag, den 19.09.2014, 22:29 +0200 schrieb Henning Thielemann:
>> 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.
> 
> I meant rules provided by whoever implements the class:
> 
>        instance Traversable Foo where..
> 
>        {-# RULES "sum/Foo" forall fx :: Foo Int . sum (toList fx) = sumFoo xs #-}
> 
> so there would be no worry about soundness.
> 
> I do _not_ mean adding such rules to where the class is defined.
> 
> (This assumes that GHC does the right thing when the overloaded toList
> occurs in a rule, which I am not sure of.)
> 
> 
> 
> Greetings,
> Joachim
> 
> 
> -- 
> Joachim “nomeata” Breitner
>  mail at joachim-breitner.de • http://www.joachim-breitner.de/
>  Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0xF0FBF51F
>  Debian Developer: nomeata at debian.org
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries