Haskell Foldable Wats

[Kris Nuttycombe]

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 at gmail.com> wrote:

> > El 24 feb 2016, a las 12:27, Chris Allen <cma at 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 at 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 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/20160224/35876bd4/attachment.html>