I don't know why "I wouldn't use it" should extend to "it shouldn't exist".
I'm in favor of these instances, if only for the sake of consistency.
However, I don't agree with this reasoning. Typeclass instances in Haskell
are an inherently global construct: once an instance is defined, you can't
do anything about it. You can't replace it or redefine it or even not
import it. At the same time, it affects type inference and type error
messages even if you're *not* using it.
As a slightly more extreme example, there's a reason we don't have a Num
instance for functions or Applicatives by default: while perfectly
well-formed and even useful, having these instances would lead to worse
error messages or even code typechecking when it shouldn't with weird
results—even if you never rely on them yourself.
On Mon, Jan 18, 2016 at 12:59 PM, Eric Seidel
On Mon, Jan 18, 2016, at 12:44, Christopher Allen wrote:
I've addressed this here:
http://bitemyapp.com/posts/2015-10-19-either-is-not-arbitrary.html
The thousand-papercuts opposition to typeclass instances on the premise that a Functor for (a, b, c) maps over the final type not making sense is a rejection of how higher kinded types and typeclasses work together. This is natural and predictable if one bothers to explain it.
The behavior is indeed predictable, but I think Henning is arguing (and I would agree) that it is *undesirable*.
That being said, I think the ship has sailed on the "should tuples be a Functor/etc" discussion. The current proposal is aimed at making the set of available instances more consistent across tuples, which I'd argue is a good thing regardless of one's position on the specific class. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries