Haskell Foldable Wats

Thu Feb 25 11:53:22 UTC 2016

In my opinion, democracy is the wrong way to design a programming language.

-----Original Message-----
From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of amindfv at gmail.com
Sent: 24 February 2016 19:11
To: Manuel Gómez
Cc: Haskell Libraries
Subject: Re: Haskell Foldable Wats

     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.
_______________________________________________
Libraries mailing list
Libraries at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products.