Re: DeriveFoldable treatment of tuples is surprising

As I recall, Richard Eisenberg has been pushing, off and on, for us to get a better vocabulary to specify "how" something is derived, via DeriveAnyClass, generalized newtype deriving, DeriveFoldable, etc. In general I think the current behavior is the least surprising as it "walks all the a's it

Re: DeriveFoldable treatment of tuples is surprising

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

Re: DeriveFoldable treatment of tuples is surprising

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

DeriveFoldable treatment of tuples is surprising

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