Proposal: Add conspicuously missing Functor instances for tuples

[David Feuer]

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" <tikhon at jelv.is> 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 <eric at seidel.io> 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 at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160118/6533a7bd/attachment-0001.html>