Proposal: Add conspicuously missing Functor instances for tuples
tikhon at jelv.is
Mon Jan 18 21:20:59 UTC 2016
> I don't know why "I wouldn't use it" should extend to "it shouldn't
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries