Haskell Foldable Wats

[amindfv at gmail.com]

(Sorry, I should have said: "core libraries *may* need to use Writer instead of redefining an instance for (,)" -- I don't mean to rule out other technical solutions if they exist)

Tom


> El 24 feb 2016, a las 14:10, amindfv at gmail.com escribió:
> 
>     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.