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

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 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@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries