Re: DeriveFoldable treatment of tuples is surprising

> On Wed Mar 22 13:54:05 UTC 2017, Twan van Laarhoven wrote: >> On 2017-03-21 21:34, 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 Hmm. *> length $

Re: DeriveFoldable treatment of tuples is surprising

> there is a fair bit of user code for things like vector types that do things like newtype V3 a = V3 (a,a,a,a) ^ 1 2 3 4(!?) Oh boy, I sure hope not ;) On Wed, Mar 22, 2017 at 8:14 AM Sven Panne wrote: > 2017-03-21 22:29 GMT+01:00 Edward Kmett

Re: DeriveFoldable treatment of tuples is surprising

2017-03-21 22:29 GMT+01:00 Edward Kmett : > [... In general I think the current behavior is the least surprising as it > "walks all the a's it can" and is the only definition compatible with > further extension with Traversable. [...] > OTOH, the current behavior contradicts my

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