Re: Proposal: Add conspicuously missing Functor instances for tuples

In every case I can think of where an instance turned out to be a problem, that was because there were multiple law-abiding options and the designers chose the wrong one. Examples that at least some people disagree with: instance Monoid a => Monoid (Maybe a) -- McBride has argued for mappend = (<|>) here instead. instance Monoid b => Monoid (a -> b) -- McBride again, IIRC, dislikes this, weakly preferring -- instance a ~ b => Monoid (a -> b) instance (Eq k, Hashable k) => Monoid (HashMap k v) -- Almost everyone wants -- instance (Semigroup v, Hashable k) => Monoid (HashMap k v) A Num instance for functions is a bad idea because it leads to terrible error messages, but I would argue that's a poor example. The (->) constructor has a sufficiently special, and sufficiently silent, role in the language that it requires a *uniquely* high level of care. When that care is taken (as with the Monad ((->) a) instance), things generally work out just fine. On Jan 18, 2016 4:21 PM, "Tikhon Jelvis" wrote:

...

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 wrote:

...

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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries