Re: DeriveFoldable treatment of tuples is surprising

For `Traversable` one have to `traverse` over everything: traverse @Foo = forall f. Applicative f => (a -> f b) -> Foo a -> f (Foo b) ~= .... -> ((a,a), a) -> f ((b,b), b) And thus the same behavior for `Foldable`. You should define: data Foo b a = Foo ((b,b), a) deriving Foldable - Oleg On 21.03.2017 23:11, David Feuer wrote:

The point is that there are two reasonable ways to do it, and the deriving mechanism, as a rule, does not make choices between reasonable alternatives.

On Tue, Mar 21, 2017 at 5:05 PM, Jake McArthur wrote:

...

I think it's a question of what one considers consistent. Is it more consistent to treat tuples as transparent and consider every component with type `a`, or is it more consistent to treat tuples as opaque and reuse the existing Foldable instance for tuples even if it might cause a compile time error?

On Tue, Mar 21, 2017, 4:34 PM David Feuer wrote:

...

This seems much too weird:

*> :set -XDeriveFoldable *> data Foo a = Foo ((a,a),a) deriving Foldable *> length ((1,1),1) 1 *> length $ Foo ((1,1),1) 3

I've opened Trac #13465 [*] for this. As I write there, I think the right thing is to refuse to derive Foldable for a type whose Foldable instance would currently fold over components of a tuple other than the last one.

I could go either way on Traversable instances. One could argue that since all relevant components *must* be traversed, we should just go ahead and do that. Or one could argue that we should be consistent with Foldable and refuse to derive it.

What do you all think?

[*] https://ghc.haskell.org/trac/ghc/ticket/13465 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

---

ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs