<div dir="ltr"><div><div>If I'm reading these threads correctly - and if I'm horribly mistaken then I apologise - they mostly are people from the 20% against FTP grumbling that the users are wrong, while a large chunk of the people from the 80% for FTP not wanting to spend that sizeable amount of energy again to debate an old argument. If that is the case then libraries@ may not be as divided as it seems.<br><br></div>To take it all back a step, unless I've missed a mail in this thread, we only have a proposal for adding Functor instances for tuples of larger size than 2.<br><br></div>If someone wants to put forward a proposal on how to remove the Functor / Foldable / Traversable instances for tuples - including how to deal with breakage in existing code and other migration issues - surely that's another thread, that would start when someone properly fleshes out the proposal.<br><div><div><br></div>Dave<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 25, 2016 at 5:10 AM, <span dir="ltr"><<a href="mailto:amindfv@gmail.com" target="_blank">amindfv@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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.<br>
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.<br>
<br>
Tom<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
El 24 feb 2016, a las 13:27, Manuel Gómez <<a href="mailto:targen@gmail.com">targen@gmail.com</a>> escribió:<br>
<br>
>> 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>
>> 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>
> 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>
_______________________________________________<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>