Another factor: Foldable and Traversable are both closed under composition, meaning that `newtype Compose f g a = Compose (f (g a))` has the following instances: 

instance (Foldable f, Foldable g) => Foldable (Compose f g)

instance (Traversable f, Traversable g) => Traversable (Compose f g)

Removing the Foldable instance for `(,) e` would also remove the Foldable and Traversable instance for any composition of functors containing tuples. If you're writing your code in terms of fixed points of type constructors, then this is a problem.

Matt Parsons

On Thu, May 4, 2017 at 2:52 PM, Chris Smith <cdsmith@gmail.com> wrote:
My answer this is: because Foldable instances on tuples make Haskell programming more dangerous.

With all instances, there is some risk of accidental unification with broken programs.  But in general, we are saved by one of two things: either the types are special-purpose enough that they are unlikely to occur by accident, or unification just propagates the incorrect type and the compiler merely puts the error message is in the wrong place.

With length and tuples, though, we're talking about a type that's used casually in many situations; and the accidental unification does not propagate the type at all.  Instead, it just generates incorrect code.  That's a bit scary!

It's unfortunate that discussions of this tend to get muddied by the possibility of length having a different meaning on tuples.  Really, IMHO, that's not even related to the problem.  The problem is that accidental unification is more risky here than anywhere other commonly used bit of Haskell that I can find. 

On Thu, May 4, 2017 at 1:32 PM, MarLinn <monkleyon@gmail.com> wrote:


This to me is the center of the conversation: we're choosing whether we need the instances badly enough that we tolerate some, ahem, bad behavior.

I dispute that. To me, the center of the disagreement is between two different kinds of consistency: On the one hand, there's the consistency with a view of the world that treats One as a special number different from all other numbers. This view is based on the real world where singularities seem rampant. On the other side is consistency with a math-y view of the world that wants to unify as much as possible so we can reduce the number of models, thus, work.

But if you want to treat the cardinality of one specially, do you want to drop Const and Identity, too? Const is closer to tuples than lists are, so why not cut them out as well? But then we had examples in just this conversation where Const and Identity where really useful. What argument is left to remove instances for tuples? If you can get over the 5-second weirdness of Const, why not tuples?

At the end I claim there is no bad behavior. I do give you that there is missing behavior because the choice to have only that one instance per tuple size is a bit arbitrary and misleading. And that is hard to change for now. But do you really want to remove those few instances we do have just because we're not ready to include the others yet?

MarLinn

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.