Haskell Foldable Wats

[amindfv at gmail.com]

     What happened in the FTP was that the libraries@ had a heated discussion, the issue was taken to the users and to a vote, and we ended up with a clear message from users: 80% voted in one direction.
     My suspicion is that on this issue too, libraries@ is more divided than the community is. I suggest we try to put this issue to bed, and if ~80% of the community says they don't want these instances, then yes -- core libraries should use Writer instead of redefining their own instance for (,). Similarly, if ~80% want the instances, we can grumble that users are wrong but democracy has spoken.

Tom


El 24 feb 2016, a las 13:27, Manuel Gómez <targen at gmail.com> escribió:

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