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
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
err
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 trea
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 c