To pile on a bit,

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.

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)`.

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.*

Kris

On Wed, Feb 24, 2016 at 11:27 AM, Manuel Gómez <targen@gmail.com> wrote:
> El 24 feb 2016, a las 12:27, Chris Allen <cma@bitemyapp.com> escribió:
>
> You can't not-include the instances because we'll just end up with orphans
> so that's not cricket I think.

On Wed, Feb 24, 2016 at 1:41 PM,  <amindfv@gmail.com> wrote:
> I don't know what this means -- can you elaborate?
>
> (What I'm proposing is, since there is a sizeable number of people on both
> sides of the issue who don't seem to be coming closer to an agreement, we
> bring a vote *to the users* on whether to provide Foldable/Traversable
> instances for tuples of size 2 and greater. If users say they're useful, we
> keep/add 'em. If they find them confusing/not useful, we remove/don't add
> 'em)

If these instances were not included in base, then these instances
would nonetheless be made available to a large amount of code because
somebody will make a base-orphans library that will define these
instances, and many libraries written by authors who believe these
instances to be useful will depend on this package (or, worse yet,
define their own instances in their own packages which will clash with
each other and break things).  If any of these libraries end up in the
transitive closure of your packages’ dependencies, then you will have
these instances defined, regardless of your opinion of them, and
regardless of their exclusion from base.

To avoid this unhelpful outcome, if the community decided to forbid
these instances, some language extension would have to be designed to
forbid instance definitions.  This has been discussed previously.  If
the community did this, it would break a lot of code that does use
these instances, and there would be no workaround, as forbidding
instances would have to be as global as defining instances.  Changing
the fundamental property of type class instances that makes them not
opt-in/opt-out, but automatically imported from transitive
dependencies, would remove one of the properties of the language that
(as Edward often argues) is a significant part of what makes Haskell
more useful and healthy than some of its kin.

This is not a matter that can be resolved but by consensus, at least
not with the solutions that have been thus far proposed (simply
removing the instances or accepting the instances as they are).  We do
not appear to be approaching consensus on these particular solutions.
Accepting the instances as they are does have the benefit of already
being implemented and being used by a lot of code (but «we’ve always
done things this way» is not a good design criterion).  Adding more
instances for tuples would make the current situation more consistent,
although perhaps proponents of removing these instances would prefer
the current status quo: inconsistency, but less instances whose
existence they reject.
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries