<div dir="ltr">To pile on a bit,<div><br></div><div>I'm somewhat of the opinion that if one doesn't like the consistency that demands typeclass instances for such "degenerate" types, that one simply *doesn't like Haskell.* Typeclass coherence, the prohibition on orphan instances, and uniformity of abstraction of this sort are so central to the language that to add corner cases which *exclude* legitimate use of existing types would be to choose a different (and in my opinion less pleasant and flexible) language entirely.<br><br>I don't presume to speak for anyone but myself, but in off-list discussion with other Haskellers essentially everyone is simply boggled by the idea that there's a group of users that wants to make Haskell *less* internally consistent, just so that they can call `length (foo, bar)`.<br><br>All in all, the complaints I've seen here strike me as very reminiscent of those who complain about type erasure on the JVM - blithely unaware that it's one of the few things that that community got *right.*</div><div><br></div><div>Kris</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 24, 2016 at 11:27 AM, Manuel Gómez <span dir="ltr"><<a href="mailto:targen@gmail.com" target="_blank">targen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> El 24 feb 2016, a las 12:27, Chris Allen <<a href="mailto:cma@bitemyapp.com">cma@bitemyapp.com</a>> escribió:<br>
><br>
> You can't not-include the instances because we'll just end up with orphans<br>
> so that's not cricket I think.<br>
<br>
</span><span class="">On Wed, Feb 24, 2016 at 1:41 PM,  <<a href="mailto:amindfv@gmail.com">amindfv@gmail.com</a>> wrote:<br>
> I don't know what this means -- can you elaborate?<br>
><br>
> (What I'm proposing is, since there is a sizeable number of people on both<br>
> sides of the issue who don't seem to be coming closer to an agreement, we<br>
> bring a vote *to the users* on whether to provide Foldable/Traversable<br>
> instances for tuples of size 2 and greater. If users say they're useful, we<br>
> keep/add 'em. If they find them confusing/not useful, we remove/don't add<br>
> 'em)<br>
<br>
</span>If these instances were not included in base, then these instances<br>
would nonetheless be made available to a large amount of code because<br>
somebody will make a base-orphans library that will define these<br>
instances, and many libraries written by authors who believe these<br>
instances to be useful will depend on this package (or, worse yet,<br>
define their own instances in their own packages which will clash with<br>
each other and break things).  If any of these libraries end up in the<br>
transitive closure of your packages’ dependencies, then you will have<br>
these instances defined, regardless of your opinion of them, and<br>
regardless of their exclusion from base.<br>
<br>
To avoid this unhelpful outcome, if the community decided to forbid<br>
these instances, some language extension would have to be designed to<br>
forbid instance definitions.  This has been discussed previously.  If<br>
the community did this, it would break a lot of code that does use<br>
these instances, and there would be no workaround, as forbidding<br>
instances would have to be as global as defining instances.  Changing<br>
the fundamental property of type class instances that makes them not<br>
opt-in/opt-out, but automatically imported from transitive<br>
dependencies, would remove one of the properties of the language that<br>
(as Edward often argues) is a significant part of what makes Haskell<br>
more useful and healthy than some of its kin.<br>
<br>
This is not a matter that can be resolved but by consensus, at least<br>
not with the solutions that have been thus far proposed (simply<br>
removing the instances or accepting the instances as they are).  We do<br>
not appear to be approaching consensus on these particular solutions.<br>
Accepting the instances as they are does have the benefit of already<br>
being implemented and being used by a lot of code (but «we’ve always<br>
done things this way» is not a good design criterion).  Adding more<br>
instances for tuples would make the current situation more consistent,<br>
although perhaps proponents of removing these instances would prefer<br>
the current status quo: inconsistency, but less instances whose<br>
existence they reject.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>