From lemming at henning-thielemann.de  Thu Jan  1 10:20:34 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 1 Jan 2015 11:20:34 +0100 (CET)
Subject: Proposal: improve the Data.Tree API
In-Reply-To: <CAAbu24o1gt6c7JtFjZNK6_vpFckDRa+tHjrOq80P7bs1Gn6k9w@mail.gmail.com>
References: <CAAbu24oYFC=JybaderA5U=8GVppTusJ2HU9CLc5Mr3wRYpRqCw@mail.gmail.com>
 <530B2A49.8030605@ibotty.net>
 <CA+u6gbyWA_eP9pk5DPzdBCwS=Fhwf5nu6ehrVfRfB9LznCuLJw@mail.gmail.com>
 <CAAbu24pEk_42V=SVxDZUM8GSk21RJ=JQY5r-DZ6omk7Du+aV_w@mail.gmail.com>
 <CAAbu24oynqR0R9Nd5be2nbpLo4iocV_7HDJd3gNYbMK7sRJ+8A@mail.gmail.com>
 <20140301113143.GA4558@city.ac.uk>
 <CAOrUaLa005kM6SMq7KDUT=9cVwmU2YeOhm4q4WyaMrT24XH3AA@mail.gmail.com>
 <CAAbu24pYDgQMQMgKzXrcBF0cbRyLKm2-bJtgYYM6jNQkOWq4EQ@mail.gmail.com>
 <20140314081521.GA15180@auryn.cz> <5322C030.7070605@henning-thielemann.de>
 <20140314084940.GA15433@auryn.cz>
 <CAOrUaLZT05UR1HJVje+sB+NH8cSKMtaE2jHDvVgBEAWs6tow5g@mail.gmail.com>
 <CAMgWh9u-ru7JM=ukaVkNa52P+LVKiqBgnwx30gARz2GJTTMU5Q@mail.gmail.com>
 <CAOrUaLYmfrZyZPET0-xaPiX+e7ZYycOJ35aJ1_JzNMSiCgZudA@mail.gmail.com>
 <CAMgWh9vkyQb-bY=f2dzDGDnBvbrZUPHNSTrS9zhtkFsFJn6C8g@mail.gmail.com>
 <CAAbu24o1gt6c7JtFjZNK6_vpFckDRa+tHjrOq80P7bs1Gn6k9w@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1501011120090.18031@sputnik>


On Wed, 31 Dec 2014, Jo?o Crist?v?o wrote:

> For the record, nevertheless, I was moving along with the separate 
> Tree/Forest modules to avoid further bikeshedding, but to be honest I 
> don't really see a big advantage - if your using one, you most probably 
> will also need to use the other, so why two imports?

What is bad about two imports?

From jmacristovao at gmail.com  Thu Jan  1 14:53:31 2015
From: jmacristovao at gmail.com (=?UTF-8?B?Sm/Do28gQ3Jpc3TDs3bDo28=?=)
Date: Thu, 1 Jan 2015 14:53:31 +0000
Subject: Proposal: improve the Data.Tree API
In-Reply-To: <alpine.DEB.2.02.1501011120090.18031@sputnik>
References: <CAAbu24oYFC=JybaderA5U=8GVppTusJ2HU9CLc5Mr3wRYpRqCw@mail.gmail.com>
 <530B2A49.8030605@ibotty.net>
 <CA+u6gbyWA_eP9pk5DPzdBCwS=Fhwf5nu6ehrVfRfB9LznCuLJw@mail.gmail.com>
 <CAAbu24pEk_42V=SVxDZUM8GSk21RJ=JQY5r-DZ6omk7Du+aV_w@mail.gmail.com>
 <CAAbu24oynqR0R9Nd5be2nbpLo4iocV_7HDJd3gNYbMK7sRJ+8A@mail.gmail.com>
 <20140301113143.GA4558@city.ac.uk>
 <CAOrUaLa005kM6SMq7KDUT=9cVwmU2YeOhm4q4WyaMrT24XH3AA@mail.gmail.com>
 <CAAbu24pYDgQMQMgKzXrcBF0cbRyLKm2-bJtgYYM6jNQkOWq4EQ@mail.gmail.com>
 <20140314081521.GA15180@auryn.cz> <5322C030.7070605@henning-thielemann.de>
 <20140314084940.GA15433@auryn.cz>
 <CAOrUaLZT05UR1HJVje+sB+NH8cSKMtaE2jHDvVgBEAWs6tow5g@mail.gmail.com>
 <CAMgWh9u-ru7JM=ukaVkNa52P+LVKiqBgnwx30gARz2GJTTMU5Q@mail.gmail.com>
 <CAOrUaLYmfrZyZPET0-xaPiX+e7ZYycOJ35aJ1_JzNMSiCgZudA@mail.gmail.com>
 <CAMgWh9vkyQb-bY=f2dzDGDnBvbrZUPHNSTrS9zhtkFsFJn6C8g@mail.gmail.com>
 <CAAbu24o1gt6c7JtFjZNK6_vpFckDRa+tHjrOq80P7bs1Gn6k9w@mail.gmail.com>
 <alpine.DEB.2.02.1501011120090.18031@sputnik>
Message-ID: <CAAbu24rAdAx6_vk1VtPDtGVScBBBG5j_z6sBwOk_YVhL9cHtsQ@mail.gmail.com>

> What is bad about two imports?

It is a breaking change from the current Data.Tree API.

>From Milan' proposal:
> users would write
>  import qualified Data.Tree as Tree
>  import qualified Data.Tree.Forest as Forest
>and then use the methods as
>  Tree.lookupTree
>  Tree.filter
>and
>  Forest.filter

Which, I would guess, would imply turning:
Data.Tree.unfoldTree  -> Data.Tree.unfold
Data.Tree.unfoldForest -> Data.Tree.Forest.unfold

Thus breaking existing code.

But again, I don't have a strong opinion about this. What really matters is
to have the new functions (and comonad references) in the API.

Cheers,
Jo?o

2015-01-01 10:20 GMT+00:00 Henning Thielemann <lemming at henning-thielemann.de
>:

>
> On Wed, 31 Dec 2014, Jo?o Crist?v?o wrote:
>
>  For the record, nevertheless, I was moving along with the separate
>> Tree/Forest modules to avoid further bikeshedding, but to be honest I don't
>> really see a big advantage - if your using one, you most probably will also
>> need to use the other, so why two imports?
>>
>
> What is bad about two imports?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150101/ae7a3dc6/attachment.html>

From gale at sefer.org  Thu Jan  1 15:27:33 2015
From: gale at sefer.org (Yitzchak Gale)
Date: Thu, 1 Jan 2015 17:27:33 +0200
Subject: Proposal: improve the Data.Tree API
In-Reply-To: <CAAbu24rAdAx6_vk1VtPDtGVScBBBG5j_z6sBwOk_YVhL9cHtsQ@mail.gmail.com>
References: <CAAbu24oYFC=JybaderA5U=8GVppTusJ2HU9CLc5Mr3wRYpRqCw@mail.gmail.com>
 <530B2A49.8030605@ibotty.net>
 <CA+u6gbyWA_eP9pk5DPzdBCwS=Fhwf5nu6ehrVfRfB9LznCuLJw@mail.gmail.com>
 <CAAbu24pEk_42V=SVxDZUM8GSk21RJ=JQY5r-DZ6omk7Du+aV_w@mail.gmail.com>
 <CAAbu24oynqR0R9Nd5be2nbpLo4iocV_7HDJd3gNYbMK7sRJ+8A@mail.gmail.com>
 <20140301113143.GA4558@city.ac.uk>
 <CAOrUaLa005kM6SMq7KDUT=9cVwmU2YeOhm4q4WyaMrT24XH3AA@mail.gmail.com>
 <CAAbu24pYDgQMQMgKzXrcBF0cbRyLKm2-bJtgYYM6jNQkOWq4EQ@mail.gmail.com>
 <20140314081521.GA15180@auryn.cz> <5322C030.7070605@henning-thielemann.de>
 <20140314084940.GA15433@auryn.cz>
 <CAOrUaLZT05UR1HJVje+sB+NH8cSKMtaE2jHDvVgBEAWs6tow5g@mail.gmail.com>
 <CAMgWh9u-ru7JM=ukaVkNa52P+LVKiqBgnwx30gARz2GJTTMU5Q@mail.gmail.com>
 <CAOrUaLYmfrZyZPET0-xaPiX+e7ZYycOJ35aJ1_JzNMSiCgZudA@mail.gmail.com>
 <CAMgWh9vkyQb-bY=f2dzDGDnBvbrZUPHNSTrS9zhtkFsFJn6C8g@mail.gmail.com>
 <CAAbu24o1gt6c7JtFjZNK6_vpFckDRa+tHjrOq80P7bs1Gn6k9w@mail.gmail.com>
 <alpine.DEB.2.02.1501011120090.18031@sputnik>
 <CAAbu24rAdAx6_vk1VtPDtGVScBBBG5j_z6sBwOk_YVhL9cHtsQ@mail.gmail.com>
Message-ID: <CAOrUaLbfAo8HiJX2a1hc=jc-d1Ff85NvVL3SOeLRw=Y=awcQ9g@mail.gmail.com>

Henning Thielemann wrote:
>> What is bad about two imports?

Jo?o Crist?v?o wrote:
> It is a breaking change from the current Data.Tree API...
> would imply turning:
> Data.Tree.unfoldTree  -> Data.Tree.unfold
> Data.Tree.unfoldForest -> Data.Tree.Forest.unfold
> Thus breaking existing code.

I didn't envision this as being a breaking change,
at least not immediately. I think the idea is:

1. Leave everything currently in Data.Tree as it is.

2. For new functions that apply to trees, put them
into Data.Tree, and if there are versions of those
that apply to forests, put those into Data.Tree.Forest
with the same name.

3. For existing functions in Data.Tree that explicitly
include "Tree" or "Forest" as part of the function name,
provide aliases using the above scheme. Perhaps mark
the old versions as deprecated, but don't get rid of them
yet.

4. Use Henning's internal module trick to work around
circular module dependencies, re-exporting and/or renaming
functions in the modules they need to appear in for the API.

Also, re-export Forest itself from Data.Tree.Forest, just
because if we don't it would look silly.

Thanks,
Yitz

From jmacristovao at gmail.com  Thu Jan  1 15:42:09 2015
From: jmacristovao at gmail.com (=?UTF-8?B?Sm/Do28gQ3Jpc3TDs3bDo28=?=)
Date: Thu, 1 Jan 2015 15:42:09 +0000
Subject: Proposal: improve the Data.Tree API
In-Reply-To: <CAOrUaLbfAo8HiJX2a1hc=jc-d1Ff85NvVL3SOeLRw=Y=awcQ9g@mail.gmail.com>
References: <CAAbu24oYFC=JybaderA5U=8GVppTusJ2HU9CLc5Mr3wRYpRqCw@mail.gmail.com>
 <530B2A49.8030605@ibotty.net>
 <CA+u6gbyWA_eP9pk5DPzdBCwS=Fhwf5nu6ehrVfRfB9LznCuLJw@mail.gmail.com>
 <CAAbu24pEk_42V=SVxDZUM8GSk21RJ=JQY5r-DZ6omk7Du+aV_w@mail.gmail.com>
 <CAAbu24oynqR0R9Nd5be2nbpLo4iocV_7HDJd3gNYbMK7sRJ+8A@mail.gmail.com>
 <20140301113143.GA4558@city.ac.uk>
 <CAOrUaLa005kM6SMq7KDUT=9cVwmU2YeOhm4q4WyaMrT24XH3AA@mail.gmail.com>
 <CAAbu24pYDgQMQMgKzXrcBF0cbRyLKm2-bJtgYYM6jNQkOWq4EQ@mail.gmail.com>
 <20140314081521.GA15180@auryn.cz> <5322C030.7070605@henning-thielemann.de>
 <20140314084940.GA15433@auryn.cz>
 <CAOrUaLZT05UR1HJVje+sB+NH8cSKMtaE2jHDvVgBEAWs6tow5g@mail.gmail.com>
 <CAMgWh9u-ru7JM=ukaVkNa52P+LVKiqBgnwx30gARz2GJTTMU5Q@mail.gmail.com>
 <CAOrUaLYmfrZyZPET0-xaPiX+e7ZYycOJ35aJ1_JzNMSiCgZudA@mail.gmail.com>
 <CAMgWh9vkyQb-bY=f2dzDGDnBvbrZUPHNSTrS9zhtkFsFJn6C8g@mail.gmail.com>
 <CAAbu24o1gt6c7JtFjZNK6_vpFckDRa+tHjrOq80P7bs1Gn6k9w@mail.gmail.com>
 <alpine.DEB.2.02.1501011120090.18031@sputnik>
 <CAAbu24rAdAx6_vk1VtPDtGVScBBBG5j_z6sBwOk_YVhL9cHtsQ@mail.gmail.com>
 <CAOrUaLbfAo8HiJX2a1hc=jc-d1Ff85NvVL3SOeLRw=Y=awcQ9g@mail.gmail.com>
Message-ID: <CAAbu24pkZ_+42_zPocOs3ten14xWJeu7hE6DL8=icZSPREgnpg@mail.gmail.com>

Ok, that seems great!

2015-01-01 15:27 GMT+00:00 Yitzchak Gale <gale at sefer.org>:

> Henning Thielemann wrote:
> >> What is bad about two imports?
>
> Jo?o Crist?v?o wrote:
> > It is a breaking change from the current Data.Tree API...
> > would imply turning:
> > Data.Tree.unfoldTree  -> Data.Tree.unfold
> > Data.Tree.unfoldForest -> Data.Tree.Forest.unfold
> > Thus breaking existing code.
>
> I didn't envision this as being a breaking change,
> at least not immediately. I think the idea is:
>
> 1. Leave everything currently in Data.Tree as it is.
>
> 2. For new functions that apply to trees, put them
> into Data.Tree, and if there are versions of those
> that apply to forests, put those into Data.Tree.Forest
> with the same name.
>
> 3. For existing functions in Data.Tree that explicitly
> include "Tree" or "Forest" as part of the function name,
> provide aliases using the above scheme. Perhaps mark
> the old versions as deprecated, but don't get rid of them
> yet.
>
> 4. Use Henning's internal module trick to work around
> circular module dependencies, re-exporting and/or renaming
> functions in the modules they need to appear in for the API.
>
> Also, re-export Forest itself from Data.Tree.Forest, just
> because if we don't it would look silly.
>
> Thanks,
> Yitz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150101/93f42e37/attachment.html>

From lemming at henning-thielemann.de  Fri Jan  2 09:50:51 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 2 Jan 2015 10:50:51 +0100 (CET)
Subject: change of strictness in zipWith
Message-ID: <alpine.DEB.2.02.1501021045190.6370@sputnik>


$ ghci-7.8.4 -Wall
Prelude> zipWith (==) "" undefined
[]

$ ghci-7.10.0.20141227 -Wall
Prelude> zipWith (==) "" undefined
*** Exception: Prelude.undefined


I found the difference because my mapAdjacent function uses 'tail' in the 
second argument of 'zipWith':

mapAdjacent :: (a -> a -> b) -> [a] -> [b]
mapAdjacent f xs = zipWith f xs (tail xs)


I get:

$ ghci-7.10.0.20141227 -Wall
*Prelude> Data.List.HT.mapAdjacent (==) ([] :: [Int])
*** Exception: Prelude.tail: empty list

From roma at ro-che.info  Fri Jan  2 09:55:48 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Fri, 02 Jan 2015 11:55:48 +0200
Subject: change of strictness in zipWith
In-Reply-To: <alpine.DEB.2.02.1501021045190.6370@sputnik>
References: <alpine.DEB.2.02.1501021045190.6370@sputnik>
Message-ID: <54A66B24.3010605@ro-che.info>

This is a big deal. That's a very common pattern.

On 02/01/15 11:50, Henning Thielemann wrote:
> 
> $ ghci-7.8.4 -Wall
> Prelude> zipWith (==) "" undefined
> []
> 
> $ ghci-7.10.0.20141227 -Wall
> Prelude> zipWith (==) "" undefined
> *** Exception: Prelude.undefined
> 
> 
> I found the difference because my mapAdjacent function uses 'tail' in
> the second argument of 'zipWith':
> 
> mapAdjacent :: (a -> a -> b) -> [a] -> [b]
> mapAdjacent f xs = zipWith f xs (tail xs)
> 
> 
> I get:
> 
> $ ghci-7.10.0.20141227 -Wall
> *Prelude> Data.List.HT.mapAdjacent (==) ([] :: [Int])
> *** Exception: Prelude.tail: empty list
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
> 


From lemming at henning-thielemann.de  Fri Jan  2 10:00:00 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 2 Jan 2015 11:00:00 +0100 (CET)
Subject: change of strictness in zipWith
In-Reply-To: <54A66B24.3010605@ro-che.info>
References: <alpine.DEB.2.02.1501021045190.6370@sputnik>
 <54A66B24.3010605@ro-che.info>
Message-ID: <alpine.DEB.2.02.1501021057480.6370@sputnik>


On Fri, 2 Jan 2015, Roman Cheplyaka wrote:

> This is a big deal. That's a very common pattern.

However, I checked the Haskell 98 report (chapter 8, standard Prelude, 
PreludeList, page 120 in the PDF) and found that the new behaviour matches 
the specified one:

zipWith :: (a -> b -> c) -> [a] -> [b] -> [c]
zipWith z (a:as) (b:bs) = z a b : zipWith z as bs
zipWith _ _ _ = []

From roma at ro-che.info  Fri Jan  2 10:07:54 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Fri, 02 Jan 2015 12:07:54 +0200
Subject: change of strictness in zipWith
In-Reply-To: <alpine.DEB.2.02.1501021057480.6370@sputnik>
References: <alpine.DEB.2.02.1501021045190.6370@sputnik>
 <54A66B24.3010605@ro-che.info> <alpine.DEB.2.02.1501021057480.6370@sputnik>
Message-ID: <54A66DFA.1060907@ro-che.info>

I don't think it does. The first pattern (a:as) will be refuted, and the
second (b:bs) won't try to match at all.

On 02/01/15 12:00, Henning Thielemann wrote:
> 
> On Fri, 2 Jan 2015, Roman Cheplyaka wrote:
> 
>> This is a big deal. That's a very common pattern.
> 
> However, I checked the Haskell 98 report (chapter 8, standard Prelude,
> PreludeList, page 120 in the PDF) and found that the new behaviour
> matches the specified one:
> 
> zipWith :: (a -> b -> c) -> [a] -> [b] -> [c]
> zipWith z (a:as) (b:bs) = z a b : zipWith z as bs
> zipWith _ _ _ = []
> 


From lemming at henning-thielemann.de  Fri Jan  2 10:23:53 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 2 Jan 2015 11:23:53 +0100 (CET)
Subject: change of strictness in zipWith
In-Reply-To: <54A66DFA.1060907@ro-che.info>
References: <alpine.DEB.2.02.1501021045190.6370@sputnik>
 <54A66B24.3010605@ro-che.info> <alpine.DEB.2.02.1501021057480.6370@sputnik>
 <54A66DFA.1060907@ro-che.info>
Message-ID: <alpine.DEB.2.02.1501021118030.6370@sputnik>


On Fri, 2 Jan 2015, Roman Cheplyaka wrote:

> I don't think it does. The first pattern (a:as) will be refuted, and the
> second (b:bs) won't try to match at all.

right - stupid me

Then, the new behavior of zipWith is really a bug. I added a ticket:

https://ghc.haskell.org/trac/ghc/ticket/9949

From david.feuer at gmail.com  Fri Jan  2 14:14:26 2015
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 2 Jan 2015 09:14:26 -0500
Subject: change of strictness in zipWith
In-Reply-To: <alpine.DEB.2.02.1501021118030.6370@sputnik>
References: <alpine.DEB.2.02.1501021045190.6370@sputnik>
 <54A66B24.3010605@ro-che.info>
 <alpine.DEB.2.02.1501021057480.6370@sputnik>
 <54A66DFA.1060907@ro-che.info>
 <alpine.DEB.2.02.1501021118030.6370@sputnik>
Message-ID: <CAMgWh9v=SSN8NEWVNN6+yS4a8AOhzRZbv-8wS4Cbq12y-t-0fA@mail.gmail.com>

It was done intentionally, to avoid having the zipWith semantics depend on
which, if either, of the venerable foldr2 RULES fired. But I'd personally
be very happy to just nix the shady rule (the other is fine), and accept
the performance penalty.
On Jan 2, 2015 5:24 AM, "Henning Thielemann" <lemming at henning-thielemann.de>
wrote:

>
> On Fri, 2 Jan 2015, Roman Cheplyaka wrote:
>
>  I don't think it does. The first pattern (a:as) will be refuted, and the
>> second (b:bs) won't try to match at all.
>>
>
> right - stupid me
>
> Then, the new behavior of zipWith is really a bug. I added a ticket:
>
> https://ghc.haskell.org/trac/ghc/ticket/9949
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150102/19692f19/attachment.html>

From bertram.felgenhauer at googlemail.com  Sat Jan  3 00:26:02 2015
From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer)
Date: Sat, 3 Jan 2015 01:26:02 +0100
Subject: replace definition of error with errorWithStackTrace
In-Reply-To: <CAHYVw0w_Ug9xXFSMVU6YwABe8OtontyWcQG6ekdn_cW95_6wqg@mail.gmail.com>
References: <CAHYVw0ys-+yiNUodvX6XAHg3Zs_yXo2G7MmvRtWDVca3-i4T4Q@mail.gmail.com>
 <CAHfTQEhJVoV1fcz+4Rt3kO-uvvo9SvEO4z_cTxrii4uYhJAOnA@mail.gmail.com>
 <CADnndOq=Wm6-T7rpY1MfvtdvzmE4FOm3oHeckQ6RcZbCEytzvg@mail.gmail.com>
 <CAKA2JgK-g5hjkZj4bD9tw2ZffE_0pxBgs+GEZsGRqow6BGn3ig@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3F0320@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAK-tuPbpjetRr496O221HKjBM_Eo=MjMxTVxttVyz7WRDbbfgQ@mail.gmail.com>
 <20141225201026.GA3326@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f>
 <618BE556AADD624C9C918AA5D5911BEF5628E424@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAHYVw0w_Ug9xXFSMVU6YwABe8OtontyWcQG6ekdn_cW95_6wqg@mail.gmail.com>
Message-ID: <20150103002602.GD3326@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f>

Carter Schonwald wrote:
> how do profiling stack traces fit into that "Static" vs "Dynamic" continuum?

Except for the way they deal with recursion (if an SCC is already on
the SCC stack, then it is not pushed again), they're static traces,
going by the description at

  https://downloads.haskell.org/~ghc/7.8.3/docs/html/users_guide/profiling.html#prof-rules

Actually recursion poses an interesting problem for static traces;
it'd be awkward to see long traces like

  foo -> foo.go -> ... -> foo.go -> bar

just because foo does some kind of iteration.

BTW, I'm not completely happy with the terminology. The idea is that

* 'static' traces match the function calls visible in the program's
  source code.
* 'dynamic' traces very much depend on the evaluation order, which
  in practice means that they're subject to optimization choices of
  the compiler and non-determinism introduced by sparks and threads.

Perhaps 'call trace' and 'stack trace' are better names. A possible
downside with those terms is that they are familiar and used
interchangably for strict programming languages, so the fact that
there's a difference between them in Haskell is easily lost.

Cheers,

Bertram

From david.feuer at gmail.com  Sat Jan  3 20:31:29 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 3 Jan 2015 15:31:29 -0500
Subject: Upgrade MaybeT to AMP, and otherwise clean it up
In-Reply-To: <CAMgWh9sxyFbiqGUiGfP-=T2JqnK_THcboJ=PBR70Uu+mQUDM9w@mail.gmail.com>
References: <CAMgWh9u3AHSeYjzPULZn_36r1sKTVeVZiS=nSS90nhO9jn3asQ@mail.gmail.com>
 <CAMgWh9tXwZdQriaHyfaUoZgSYn4cW3TZZxqXcfMRWv-ccGqcxg@mail.gmail.com>
 <CAMgWh9sxyFbiqGUiGfP-=T2JqnK_THcboJ=PBR70Uu+mQUDM9w@mail.gmail.com>
Message-ID: <CAMgWh9sTBZubFV0pUgZcesPRBN3FsaxZUSdFp1==hDUAbb8Dqg@mail.gmail.com>

http://stackoverflow.com/questions/22750315/applicative-instance-for-maybet-m-assumes-monad-m
noted that

instance (Functor m, Monad m) => Applicative (MaybeT m)
instance (Functor m, Monad m) => Alternative (MaybeT m)

is not exactly ideal. An answer to the question explained why MaybeT isn't
really so important for Applicative, but that doesn't seem to be a good
reason to leave the status quo in place. If I'm not very much mistaken,
there are two issues:

1. The Functor constraint is never used, and of course every valid monad is
also a valid functor with fmap=liftM. So for pre-AMP base, the signatures
should have had only a Monad constraint, and not a Functor one.

2. For AMP, the constraints should be changed to require Applicative
instead of Monad.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150103/6e275e0a/attachment.html>

From R.Paterson at city.ac.uk  Sun Jan  4 02:18:55 2015
From: R.Paterson at city.ac.uk (Ross Paterson)
Date: Sun, 4 Jan 2015 02:18:55 +0000
Subject: Upgrade MaybeT to AMP, and otherwise clean it up
In-Reply-To: <CAMgWh9sTBZubFV0pUgZcesPRBN3FsaxZUSdFp1==hDUAbb8Dqg@mail.gmail.com>
References: <CAMgWh9u3AHSeYjzPULZn_36r1sKTVeVZiS=nSS90nhO9jn3asQ@mail.gmail.com>
 <CAMgWh9tXwZdQriaHyfaUoZgSYn4cW3TZZxqXcfMRWv-ccGqcxg@mail.gmail.com>
 <CAMgWh9sxyFbiqGUiGfP-=T2JqnK_THcboJ=PBR70Uu+mQUDM9w@mail.gmail.com>
 <CAMgWh9sTBZubFV0pUgZcesPRBN3FsaxZUSdFp1==hDUAbb8Dqg@mail.gmail.com>
Message-ID: <20150104021855.GA11837@city.ac.uk>

On Sat, Jan 03, 2015 at 03:31:29PM -0500, David Feuer wrote:
> http://stackoverflow.com/questions/22750315/
> applicative-instance-for-maybet-m-assumes-monad-m noted that
> 
> instance (Functor m, Monad m) => Applicative (MaybeT m)
> instance (Functor m, Monad m) => Alternative (MaybeT m)
> 
> is not exactly ideal. An answer to the question explained why MaybeT isn't
> really so important for Applicative, but that doesn't seem to be a good reason
> to leave the status quo in place. If I'm not very much mistaken, there are two
> issues:
> 
> 1. The Functor constraint is never used, and of course every valid monad is
> also a valid functor with fmap=liftM. So for pre-AMP base, the signatures
> should have had only a Monad constraint, and not a Functor one.

I guess the unused Functor constraint might as well be dropped -- it
will be redundant in the AMP world anyway.

> 2. For AMP, the constraints should be changed to require Applicative
> instead of Monad.

This instance will still require Monad even if Applicative is a
superclass.  We expect that applicatives that are also monads will satisfy
(<*>) = ap (though sometimes (<*>) will be more efficient, it should be
semantically equivalent).  Since ap doesn't execute the second action if
the first one fails, this requires that the inner constructor is a monad.
(The instance proposed at the above link doesn't meet this expectation;
it is equivalent to Errors ().)

From david.feuer at gmail.com  Sun Jan  4 02:47:22 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 3 Jan 2015 21:47:22 -0500
Subject: Upgrade MaybeT to AMP, and otherwise clean it up
In-Reply-To: <20150104021855.GA11837@city.ac.uk>
References: <CAMgWh9u3AHSeYjzPULZn_36r1sKTVeVZiS=nSS90nhO9jn3asQ@mail.gmail.com>
 <CAMgWh9tXwZdQriaHyfaUoZgSYn4cW3TZZxqXcfMRWv-ccGqcxg@mail.gmail.com>
 <CAMgWh9sxyFbiqGUiGfP-=T2JqnK_THcboJ=PBR70Uu+mQUDM9w@mail.gmail.com>
 <CAMgWh9sTBZubFV0pUgZcesPRBN3FsaxZUSdFp1==hDUAbb8Dqg@mail.gmail.com>
 <20150104021855.GA11837@city.ac.uk>
Message-ID: <CAMgWh9sGLMw3xJ1cX9f_5_MjmrT119jS=Ts0p2vn354y=Ufz5g@mail.gmail.com>

Yes, I see now that that's impossible. Sorry! I guess just drop the
redundant constraint.
On Jan 3, 2015 9:19 PM, "Ross Paterson" <R.Paterson at city.ac.uk> wrote:

> On Sat, Jan 03, 2015 at 03:31:29PM -0500, David Feuer wrote:
> > http://stackoverflow.com/questions/22750315/
> > applicative-instance-for-maybet-m-assumes-monad-m noted that
> >
> > instance (Functor m, Monad m) => Applicative (MaybeT m)
> > instance (Functor m, Monad m) => Alternative (MaybeT m)
> >
> > is not exactly ideal. An answer to the question explained why MaybeT
> isn't
> > really so important for Applicative, but that doesn't seem to be a good
> reason
> > to leave the status quo in place. If I'm not very much mistaken, there
> are two
> > issues:
> >
> > 1. The Functor constraint is never used, and of course every valid monad
> is
> > also a valid functor with fmap=liftM. So for pre-AMP base, the signatures
> > should have had only a Monad constraint, and not a Functor one.
>
> I guess the unused Functor constraint might as well be dropped -- it
> will be redundant in the AMP world anyway.
>
> > 2. For AMP, the constraints should be changed to require Applicative
> > instead of Monad.
>
> This instance will still require Monad even if Applicative is a
> superclass.  We expect that applicatives that are also monads will satisfy
> (<*>) = ap (though sometimes (<*>) will be more efficient, it should be
> semantically equivalent).  Since ap doesn't execute the second action if
> the first one fails, this requires that the inner constructor is a monad.
> (The instance proposed at the above link doesn't meet this expectation;
> it is equivalent to Errors ().)
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150103/ed54d73e/attachment.html>

From R.Paterson at city.ac.uk  Sun Jan  4 15:20:22 2015
From: R.Paterson at city.ac.uk (Ross Paterson)
Date: Sun, 4 Jan 2015 15:20:22 +0000
Subject: Upgrade MaybeT to AMP, and otherwise clean it up
In-Reply-To: <20150104021855.GA11837@city.ac.uk>
References: <CAMgWh9u3AHSeYjzPULZn_36r1sKTVeVZiS=nSS90nhO9jn3asQ@mail.gmail.com>
 <CAMgWh9tXwZdQriaHyfaUoZgSYn4cW3TZZxqXcfMRWv-ccGqcxg@mail.gmail.com>
 <CAMgWh9sxyFbiqGUiGfP-=T2JqnK_THcboJ=PBR70Uu+mQUDM9w@mail.gmail.com>
 <CAMgWh9sTBZubFV0pUgZcesPRBN3FsaxZUSdFp1==hDUAbb8Dqg@mail.gmail.com>
 <20150104021855.GA11837@city.ac.uk>
Message-ID: <20150104152022.GA3331@city.ac.uk>

On Sun, Jan 04, 2015 at 02:18:55AM +0000, Ross Paterson wrote:
> On Sat, Jan 03, 2015 at 03:31:29PM -0500, David Feuer wrote:
> > http://stackoverflow.com/questions/22750315/
> [...]
> (The instance proposed at the above link doesn't meet this expectation;
> it is equivalent to Errors ().)

Correction: it is equivalent to Compose Maybe

From mblazevic at stilo.com  Mon Jan  5 16:53:11 2015
From: mblazevic at stilo.com (=?UTF-8?B?TWFyaW8gQmxhxb5ldmnEhw==?=)
Date: Mon, 05 Jan 2015 11:53:11 -0500
Subject: Generalize filterM to Applicative
In-Reply-To: <CAMgWh9tYKPncD5Bb_Boqo8HPwjXpem+fhg_of6LK1upzhMBvnQ@mail.gmail.com>
References: <CAMgWh9v3poZ9NFFyEwrrhD_1YL9x7OKKCGVf_wT4R1kDTWzKDA@mail.gmail.com>
 <CAOrUaLaGPME0t8iFK25X1KfUEFYfXfNcN+OVhnYuZiwNWWmETw@mail.gmail.com>
 <CAJumaK_+z5i7B-c7UrZBVVcAKANoDMQGTw27PPSihK-jW9YDvQ@mail.gmail.com>
 <CAPY+ZdQAtoRSAvBNnRnZqxvW6SuHQFT1tyqDRAK5Wj+d9fRVgw@mail.gmail.com>
 <54A19DFC.7000909@ifi.lmu.de>
 <CAJumaK83zZx6xYtVguuV8gmT22+wy7NOBrD4uFBuvsbB=qBUqg@mail.gmail.com>
 <CAMgWh9tYKPncD5Bb_Boqo8HPwjXpem+fhg_of6LK1upzhMBvnQ@mail.gmail.com>
Message-ID: <54AAC177.8070600@stilo.com>

On 14-12-30 12:34 PM, David Feuer wrote:
> I realized just now that we can actually make the type a little bit
> more general still, interpreting `filterM` for lists as being an
> applicative filter *producing* lists:
>
> filterM :: (Applicative f, Foldable t) => (a -> f Bool) -> t a -> f [a]

	I'm +1 on the more limited generalization proposal, but not on this 
one. I've been feeling for a while that we need a subclass of 
Traversable to generalize functions like filter, mapMaybe, and partition 
(potentially span, splitAt and others as well). If you call this missing 
class Filterable, the properly-generalized signature would be

 > filterM :: (Applicative f, Filterable t) =>
 > (a -> f Bool) -> t a -> f (t a)



>
> On Mon, Dec 29, 2014 at 3:17 PM, Edward Kmett <ekmett at gmail.com> wrote:
>> I think this is the interpretation I think we're probably best left with.
>>
>> I agree that names matter and that anachronistic labels confuse, but I think
>> it is the lesser of evils to widen the definition of the 'M' suffix than it
>> is to double up on almost all the names taken in the environment and force
>> the entire community to go through a positively gigantic deprecation cycle.
>>
>> -Edward
>>
>> On Mon, Dec 29, 2014 at 1:31 PM, Andreas Abel <andreas.abel at ifi.lmu.de>
>> wrote:
>>>
>>> Or you can widen the interpretation of suffix ...M as "effectful", which
>>> could be a monadic or applicative effect.
>>>
>>> On 29.12.2014 16:50, Kim-Ee Yeoh wrote:
>>>>
>>>>
>>>> On Mon, Dec 29, 2014 at 7:58 PM, Edward Kmett <ekmett at gmail.com
>>>> <mailto:ekmett at gmail.com>> wrote:
>>>>
>>>>      Is it "madness" to want to avoid namespace proliferation and
>>>>      maximize the usefulness of an existing combinator now that the
>>>>      constraints that forged it have changed to allow it to be slightly
>>>>      more permissive?
>>>>
>>>>
>>>> Madness is such strong language for this august list.
>>>>
>>>> May I speak on behalf of haskell newcomers for a time?
>>>>
>>>> Haskell places such an emphasis on uniformity and regularity. Functions
>>>> with names that end with M once meant they were monadic variants of
>>>> those that don't. That's no longer uniformly the case, because of the
>>>> FAM restructuring.
>>>>
>>>> The names of functions matter.
>>>>
>>>> Anachronistic labels confuse.
>>>>
>>>> Leaving filterM with a type signature of Applicative cannot be the
>>>> long-term solution.
>>>>
>>>> -- Kim-Ee
>>>>
>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>
>>>
>>>
>>> --
>>> Andreas Abel  <><      Du bist der geliebte Mensch.
>>>
>>> Department of Computer Science and Engineering
>>> Chalmers and Gothenburg University, Sweden
>>>
>>> andreas.abel at gu.se
>>> http://www2.tcs.ifi.lmu.de/~abel/
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>


-- 
Mario Blazevic
mblazevic at stilo.com
Stilo International

This message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure, copying, or
distribution is strictly prohibited. If you are not the intended
recipient(s) please contact the sender by reply email and destroy
all copies of the original message and any attachments.

From ezyang at mit.edu  Mon Jan  5 22:25:35 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Mon, 05 Jan 2015 14:25:35 -0800
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
Message-ID: <1420496644-sup-4814@sabre>

Discussion period: one month

I propose to backwards incompatibly change the behavior of
removeDirectoryRecursive to not follow symlinks.  We could optionally
add a replacement function under a new name which does follow symlinks.

This would bring its behavior inline with rm -rf.

I also opened a ticket here: https://ghc.haskell.org/trac/ghc/ticket/9266

Thanks,
Edward

From david.feuer at gmail.com  Mon Jan  5 22:31:00 2015
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 5 Jan 2015 17:31:00 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <1420496644-sup-4814@sabre>
References: <1420496644-sup-4814@sabre>
Message-ID: <CAMgWh9vr86kJkCkFxMrQJ_ceb7o6cCJDUWGMLxoprOiOSqeWFA@mail.gmail.com>

+1. Following symlinks in such a potentially-destructive operation is
fundamentally wrong.

On Mon, Jan 5, 2015 at 5:25 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> Discussion period: one month
>
> I propose to backwards incompatibly change the behavior of
> removeDirectoryRecursive to not follow symlinks.  We could optionally
> add a replacement function under a new name which does follow symlinks.
>
> This would bring its behavior inline with rm -rf.
>
> I also opened a ticket here: https://ghc.haskell.org/trac/ghc/ticket/9266
>
> Thanks,
> Edward
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

From greg at gregweber.info  Mon Jan  5 22:33:41 2015
From: greg at gregweber.info (Greg Weber)
Date: Mon, 5 Jan 2015 14:33:41 -0800
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAMgWh9vr86kJkCkFxMrQJ_ceb7o6cCJDUWGMLxoprOiOSqeWFA@mail.gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAMgWh9vr86kJkCkFxMrQJ_ceb7o6cCJDUWGMLxoprOiOSqeWFA@mail.gmail.com>
Message-ID: <CAKRanNCFAFZULcf4Uzu0E9AhPdzEH3tcz=s2YUHJEbAW8Tqwjw@mail.gmail.com>

How about being backwards-compatible friendly by adding a new function with
the friendly behavior, adding a deprecation notice to the existing
function, and putting the existing function under a new name that signifies
the -rf? That would put me at a +1

On Mon, Jan 5, 2015 at 2:31 PM, David Feuer <david.feuer at gmail.com> wrote:

> +1. Following symlinks in such a potentially-destructive operation is
> fundamentally wrong.
>
> On Mon, Jan 5, 2015 at 5:25 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> > Discussion period: one month
> >
> > I propose to backwards incompatibly change the behavior of
> > removeDirectoryRecursive to not follow symlinks.  We could optionally
> > add a replacement function under a new name which does follow symlinks.
> >
> > This would bring its behavior inline with rm -rf.
> >
> > I also opened a ticket here:
> https://ghc.haskell.org/trac/ghc/ticket/9266
> >
> > Thanks,
> > Edward
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150105/9a17399c/attachment.html>

From allbery.b at gmail.com  Mon Jan  5 22:39:50 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 5 Jan 2015 17:39:50 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAKRanNCFAFZULcf4Uzu0E9AhPdzEH3tcz=s2YUHJEbAW8Tqwjw@mail.gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAMgWh9vr86kJkCkFxMrQJ_ceb7o6cCJDUWGMLxoprOiOSqeWFA@mail.gmail.com>
 <CAKRanNCFAFZULcf4Uzu0E9AhPdzEH3tcz=s2YUHJEbAW8Tqwjw@mail.gmail.com>
Message-ID: <CAKFCL4VfH6mOmX9UoZbAz745abhwJvHJBLhqwsn9fiT3W3XPPA@mail.gmail.com>

On Mon, Jan 5, 2015 at 5:33 PM, Greg Weber <greg at gregweber.info> wrote:

> How about being backwards-compatible friendly by adding a new function
> with the friendly behavior, adding a deprecation notice to the existing
> function, and putting the existing function under a new name that signifies
> the -rf? That would put me at a +1
>

To be honest, that it followed symlinks in the first place is arguably a
severe bug and also violates people's expectations. I suspect most existing
users would either be (a) applying it to something they created with a
known safe structure, so the change is irrelevant, or (b) horrified at the
unexpected lurking bug.

Functions like this should not follow symlinks.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150105/c0029225/attachment.html>

From david.feuer at gmail.com  Mon Jan  5 22:41:12 2015
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 5 Jan 2015 17:41:12 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAKRanNCFAFZULcf4Uzu0E9AhPdzEH3tcz=s2YUHJEbAW8Tqwjw@mail.gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAMgWh9vr86kJkCkFxMrQJ_ceb7o6cCJDUWGMLxoprOiOSqeWFA@mail.gmail.com>
 <CAKRanNCFAFZULcf4Uzu0E9AhPdzEH3tcz=s2YUHJEbAW8Tqwjw@mail.gmail.com>
Message-ID: <CAMgWh9uxCfO9x3sP7DsTGf6Es6QC1b5frsdOkXAd2uADJH755g@mail.gmail.com>

This is much, much worse than -rf. GNU rm, at least, offers no way at
all to get the current behavior of removeDirectoryRecursive. I don't
think it's okay to leave it in the library by this name, and I'm a
moderate -1 on giving it a new name.

On Mon, Jan 5, 2015 at 5:33 PM, Greg Weber <greg at gregweber.info> wrote:
> How about being backwards-compatible friendly by adding a new function with
> the friendly behavior, adding a deprecation notice to the existing function,
> and putting the existing function under a new name that signifies the -rf?
> That would put me at a +1
>
> On Mon, Jan 5, 2015 at 2:31 PM, David Feuer <david.feuer at gmail.com> wrote:
>>
>> +1. Following symlinks in such a potentially-destructive operation is
>> fundamentally wrong.
>>
>> On Mon, Jan 5, 2015 at 5:25 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
>> > Discussion period: one month
>> >
>> > I propose to backwards incompatibly change the behavior of
>> > removeDirectoryRecursive to not follow symlinks.  We could optionally
>> > add a replacement function under a new name which does follow symlinks.
>> >
>> > This would bring its behavior inline with rm -rf.
>> >
>> > I also opened a ticket here:
>> > https://ghc.haskell.org/trac/ghc/ticket/9266
>> >
>> > Thanks,
>> > Edward
>> > _______________________________________________
>> > Libraries mailing list
>> > Libraries at haskell.org
>> > http://www.haskell.org/mailman/listinfo/libraries
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>
>

From ezyang at mit.edu  Mon Jan  5 22:43:05 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Mon, 05 Jan 2015 14:43:05 -0800
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAKRanNCFAFZULcf4Uzu0E9AhPdzEH3tcz=s2YUHJEbAW8Tqwjw@mail.gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAMgWh9vr86kJkCkFxMrQJ_ceb7o6cCJDUWGMLxoprOiOSqeWFA@mail.gmail.com>
 <CAKRanNCFAFZULcf4Uzu0E9AhPdzEH3tcz=s2YUHJEbAW8Tqwjw@mail.gmail.com>
Message-ID: <1420497730-sup-3169@sabre>

Sure, I'm happy for someone to put this forward as a counterproposal.

My reasoning for changing the meaning of the identifier: I'm pretty
sure almost everyone using the current function doesn't actually
want to follow symlinks.  To actually verify this I'd have to do
some Hackage spelunking.

Edward

Excerpts from Greg Weber's message of 2015-01-05 14:33:41 -0800:
> How about being backwards-compatible friendly by adding a new function with
> the friendly behavior, adding a deprecation notice to the existing
> function, and putting the existing function under a new name that signifies
> the -rf? That would put me at a +1
> 
> On Mon, Jan 5, 2015 at 2:31 PM, David Feuer <david.feuer at gmail.com> wrote:
> 
> > +1. Following symlinks in such a potentially-destructive operation is
> > fundamentally wrong.
> >
> > On Mon, Jan 5, 2015 at 5:25 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> > > Discussion period: one month
> > >
> > > I propose to backwards incompatibly change the behavior of
> > > removeDirectoryRecursive to not follow symlinks.  We could optionally
> > > add a replacement function under a new name which does follow symlinks.
> > >
> > > This would bring its behavior inline with rm -rf.
> > >
> > > I also opened a ticket here:
> > https://ghc.haskell.org/trac/ghc/ticket/9266
> > >
> > > Thanks,
> > > Edward
> > > _______________________________________________
> > > Libraries mailing list
> > > Libraries at haskell.org
> > > http://www.haskell.org/mailman/listinfo/libraries
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> >

From spam at scientician.net  Mon Jan  5 22:46:38 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Mon, 05 Jan 2015 23:46:38 +0100
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <1420496644-sup-4814@sabre>
References: <1420496644-sup-4814@sabre>
Message-ID: <m8f48e$c2q$1@ger.gmane.org>

On 2015-01-05 23:25, Edward Z. Yang wrote:
> Discussion period: one month
> 
> I propose to backwards incompatibly change the behavior of
> removeDirectoryRecursive to not follow symlinks.  We could optionally
> add a replacement function under a new name which does follow symlinks.
> 
> This would bring its behavior inline with rm -rf.
> 
> I also opened a ticket here: https://ghc.haskell.org/trac/ghc/ticket/9266
> 
> Thanks,
> Edward
> 

+1 as is.

-1 on adding a deprecation cycle unless someone can come up with a
REALLY good reason for that.



From andreas.abel at ifi.lmu.de  Mon Jan  5 22:51:35 2015
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Mon, 05 Jan 2015 23:51:35 +0100
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <m8f48e$c2q$1@ger.gmane.org>
References: <1420496644-sup-4814@sabre> <m8f48e$c2q$1@ger.gmane.org>
Message-ID: <54AB1577.3050303@ifi.lmu.de>

+1 to change implementation as proposed.

On 05.01.2015 23:46, Bardur Arantsson wrote:
> On 2015-01-05 23:25, Edward Z. Yang wrote:
>> Discussion period: one month
>>
>> I propose to backwards incompatibly change the behavior of
>> removeDirectoryRecursive to not follow symlinks.  We could optionally
>> add a replacement function under a new name which does follow symlinks.
>>
>> This would bring its behavior inline with rm -rf.
>>
>> I also opened a ticket here: https://ghc.haskell.org/trac/ghc/ticket/9266
>>
>> Thanks,
>> Edward
>>
>
> +1 as is.
>
> -1 on adding a deprecation cycle unless someone can come up with a
> REALLY good reason for that.
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>


-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/

From johan.tibell at gmail.com  Mon Jan  5 22:54:40 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 5 Jan 2015 17:54:40 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <54AB1577.3050303@ifi.lmu.de>
References: <1420496644-sup-4814@sabre> <m8f48e$c2q$1@ger.gmane.org>
 <54AB1577.3050303@ifi.lmu.de>
Message-ID: <CAK-tuPZnJ7d00p+8i5mqyt+Azg-xm+oLCDL=vXkH5Bum+ytXcw@mail.gmail.com>

-1 For changing the existing function.

+1 For adding it under a different name. +1 to adding a deprecation pragma
to the old one, if we consider the old behavior harmful to users.

Aside: can we look at what other languages with similar functions do?

On Mon, Jan 5, 2015 at 5:51 PM, Andreas Abel <andreas.abel at ifi.lmu.de>
wrote:

> +1 to change implementation as proposed.
>
>
> On 05.01.2015 23:46, Bardur Arantsson wrote:
>
>> On 2015-01-05 23:25, Edward Z. Yang wrote:
>>
>>> Discussion period: one month
>>>
>>> I propose to backwards incompatibly change the behavior of
>>> removeDirectoryRecursive to not follow symlinks.  We could optionally
>>> add a replacement function under a new name which does follow symlinks.
>>>
>>> This would bring its behavior inline with rm -rf.
>>>
>>> I also opened a ticket here: https://ghc.haskell.org/trac/
>>> ghc/ticket/9266
>>>
>>> Thanks,
>>> Edward
>>>
>>>
>> +1 as is.
>>
>> -1 on adding a deprecation cycle unless someone can come up with a
>> REALLY good reason for that.
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>
> --
> Andreas Abel  <><      Du bist der geliebte Mensch.
>
> Department of Computer Science and Engineering
> Chalmers and Gothenburg University, Sweden
>
> andreas.abel at gu.se
> http://www2.tcs.ifi.lmu.de/~abel/
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150105/adeaacf9/attachment.html>

From allbery.b at gmail.com  Mon Jan  5 23:44:33 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 5 Jan 2015 18:44:33 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAK-tuPZnJ7d00p+8i5mqyt+Azg-xm+oLCDL=vXkH5Bum+ytXcw@mail.gmail.com>
References: <1420496644-sup-4814@sabre> <m8f48e$c2q$1@ger.gmane.org>
 <54AB1577.3050303@ifi.lmu.de>
 <CAK-tuPZnJ7d00p+8i5mqyt+Azg-xm+oLCDL=vXkH5Bum+ytXcw@mail.gmail.com>
Message-ID: <CAKFCL4V0iWPA8+M4w=EU9Oh6DQXJtSjjCFT5bpDkHb6YCpF0kA@mail.gmail.com>

On Mon, Jan 5, 2015 at 5:54 PM, Johan Tibell <johan.tibell at gmail.com> wrote:

> Aside: can we look at what other languages with similar functions do?


You will find that essentially all other implementations do the right thing
and not follow symlinks, because the other behavior is a severe bug. I
really do not understand why anyone believes the current behavior is
defensible.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150105/7208abae/attachment.html>

From david.feuer at gmail.com  Mon Jan  5 23:51:27 2015
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 5 Jan 2015 18:51:27 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAKFCL4V0iWPA8+M4w=EU9Oh6DQXJtSjjCFT5bpDkHb6YCpF0kA@mail.gmail.com>
References: <1420496644-sup-4814@sabre> <m8f48e$c2q$1@ger.gmane.org>
 <54AB1577.3050303@ifi.lmu.de>
 <CAK-tuPZnJ7d00p+8i5mqyt+Azg-xm+oLCDL=vXkH5Bum+ytXcw@mail.gmail.com>
 <CAKFCL4V0iWPA8+M4w=EU9Oh6DQXJtSjjCFT5bpDkHb6YCpF0kA@mail.gmail.com>
Message-ID: <CAMgWh9vuS6v7+WxuvtgBw00Fe8EeEwn2=Pknvqi=VVFHXkXrpA@mail.gmail.com>

In case some people don't understand just how horrible this is: imagine a
privileged user uses this to erase a user's home directory. It could easily
hit a symbolic link to a critical system directory and hose the whole
machine.
On Jan 5, 2015 6:44 PM, "Brandon Allbery" <allbery.b at gmail.com> wrote:

> On Mon, Jan 5, 2015 at 5:54 PM, Johan Tibell <johan.tibell at gmail.com>
> wrote:
>
>> Aside: can we look at what other languages with similar functions do?
>
>
> You will find that essentially all other implementations do the right
> thing and not follow symlinks, because the other behavior is a severe bug.
> I really do not understand why anyone believes the current behavior is
> defensible.
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150105/82311aa4/attachment.html>

From amindfv at gmail.com  Tue Jan  6 00:50:46 2015
From: amindfv at gmail.com (amindfv at gmail.com)
Date: Mon, 5 Jan 2015 19:50:46 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAKFCL4V0iWPA8+M4w=EU9Oh6DQXJtSjjCFT5bpDkHb6YCpF0kA@mail.gmail.com>
References: <1420496644-sup-4814@sabre> <m8f48e$c2q$1@ger.gmane.org>
 <54AB1577.3050303@ifi.lmu.de>
 <CAK-tuPZnJ7d00p+8i5mqyt+Azg-xm+oLCDL=vXkH5Bum+ytXcw@mail.gmail.com>
 <CAKFCL4V0iWPA8+M4w=EU9Oh6DQXJtSjjCFT5bpDkHb6YCpF0kA@mail.gmail.com>
Message-ID: <023F16C4-BEA8-43A5-AFBD-1AC5C2DB06E2@gmail.com>

Wow, I did not realize this was the behavior. I would consider it a major bug.

+1 to removing, -1 to any deprecation periods or delay, +0 to adding the existing function with a new name (as long as warnings are clearly visible)

I would also support backporting a warning to haddocks for versions before the "fix"

Tom


El Jan 5, 2015, a las 18:44, Brandon Allbery <allbery.b at gmail.com> escribi?:

> On Mon, Jan 5, 2015 at 5:54 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
>> Aside: can we look at what other languages with similar functions do?
> 
> You will find that essentially all other implementations do the right thing and not follow symlinks, because the other behavior is a severe bug. I really do not understand why anyone believes the current behavior is defensible.
> 
> -- 
> brandon s allbery kf8nh                               sine nomine associates
> allbery.b at gmail.com                                  ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150105/672aa367/attachment.html>

From austin at well-typed.com  Tue Jan  6 01:08:29 2015
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 5 Jan 2015 19:08:29 -0600
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAMgWh9vuS6v7+WxuvtgBw00Fe8EeEwn2=Pknvqi=VVFHXkXrpA@mail.gmail.com>
References: <1420496644-sup-4814@sabre> <m8f48e$c2q$1@ger.gmane.org>
 <54AB1577.3050303@ifi.lmu.de>
 <CAK-tuPZnJ7d00p+8i5mqyt+Azg-xm+oLCDL=vXkH5Bum+ytXcw@mail.gmail.com>
 <CAKFCL4V0iWPA8+M4w=EU9Oh6DQXJtSjjCFT5bpDkHb6YCpF0kA@mail.gmail.com>
 <CAMgWh9vuS6v7+WxuvtgBw00Fe8EeEwn2=Pknvqi=VVFHXkXrpA@mail.gmail.com>
Message-ID: <CAEs96n3_Aa8cbcMX8jGp+s2-nw=hBG=3HbpjFYOCwfAQ-YnDjg@mail.gmail.com>

On Mon, Jan 5, 2015 at 5:51 PM, David Feuer <david.feuer at gmail.com> wrote:
> In case some people don't understand just how horrible this is: imagine a
> privileged user uses this to erase a user's home directory. It could easily
> hit a symbolic link to a critical system directory and hose the whole
> machine.

I think it's potentially even worse than that: this subtle behavior
could easily be abused for this exact scenario by a hostile entity.
Imagine a scenario where an attacker may have permission to place a
symlink somewhere that a privileged process recursively removes; then
your / (or any number of things) goes 'boom'. This could easily happen
through a combination of a race condition (say, placing junk files in
/tmp you later remove, and the attacker races to place the symlink
there) and an improper umask setting. Or if the attacker simply may be
part of a group that allows access to something a program will remove,
etc etc.

I agree this behavior is fundamentally wrong, and I'm strongly +1 on
changing the existing behavior, which I think is the only sane thing
to do. Otherwise any existing callers of this function in old code
could very easily do The Wrong Thing if they don't get the memo.

I have no opinion on warnings or adding a function that preserves the
old behavior.

> On Jan 5, 2015 6:44 PM, "Brandon Allbery" <allbery.b at gmail.com> wrote:
>>
>> On Mon, Jan 5, 2015 at 5:54 PM, Johan Tibell <johan.tibell at gmail.com>
>> wrote:
>>>
>>> Aside: can we look at what other languages with similar functions do?
>>
>>
>> You will find that essentially all other implementations do the right
>> thing and not follow symlinks, because the other behavior is a severe bug. I
>> really do not understand why anyone believes the current behavior is
>> defensible.
>>
>> --
>> brandon s allbery kf8nh                               sine nomine
>> associates
>> allbery.b at gmail.com
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From johan.tibell at gmail.com  Tue Jan  6 01:16:37 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Mon, 5 Jan 2015 20:16:37 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAEs96n3_Aa8cbcMX8jGp+s2-nw=hBG=3HbpjFYOCwfAQ-YnDjg@mail.gmail.com>
References: <1420496644-sup-4814@sabre> <m8f48e$c2q$1@ger.gmane.org>
 <54AB1577.3050303@ifi.lmu.de>
 <CAK-tuPZnJ7d00p+8i5mqyt+Azg-xm+oLCDL=vXkH5Bum+ytXcw@mail.gmail.com>
 <CAKFCL4V0iWPA8+M4w=EU9Oh6DQXJtSjjCFT5bpDkHb6YCpF0kA@mail.gmail.com>
 <CAMgWh9vuS6v7+WxuvtgBw00Fe8EeEwn2=Pknvqi=VVFHXkXrpA@mail.gmail.com>
 <CAEs96n3_Aa8cbcMX8jGp+s2-nw=hBG=3HbpjFYOCwfAQ-YnDjg@mail.gmail.com>
Message-ID: <CAK-tuPaXMBRZ2CNGSdWLns3s31YRCzDqJXA7QS76-_kY-BWvSA@mail.gmail.com>

Let me make a wider comment about backwards compatibility. Many successful
programming languages (e.g. Java) *never* break backwards compatibility.
They deprecate (and only if the old API is too error prone for the
programmer) and add a new API. In my opinion breaking backwards
compatibility is almost never worth it*. Our libraries are already full of
#ifdefs and maintaining our core libraries (which I maintain some of) is a
headache because the code gets worse every time we "clean it up".

* And it's only worth it sometimes because we're still a relatively small
language, by usage.

On Mon, Jan 5, 2015 at 8:08 PM, Austin Seipp <austin at well-typed.com> wrote:

> On Mon, Jan 5, 2015 at 5:51 PM, David Feuer <david.feuer at gmail.com> wrote:
> > In case some people don't understand just how horrible this is: imagine a
> > privileged user uses this to erase a user's home directory. It could
> easily
> > hit a symbolic link to a critical system directory and hose the whole
> > machine.
>
> I think it's potentially even worse than that: this subtle behavior
> could easily be abused for this exact scenario by a hostile entity.
> Imagine a scenario where an attacker may have permission to place a
> symlink somewhere that a privileged process recursively removes; then
> your / (or any number of things) goes 'boom'. This could easily happen
> through a combination of a race condition (say, placing junk files in
> /tmp you later remove, and the attacker races to place the symlink
> there) and an improper umask setting. Or if the attacker simply may be
> part of a group that allows access to something a program will remove,
> etc etc.
>
> I agree this behavior is fundamentally wrong, and I'm strongly +1 on
> changing the existing behavior, which I think is the only sane thing
> to do. Otherwise any existing callers of this function in old code
> could very easily do The Wrong Thing if they don't get the memo.
>
> I have no opinion on warnings or adding a function that preserves the
> old behavior.
>
> > On Jan 5, 2015 6:44 PM, "Brandon Allbery" <allbery.b at gmail.com> wrote:
> >>
> >> On Mon, Jan 5, 2015 at 5:54 PM, Johan Tibell <johan.tibell at gmail.com>
> >> wrote:
> >>>
> >>> Aside: can we look at what other languages with similar functions do?
> >>
> >>
> >> You will find that essentially all other implementations do the right
> >> thing and not follow symlinks, because the other behavior is a severe
> bug. I
> >> really do not understand why anyone believes the current behavior is
> >> defensible.
> >>
> >> --
> >> brandon s allbery kf8nh                               sine nomine
> >> associates
> >> allbery.b at gmail.com
> >> ballbery at sinenomine.net
> >> unix, openafs, kerberos, infrastructure, xmonad
> >> http://sinenomine.net
> >>
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://www.haskell.org/mailman/listinfo/libraries
> >>
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> >
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150105/5dcb5a53/attachment.html>

From emertens at gmail.com  Tue Jan  6 01:22:11 2015
From: emertens at gmail.com (Eric Mertens)
Date: Tue, 06 Jan 2015 01:22:11 +0000
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
References: <1420496644-sup-4814@sabre> <m8f48e$c2q$1@ger.gmane.org>
 <54AB1577.3050303@ifi.lmu.de>
 <CAK-tuPZnJ7d00p+8i5mqyt+Azg-xm+oLCDL=vXkH5Bum+ytXcw@mail.gmail.com>
 <CAKFCL4V0iWPA8+M4w=EU9Oh6DQXJtSjjCFT5bpDkHb6YCpF0kA@mail.gmail.com>
 <CAMgWh9vuS6v7+WxuvtgBw00Fe8EeEwn2=Pknvqi=VVFHXkXrpA@mail.gmail.com>
 <CAEs96n3_Aa8cbcMX8jGp+s2-nw=hBG=3HbpjFYOCwfAQ-YnDjg@mail.gmail.com>
 <CAK-tuPaXMBRZ2CNGSdWLns3s31YRCzDqJXA7QS76-_kY-BWvSA@mail.gmail.com>
Message-ID: <CALya090FjXDMXkTeNj-EjyvRvSLGpA_b3hn5HgzeZPi=rvU5+g@mail.gmail.com>

I'm concerned that changing the behavior of the existing function would
make it too easy to write vulnerable programs when compiled with older
GHCs. Having a new safe function along with a deprecation warning on the
old one would clue people in and avoid functionality varying
subtly/dangerously based on the compiler used.

On Mon, Jan 5, 2015, 5:17 PM Johan Tibell <johan.tibell at gmail.com> wrote:

> Let me make a wider comment about backwards compatibility. Many successful
> programming languages (e.g. Java) *never* break backwards compatibility.
> They deprecate (and only if the old API is too error prone for the
> programmer) and add a new API. In my opinion breaking backwards
> compatibility is almost never worth it*. Our libraries are already full of
> #ifdefs and maintaining our core libraries (which I maintain some of) is a
> headache because the code gets worse every time we "clean it up".
>
> * And it's only worth it sometimes because we're still a relatively small
> language, by usage.
>
> On Mon, Jan 5, 2015 at 8:08 PM, Austin Seipp <austin at well-typed.com>
> wrote:
>
>> On Mon, Jan 5, 2015 at 5:51 PM, David Feuer <david.feuer at gmail.com>
>> wrote:
>> > In case some people don't understand just how horrible this is: imagine
>> a
>> > privileged user uses this to erase a user's home directory. It could
>> easily
>> > hit a symbolic link to a critical system directory and hose the whole
>> > machine.
>>
>> I think it's potentially even worse than that: this subtle behavior
>> could easily be abused for this exact scenario by a hostile entity.
>> Imagine a scenario where an attacker may have permission to place a
>> symlink somewhere that a privileged process recursively removes; then
>> your / (or any number of things) goes 'boom'. This could easily happen
>> through a combination of a race condition (say, placing junk files in
>> /tmp you later remove, and the attacker races to place the symlink
>> there) and an improper umask setting. Or if the attacker simply may be
>> part of a group that allows access to something a program will remove,
>> etc etc.
>>
>> I agree this behavior is fundamentally wrong, and I'm strongly +1 on
>> changing the existing behavior, which I think is the only sane thing
>> to do. Otherwise any existing callers of this function in old code
>> could very easily do The Wrong Thing if they don't get the memo.
>>
>> I have no opinion on warnings or adding a function that preserves the
>> old behavior.
>>
>> > On Jan 5, 2015 6:44 PM, "Brandon Allbery" <allbery.b at gmail.com> wrote:
>> >>
>> >> On Mon, Jan 5, 2015 at 5:54 PM, Johan Tibell <johan.tibell at gmail.com>
>> >> wrote:
>> >>>
>> >>> Aside: can we look at what other languages with similar functions do?
>> >>
>> >>
>> >> You will find that essentially all other implementations do the right
>> >> thing and not follow symlinks, because the other behavior is a severe
>> bug. I
>> >> really do not understand why anyone believes the current behavior is
>> >> defensible.
>> >>
>> >> --
>> >> brandon s allbery kf8nh                               sine nomine
>> >> associates
>> >> allbery.b at gmail.com
>> >> ballbery at sinenomine.net
>> >> unix, openafs, kerberos, infrastructure, xmonad
>> >> http://sinenomine.net
>> >>
>> >> _______________________________________________
>> >> Libraries mailing list
>> >> Libraries at haskell.org
>> >> http://www.haskell.org/mailman/listinfo/libraries
>> >>
>> >
>> > _______________________________________________
>> > Libraries mailing list
>> > Libraries at haskell.org
>> > http://www.haskell.org/mailman/listinfo/libraries
>> >
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150106/405c587e/attachment.html>

From allbery.b at gmail.com  Tue Jan  6 01:25:51 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 5 Jan 2015 20:25:51 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAK-tuPaXMBRZ2CNGSdWLns3s31YRCzDqJXA7QS76-_kY-BWvSA@mail.gmail.com>
References: <1420496644-sup-4814@sabre> <m8f48e$c2q$1@ger.gmane.org>
 <54AB1577.3050303@ifi.lmu.de>
 <CAK-tuPZnJ7d00p+8i5mqyt+Azg-xm+oLCDL=vXkH5Bum+ytXcw@mail.gmail.com>
 <CAKFCL4V0iWPA8+M4w=EU9Oh6DQXJtSjjCFT5bpDkHb6YCpF0kA@mail.gmail.com>
 <CAMgWh9vuS6v7+WxuvtgBw00Fe8EeEwn2=Pknvqi=VVFHXkXrpA@mail.gmail.com>
 <CAEs96n3_Aa8cbcMX8jGp+s2-nw=hBG=3HbpjFYOCwfAQ-YnDjg@mail.gmail.com>
 <CAK-tuPaXMBRZ2CNGSdWLns3s31YRCzDqJXA7QS76-_kY-BWvSA@mail.gmail.com>
Message-ID: <CAKFCL4VXQKAQfmhAN7X=8Ti9923_Me9=+QicVtTFkmjiu+qHiw@mail.gmail.com>

On Mon, Jan 5, 2015 at 8:16 PM, Johan Tibell <johan.tibell at gmail.com> wrote:

> Let me make a wider comment about backwards compatibility.


The community has already messed up backward compatibility in far more
obvious and wide-reaching ways, for far worse reasons, many times. Suddenly
deciding to stand on principle, in a case where the current behavior is
*clearly* wrong and dangerous, seems "off" to me.

Of course, you're welcome to do it... I'll just have to make sure it's
understood that the decision was made to enshrine actively dangerous
behavior.

(I could make an argument for this being CVE-worthy. In fact, Austin Seipp
has already made most of it. Should a major security hole also be protected
and propagated by a sudden need to stand on backward compatibility
principles that have never been given much more than lip service in the
past?)

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150105/6c2c7c21/attachment.html>

From allbery.b at gmail.com  Tue Jan  6 01:28:44 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 5 Jan 2015 20:28:44 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CALya090FjXDMXkTeNj-EjyvRvSLGpA_b3hn5HgzeZPi=rvU5+g@mail.gmail.com>
References: <1420496644-sup-4814@sabre> <m8f48e$c2q$1@ger.gmane.org>
 <54AB1577.3050303@ifi.lmu.de>
 <CAK-tuPZnJ7d00p+8i5mqyt+Azg-xm+oLCDL=vXkH5Bum+ytXcw@mail.gmail.com>
 <CAKFCL4V0iWPA8+M4w=EU9Oh6DQXJtSjjCFT5bpDkHb6YCpF0kA@mail.gmail.com>
 <CAMgWh9vuS6v7+WxuvtgBw00Fe8EeEwn2=Pknvqi=VVFHXkXrpA@mail.gmail.com>
 <CAEs96n3_Aa8cbcMX8jGp+s2-nw=hBG=3HbpjFYOCwfAQ-YnDjg@mail.gmail.com>
 <CAK-tuPaXMBRZ2CNGSdWLns3s31YRCzDqJXA7QS76-_kY-BWvSA@mail.gmail.com>
 <CALya090FjXDMXkTeNj-EjyvRvSLGpA_b3hn5HgzeZPi=rvU5+g@mail.gmail.com>
Message-ID: <CAKFCL4Uouq6Wiy6NVrmW4gQ_DUDjAaEFdZC4kcwQmf1Vv15u-Q@mail.gmail.com>

On Mon, Jan 5, 2015 at 8:22 PM, Eric Mertens <emertens at gmail.com> wrote:

> I'm concerned that changing the behavior of the existing function would
> make it too easy to write vulnerable programs when compiled with older
> GHCs. Having a new safe function along with a deprecation warning on the
> old one would clue people in and avoid functionality varying
> subtly/dangerously based on the compiler used.


Only really helpful if you can go back and retrofit that deprecation into
already deployed older versions. Also, it's using the obvious name for the
function. So the correctly working one needs to have some unobvious name
and a 'warning you should not use this, use some_other_function instead'
form this point on?

Indeed, the Java community does do things that way. One of many reasons the
Java ecosystem is an absolute, irredeemable mess.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150105/cb725bd2/attachment-0001.html>

From michael at snoyman.com  Tue Jan  6 04:22:09 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Tue, 06 Jan 2015 04:22:09 +0000
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
References: <1420496644-sup-4814@sabre> <m8f48e$c2q$1@ger.gmane.org>
 <54AB1577.3050303@ifi.lmu.de>
 <CAK-tuPZnJ7d00p+8i5mqyt+Azg-xm+oLCDL=vXkH5Bum+ytXcw@mail.gmail.com>
 <CAKFCL4V0iWPA8+M4w=EU9Oh6DQXJtSjjCFT5bpDkHb6YCpF0kA@mail.gmail.com>
 <CAMgWh9vuS6v7+WxuvtgBw00Fe8EeEwn2=Pknvqi=VVFHXkXrpA@mail.gmail.com>
 <CAEs96n3_Aa8cbcMX8jGp+s2-nw=hBG=3HbpjFYOCwfAQ-YnDjg@mail.gmail.com>
 <CAK-tuPaXMBRZ2CNGSdWLns3s31YRCzDqJXA7QS76-_kY-BWvSA@mail.gmail.com>
Message-ID: <CAKA2JgKsqcD0dgOEsDa02RpKCfcN6ZWN99DNtGekPs8N9ZCWrQ@mail.gmail.com>

I strongly support this position. Put me as +1 on the deprecation and new
function approach.

On Tue, Jan 6, 2015, 3:17 AM Johan Tibell <johan.tibell at gmail.com> wrote:

> Let me make a wider comment about backwards compatibility. Many successful
> programming languages (e.g. Java) *never* break backwards compatibility.
> They deprecate (and only if the old API is too error prone for the
> programmer) and add a new API. In my opinion breaking backwards
> compatibility is almost never worth it*. Our libraries are already full of
> #ifdefs and maintaining our core libraries (which I maintain some of) is a
> headache because the code gets worse every time we "clean it up".
>
> * And it's only worth it sometimes because we're still a relatively small
> language, by usage.
>
> On Mon, Jan 5, 2015 at 8:08 PM, Austin Seipp <austin at well-typed.com>
> wrote:
>
>> On Mon, Jan 5, 2015 at 5:51 PM, David Feuer <david.feuer at gmail.com>
>> wrote:
>> > In case some people don't understand just how horrible this is: imagine
>> a
>> > privileged user uses this to erase a user's home directory. It could
>> easily
>> > hit a symbolic link to a critical system directory and hose the whole
>> > machine.
>>
>> I think it's potentially even worse than that: this subtle behavior
>> could easily be abused for this exact scenario by a hostile entity.
>> Imagine a scenario where an attacker may have permission to place a
>> symlink somewhere that a privileged process recursively removes; then
>> your / (or any number of things) goes 'boom'. This could easily happen
>> through a combination of a race condition (say, placing junk files in
>> /tmp you later remove, and the attacker races to place the symlink
>> there) and an improper umask setting. Or if the attacker simply may be
>> part of a group that allows access to something a program will remove,
>> etc etc.
>>
>> I agree this behavior is fundamentally wrong, and I'm strongly +1 on
>> changing the existing behavior, which I think is the only sane thing
>> to do. Otherwise any existing callers of this function in old code
>> could very easily do The Wrong Thing if they don't get the memo.
>>
>> I have no opinion on warnings or adding a function that preserves the
>> old behavior.
>>
>> > On Jan 5, 2015 6:44 PM, "Brandon Allbery" <allbery.b at gmail.com> wrote:
>> >>
>> >> On Mon, Jan 5, 2015 at 5:54 PM, Johan Tibell <johan.tibell at gmail.com>
>> >> wrote:
>> >>>
>> >>> Aside: can we look at what other languages with similar functions do?
>> >>
>> >>
>> >> You will find that essentially all other implementations do the right
>> >> thing and not follow symlinks, because the other behavior is a severe
>> bug. I
>> >> really do not understand why anyone believes the current behavior is
>> >> defensible.
>> >>
>> >> --
>> >> brandon s allbery kf8nh                               sine nomine
>> >> associates
>> >> allbery.b at gmail.com
>> >> ballbery at sinenomine.net
>> >> unix, openafs, kerberos, infrastructure, xmonad
>> >> http://sinenomine.net
>> >>
>> >> _______________________________________________
>> >> Libraries mailing list
>> >> Libraries at haskell.org
>> >> http://www.haskell.org/mailman/listinfo/libraries
>> >>
>> >
>> > _______________________________________________
>> > Libraries mailing list
>> > Libraries at haskell.org
>> > http://www.haskell.org/mailman/listinfo/libraries
>> >
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150106/6241171b/attachment.html>

From greg at gregweber.info  Tue Jan  6 05:30:34 2015
From: greg at gregweber.info (Greg Weber)
Date: Mon, 5 Jan 2015 21:30:34 -0800
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAKFCL4Uouq6Wiy6NVrmW4gQ_DUDjAaEFdZC4kcwQmf1Vv15u-Q@mail.gmail.com>
References: <1420496644-sup-4814@sabre> <m8f48e$c2q$1@ger.gmane.org>
 <54AB1577.3050303@ifi.lmu.de>
 <CAK-tuPZnJ7d00p+8i5mqyt+Azg-xm+oLCDL=vXkH5Bum+ytXcw@mail.gmail.com>
 <CAKFCL4V0iWPA8+M4w=EU9Oh6DQXJtSjjCFT5bpDkHb6YCpF0kA@mail.gmail.com>
 <CAMgWh9vuS6v7+WxuvtgBw00Fe8EeEwn2=Pknvqi=VVFHXkXrpA@mail.gmail.com>
 <CAEs96n3_Aa8cbcMX8jGp+s2-nw=hBG=3HbpjFYOCwfAQ-YnDjg@mail.gmail.com>
 <CAK-tuPaXMBRZ2CNGSdWLns3s31YRCzDqJXA7QS76-_kY-BWvSA@mail.gmail.com>
 <CALya090FjXDMXkTeNj-EjyvRvSLGpA_b3hn5HgzeZPi=rvU5+g@mail.gmail.com>
 <CAKFCL4Uouq6Wiy6NVrmW4gQ_DUDjAaEFdZC4kcwQmf1Vv15u-Q@mail.gmail.com>
Message-ID: <CAKRanNDUkCBW-1OKpwzVu5MdCbCED3vuSiw=+JqA3ymU0tdZ+g@mail.gmail.com>

On Mon, Jan 5, 2015 at 5:28 PM, Brandon Allbery <allbery.b at gmail.com> wrote:

> On Mon, Jan 5, 2015 at 8:22 PM, Eric Mertens <emertens at gmail.com> wrote:
>
>> I'm concerned that changing the behavior of the existing function would
>> make it too easy to write vulnerable programs when compiled with older
>> GHCs. Having a new safe function along with a deprecation warning on the
>> old one would clue people in and avoid functionality varying
>> subtly/dangerously based on the compiler used.
>
>
> Only really helpful if you can go back and retrofit that deprecation into
> already deployed older versions. Also, it's using the obvious name for the
> function. So the correctly working one needs to have some unobvious name
> and a 'warning you should not use this, use some_other_function instead'
> form this point on?
>

I don't know why 'removeDirectoryRecursive' would be considered by someone
to be the only obvious name available. `removeDirectoryTree` would work
also. Also, the warning does not have to be placed on older versions for it
to have effect with older versions. The point is that the library author
will be taught not to use this function at all.

When I suggested deprecation, I assumed that following a symlink was a
desirable behavior for someone. If it is not and it is 100% the case that
this behavior is a defect, then this is just a bugfix then deprecation is
not needed.

However, since this is considered dangerous, I think Eric makes an
excellent point that it makes it possible for the function to be used
properly for one compilation of a library that depends on `directory`, but
for another compilation to pick up an older version of `directory`. That
means that just fixing the behavior in the newest version of `directory` is
not very satisfactory.

So I see 2 approaches to address these issues

1) the deprecation warning approach
2) produce an updated point releases with the bugfix for every major
version of directory. It still could be a good idea to do the deprecation
warning on top of this because there are still older versions of the
function out there with the bad behavior.


>
> Indeed, the Java community does do things that way. One of many reasons
> the Java ecosystem is an absolute, irredeemable mess.
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150105/f0c36f60/attachment.html>

From sol at typeful.net  Tue Jan  6 05:53:58 2015
From: sol at typeful.net (Simon Hengel)
Date: Tue, 6 Jan 2015 13:53:58 +0800
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <1420496644-sup-4814@sabre>
References: <1420496644-sup-4814@sabre>
Message-ID: <20150106055358.GB3666@x200>

> I propose to backwards incompatibly change the behavior of
> removeDirectoryRecursive to not follow symlinks.

+1

> We could optionally add a replacement function under a new name which
> does follow symlinks.

-1 (I don't see the need for this)

Cheers,
Simon

From sol at typeful.net  Tue Jan  6 06:14:54 2015
From: sol at typeful.net (Simon Hengel)
Date: Tue, 6 Jan 2015 14:14:54 +0800
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <20150106055358.GB3666@x200>
References: <1420496644-sup-4814@sabre>
 <20150106055358.GB3666@x200>
Message-ID: <20150106061454.GC3666@x200>

And for what it's worth, -1 for a deprecation cycle.

On Tue, Jan 06, 2015 at 01:53:58PM +0800, Simon Hengel wrote:
> > I propose to backwards incompatibly change the behavior of
> > removeDirectoryRecursive to not follow symlinks.
> 
> +1
> 
> > We could optionally add a replacement function under a new name which
> > does follow symlinks.
> 
> -1 (I don't see the need for this)
> 
> Cheers,
> Simon
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

From bgamari.foss at gmail.com  Tue Jan  6 06:40:55 2015
From: bgamari.foss at gmail.com (Ben Gamari)
Date: Tue, 06 Jan 2015 01:40:55 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <1420496644-sup-4814@sabre>
References: <1420496644-sup-4814@sabre>
Message-ID: <87lhlg2yyw.fsf@gmail.com>

"Edward Z. Yang" <ezyang at mit.edu> writes:

> Discussion period: one month
>
> I propose to backwards incompatibly change the behavior of
> removeDirectoryRecursive to not follow symlinks.  We could optionally
> add a replacement function under a new name which does follow symlinks.
>
+1. The fact that this function (which I've reached for regularly)
behaves like this is unexpected and a bit terrifying.  It's mildly
amazing that there haven't been more complaints of lost data due to this
behavior.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150106/f6adb942/attachment-0001.sig>

From spam at scientician.net  Tue Jan  6 06:58:44 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Tue, 06 Jan 2015 07:58:44 +0100
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAK-tuPaXMBRZ2CNGSdWLns3s31YRCzDqJXA7QS76-_kY-BWvSA@mail.gmail.com>
References: <1420496644-sup-4814@sabre> <m8f48e$c2q$1@ger.gmane.org>
 <54AB1577.3050303@ifi.lmu.de>
 <CAK-tuPZnJ7d00p+8i5mqyt+Azg-xm+oLCDL=vXkH5Bum+ytXcw@mail.gmail.com>
 <CAKFCL4V0iWPA8+M4w=EU9Oh6DQXJtSjjCFT5bpDkHb6YCpF0kA@mail.gmail.com>
 <CAMgWh9vuS6v7+WxuvtgBw00Fe8EeEwn2=Pknvqi=VVFHXkXrpA@mail.gmail.com>
 <CAEs96n3_Aa8cbcMX8jGp+s2-nw=hBG=3HbpjFYOCwfAQ-YnDjg@mail.gmail.com>
 <CAK-tuPaXMBRZ2CNGSdWLns3s31YRCzDqJXA7QS76-_kY-BWvSA@mail.gmail.com>
Message-ID: <m8g134$gvi$1@ger.gmane.org>

On 2015-01-06 02:16, Johan Tibell wrote:
> Let me make a wider comment about backwards compatibility. Many successful
> programming languages (e.g. Java) *never* break backwards compatibility.

That is not quite correct. They're certainly averse to it, but for
example the JDK developers changed String's fundamental behavior wrt.
whether "substring" should copy the relevant string slice or whether it
should just point into the original string. You might argue that the
semantics didn't change, but this change *did* (predictably) break quite
a few programs which suddenly experienced pathological memory allocation
behavior and crashed with OoM's where they had none before.

> They deprecate (and only if the old API is too error prone for the
> programmer) and add a new API. In my opinion breaking backwards
> compatibility is almost never worth it*. Our libraries are already full of
> #ifdefs and maintaining our core libraries (which I maintain some of) is a
> headache because the code gets worse every time we "clean it up".
> 
> * And it's only worth it sometimes because we're still a relatively small
> language, by usage.
> 

I don't disagree with the general point, but this in this case we're
talking about absurdly dangerous and incorrect behavior which (as Austin
points out is trivially exploitable by messing around in /tmp and
waiting until e.g. a "clean-tmp" cron jobs starts running). AFAICT there
isn't even a function that *does the right thing* in System.Directory!
If someone wants this crazy behavior they can damn well code it
themselves ;)

Regards,


From ganesh at earth.li  Tue Jan  6 07:03:36 2015
From: ganesh at earth.li (Ganesh Sittampalam)
Date: Tue, 06 Jan 2015 07:03:36 +0000
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAKRanNDUkCBW-1OKpwzVu5MdCbCED3vuSiw=+JqA3ymU0tdZ+g@mail.gmail.com>
References: <1420496644-sup-4814@sabre> <m8f48e$c2q$1@ger.gmane.org>
 <54AB1577.3050303@ifi.lmu.de>
 <CAK-tuPZnJ7d00p+8i5mqyt+Azg-xm+oLCDL=vXkH5Bum+ytXcw@mail.gmail.com>
 <CAKFCL4V0iWPA8+M4w=EU9Oh6DQXJtSjjCFT5bpDkHb6YCpF0kA@mail.gmail.com>
 <CAMgWh9vuS6v7+WxuvtgBw00Fe8EeEwn2=Pknvqi=VVFHXkXrpA@mail.gmail.com>
 <CAEs96n3_Aa8cbcMX8jGp+s2-nw=hBG=3HbpjFYOCwfAQ-YnDjg@mail.gmail.com>
 <CAK-tuPaXMBRZ2CNGSdWLns3s31YRCzDqJXA7QS76-_kY-BWvSA@mail.gmail.com>
 <CALya090FjXDMXkTeNj-EjyvRvSLGpA_b3hn5HgzeZPi=rvU5+g@mail.gmail.com>
 <CAKFCL4Uouq6Wiy6NVrmW4gQ_DUDjAaEFdZC4kcwQmf1Vv15u-Q@mail.gmail.com>
 <CAKRanNDUkCBW-1OKpwzVu5MdCbCED3vuSiw=+JqA3ymU0tdZ+g@mail.gmail.com>
Message-ID: <54AB88C8.7040705@earth.li>

On 06/01/2015 05:30, Greg Weber wrote:

> When I suggested deprecation, I assumed that following a symlink was a
> desirable behavior for someone. If it is not and it is 100% the case
> that this behavior is a defect, then this is just a bugfix then
> deprecation is not needed.

My general feeling is that it is just a bug.

> However, since this is considered dangerous, I think Eric makes an
> excellent point that it makes it possible for the function to be used
> properly for one compilation of a library that depends on `directory`,
> but for another compilation to pick up an older version of `directory`.
> That means that just fixing the behavior in the newest version of
> `directory` is not very satisfactory.
> 
> So I see 2 approaches to address these issues
> 
> 1) the deprecation warning approach
> 2) produce an updated point releases with the bugfix for every major
> version of directory. It still could be a good idea to do the
> deprecation warning on top of this because there are still older
> versions of the function out there with the bad behavior.

Will (2) this be enough for old GHCs, which will have a buggy version of
directory already installed? I think cabal will prefer the installed one
over a point release.

Ganesh


From spam at scientician.net  Tue Jan  6 07:21:13 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Tue, 06 Jan 2015 08:21:13 +0100
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <54AB88C8.7040705@earth.li>
References: <1420496644-sup-4814@sabre> <m8f48e$c2q$1@ger.gmane.org>
 <54AB1577.3050303@ifi.lmu.de>
 <CAK-tuPZnJ7d00p+8i5mqyt+Azg-xm+oLCDL=vXkH5Bum+ytXcw@mail.gmail.com>
 <CAKFCL4V0iWPA8+M4w=EU9Oh6DQXJtSjjCFT5bpDkHb6YCpF0kA@mail.gmail.com>
 <CAMgWh9vuS6v7+WxuvtgBw00Fe8EeEwn2=Pknvqi=VVFHXkXrpA@mail.gmail.com>
 <CAEs96n3_Aa8cbcMX8jGp+s2-nw=hBG=3HbpjFYOCwfAQ-YnDjg@mail.gmail.com>
 <CAK-tuPaXMBRZ2CNGSdWLns3s31YRCzDqJXA7QS76-_kY-BWvSA@mail.gmail.com>
 <CALya090FjXDMXkTeNj-EjyvRvSLGpA_b3hn5HgzeZPi=rvU5+g@mail.gmail.com>
 <CAKFCL4Uouq6Wiy6NVrmW4gQ_DUDjAaEFdZC4kcwQmf1Vv15u-Q@mail.gmail.com>
 <CAKRanNDUkCBW-1OKpwzVu5MdCbCED3vuSiw=+JqA3ymU0tdZ+g@mail.gmail.com>
 <54AB88C8.7040705@earth.li>
Message-ID: <m8g2da$3k5$1@ger.gmane.org>

On 2015-01-06 08:03, Ganesh Sittampalam wrote:
> On 06/01/2015 05:30, Greg Weber wrote:
> 
>> When I suggested deprecation, I assumed that following a symlink was a
>> desirable behavior for someone. If it is not and it is 100% the case
>> that this behavior is a defect, then this is just a bugfix then
>> deprecation is not needed.
> 
> My general feeling is that it is just a bug.
> 

That's what I thought too -- it's a typical rookie mistake to forget to
check if "isDirecory?" will return "true" for symlinks to directories.
But the documentation actually states the expected behavior correctly --
it's not nearly explicit enough about how dangerous it is, but the
documentation is technically correct.

However, even so, this is CVE-worthy behavior on its own (as pointed out
by Brandon), and should be removed pronto. Perhaps with new minor
versions for all affected major versions (excellent point by Greg
Weber), depending on how much work that is.



From roma at ro-che.info  Tue Jan  6 07:47:37 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Tue, 06 Jan 2015 09:47:37 +0200
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <1420496644-sup-4814@sabre>
References: <1420496644-sup-4814@sabre>
Message-ID: <54AB9319.1050308@ro-che.info>

+1 for fixing this asap.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150106/33db5736/attachment.sig>

From fox at ucw.cz  Tue Jan  6 07:53:41 2015
From: fox at ucw.cz (Milan Straka)
Date: Tue, 6 Jan 2015 08:53:41 +0100
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <1420496644-sup-4814@sabre>
References: <1420496644-sup-4814@sabre>
Message-ID: <20150106075340.GA29615@auryn.cz>

Hi all,

> -----Original message-----
> From: "Edward Z. Yang" <ezyang at mit.edu>
> Sent: 5 Jan 2015, 14:25
>
> I propose to backwards incompatibly change the behavior of
> removeDirectoryRecursive to not follow symlinks.  We could optionally
> add a replacement function under a new name which does follow symlinks.

+1 to changing behaviour of removeDirectoryRecursive.

-1 to depreciation cycle and a replacement function.

To me, this feels like bugfixing, not backwards incompatible change, as
the current behaviour is unexpected and potentially harmful.

Cheers,
Milan Straka

From hvr at gnu.org  Tue Jan  6 09:33:21 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 06 Jan 2015 10:33:21 +0100
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <1420496644-sup-4814@sabre> (Edward Z. Yang's message of "Mon, 05
 Jan 2015 14:25:35 -0800")
References: <1420496644-sup-4814@sabre>
Message-ID: <87lhlguuce.fsf@gnu.org>

Hello *,

I'd like to hijack this discussion to bring attention to two IMO
strongly related tickets filed against directory which could benefit from
some feedback/comments:

 - removeFile and directories and symlinks to directories #3 
   https://github.com/haskell/directory/issues/3

 - removeDirectory and symlinks #2 
   https://github.com/haskell/directory/issues/2


Cheers,
  hvr

From david.feuer at gmail.com  Tue Jan  6 11:17:53 2015
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 6 Jan 2015 06:17:53 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CALya090FjXDMXkTeNj-EjyvRvSLGpA_b3hn5HgzeZPi=rvU5+g@mail.gmail.com>
References: <1420496644-sup-4814@sabre> <m8f48e$c2q$1@ger.gmane.org>
 <54AB1577.3050303@ifi.lmu.de>
 <CAK-tuPZnJ7d00p+8i5mqyt+Azg-xm+oLCDL=vXkH5Bum+ytXcw@mail.gmail.com>
 <CAKFCL4V0iWPA8+M4w=EU9Oh6DQXJtSjjCFT5bpDkHb6YCpF0kA@mail.gmail.com>
 <CAMgWh9vuS6v7+WxuvtgBw00Fe8EeEwn2=Pknvqi=VVFHXkXrpA@mail.gmail.com>
 <CAEs96n3_Aa8cbcMX8jGp+s2-nw=hBG=3HbpjFYOCwfAQ-YnDjg@mail.gmail.com>
 <CAK-tuPaXMBRZ2CNGSdWLns3s31YRCzDqJXA7QS76-_kY-BWvSA@mail.gmail.com>
 <CALya090FjXDMXkTeNj-EjyvRvSLGpA_b3hn5HgzeZPi=rvU5+g@mail.gmail.com>
Message-ID: <CAMgWh9t02JwO7269QW3fv3OzuzTT2tqkPc1LAHBFUzekn_dOFg@mail.gmail.com>

One approach (extreme, perhaps) would be to simply write

{-# DEPRECATED removeDirectoryRecursive #-}
removeDirectoryRecursive = error "This function was horribly dangerous and
has been removed. Use _____ instead."
On Jan 5, 2015 8:22 PM, "Eric Mertens" <emertens at gmail.com> wrote:

> I'm concerned that changing the behavior of the existing function would
> make it too easy to write vulnerable programs when compiled with older
> GHCs. Having a new safe function along with a deprecation warning on the
> old one would clue people in and avoid functionality varying
> subtly/dangerously based on the compiler used.
>
> On Mon, Jan 5, 2015, 5:17 PM Johan Tibell <johan.tibell at gmail.com> wrote:
>
>> Let me make a wider comment about backwards compatibility. Many
>> successful programming languages (e.g. Java) *never* break backwards
>> compatibility. They deprecate (and only if the old API is too error prone
>> for the programmer) and add a new API. In my opinion breaking backwards
>> compatibility is almost never worth it*. Our libraries are already full of
>> #ifdefs and maintaining our core libraries (which I maintain some of) is a
>> headache because the code gets worse every time we "clean it up".
>>
>> * And it's only worth it sometimes because we're still a relatively small
>> language, by usage.
>>
>> On Mon, Jan 5, 2015 at 8:08 PM, Austin Seipp <austin at well-typed.com>
>> wrote:
>>
>>> On Mon, Jan 5, 2015 at 5:51 PM, David Feuer <david.feuer at gmail.com>
>>> wrote:
>>> > In case some people don't understand just how horrible this is:
>>> imagine a
>>> > privileged user uses this to erase a user's home directory. It could
>>> easily
>>> > hit a symbolic link to a critical system directory and hose the whole
>>> > machine.
>>>
>>> I think it's potentially even worse than that: this subtle behavior
>>> could easily be abused for this exact scenario by a hostile entity.
>>> Imagine a scenario where an attacker may have permission to place a
>>> symlink somewhere that a privileged process recursively removes; then
>>> your / (or any number of things) goes 'boom'. This could easily happen
>>> through a combination of a race condition (say, placing junk files in
>>> /tmp you later remove, and the attacker races to place the symlink
>>> there) and an improper umask setting. Or if the attacker simply may be
>>> part of a group that allows access to something a program will remove,
>>> etc etc.
>>>
>>> I agree this behavior is fundamentally wrong, and I'm strongly +1 on
>>> changing the existing behavior, which I think is the only sane thing
>>> to do. Otherwise any existing callers of this function in old code
>>> could very easily do The Wrong Thing if they don't get the memo.
>>>
>>> I have no opinion on warnings or adding a function that preserves the
>>> old behavior.
>>>
>>> > On Jan 5, 2015 6:44 PM, "Brandon Allbery" <allbery.b at gmail.com> wrote:
>>> >>
>>> >> On Mon, Jan 5, 2015 at 5:54 PM, Johan Tibell <johan.tibell at gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> Aside: can we look at what other languages with similar functions do?
>>> >>
>>> >>
>>> >> You will find that essentially all other implementations do the right
>>> >> thing and not follow symlinks, because the other behavior is a severe
>>> bug. I
>>> >> really do not understand why anyone believes the current behavior is
>>> >> defensible.
>>> >>
>>> >> --
>>> >> brandon s allbery kf8nh                               sine nomine
>>> >> associates
>>> >> allbery.b at gmail.com
>>> >> ballbery at sinenomine.net
>>> >> unix, openafs, kerberos, infrastructure, xmonad
>>> >> http://sinenomine.net
>>> >>
>>> >> _______________________________________________
>>> >> Libraries mailing list
>>> >> Libraries at haskell.org
>>> >> http://www.haskell.org/mailman/listinfo/libraries
>>> >>
>>> >
>>> > _______________________________________________
>>> > Libraries mailing list
>>> > Libraries at haskell.org
>>> > http://www.haskell.org/mailman/listinfo/libraries
>>> >
>>>
>>> --
>>> Regards,
>>>
>>> Austin Seipp, Haskell Consultant
>>> Well-Typed LLP, http://www.well-typed.com/
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150106/0bede5c5/attachment-0001.html>

From andreas.abel at ifi.lmu.de  Tue Jan  6 11:33:40 2015
From: andreas.abel at ifi.lmu.de (Andreas Abel)
Date: Tue, 06 Jan 2015 12:33:40 +0100
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <20150106075340.GA29615@auryn.cz>
References: <1420496644-sup-4814@sabre> <20150106075340.GA29615@auryn.cz>
Message-ID: <54ABC814.7070801@ifi.lmu.de>

I also consider this a bugfix.  Bugfixes (hopefully) change semantics 
and break backwards-compatibility (but in a good way).

+1 for fixing and backporting as far as possible.

On 06.01.2015 08:53, Milan Straka wrote:
> Hi all,
>
>> -----Original message-----
>> From: "Edward Z. Yang" <ezyang at mit.edu>
>> Sent: 5 Jan 2015, 14:25
>>
>> I propose to backwards incompatibly change the behavior of
>> removeDirectoryRecursive to not follow symlinks.  We could optionally
>> add a replacement function under a new name which does follow symlinks.
>
> +1 to changing behaviour of removeDirectoryRecursive.
>
> -1 to depreciation cycle and a replacement function.
>
> To me, this feels like bugfixing, not backwards incompatible change, as
> the current behaviour is unexpected and potentially harmful.
>
> Cheers,
> Milan Straka
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>


-- 
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andreas.abel at gu.se
http://www2.tcs.ifi.lmu.de/~abel/

From alois.cochard at gmail.com  Tue Jan  6 12:16:00 2015
From: alois.cochard at gmail.com (Alois Cochard)
Date: Tue, 6 Jan 2015 13:16:00 +0100
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <1420496644-sup-4814@sabre>
References: <1420496644-sup-4814@sabre>
Message-ID: <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>

+1 for fixing this

-1 for the deprecation cycle

I don't think it's sane to rely on the current behavior anyway.

Cheers

On 5 January 2015 at 23:25, Edward Z. Yang <ezyang at mit.edu> wrote:

> Discussion period: one month
>
> I propose to backwards incompatibly change the behavior of
> removeDirectoryRecursive to not follow symlinks.  We could optionally
> add a replacement function under a new name which does follow symlinks.
>
> This would bring its behavior inline with rm -rf.
>
> I also opened a ticket here: https://ghc.haskell.org/trac/ghc/ticket/9266
>
> Thanks,
> Edward
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>



-- 
*?\ois*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150106/f565cd1e/attachment.html>

From johan.tibell at gmail.com  Tue Jan  6 13:48:52 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 6 Jan 2015 08:48:52 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
Message-ID: <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>

This is not a bugfix. A bug is failing to follow the functions
specification, which *does* include following symlinks.

On Tue, Jan 6, 2015 at 7:16 AM, Alois Cochard <alois.cochard at gmail.com>
wrote:

> +1 for fixing this
>
> -1 for the deprecation cycle
>
> I don't think it's sane to rely on the current behavior anyway.
>
> Cheers
>
> On 5 January 2015 at 23:25, Edward Z. Yang <ezyang at mit.edu> wrote:
>
>> Discussion period: one month
>>
>> I propose to backwards incompatibly change the behavior of
>> removeDirectoryRecursive to not follow symlinks.  We could optionally
>> add a replacement function under a new name which does follow symlinks.
>>
>> This would bring its behavior inline with rm -rf.
>>
>> I also opened a ticket here: https://ghc.haskell.org/trac/ghc/ticket/9266
>>
>> Thanks,
>> Edward
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
>
> --
> *?\ois*
> http://twitter.com/aloiscochard
> http://github.com/aloiscochard
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150106/b69924b3/attachment.html>

From mwm at mired.org  Tue Jan  6 13:57:28 2015
From: mwm at mired.org (Mike Meyer)
Date: Tue, 6 Jan 2015 07:57:28 -0600
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
Message-ID: <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>

On Tue, Jan 6, 2015 at 7:48 AM, Johan Tibell <johan.tibell at gmail.com> wrote:

> This is not a bugfix. A bug is failing to follow the functions
> specification, which *does* include following symlinks.
>

It's a bug in the design, not the code. The API it provides is useful, but
dangerous and less useful than the safe version.

Breaking the API has been proposed. If we're going to do that, why not add
a followSymlinks ::Bool argument as well, and document why the API was
broken in this way. Going forward, at least. Not sure about backwards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150106/16fde0ab/attachment.html>

From spam at scientician.net  Tue Jan  6 14:59:36 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Tue, 06 Jan 2015 15:59:36 +0100
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
 <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
Message-ID: <m8gt8o$6f3$1@ger.gmane.org>

On 2015-01-06 14:57, Mike Meyer wrote:
> On Tue, Jan 6, 2015 at 7:48 AM, Johan Tibell <johan.tibell at gmail.com> wrote:
> 
>> This is not a bugfix. A bug is failing to follow the functions
>> specification, which *does* include following symlinks.
>>
> 
> It's a bug in the design, not the code. The API it provides is useful, but
> dangerous and less useful than the safe version.
> 
> Breaking the API has been proposed. If we're going to do that, why not add
> a followSymlinks ::Bool argument as well, and document why the API was
> broken in this way. Going forward, at least. Not sure about backwards.
> 

Because *nobody* wants to follow symlinks when doing "rm -rf". Even if
they think they do, they *really* don't. Any design which relies on it
is probably fundamentally broken. (If they're *really really* sure, they
can write their own.)

Btw, a Bool argumnent usually isn't a good idea. Better API design would be

   data SymlinkBehavior =
      FollowSymlinks
     | NoFollowSymlinks

(so that it's easy to tell at all call sites what it's doing.). However,
without default arguments this is forcing a pointless decision upon the
user, i.e. 99.9%+ of all usages should be using NoFollow, so why force
the user of the API to decide?

Even with such a change, I don't think the functionality should exist in
a "standard" library. (I won't repeat all the arguments; see the rest of
the thread :))

Regards,



From mwm at mired.org  Tue Jan  6 15:43:14 2015
From: mwm at mired.org (Mike Meyer)
Date: Tue, 6 Jan 2015 09:43:14 -0600
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <m8gt8o$6f3$1@ger.gmane.org>
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
 <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
 <m8gt8o$6f3$1@ger.gmane.org>
Message-ID: <CAD=7U2Ahbh5u4t+M5xjMKeS4X7-5op4qXtY6ap6mZNoCa6ey3A@mail.gmail.com>

On Tue, Jan 6, 2015 at 8:59 AM, Bardur Arantsson <spam at scientician.net>
wrote:
>
> Because *nobody* wants to follow symlinks when doing "rm -rf". Even if
> they think they do, they *really* don't. Any design which relies on it
> is probably fundamentally broken. (If they're *really really* sure, they
> can write their own.)
>

Don't need to reread the arguments - I've been aware of them since CSRG
introduced symlinks in 4BSD, and the utilities didn't know about them in
the beta releases.

You pretty much never want to call it on a file tree you didn't build.  But
if I built the file tree, then I know what's going on. Making me write my
own is probably going to result in less robust code, or copying the code
out of the library and tweaking it, neither of which is desirable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150106/88a40d53/attachment.html>

From david.feuer at gmail.com  Tue Jan  6 15:51:09 2015
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 6 Jan 2015 10:51:09 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAD=7U2Ahbh5u4t+M5xjMKeS4X7-5op4qXtY6ap6mZNoCa6ey3A@mail.gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
 <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
 <m8gt8o$6f3$1@ger.gmane.org>
 <CAD=7U2Ahbh5u4t+M5xjMKeS4X7-5op4qXtY6ap6mZNoCa6ey3A@mail.gmail.com>
Message-ID: <CAMgWh9sGMqWcbGd7srvfmG=d4iyFWn-c7FHfm8GjN4k4UZx89A@mail.gmail.com>

So stick it in a directory-for-insane-people package and call it
removeDirectoryRecursiveFollowSymlinksISwearIReallyWantThat.
On Jan 6, 2015 10:43 AM, "Mike Meyer" <mwm at mired.org> wrote:

> On Tue, Jan 6, 2015 at 8:59 AM, Bardur Arantsson <spam at scientician.net>
> wrote:
>>
>> Because *nobody* wants to follow symlinks when doing "rm -rf". Even if
>> they think they do, they *really* don't. Any design which relies on it
>> is probably fundamentally broken. (If they're *really really* sure, they
>> can write their own.)
>>
>
> Don't need to reread the arguments - I've been aware of them since CSRG
> introduced symlinks in 4BSD, and the utilities didn't know about them in
> the beta releases.
>
> You pretty much never want to call it on a file tree you didn't build.
> But if I built the file tree, then I know what's going on. Making me write
> my own is probably going to result in less robust code, or copying the code
> out of the library and tweaking it, neither of which is desirable.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150106/3ce36226/attachment.html>

From spam at scientician.net  Tue Jan  6 15:50:04 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Tue, 06 Jan 2015 16:50:04 +0100
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAD=7U2Ahbh5u4t+M5xjMKeS4X7-5op4qXtY6ap6mZNoCa6ey3A@mail.gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
 <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
 <m8gt8o$6f3$1@ger.gmane.org>
 <CAD=7U2Ahbh5u4t+M5xjMKeS4X7-5op4qXtY6ap6mZNoCa6ey3A@mail.gmail.com>
Message-ID: <m8h07c$o27$1@ger.gmane.org>

On 2015-01-06 16:43, Mike Meyer wrote:
> On Tue, Jan 6, 2015 at 8:59 AM, Bardur Arantsson <spam at scientician.net>
> wrote:
>>
>> Because *nobody* wants to follow symlinks when doing "rm -rf". Even if
>> they think they do, they *really* don't. Any design which relies on it
>> is probably fundamentally broken. (If they're *really really* sure, they
>> can write their own.)
>>
> 
> Don't need to reread the arguments - I've been aware of them since CSRG
> introduced symlinks in 4BSD, and the utilities didn't know about them in
> the beta releases.
> 
> You pretty much never want to call it on a file tree you didn't build.  But
> if I built the file tree, then I know what's going on.

Indeed, but even in *that* case it's incredibly error-prone...

> Making me write my
> own is probably going to result in less robust code, or copying the code
> out of the library and tweaking it, neither of which is desirable.
> 

It's such a rare need and so dangerous that I'd argue that forcing a
copy + tweak is actually desirable in this case.

Regards,


From malcolm.wallace at me.com  Tue Jan  6 16:14:29 2015
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Tue, 06 Jan 2015 16:14:29 +0000
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <m8gt8o$6f3$1@ger.gmane.org>
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
 <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
 <m8gt8o$6f3$1@ger.gmane.org>
Message-ID: <455CD231-2D34-4E1E-B96B-50D923D3B737@me.com>


On 6 Jan 2015, at 14:59, Bardur Arantsson wrote:

> On 2015-01-06 14:57, Mike Meyer wrote:
>> On Tue, Jan 6, 2015 at 7:48 AM, Johan Tibell <johan.tibell at gmail.com> wrote:
>> 
>>> This is not a bugfix. A bug is failing to follow the functions
>>> specification, which *does* include following symlinks.
>>> 
>> 
>> It's a bug in the design, not the code. 

> Because *nobody* wants to follow symlinks when doing "rm -rf". Even if
> they think they do, they *really* don't.

I agree 100%.  Even time I use this function, I worry briefly about whether it follows symlinks, then think to myself "no, no-one would be so stupid to implement that deliberately in a publically available API".  So it was a real shock to discover in this thread that I was wrong, and furthermore that the function is documented as doing the wrong thing.  We should fix both spec and implementation, as soon as possible.

Regards,
    Malcolm

From ekmett at gmail.com  Tue Jan  6 19:37:20 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 6 Jan 2015 14:37:20 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <455CD231-2D34-4E1E-B96B-50D923D3B737@me.com>
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
 <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
 <m8gt8o$6f3$1@ger.gmane.org>
 <455CD231-2D34-4E1E-B96B-50D923D3B737@me.com>
Message-ID: <CAJumaK_T3x1e13oOMEtnkmJ5CPornwbH7S7FJWzAFB0cxmYKUw@mail.gmail.com>

I'm +1 for fixing this, in place, on the current function.

The specification we have here is doing a very very bad thing and needs to
be fixed, not slavishly copied forward because someone sometime once made a
mistake.

The current behavior grievously violates the expectations of anyone who
would be in a situation to go and reach for it and has any prior experience
with any other such tool.

-Edward



On Tue, Jan 6, 2015 at 11:14 AM, Malcolm Wallace <malcolm.wallace at me.com>
wrote:

>
> On 6 Jan 2015, at 14:59, Bardur Arantsson wrote:
>
> > On 2015-01-06 14:57, Mike Meyer wrote:
> >> On Tue, Jan 6, 2015 at 7:48 AM, Johan Tibell <johan.tibell at gmail.com>
> wrote:
> >>
> >>> This is not a bugfix. A bug is failing to follow the functions
> >>> specification, which *does* include following symlinks.
> >>>
> >>
> >> It's a bug in the design, not the code.
>
> > Because *nobody* wants to follow symlinks when doing "rm -rf". Even if
> > they think they do, they *really* don't.
>
> I agree 100%.  Even time I use this function, I worry briefly about
> whether it follows symlinks, then think to myself "no, no-one would be so
> stupid to implement that deliberately in a publically available API".  So
> it was a real shock to discover in this thread that I was wrong, and
> furthermore that the function is documented as doing the wrong thing.  We
> should fix both spec and implementation, as soon as possible.
>
> Regards,
>     Malcolm
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150106/df74c77f/attachment.html>

From gabriel439 at gmail.com  Tue Jan  6 19:40:03 2015
From: gabriel439 at gmail.com (Gabriel Gonzalez)
Date: Tue, 06 Jan 2015 11:40:03 -0800
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAJumaK_T3x1e13oOMEtnkmJ5CPornwbH7S7FJWzAFB0cxmYKUw@mail.gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
 <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
 <m8gt8o$6f3$1@ger.gmane.org> <455CD231-2D34-4E1E-B96B-50D923D3B737@me.com>
 <CAJumaK_T3x1e13oOMEtnkmJ5CPornwbH7S7FJWzAFB0cxmYKUw@mail.gmail.com>
Message-ID: <54AC3A13.207@gmail.com>

I think it's safer to remove the old function altogether (perhaps after 
one deprecation cycle) and provide a new one under a different name, 
rather than modify it in place.

Modifying it in place risks the behavior that others mentioned where 
your program is unsafe to compile against older library versions. Yes, 
the user could explicitly enforce that by putting a lower bound on the 
library, but most users won't even realize that they need to do that.


On 1/6/15, 11:37 AM, Edward Kmett wrote:
> I'm +1 for fixing this, in place, on the current function.
>
> The specification we have here is doing a very very bad thing and 
> needs to be fixed, not slavishly copied forward because someone 
> sometime once made a mistake.
>
> The current behavior grievously violates the expectations of anyone 
> who would be in a situation to go and reach for it and has any prior 
> experience with any other such tool.
>
> -Edward
>
>
>
> On Tue, Jan 6, 2015 at 11:14 AM, Malcolm Wallace 
> <malcolm.wallace at me.com <mailto:malcolm.wallace at me.com>> wrote:
>
>
>     On 6 Jan 2015, at 14:59, Bardur Arantsson wrote:
>
>     > On 2015-01-06 14:57, Mike Meyer wrote:
>     >> On Tue, Jan 6, 2015 at 7:48 AM, Johan Tibell
>     <johan.tibell at gmail.com <mailto:johan.tibell at gmail.com>> wrote:
>     >>
>     >>> This is not a bugfix. A bug is failing to follow the functions
>     >>> specification, which *does* include following symlinks.
>     >>>
>     >>
>     >> It's a bug in the design, not the code.
>
>     > Because *nobody* wants to follow symlinks when doing "rm -rf". Even if
>     > they think they do, they *really* don't.
>
>     I agree 100%.  Even time I use this function, I worry briefly
>     about whether it follows symlinks, then think to myself "no,
>     no-one would be so stupid to implement that deliberately in a
>     publically available API".  So it was a real shock to discover in
>     this thread that I was wrong, and furthermore that the function is
>     documented as doing the wrong thing.  We should fix both spec and
>     implementation, as soon as possible.
>
>     Regards,
>         Malcolm
>     _______________________________________________
>     Libraries mailing list
>     Libraries at haskell.org <mailto:Libraries at haskell.org>
>     http://www.haskell.org/mailman/listinfo/libraries
>
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150106/9d10e546/attachment.html>

From david.feuer at gmail.com  Tue Jan  6 19:45:27 2015
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 6 Jan 2015 14:45:27 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <54AC3A13.207@gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
 <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
 <m8gt8o$6f3$1@ger.gmane.org>
 <455CD231-2D34-4E1E-B96B-50D923D3B737@me.com>
 <CAJumaK_T3x1e13oOMEtnkmJ5CPornwbH7S7FJWzAFB0cxmYKUw@mail.gmail.com>
 <54AC3A13.207@gmail.com>
Message-ID: <CAMgWh9vUoqqmDYkUFKr7YavptKqS=_swziQXWr-Y_+g2hq7Z7g@mail.gmail.com>

This seems reasonable, but if we have a deprecation cycle, the old name
should (temporarily) be a synonym for the new one, and the deprecation
warning should indicate that code intended to work with older versions
needs to be audited.
On Jan 6, 2015 2:40 PM, "Gabriel Gonzalez" <gabriel439 at gmail.com> wrote:

>  I think it's safer to remove the old function altogether (perhaps after
> one deprecation cycle) and provide a new one under a different name, rather
> than modify it in place.
>
> Modifying it in place risks the behavior that others mentioned where your
> program is unsafe to compile against older library versions.  Yes, the user
> could explicitly enforce that by putting a lower bound on the library, but
> most users won't even realize that they need to do that.
>
>
> On 1/6/15, 11:37 AM, Edward Kmett wrote:
>
> I'm +1 for fixing this, in place, on the current function.
>
>  The specification we have here is doing a very very bad thing and needs
> to be fixed, not slavishly copied forward because someone sometime once
> made a mistake.
>
>  The current behavior grievously violates the expectations of anyone who
> would be in a situation to go and reach for it and has any prior experience
> with any other such tool.
>
>  -Edward
>
>
>
> On Tue, Jan 6, 2015 at 11:14 AM, Malcolm Wallace <malcolm.wallace at me.com>
> wrote:
>
>>
>> On 6 Jan 2015, at 14:59, Bardur Arantsson wrote:
>>
>> > On 2015-01-06 14:57, Mike Meyer wrote:
>> >> On Tue, Jan 6, 2015 at 7:48 AM, Johan Tibell <johan.tibell at gmail.com>
>> wrote:
>> >>
>> >>> This is not a bugfix. A bug is failing to follow the functions
>> >>> specification, which *does* include following symlinks.
>> >>>
>> >>
>> >> It's a bug in the design, not the code.
>>
>> > Because *nobody* wants to follow symlinks when doing "rm -rf". Even if
>> > they think they do, they *really* don't.
>>
>> I agree 100%.  Even time I use this function, I worry briefly about
>> whether it follows symlinks, then think to myself "no, no-one would be so
>> stupid to implement that deliberately in a publically available API".  So
>> it was a real shock to discover in this thread that I was wrong, and
>> furthermore that the function is documented as doing the wrong thing.  We
>> should fix both spec and implementation, as soon as possible.
>>
>> Regards,
>>     Malcolm
>>  _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
>
> _______________________________________________
> Libraries mailing listLibraries at haskell.orghttp://www.haskell.org/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150106/9312d2ae/attachment-0001.html>

From johan.tibell at gmail.com  Tue Jan  6 20:37:49 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 6 Jan 2015 15:37:49 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAMgWh9vUoqqmDYkUFKr7YavptKqS=_swziQXWr-Y_+g2hq7Z7g@mail.gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
 <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
 <m8gt8o$6f3$1@ger.gmane.org> <455CD231-2D34-4E1E-B96B-50D923D3B737@me.com>
 <CAJumaK_T3x1e13oOMEtnkmJ5CPornwbH7S7FJWzAFB0cxmYKUw@mail.gmail.com>
 <54AC3A13.207@gmail.com>
 <CAMgWh9vUoqqmDYkUFKr7YavptKqS=_swziQXWr-Y_+g2hq7Z7g@mail.gmail.com>
Message-ID: <CAK-tuPbDyV=O+ygRCEEYzknHBosZ0Z1-4vSQUE+whUnRT1ja2g@mail.gmail.com>

Who volunteers to fix the breakages in Cabal and add all the needed CPP?

On Tue, Jan 6, 2015 at 2:45 PM, David Feuer <david.feuer at gmail.com> wrote:

> This seems reasonable, but if we have a deprecation cycle, the old name
> should (temporarily) be a synonym for the new one, and the deprecation
> warning should indicate that code intended to work with older versions
> needs to be audited.
> On Jan 6, 2015 2:40 PM, "Gabriel Gonzalez" <gabriel439 at gmail.com> wrote:
>
>>  I think it's safer to remove the old function altogether (perhaps after
>> one deprecation cycle) and provide a new one under a different name, rather
>> than modify it in place.
>>
>> Modifying it in place risks the behavior that others mentioned where your
>> program is unsafe to compile against older library versions.  Yes, the user
>> could explicitly enforce that by putting a lower bound on the library, but
>> most users won't even realize that they need to do that.
>>
>>
>> On 1/6/15, 11:37 AM, Edward Kmett wrote:
>>
>> I'm +1 for fixing this, in place, on the current function.
>>
>>  The specification we have here is doing a very very bad thing and needs
>> to be fixed, not slavishly copied forward because someone sometime once
>> made a mistake.
>>
>>  The current behavior grievously violates the expectations of anyone who
>> would be in a situation to go and reach for it and has any prior experience
>> with any other such tool.
>>
>>  -Edward
>>
>>
>>
>> On Tue, Jan 6, 2015 at 11:14 AM, Malcolm Wallace <malcolm.wallace at me.com>
>> wrote:
>>
>>>
>>> On 6 Jan 2015, at 14:59, Bardur Arantsson wrote:
>>>
>>> > On 2015-01-06 14:57, Mike Meyer wrote:
>>> >> On Tue, Jan 6, 2015 at 7:48 AM, Johan Tibell <johan.tibell at gmail.com>
>>> wrote:
>>> >>
>>> >>> This is not a bugfix. A bug is failing to follow the functions
>>> >>> specification, which *does* include following symlinks.
>>> >>>
>>> >>
>>> >> It's a bug in the design, not the code.
>>>
>>> > Because *nobody* wants to follow symlinks when doing "rm -rf". Even if
>>> > they think they do, they *really* don't.
>>>
>>> I agree 100%.  Even time I use this function, I worry briefly about
>>> whether it follows symlinks, then think to myself "no, no-one would be so
>>> stupid to implement that deliberately in a publically available API".  So
>>> it was a real shock to discover in this thread that I was wrong, and
>>> furthermore that the function is documented as doing the wrong thing.  We
>>> should fix both spec and implementation, as soon as possible.
>>>
>>> Regards,
>>>     Malcolm
>>>  _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>
>>
>>
>> _______________________________________________
>> Libraries mailing listLibraries at haskell.orghttp://www.haskell.org/mailman/listinfo/libraries
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150106/bebce2cc/attachment.html>

From hesselink at gmail.com  Tue Jan  6 20:39:22 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 6 Jan 2015 21:39:22 +0100
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAK-tuPbDyV=O+ygRCEEYzknHBosZ0Z1-4vSQUE+whUnRT1ja2g@mail.gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
 <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
 <m8gt8o$6f3$1@ger.gmane.org> <455CD231-2D34-4E1E-B96B-50D923D3B737@me.com>
 <CAJumaK_T3x1e13oOMEtnkmJ5CPornwbH7S7FJWzAFB0cxmYKUw@mail.gmail.com>
 <54AC3A13.207@gmail.com>
 <CAMgWh9vUoqqmDYkUFKr7YavptKqS=_swziQXWr-Y_+g2hq7Z7g@mail.gmail.com>
 <CAK-tuPbDyV=O+ygRCEEYzknHBosZ0Z1-4vSQUE+whUnRT1ja2g@mail.gmail.com>
Message-ID: <CAPeieQENQvpfMS_qT00vGTykfeQmHaAH-v9UHsT_RD9m34+CCw@mail.gmail.com>

Does cabal rely on this behavior?

Erik

On Tue, Jan 6, 2015 at 9:37 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
> Who volunteers to fix the breakages in Cabal and add all the needed CPP?
>
> On Tue, Jan 6, 2015 at 2:45 PM, David Feuer <david.feuer at gmail.com> wrote:
>>
>> This seems reasonable, but if we have a deprecation cycle, the old name
>> should (temporarily) be a synonym for the new one, and the deprecation
>> warning should indicate that code intended to work with older versions needs
>> to be audited.
>>
>> On Jan 6, 2015 2:40 PM, "Gabriel Gonzalez" <gabriel439 at gmail.com> wrote:
>>>
>>> I think it's safer to remove the old function altogether (perhaps after
>>> one deprecation cycle) and provide a new one under a different name, rather
>>> than modify it in place.
>>>
>>> Modifying it in place risks the behavior that others mentioned where your
>>> program is unsafe to compile against older library versions.  Yes, the user
>>> could explicitly enforce that by putting a lower bound on the library, but
>>> most users won't even realize that they need to do that.
>>>
>>>
>>> On 1/6/15, 11:37 AM, Edward Kmett wrote:
>>>
>>> I'm +1 for fixing this, in place, on the current function.
>>>
>>> The specification we have here is doing a very very bad thing and needs
>>> to be fixed, not slavishly copied forward because someone sometime once made
>>> a mistake.
>>>
>>> The current behavior grievously violates the expectations of anyone who
>>> would be in a situation to go and reach for it and has any prior experience
>>> with any other such tool.
>>>
>>> -Edward
>>>
>>>
>>>
>>> On Tue, Jan 6, 2015 at 11:14 AM, Malcolm Wallace <malcolm.wallace at me.com>
>>> wrote:
>>>>
>>>>
>>>> On 6 Jan 2015, at 14:59, Bardur Arantsson wrote:
>>>>
>>>> > On 2015-01-06 14:57, Mike Meyer wrote:
>>>> >> On Tue, Jan 6, 2015 at 7:48 AM, Johan Tibell <johan.tibell at gmail.com>
>>>> >> wrote:
>>>> >>
>>>> >>> This is not a bugfix. A bug is failing to follow the functions
>>>> >>> specification, which *does* include following symlinks.
>>>> >>>
>>>> >>
>>>> >> It's a bug in the design, not the code.
>>>>
>>>> > Because *nobody* wants to follow symlinks when doing "rm -rf". Even if
>>>> > they think they do, they *really* don't.
>>>>
>>>> I agree 100%.  Even time I use this function, I worry briefly about
>>>> whether it follows symlinks, then think to myself "no, no-one would be so
>>>> stupid to implement that deliberately in a publically available API".  So it
>>>> was a real shock to discover in this thread that I was wrong, and
>>>> furthermore that the function is documented as doing the wrong thing.  We
>>>> should fix both spec and implementation, as soon as possible.
>>>>
>>>> Regards,
>>>>     Malcolm
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

From ezyang at mit.edu  Tue Jan  6 20:43:14 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Tue, 06 Jan 2015 12:43:14 -0800
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAPeieQENQvpfMS_qT00vGTykfeQmHaAH-v9UHsT_RD9m34+CCw@mail.gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
 <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
 <m8gt8o$6f3$1@ger.gmane.org> <455CD231-2D34-4E1E-B96B-50D923D3B737@me.com>
 <CAJumaK_T3x1e13oOMEtnkmJ5CPornwbH7S7FJWzAFB0cxmYKUw@mail.gmail.com>
 <54AC3A13.207@gmail.com>
 <CAMgWh9vUoqqmDYkUFKr7YavptKqS=_swziQXWr-Y_+g2hq7Z7g@mail.gmail.com>
 <CAK-tuPbDyV=O+ygRCEEYzknHBosZ0Z1-4vSQUE+whUnRT1ja2g@mail.gmail.com>
 <CAPeieQENQvpfMS_qT00vGTykfeQmHaAH-v9UHsT_RD9m34+CCw@mail.gmail.com>
Message-ID: <1420576977-sup-7054@sabre>

I did a quick check, and all references in Cabal implicitly assume there
will be no symlinks in the directory being deleted.

Edward

Excerpts from Erik Hesselink's message of 2015-01-06 12:39:22 -0800:
> Does cabal rely on this behavior?
> 
> Erik
> 
> On Tue, Jan 6, 2015 at 9:37 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
> > Who volunteers to fix the breakages in Cabal and add all the needed CPP?
> >
> > On Tue, Jan 6, 2015 at 2:45 PM, David Feuer <david.feuer at gmail.com> wrote:
> >>
> >> This seems reasonable, but if we have a deprecation cycle, the old name
> >> should (temporarily) be a synonym for the new one, and the deprecation
> >> warning should indicate that code intended to work with older versions needs
> >> to be audited.
> >>
> >> On Jan 6, 2015 2:40 PM, "Gabriel Gonzalez" <gabriel439 at gmail.com> wrote:
> >>>
> >>> I think it's safer to remove the old function altogether (perhaps after
> >>> one deprecation cycle) and provide a new one under a different name, rather
> >>> than modify it in place.
> >>>
> >>> Modifying it in place risks the behavior that others mentioned where your
> >>> program is unsafe to compile against older library versions.  Yes, the user
> >>> could explicitly enforce that by putting a lower bound on the library, but
> >>> most users won't even realize that they need to do that.
> >>>
> >>>
> >>> On 1/6/15, 11:37 AM, Edward Kmett wrote:
> >>>
> >>> I'm +1 for fixing this, in place, on the current function.
> >>>
> >>> The specification we have here is doing a very very bad thing and needs
> >>> to be fixed, not slavishly copied forward because someone sometime once made
> >>> a mistake.
> >>>
> >>> The current behavior grievously violates the expectations of anyone who
> >>> would be in a situation to go and reach for it and has any prior experience
> >>> with any other such tool.
> >>>
> >>> -Edward
> >>>
> >>>
> >>>
> >>> On Tue, Jan 6, 2015 at 11:14 AM, Malcolm Wallace <malcolm.wallace at me.com>
> >>> wrote:
> >>>>
> >>>>
> >>>> On 6 Jan 2015, at 14:59, Bardur Arantsson wrote:
> >>>>
> >>>> > On 2015-01-06 14:57, Mike Meyer wrote:
> >>>> >> On Tue, Jan 6, 2015 at 7:48 AM, Johan Tibell <johan.tibell at gmail.com>
> >>>> >> wrote:
> >>>> >>
> >>>> >>> This is not a bugfix. A bug is failing to follow the functions
> >>>> >>> specification, which *does* include following symlinks.
> >>>> >>>
> >>>> >>
> >>>> >> It's a bug in the design, not the code.
> >>>>
> >>>> > Because *nobody* wants to follow symlinks when doing "rm -rf". Even if
> >>>> > they think they do, they *really* don't.
> >>>>
> >>>> I agree 100%.  Even time I use this function, I worry briefly about
> >>>> whether it follows symlinks, then think to myself "no, no-one would be so
> >>>> stupid to implement that deliberately in a publically available API".  So it
> >>>> was a real shock to discover in this thread that I was wrong, and
> >>>> furthermore that the function is documented as doing the wrong thing.  We
> >>>> should fix both spec and implementation, as soon as possible.
> >>>>
> >>>> Regards,
> >>>>     Malcolm
> >>>> _______________________________________________
> >>>> Libraries mailing list
> >>>> Libraries at haskell.org
> >>>> http://www.haskell.org/mailman/listinfo/libraries
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Libraries mailing list
> >>> Libraries at haskell.org
> >>> http://www.haskell.org/mailman/listinfo/libraries
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Libraries mailing list
> >>> Libraries at haskell.org
> >>> http://www.haskell.org/mailman/listinfo/libraries
> >>>
> >>
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://www.haskell.org/mailman/listinfo/libraries
> >>
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> >

From emertens at gmail.com  Tue Jan  6 23:30:51 2015
From: emertens at gmail.com (Eric Mertens)
Date: Tue, 06 Jan 2015 23:30:51 +0000
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
 <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
 <m8gt8o$6f3$1@ger.gmane.org> <455CD231-2D34-4E1E-B96B-50D923D3B737@me.com>
 <CAJumaK_T3x1e13oOMEtnkmJ5CPornwbH7S7FJWzAFB0cxmYKUw@mail.gmail.com>
 <54AC3A13.207@gmail.com>
 <CAMgWh9vUoqqmDYkUFKr7YavptKqS=_swziQXWr-Y_+g2hq7Z7g@mail.gmail.com>
 <CAK-tuPbDyV=O+ygRCEEYzknHBosZ0Z1-4vSQUE+whUnRT1ja2g@mail.gmail.com>
Message-ID: <CALya091hVi1QZ1=3VWBmunMEAA=E4Y=y_r+ydvx67HWeL1o_9w@mail.gmail.com>

There's no option which avoid needing to fix all packages on hackage, so
each maintainer using this function will be responsible for fixing his
packages.

If we fix it in place everyone needs to add CPP to avoid calling the broken
version on old versions of directory and use an alternative implementation.

If we make a new function everyone needs to conditionally call the new
function or use an alternative implementation.

On Tue, Jan 6, 2015, 12:38 PM Johan Tibell <johan.tibell at gmail.com> wrote:

> Who volunteers to fix the breakages in Cabal and add all the needed CPP?
>
> On Tue, Jan 6, 2015 at 2:45 PM, David Feuer <david.feuer at gmail.com> wrote:
>
>> This seems reasonable, but if we have a deprecation cycle, the old name
>> should (temporarily) be a synonym for the new one, and the deprecation
>> warning should indicate that code intended to work with older versions
>> needs to be audited.
>> On Jan 6, 2015 2:40 PM, "Gabriel Gonzalez" <gabriel439 at gmail.com> wrote:
>>
>>>  I think it's safer to remove the old function altogether (perhaps after
>>> one deprecation cycle) and provide a new one under a different name, rather
>>> than modify it in place.
>>>
>>> Modifying it in place risks the behavior that others mentioned where
>>> your program is unsafe to compile against older library versions.  Yes, the
>>> user could explicitly enforce that by putting a lower bound on the library,
>>> but most users won't even realize that they need to do that.
>>>
>>>
>>> On 1/6/15, 11:37 AM, Edward Kmett wrote:
>>>
>>> I'm +1 for fixing this, in place, on the current function.
>>>
>>>  The specification we have here is doing a very very bad thing and
>>> needs to be fixed, not slavishly copied forward because someone sometime
>>> once made a mistake.
>>>
>>>  The current behavior grievously violates the expectations of anyone
>>> who would be in a situation to go and reach for it and has any prior
>>> experience with any other such tool.
>>>
>>>  -Edward
>>>
>>>
>>>
>>> On Tue, Jan 6, 2015 at 11:14 AM, Malcolm Wallace <malcolm.wallace at me.com
>>> > wrote:
>>>
>>>>
>>>> On 6 Jan 2015, at 14:59, Bardur Arantsson wrote:
>>>>
>>>> > On 2015-01-06 14:57, Mike Meyer wrote:
>>>> >> On Tue, Jan 6, 2015 at 7:48 AM, Johan Tibell <johan.tibell at gmail.com>
>>>> wrote:
>>>> >>
>>>> >>> This is not a bugfix. A bug is failing to follow the functions
>>>> >>> specification, which *does* include following symlinks.
>>>> >>>
>>>> >>
>>>> >> It's a bug in the design, not the code.
>>>>
>>>> > Because *nobody* wants to follow symlinks when doing "rm -rf". Even if
>>>> > they think they do, they *really* don't.
>>>>
>>>> I agree 100%.  Even time I use this function, I worry briefly about
>>>> whether it follows symlinks, then think to myself "no, no-one would be so
>>>> stupid to implement that deliberately in a publically available API".  So
>>>> it was a real shock to discover in this thread that I was wrong, and
>>>> furthermore that the function is documented as doing the wrong thing.  We
>>>> should fix both spec and implementation, as soon as possible.
>>>>
>>>> Regards,
>>>>     Malcolm
>>>>  _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Libraries mailing listLibraries at haskell.orghttp://www.haskell.org/mailman/listinfo/libraries
>>>
>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150106/fcccf58a/attachment-0001.html>

From david.feuer at gmail.com  Tue Jan  6 23:36:08 2015
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 6 Jan 2015 18:36:08 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CALya091hVi1QZ1=3VWBmunMEAA=E4Y=y_r+ydvx67HWeL1o_9w@mail.gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
 <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
 <m8gt8o$6f3$1@ger.gmane.org>
 <455CD231-2D34-4E1E-B96B-50D923D3B737@me.com>
 <CAJumaK_T3x1e13oOMEtnkmJ5CPornwbH7S7FJWzAFB0cxmYKUw@mail.gmail.com>
 <54AC3A13.207@gmail.com>
 <CAMgWh9vUoqqmDYkUFKr7YavptKqS=_swziQXWr-Y_+g2hq7Z7g@mail.gmail.com>
 <CAK-tuPbDyV=O+ygRCEEYzknHBosZ0Z1-4vSQUE+whUnRT1ja2g@mail.gmail.com>
 <CALya091hVi1QZ1=3VWBmunMEAA=E4Y=y_r+ydvx67HWeL1o_9w@mail.gmail.com>
Message-ID: <CAMgWh9tdV7QNnoK4RAw3obr=L0a4OqigdxhWYb1hrmBbcbA12w@mail.gmail.com>

Do we need a separate compatibility package for just this function?
Not many people will want to try to roll their own.

On Tue, Jan 6, 2015 at 6:30 PM, Eric Mertens <emertens at gmail.com> wrote:
> There's no option which avoid needing to fix all packages on hackage, so
> each maintainer using this function will be responsible for fixing his
> packages.
>
> If we fix it in place everyone needs to add CPP to avoid calling the broken
> version on old versions of directory and use an alternative implementation.
>
> If we make a new function everyone needs to conditionally call the new
> function or use an alternative implementation.

From david.feuer at gmail.com  Wed Jan  7 04:36:34 2015
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 6 Jan 2015 23:36:34 -0500
Subject: Discussion: Can we make evaluate easier to find?
Message-ID: <CAMgWh9tSSYO+CNL6P3rwjUxZ9XVP7N2iAD6jPBL+CodGW8WrJw@mail.gmail.com>

The evaluate function is defined in GHC.IO, and exported publicly by
Control.Exception. This strikes me as an extremely strange place for
it. Can we find another place to put it that would seem more sensible?
I don't think it should be removed from Control.Exception, but rather
that maybe it should be added somewhere else as well.

Digging all around, I've come up with one idea that might work, if we
give evaluate a more general type:

evaluate :: PrimMonad m => a -> m a
evaluate a = primitive (\s -> seq# a s)

With this type, we could easily put it in Control.Monad.Primitive.
There may be some challenges wiggling module dependencies around, but
hopefully not huge ones.

David

From david.feuer at gmail.com  Wed Jan  7 06:00:33 2015
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 7 Jan 2015 01:00:33 -0500
Subject: Discussion: Can we make evaluate easier to find?
In-Reply-To: <CAMgWh9tSSYO+CNL6P3rwjUxZ9XVP7N2iAD6jPBL+CodGW8WrJw@mail.gmail.com>
References: <CAMgWh9tSSYO+CNL6P3rwjUxZ9XVP7N2iAD6jPBL+CodGW8WrJw@mail.gmail.com>
Message-ID: <CAMgWh9uMLiRumAKO9_fMCehczR62NzeefeOMSeWYBuRipEJEkA@mail.gmail.com>

I went ahead and tried this. It works like a charm, but there's one
minor wrinkle: it seems we'd have to move the declaration of the
PrimMonad class out of the primitive package and into base, perhaps
into GHC.Base, with the IO instance in GHC.Base and the ST instance in
GHC.ST. What do people think?

On Tue, Jan 6, 2015 at 11:36 PM, David Feuer <david.feuer at gmail.com> wrote:
> The evaluate function is defined in GHC.IO, and exported publicly by
> Control.Exception. This strikes me as an extremely strange place for
> it. Can we find another place to put it that would seem more sensible?
> I don't think it should be removed from Control.Exception, but rather
> that maybe it should be added somewhere else as well.
>
> Digging all around, I've come up with one idea that might work, if we
> give evaluate a more general type:
>
> evaluate :: PrimMonad m => a -> m a
> evaluate a = primitive (\s -> seq# a s)
>
> With this type, we could easily put it in Control.Monad.Primitive.
> There may be some challenges wiggling module dependencies around, but
> hopefully not huge ones.
>
> David

From johan.tibell at gmail.com  Wed Jan  7 09:47:21 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 7 Jan 2015 04:47:21 -0500
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAPeieQENQvpfMS_qT00vGTykfeQmHaAH-v9UHsT_RD9m34+CCw@mail.gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
 <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
 <m8gt8o$6f3$1@ger.gmane.org>
 <455CD231-2D34-4E1E-B96B-50D923D3B737@me.com>
 <CAJumaK_T3x1e13oOMEtnkmJ5CPornwbH7S7FJWzAFB0cxmYKUw@mail.gmail.com>
 <54AC3A13.207@gmail.com>
 <CAMgWh9vUoqqmDYkUFKr7YavptKqS=_swziQXWr-Y_+g2hq7Z7g@mail.gmail.com>
 <CAK-tuPbDyV=O+ygRCEEYzknHBosZ0Z1-4vSQUE+whUnRT1ja2g@mail.gmail.com>
 <CAPeieQENQvpfMS_qT00vGTykfeQmHaAH-v9UHsT_RD9m34+CCw@mail.gmail.com>
Message-ID: <CAK-tuPZgOOzPX4KgwMzMETokXg=2-5CCJHUCJCG6wOoxk2XRrQ@mail.gmail.com>

I don't think so but if we change the function signature or name as some
suggested it all needs to be cpped still.
On Jan 6, 2015 9:39 PM, "Erik Hesselink" <hesselink at gmail.com> wrote:

> Does cabal rely on this behavior?
>
> Erik
>
> On Tue, Jan 6, 2015 at 9:37 PM, Johan Tibell <johan.tibell at gmail.com>
> wrote:
> > Who volunteers to fix the breakages in Cabal and add all the needed CPP?
> >
> > On Tue, Jan 6, 2015 at 2:45 PM, David Feuer <david.feuer at gmail.com>
> wrote:
> >>
> >> This seems reasonable, but if we have a deprecation cycle, the old name
> >> should (temporarily) be a synonym for the new one, and the deprecation
> >> warning should indicate that code intended to work with older versions
> needs
> >> to be audited.
> >>
> >> On Jan 6, 2015 2:40 PM, "Gabriel Gonzalez" <gabriel439 at gmail.com>
> wrote:
> >>>
> >>> I think it's safer to remove the old function altogether (perhaps after
> >>> one deprecation cycle) and provide a new one under a different name,
> rather
> >>> than modify it in place.
> >>>
> >>> Modifying it in place risks the behavior that others mentioned where
> your
> >>> program is unsafe to compile against older library versions.  Yes, the
> user
> >>> could explicitly enforce that by putting a lower bound on the library,
> but
> >>> most users won't even realize that they need to do that.
> >>>
> >>>
> >>> On 1/6/15, 11:37 AM, Edward Kmett wrote:
> >>>
> >>> I'm +1 for fixing this, in place, on the current function.
> >>>
> >>> The specification we have here is doing a very very bad thing and needs
> >>> to be fixed, not slavishly copied forward because someone sometime
> once made
> >>> a mistake.
> >>>
> >>> The current behavior grievously violates the expectations of anyone who
> >>> would be in a situation to go and reach for it and has any prior
> experience
> >>> with any other such tool.
> >>>
> >>> -Edward
> >>>
> >>>
> >>>
> >>> On Tue, Jan 6, 2015 at 11:14 AM, Malcolm Wallace <
> malcolm.wallace at me.com>
> >>> wrote:
> >>>>
> >>>>
> >>>> On 6 Jan 2015, at 14:59, Bardur Arantsson wrote:
> >>>>
> >>>> > On 2015-01-06 14:57, Mike Meyer wrote:
> >>>> >> On Tue, Jan 6, 2015 at 7:48 AM, Johan Tibell <
> johan.tibell at gmail.com>
> >>>> >> wrote:
> >>>> >>
> >>>> >>> This is not a bugfix. A bug is failing to follow the functions
> >>>> >>> specification, which *does* include following symlinks.
> >>>> >>>
> >>>> >>
> >>>> >> It's a bug in the design, not the code.
> >>>>
> >>>> > Because *nobody* wants to follow symlinks when doing "rm -rf". Even
> if
> >>>> > they think they do, they *really* don't.
> >>>>
> >>>> I agree 100%.  Even time I use this function, I worry briefly about
> >>>> whether it follows symlinks, then think to myself "no, no-one would
> be so
> >>>> stupid to implement that deliberately in a publically available
> API".  So it
> >>>> was a real shock to discover in this thread that I was wrong, and
> >>>> furthermore that the function is documented as doing the wrong
> thing.  We
> >>>> should fix both spec and implementation, as soon as possible.
> >>>>
> >>>> Regards,
> >>>>     Malcolm
> >>>> _______________________________________________
> >>>> Libraries mailing list
> >>>> Libraries at haskell.org
> >>>> http://www.haskell.org/mailman/listinfo/libraries
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Libraries mailing list
> >>> Libraries at haskell.org
> >>> http://www.haskell.org/mailman/listinfo/libraries
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Libraries mailing list
> >>> Libraries at haskell.org
> >>> http://www.haskell.org/mailman/listinfo/libraries
> >>>
> >>
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://www.haskell.org/mailman/listinfo/libraries
> >>
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150107/1e8dc75b/attachment.html>

From david.feuer at gmail.com  Wed Jan  7 15:40:59 2015
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 7 Jan 2015 10:40:59 -0500
Subject: Proposal: generalize evaluate
Message-ID: <CAMgWh9vnpVXz1c_WPjm=zm1tyYnQw58S5pY_xUffRu9f6dq4hg@mail.gmail.com>

Apparently, there was an issue with my last messages about this for some
people, so here's the idea again:

We could generalize Control.Exception.evaluate to

evaluate :: PrimMonad m => a -> m a
evaluate a = primitive (\s -> seq# a s)

and then export it from Control.Monad.Primitive as well, which seems to me
a much more natural place for it. The only challenge is that the PrimMonad
class would need to be moved to base.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150107/3218f8f0/attachment.html>

From michael at snoyman.com  Wed Jan  7 15:44:03 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 07 Jan 2015 15:44:03 +0000
Subject: Proposal: generalize evaluate
References: <CAMgWh9vnpVXz1c_WPjm=zm1tyYnQw58S5pY_xUffRu9f6dq4hg@mail.gmail.com>
Message-ID: <CAKA2JgJF_yA33TfFYfRfoHpGAQ_T7kQ82ioDCvRt7i08sNX6xg@mail.gmail.com>

-1 from me, adding things to base like this is a step backwards IMO. I
don't see a problem with adding a generalize evaluate to primitive as well,
however. We could also consider adding an evaluateST function somewhere in
base, if that was desired (I've personally never needed it, but I could
imagine it being useful).

On Wed Jan 07 2015 at 5:41:06 PM David Feuer <david.feuer at gmail.com> wrote:

> Apparently, there was an issue with my last messages about this for some
> people, so here's the idea again:
>
> We could generalize Control.Exception.evaluate to
>
> evaluate :: PrimMonad m => a -> m a
> evaluate a = primitive (\s -> seq# a s)
>
> and then export it from Control.Monad.Primitive as well, which seems to me
> a much more natural place for it. The only challenge is that the PrimMonad
> class would need to be moved to base.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150107/004bda09/attachment.html>

From david.feuer at gmail.com  Wed Jan  7 15:48:13 2015
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 7 Jan 2015 10:48:13 -0500
Subject: Proposal: generalize evaluate
In-Reply-To: <CAKA2JgJF_yA33TfFYfRfoHpGAQ_T7kQ82ioDCvRt7i08sNX6xg@mail.gmail.com>
References: <CAMgWh9vnpVXz1c_WPjm=zm1tyYnQw58S5pY_xUffRu9f6dq4hg@mail.gmail.com>
 <CAKA2JgJF_yA33TfFYfRfoHpGAQ_T7kQ82ioDCvRt7i08sNX6xg@mail.gmail.com>
Message-ID: <CAMgWh9u=ev5YPJs5J+xX7Q8+ezpzc4eGwj0WOOWznGJ9-SYR_g@mail.gmail.com>

FYI, my original goal was not actually generalizing it, but rather finding
it a more obvious home than Control.Exception. Control.Monad.Primitive was
the best match I could find, since there is no Control.Monad.IO to match
Control.Monad.ST.
On Jan 7, 2015 10:44 AM, "Michael Snoyman" <michael at snoyman.com> wrote:

> -1 from me, adding things to base like this is a step backwards IMO. I
> don't see a problem with adding a generalize evaluate to primitive as well,
> however. We could also consider adding an evaluateST function somewhere in
> base, if that was desired (I've personally never needed it, but I could
> imagine it being useful).
>
> On Wed Jan 07 2015 at 5:41:06 PM David Feuer <david.feuer at gmail.com>
> wrote:
>
>> Apparently, there was an issue with my last messages about this for some
>> people, so here's the idea again:
>>
>> We could generalize Control.Exception.evaluate to
>>
>> evaluate :: PrimMonad m => a -> m a
>> evaluate a = primitive (\s -> seq# a s)
>>
>> and then export it from Control.Monad.Primitive as well, which seems to
>> me a much more natural place for it. The only challenge is that the
>> PrimMonad class would need to be moved to base.
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150107/3d38f838/attachment.html>

From me at lelf.lu  Wed Jan  7 17:19:32 2015
From: me at lelf.lu (Antonio Nikishaev)
Date: Wed, 07 Jan 2015 21:19:32 +0400
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
References: <1420496644-sup-4814@sabre>
Message-ID: <m28uheld97.fsf@lelf.me>

"Edward Z. Yang" <ezyang at mit.edu> writes:

> I propose to backwards incompatibly change the behavior of
> removeDirectoryRecursive to not follow symlinks.  We could optionally
> add a replacement function under a new name which does follow
> symlinks.

+1 for changing it immediately,
-1 for any deprecation period,
-1 for adding the old one under another name

Motivation: even if documented, the behaviour is severe bug with
security implications.  I don't think anyone in the right mind would
expect such a function to follow symlinks.




From gabriel439 at gmail.com  Wed Jan  7 17:49:47 2015
From: gabriel439 at gmail.com (Gabriel Gonzalez)
Date: Wed, 07 Jan 2015 09:49:47 -0800
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAK-tuPZgOOzPX4KgwMzMETokXg=2-5CCJHUCJCG6wOoxk2XRrQ@mail.gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
 <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
 <m8gt8o$6f3$1@ger.gmane.org> <455CD231-2D34-4E1E-B96B-50D923D3B737@me.com>
 <CAJumaK_T3x1e13oOMEtnkmJ5CPornwbH7S7FJWzAFB0cxmYKUw@mail.gmail.com>
 <54AC3A13.207@gmail.com>
 <CAMgWh9vUoqqmDYkUFKr7YavptKqS=_swziQXWr-Y_+g2hq7Z7g@mail.gmail.com>
 <CAK-tuPbDyV=O+ygRCEEYzknHBosZ0Z1-4vSQUE+whUnRT1ja2g@mail.gmail.com>
 <CAPeieQENQvpfMS_qT00vGTykfeQmHaAH-v9UHsT_RD9m34+CCw@mail.gmail.com>
 <CAK-tuPZgOOzPX4KgwMzMETokXg=2-5CCJHUCJCG6wOoxk2XRrQ@mail.gmail.com>
Message-ID: <54AD71BB.50906@gmail.com>

Actually, I might retract my recommendation to provided it under a 
different name.  I'm neutral on this now and would consider it okay to 
change in place.

My reasoning is that this is a bug fix, so we can reasonably expect 
users to put lower bounds on software in response to bug fixes like we 
do with other software.

On 1/7/15, 1:47 AM, Johan Tibell wrote:
>
> I don't think so but if we change the function signature or name as 
> some suggested it all needs to be cpped still.
>
> On Jan 6, 2015 9:39 PM, "Erik Hesselink" <hesselink at gmail.com 
> <mailto:hesselink at gmail.com>> wrote:
>
>     Does cabal rely on this behavior?
>
>     Erik
>
>     On Tue, Jan 6, 2015 at 9:37 PM, Johan Tibell
>     <johan.tibell at gmail.com <mailto:johan.tibell at gmail.com>> wrote:
>     > Who volunteers to fix the breakages in Cabal and add all the
>     needed CPP?
>     >
>     > On Tue, Jan 6, 2015 at 2:45 PM, David Feuer
>     <david.feuer at gmail.com <mailto:david.feuer at gmail.com>> wrote:
>     >>
>     >> This seems reasonable, but if we have a deprecation cycle, the
>     old name
>     >> should (temporarily) be a synonym for the new one, and the
>     deprecation
>     >> warning should indicate that code intended to work with older
>     versions needs
>     >> to be audited.
>     >>
>     >> On Jan 6, 2015 2:40 PM, "Gabriel Gonzalez"
>     <gabriel439 at gmail.com <mailto:gabriel439 at gmail.com>> wrote:
>     >>>
>     >>> I think it's safer to remove the old function altogether
>     (perhaps after
>     >>> one deprecation cycle) and provide a new one under a different
>     name, rather
>     >>> than modify it in place.
>     >>>
>     >>> Modifying it in place risks the behavior that others mentioned
>     where your
>     >>> program is unsafe to compile against older library versions. 
>     Yes, the user
>     >>> could explicitly enforce that by putting a lower bound on the
>     library, but
>     >>> most users won't even realize that they need to do that.
>     >>>
>     >>>
>     >>> On 1/6/15, 11:37 AM, Edward Kmett wrote:
>     >>>
>     >>> I'm +1 for fixing this, in place, on the current function.
>     >>>
>     >>> The specification we have here is doing a very very bad thing
>     and needs
>     >>> to be fixed, not slavishly copied forward because someone
>     sometime once made
>     >>> a mistake.
>     >>>
>     >>> The current behavior grievously violates the expectations of
>     anyone who
>     >>> would be in a situation to go and reach for it and has any
>     prior experience
>     >>> with any other such tool.
>     >>>
>     >>> -Edward
>     >>>
>     >>>
>     >>>
>     >>> On Tue, Jan 6, 2015 at 11:14 AM, Malcolm Wallace
>     <malcolm.wallace at me.com <mailto:malcolm.wallace at me.com>>
>     >>> wrote:
>     >>>>
>     >>>>
>     >>>> On 6 Jan 2015, at 14:59, Bardur Arantsson wrote:
>     >>>>
>     >>>> > On 2015-01-06 14:57, Mike Meyer wrote:
>     >>>> >> On Tue, Jan 6, 2015 at 7:48 AM, Johan Tibell
>     <johan.tibell at gmail.com <mailto:johan.tibell at gmail.com>>
>     >>>> >> wrote:
>     >>>> >>
>     >>>> >>> This is not a bugfix. A bug is failing to follow the
>     functions
>     >>>> >>> specification, which *does* include following symlinks.
>     >>>> >>>
>     >>>> >>
>     >>>> >> It's a bug in the design, not the code.
>     >>>>
>     >>>> > Because *nobody* wants to follow symlinks when doing "rm
>     -rf". Even if
>     >>>> > they think they do, they *really* don't.
>     >>>>
>     >>>> I agree 100%.  Even time I use this function, I worry briefly
>     about
>     >>>> whether it follows symlinks, then think to myself "no, no-one
>     would be so
>     >>>> stupid to implement that deliberately in a publically
>     available API".  So it
>     >>>> was a real shock to discover in this thread that I was wrong, and
>     >>>> furthermore that the function is documented as doing the
>     wrong thing.  We
>     >>>> should fix both spec and implementation, as soon as possible.
>     >>>>
>     >>>> Regards,
>     >>>>     Malcolm
>     >>>> _______________________________________________
>     >>>> Libraries mailing list
>     >>>> Libraries at haskell.org <mailto:Libraries at haskell.org>
>     >>>> http://www.haskell.org/mailman/listinfo/libraries
>     >>>
>     >>>
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> Libraries mailing list
>     >>> Libraries at haskell.org <mailto:Libraries at haskell.org>
>     >>> http://www.haskell.org/mailman/listinfo/libraries
>     >>>
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> Libraries mailing list
>     >>> Libraries at haskell.org <mailto:Libraries at haskell.org>
>     >>> http://www.haskell.org/mailman/listinfo/libraries
>     >>>
>     >>
>     >> _______________________________________________
>     >> Libraries mailing list
>     >> Libraries at haskell.org <mailto:Libraries at haskell.org>
>     >> http://www.haskell.org/mailman/listinfo/libraries
>     >>
>     >
>     >
>     > _______________________________________________
>     > Libraries mailing list
>     > Libraries at haskell.org <mailto:Libraries at haskell.org>
>     > http://www.haskell.org/mailman/listinfo/libraries
>     >
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150107/b1628ddc/attachment-0001.html>

From lemming at henning-thielemann.de  Wed Jan  7 19:45:32 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed, 7 Jan 2015 20:45:32 +0100 (CET)
Subject: Discussion: Can we make evaluate easier to find?
In-Reply-To: <CAMgWh9uMLiRumAKO9_fMCehczR62NzeefeOMSeWYBuRipEJEkA@mail.gmail.com>
References: <CAMgWh9tSSYO+CNL6P3rwjUxZ9XVP7N2iAD6jPBL+CodGW8WrJw@mail.gmail.com>
 <CAMgWh9uMLiRumAKO9_fMCehczR62NzeefeOMSeWYBuRipEJEkA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1501072044150.6742@sputnik>


> On Tue, Jan 6, 2015 at 11:36 PM, David Feuer <david.feuer at gmail.com> wrote:

>> The evaluate function is defined in GHC.IO, and exported publicly by 
>> Control.Exception. This strikes me as an extremely strange place for 
>> it.

I also find the place strange. If there would be a module with a type 
class for seq (like Eval), it would be certainly a good place for 
'evaluate'.

From jwlato at gmail.com  Wed Jan  7 20:27:24 2015
From: jwlato at gmail.com (John Lato)
Date: Wed, 07 Jan 2015 20:27:24 +0000
Subject: Discussion: Can we make evaluate easier to find?
References: <CAMgWh9tSSYO+CNL6P3rwjUxZ9XVP7N2iAD6jPBL+CodGW8WrJw@mail.gmail.com>
 <CAMgWh9uMLiRumAKO9_fMCehczR62NzeefeOMSeWYBuRipEJEkA@mail.gmail.com>
 <alpine.DEB.2.02.1501072044150.6742@sputnik>
Message-ID: <CAJ727Gi936vpw0DLq_XW+GLkXvN8RPMegYfhGqbKO0LKGq4AmA@mail.gmail.com>

I agree that Control.Exception seems like a very strange place for
`evaluate` to be publicly exported.  However, I've never wanted that
function except in the context of forcing evaluation of a pure value in
order to catch exceptions.  I also can't think of any other use cases that
aren't more easily solved by seq/bang patterns.  If the only use case is in
fact exception handling, Control.Exception seems like a pretty good
location.
On Wed Jan 07 2015 at 11:45:39 AM Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> > On Tue, Jan 6, 2015 at 11:36 PM, David Feuer <david.feuer at gmail.com>
> wrote:
>
> >> The evaluate function is defined in GHC.IO, and exported publicly by
> >> Control.Exception. This strikes me as an extremely strange place for
> >> it.
>
> I also find the place strange. If there would be a module with a type
> class for seq (like Eval), it would be certainly a good place for
> 'evaluate'.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150107/7ad252ed/attachment.html>

From david.feuer at gmail.com  Wed Jan  7 20:30:26 2015
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 7 Jan 2015 15:30:26 -0500
Subject: Discussion: Can we make evaluate easier to find?
In-Reply-To: <CAJ727Gi936vpw0DLq_XW+GLkXvN8RPMegYfhGqbKO0LKGq4AmA@mail.gmail.com>
References: <CAMgWh9tSSYO+CNL6P3rwjUxZ9XVP7N2iAD6jPBL+CodGW8WrJw@mail.gmail.com>
 <CAMgWh9uMLiRumAKO9_fMCehczR62NzeefeOMSeWYBuRipEJEkA@mail.gmail.com>
 <alpine.DEB.2.02.1501072044150.6742@sputnik>
 <CAJ727Gi936vpw0DLq_XW+GLkXvN8RPMegYfhGqbKO0LKGq4AmA@mail.gmail.com>
Message-ID: <CAMgWh9tg0NU0-g2K1vn0+h0M-nEpWK7SePKW3UDEunc60yg-kQ@mail.gmail.com>

Isn't it the official way to make sure lazy IO gets performed before a
file is closed, or is ($!) actually safe for that? (I really and truly
can't understand all the details of what goes on in the rather old bug
reports relating to the implementation of evaluate).

On Wed, Jan 7, 2015 at 3:27 PM, John Lato <jwlato at gmail.com> wrote:
> I agree that Control.Exception seems like a very strange place for
> `evaluate` to be publicly exported.  However, I've never wanted that
> function except in the context of forcing evaluation of a pure value in
> order to catch exceptions.  I also can't think of any other use cases that
> aren't more easily solved by seq/bang patterns.  If the only use case is in
> fact exception handling, Control.Exception seems like a pretty good
> location.
> On Wed Jan 07 2015 at 11:45:39 AM Henning Thielemann
> <lemming at henning-thielemann.de> wrote:
>>
>>
>> > On Tue, Jan 6, 2015 at 11:36 PM, David Feuer <david.feuer at gmail.com>
>> > wrote:
>>
>> >> The evaluate function is defined in GHC.IO, and exported publicly by
>> >> Control.Exception. This strikes me as an extremely strange place for
>> >> it.
>>
>> I also find the place strange. If there would be a module with a type
>> class for seq (like Eval), it would be certainly a good place for
>> 'evaluate'.
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries

From jwlato at gmail.com  Thu Jan  8 17:11:22 2015
From: jwlato at gmail.com (John Lato)
Date: Thu, 08 Jan 2015 17:11:22 +0000
Subject: Discussion: Can we make evaluate easier to find?
References: <CAMgWh9tSSYO+CNL6P3rwjUxZ9XVP7N2iAD6jPBL+CodGW8WrJw@mail.gmail.com>
 <CAMgWh9uMLiRumAKO9_fMCehczR62NzeefeOMSeWYBuRipEJEkA@mail.gmail.com>
 <alpine.DEB.2.02.1501072044150.6742@sputnik>
 <CAJ727Gi936vpw0DLq_XW+GLkXvN8RPMegYfhGqbKO0LKGq4AmA@mail.gmail.com>
 <CAMgWh9tg0NU0-g2K1vn0+h0M-nEpWK7SePKW3UDEunc60yg-kQ@mail.gmail.com>
Message-ID: <CAJ727GheA0dPsikEB-5+5v6YkodufucDKVwT5K90rumRx3hDNQ@mail.gmail.com>

AKAIK neither one is necessarily safe. You need something like deepseq to
fully evaluate the lazy structure.

If you are sure that evaluation to WHNF is sufficient for performing all
lazy IO, then I think either evaluate or ($!) will work.

evaluate is probably to be preferred if IO is available, similar to throw
vs throwIO.  However I think idioms with seq and ($!) are so common that
they need to be supported too. After all, you may have just a 'Monad m'
context.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150108/bf59123d/attachment.html>

From david.feuer at gmail.com  Thu Jan  8 17:15:06 2015
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 8 Jan 2015 12:15:06 -0500
Subject: Discussion: Can we make evaluate easier to find?
In-Reply-To: <CAJ727GheA0dPsikEB-5+5v6YkodufucDKVwT5K90rumRx3hDNQ@mail.gmail.com>
References: <CAMgWh9tSSYO+CNL6P3rwjUxZ9XVP7N2iAD6jPBL+CodGW8WrJw@mail.gmail.com>
 <CAMgWh9uMLiRumAKO9_fMCehczR62NzeefeOMSeWYBuRipEJEkA@mail.gmail.com>
 <alpine.DEB.2.02.1501072044150.6742@sputnik>
 <CAJ727Gi936vpw0DLq_XW+GLkXvN8RPMegYfhGqbKO0LKGq4AmA@mail.gmail.com>
 <CAMgWh9tg0NU0-g2K1vn0+h0M-nEpWK7SePKW3UDEunc60yg-kQ@mail.gmail.com>
 <CAJ727GheA0dPsikEB-5+5v6YkodufucDKVwT5K90rumRx3hDNQ@mail.gmail.com>
Message-ID: <CAMgWh9uzMvUtMjGYYMa=Yz158DRZg2oNnUq+vd8rbJH1VbB8PA@mail.gmail.com>

deepseq is somewhat orthogonal:

shallow: v $! return v
deep: v $!! return v
shallow: evaluate v >>= return
deep: evaluate (force v) >>= return

On Thu, Jan 8, 2015 at 12:11 PM, John Lato <jwlato at gmail.com> wrote:
> AKAIK neither one is necessarily safe. You need something like deepseq to
> fully evaluate the lazy structure.
>
> If you are sure that evaluation to WHNF is sufficient for performing all
> lazy IO, then I think either evaluate or ($!) will work.
>
> evaluate is probably to be preferred if IO is available, similar to throw vs
> throwIO.  However I think idioms with seq and ($!) are so common that they
> need to be supported too. After all, you may have just a 'Monad m' context.
>
> John

From jwlato at gmail.com  Thu Jan  8 17:25:51 2015
From: jwlato at gmail.com (John Lato)
Date: Thu, 08 Jan 2015 17:25:51 +0000
Subject: Discussion: Can we make evaluate easier to find?
References: <CAMgWh9tSSYO+CNL6P3rwjUxZ9XVP7N2iAD6jPBL+CodGW8WrJw@mail.gmail.com>
 <CAMgWh9uMLiRumAKO9_fMCehczR62NzeefeOMSeWYBuRipEJEkA@mail.gmail.com>
 <alpine.DEB.2.02.1501072044150.6742@sputnik>
 <CAJ727Gi936vpw0DLq_XW+GLkXvN8RPMegYfhGqbKO0LKGq4AmA@mail.gmail.com>
 <CAMgWh9tg0NU0-g2K1vn0+h0M-nEpWK7SePKW3UDEunc60yg-kQ@mail.gmail.com>
 <CAJ727GheA0dPsikEB-5+5v6YkodufucDKVwT5K90rumRx3hDNQ@mail.gmail.com>
 <CAMgWh9uzMvUtMjGYYMa=Yz158DRZg2oNnUq+vd8rbJH1VbB8PA@mail.gmail.com>
Message-ID: <CAJ727GhJT_KzC+xREYAJ92EC28K+_JzoB33pG2S4OspQMkUv_w@mail.gmail.com>

It's a bit orthogonal, but since you brought up lazy IO I thought it was
worth mentioning, as shallow evaluation is insufficient.

On 09:15, Thu, Jan 8, 2015 David Feuer <david.feuer at gmail.com> wrote:

> deepseq is somewhat orthogonal:
>
> shallow: v $! return v
> deep: v $!! return v
> shallow: evaluate v >>= return
> deep: evaluate (force v) >>= return
>
> On Thu, Jan 8, 2015 at 12:11 PM, John Lato <jwlato at gmail.com> wrote:
> > AKAIK neither one is necessarily safe. You need something like deepseq to
> > fully evaluate the lazy structure.
> >
> > If you are sure that evaluation to WHNF is sufficient for performing all
> > lazy IO, then I think either evaluate or ($!) will work.
> >
> > evaluate is probably to be preferred if IO is available, similar to
> throw vs
> > throwIO.  However I think idioms with seq and ($!) are so common that
> they
> > need to be supported too. After all, you may have just a 'Monad m'
> context.
> >
> > John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150108/2f997177/attachment.html>

From david.feuer at gmail.com  Thu Jan  8 17:27:57 2015
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 8 Jan 2015 12:27:57 -0500
Subject: Adding Read instances for HList
Message-ID: <CAMgWh9uXuBDpq=bwcY5NZXF3kA3f8bkO+ZRM7CpuNG+d9xROJA@mail.gmail.com>

One option looks something like the code below. Another option would
mirror the current Show instances by pushing "H[" back onto the state
each time an item is parsed (I don't think that's a particularly clean
approach, but it's an option).


{-# LANGUAGE
  DataKinds
 ,KindSignatures
 ,FlexibleContexts
 ,FlexibleInstances
 ,TypeOperators
 ,GADTs
 ,ScopedTypeVariables
 #-}

module MyHList where
import GHC.Read
import Text.ParserCombinators.ReadPrec
import qualified Text.Read.Lex as L

-- This declaration is copied from `Data.HList.HList`.
data HList (l::[*]) where
  HNil  :: HList '[]
  HCons :: e -> HList l -> HList (e ': l)

infixr 2 `HCons`


instance Read (HList '[]) where
  readPrec = parens
    ( do
        expectP (L.Ident "H")
        expectP (L.Punc "[")
        expectP (L.Punc "]")
        return HNil
    )

instance forall e . Read e => Read (HList (e ': '[])) where
  readPrec = parens
    ( do
        expectP (L.Ident "H")
        expectP (L.Punc "[")
        e <- reset $ (readPrec::ReadPrec e)
        expectP (L.Punc "]")
        return (e `HCons` HNil)
    )

instance forall e f (l::[*]) . (Read e, ReadTl (HList (f ': l))) =>
   Read (HList (e ': f ': l)) where
  readPrec = parens
    ( do
        expectP (L.Ident "H")
        expectP (L.Punc "[")
        e <- reset $ (readPrec::ReadPrec e)
        expectP (L.Punc ",")
        rest <- readTl :: ReadPrec (HList (f ': l))
        return (e `HCons` rest)
    )

class ReadTl l where
  readTl :: ReadPrec l

instance forall e . Read e => ReadTl (HList (e ': '[])) where
  {-# INLINE readTl #-}
  readTl = do
    e <- reset $ (readPrec::ReadPrec e)
    expectP (L.Punc "]")
    return $ e `HCons` HNil

instance forall e f (l::[*]) . (Read e, ReadTl (HList (f ': l)))
             => ReadTl (HList (e ': f ': l)) where
  {-# INLINE readTl #-}
  readTl = do
    e <- reset $ (readPrec::ReadPrec e)
    expectP (L.Punc ",")
    rest <- readTl
    return (e `HCons` rest)

From greg at gregweber.info  Fri Jan  9 00:06:29 2015
From: greg at gregweber.info (Greg Weber)
Date: Thu, 8 Jan 2015 16:06:29 -0800
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <54AD71BB.50906@gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
 <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
 <m8gt8o$6f3$1@ger.gmane.org> <455CD231-2D34-4E1E-B96B-50D923D3B737@me.com>
 <CAJumaK_T3x1e13oOMEtnkmJ5CPornwbH7S7FJWzAFB0cxmYKUw@mail.gmail.com>
 <54AC3A13.207@gmail.com>
 <CAMgWh9vUoqqmDYkUFKr7YavptKqS=_swziQXWr-Y_+g2hq7Z7g@mail.gmail.com>
 <CAK-tuPbDyV=O+ygRCEEYzknHBosZ0Z1-4vSQUE+whUnRT1ja2g@mail.gmail.com>
 <CAPeieQENQvpfMS_qT00vGTykfeQmHaAH-v9UHsT_RD9m34+CCw@mail.gmail.com>
 <CAK-tuPZgOOzPX4KgwMzMETokXg=2-5CCJHUCJCG6wOoxk2XRrQ@mail.gmail.com>
 <54AD71BB.50906@gmail.com>
Message-ID: <CAKRanNA0MrUKcWRSm4Y9ym90mxf_JMsKYb4xYH5gnFrpM29HUA@mail.gmail.com>

We all agree that we should do something about this. For 99% of use cases
this is a bug fix.
So I would like to just leave it up to the implementer to decide what to do.


On Wed, Jan 7, 2015 at 9:49 AM, Gabriel Gonzalez <gabriel439 at gmail.com>
wrote:

>  Actually, I might retract my recommendation to provided it under a
> different name.  I'm neutral on this now and would consider it okay to
> change in place.
>
> My reasoning is that this is a bug fix, so we can reasonably expect users
> to put lower bounds on software in response to bug fixes like we do with
> other software.
>
>
> On 1/7/15, 1:47 AM, Johan Tibell wrote:
>
> I don't think so but if we change the function signature or name as some
> suggested it all needs to be cpped still.
> On Jan 6, 2015 9:39 PM, "Erik Hesselink" <hesselink at gmail.com> wrote:
>
>> Does cabal rely on this behavior?
>>
>> Erik
>>
>> On Tue, Jan 6, 2015 at 9:37 PM, Johan Tibell <johan.tibell at gmail.com>
>> wrote:
>> > Who volunteers to fix the breakages in Cabal and add all the needed CPP?
>> >
>> > On Tue, Jan 6, 2015 at 2:45 PM, David Feuer <david.feuer at gmail.com>
>> wrote:
>> >>
>> >> This seems reasonable, but if we have a deprecation cycle, the old name
>> >> should (temporarily) be a synonym for the new one, and the deprecation
>> >> warning should indicate that code intended to work with older versions
>> needs
>> >> to be audited.
>> >>
>> >> On Jan 6, 2015 2:40 PM, "Gabriel Gonzalez" <gabriel439 at gmail.com>
>> wrote:
>> >>>
>> >>> I think it's safer to remove the old function altogether (perhaps
>> after
>> >>> one deprecation cycle) and provide a new one under a different name,
>> rather
>> >>> than modify it in place.
>> >>>
>> >>> Modifying it in place risks the behavior that others mentioned where
>> your
>> >>> program is unsafe to compile against older library versions.  Yes,
>> the user
>> >>> could explicitly enforce that by putting a lower bound on the
>> library, but
>> >>> most users won't even realize that they need to do that.
>> >>>
>> >>>
>> >>> On 1/6/15, 11:37 AM, Edward Kmett wrote:
>> >>>
>> >>> I'm +1 for fixing this, in place, on the current function.
>> >>>
>> >>> The specification we have here is doing a very very bad thing and
>> needs
>> >>> to be fixed, not slavishly copied forward because someone sometime
>> once made
>> >>> a mistake.
>> >>>
>> >>> The current behavior grievously violates the expectations of anyone
>> who
>> >>> would be in a situation to go and reach for it and has any prior
>> experience
>> >>> with any other such tool.
>> >>>
>> >>> -Edward
>> >>>
>> >>>
>> >>>
>> >>> On Tue, Jan 6, 2015 at 11:14 AM, Malcolm Wallace <
>> malcolm.wallace at me.com>
>> >>> wrote:
>> >>>>
>> >>>>
>> >>>> On 6 Jan 2015, at 14:59, Bardur Arantsson wrote:
>> >>>>
>> >>>> > On 2015-01-06 14:57, Mike Meyer wrote:
>> >>>> >> On Tue, Jan 6, 2015 at 7:48 AM, Johan Tibell <
>> johan.tibell at gmail.com>
>> >>>> >> wrote:
>> >>>> >>
>> >>>> >>> This is not a bugfix. A bug is failing to follow the functions
>> >>>> >>> specification, which *does* include following symlinks.
>> >>>> >>>
>> >>>> >>
>> >>>> >> It's a bug in the design, not the code.
>> >>>>
>> >>>> > Because *nobody* wants to follow symlinks when doing "rm -rf".
>> Even if
>> >>>> > they think they do, they *really* don't.
>> >>>>
>> >>>> I agree 100%.  Even time I use this function, I worry briefly about
>> >>>> whether it follows symlinks, then think to myself "no, no-one would
>> be so
>> >>>> stupid to implement that deliberately in a publically available
>> API".  So it
>> >>>> was a real shock to discover in this thread that I was wrong, and
>> >>>> furthermore that the function is documented as doing the wrong
>> thing.  We
>> >>>> should fix both spec and implementation, as soon as possible.
>> >>>>
>> >>>> Regards,
>> >>>>     Malcolm
>> >>>> _______________________________________________
>> >>>> Libraries mailing list
>> >>>> Libraries at haskell.org
>> >>>> http://www.haskell.org/mailman/listinfo/libraries
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Libraries mailing list
>> >>> Libraries at haskell.org
>> >>> http://www.haskell.org/mailman/listinfo/libraries
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Libraries mailing list
>> >>> Libraries at haskell.org
>> >>> http://www.haskell.org/mailman/listinfo/libraries
>> >>>
>> >>
>> >> _______________________________________________
>> >> Libraries mailing list
>> >> Libraries at haskell.org
>> >> http://www.haskell.org/mailman/listinfo/libraries
>> >>
>> >
>> >
>> > _______________________________________________
>> > Libraries mailing list
>> > Libraries at haskell.org
>> > http://www.haskell.org/mailman/listinfo/libraries
>> >
>>
>
>
> _______________________________________________
> Libraries mailing listLibraries at haskell.orghttp://www.haskell.org/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150108/a4ed4d89/attachment-0001.html>

From hvr at gnu.org  Fri Jan  9 10:55:21 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Fri, 09 Jan 2015 11:55:21 +0100
Subject: Discussion: Can we make evaluate easier to find?
In-Reply-To: <CAJ727GheA0dPsikEB-5+5v6YkodufucDKVwT5K90rumRx3hDNQ@mail.gmail.com>
 (John Lato's message of "Thu, 08 Jan 2015 17:11:22 +0000")
References: <CAMgWh9tSSYO+CNL6P3rwjUxZ9XVP7N2iAD6jPBL+CodGW8WrJw@mail.gmail.com>
 <CAMgWh9uMLiRumAKO9_fMCehczR62NzeefeOMSeWYBuRipEJEkA@mail.gmail.com>
 <alpine.DEB.2.02.1501072044150.6742@sputnik>
 <CAJ727Gi936vpw0DLq_XW+GLkXvN8RPMegYfhGqbKO0LKGq4AmA@mail.gmail.com>
 <CAMgWh9tg0NU0-g2K1vn0+h0M-nEpWK7SePKW3UDEunc60yg-kQ@mail.gmail.com>
 <CAJ727GheA0dPsikEB-5+5v6YkodufucDKVwT5K90rumRx3hDNQ@mail.gmail.com>
Message-ID: <87k30wb4va.fsf@gnu.org>

On 2015-01-08 at 18:11:22 +0100, John Lato wrote:

[...]

> evaluate is probably to be preferred if IO is available, similar to throw
> vs throwIO.  However I think idioms with seq and ($!) are so common that
> they need to be supported too. After all, you may have just a 'Monad m'
> context.

One thing that always confused me is the semantics of seq/($!)/($!!) in
something like

  foo = do { x <- getX; rnf x `seq` return x }

as in my mental model, `;` or rather (>>=) combines two monadic actions
(according to the monad-laws), into a combined monadic action "value"
'Monad m => m a', which then needs to be executed via some monad-runner
to have any monadic effect and/or extract the result of type 'a'.

But I don't see how the monad-laws tell me anything about when that
`seq` is executed (is it evaluated at monadic combination time[1], or only
lateron at monadic execution?).

Otoh, in the IO-monad, 'evaluate' seems to be quite clear to me in its
semantics: it forces WHNF on its argument at execution-time.


 [1]: what effects does "seq foo ()" perform? If the action was

        foo' = do { undefined `seq` return () } :: Monad m => m ()

      then "seq foo' ()" will in fact diverge. So in that case, the
      `seq` is evaluated at monadic combination time; but otoh for

        foo'' = do { return undefined } :: Monad m => m ()

      "seq foo'' ()" will (for a sane 'return') evaluate to '()'

Cheers,
  hvr

From R.Paterson at city.ac.uk  Fri Jan  9 15:25:29 2015
From: R.Paterson at city.ac.uk (Ross Paterson)
Date: Fri, 9 Jan 2015 15:25:29 +0000
Subject: removing constraints
Message-ID: <20150109152529.GA5022@city.ac.uk>

Recent changes to avoid warnings have removed some constraints from
module interfaces:

* in Data.Array, Ix i was removed from:

    instance Ix i => Functor (Array i)
    instance Ix i => Foldable (Array i)
    bounds :: Ix i => Array i e -> (i,i)
    elems :: Ix i => Array i e -> [e]

* in Data.Ratio, Integral a was removed from:

    instance (Integral a, Show a) => Show (Ratio a)
    numerator :: (Integral a) => Ratio a -> a
    denominator :: (Integral a) => Ratio a -> a

These constraints are not needed by the GHC implementations, but might be
needed for other possible implementations, so in a sense the changes are
leaking the GHC implementations.  This seems most clear in the Functor
and Foldable instances for Array, and elems.  Portable implementations
of these will require the Ix constraint -- I think it should be restored.

The other cases are more arguable.  For example the change to Data.Ratio
declares that the pair is kept in reduced form, but one could argue that
requiring that is no bad thing.

From david.feuer at gmail.com  Fri Jan  9 15:29:43 2015
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 9 Jan 2015 10:29:43 -0500
Subject: removing constraints
In-Reply-To: <20150109152529.GA5022@city.ac.uk>
References: <20150109152529.GA5022@city.ac.uk>
Message-ID: <CAMgWh9ta6vagu877Skqh+7581tc1_pc8juLG3Bhm7UeHGb=+VQ@mail.gmail.com>

On Jan 9, 2015 10:25 AM, "Ross Paterson" <R.Paterson at city.ac.uk> wrote:
> These constraints are not needed by the GHC implementations, but might be
> needed for other possible implementations, so in a sense the changes are
> leaking the GHC implementations.  This seems most clear in the Functor
> and Foldable instances for Array, and elems.  Portable implementations
> of these will require the Ix constraint -- I think it should be restored.

Agreed.

> The other cases are more arguable.  For example the change to Data.Ratio
> declares that the pair is kept in reduced form, but one could argue that
> requiring that is no bad thing.

Disagreed. However, some have argued convincingly that the Ratio type as it
stands makes little sense anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150109/957d2aeb/attachment.html>

From roma at ro-che.info  Fri Jan  9 15:38:48 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Fri, 09 Jan 2015 17:38:48 +0200
Subject: removing constraints
In-Reply-To: <CAMgWh9ta6vagu877Skqh+7581tc1_pc8juLG3Bhm7UeHGb=+VQ@mail.gmail.com>
References: <20150109152529.GA5022@city.ac.uk>
 <CAMgWh9ta6vagu877Skqh+7581tc1_pc8juLG3Bhm7UeHGb=+VQ@mail.gmail.com>
Message-ID: <54AFF608.5030002@ro-che.info>

On 09/01/15 17:29, David Feuer wrote:
>> The other cases are more arguable.  For example the change to Data.Ratio
>> declares that the pair is kept in reduced form, but one could argue that
>> requiring that is no bad thing.
> 
> Disagreed. However, some have argued convincingly that the Ratio type as
> it stands makes little sense anyway.

[citation needed]


From allbery.b at gmail.com  Fri Jan  9 15:44:38 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 9 Jan 2015 10:44:38 -0500
Subject: removing constraints
In-Reply-To: <54AFF608.5030002@ro-che.info>
References: <20150109152529.GA5022@city.ac.uk>
 <CAMgWh9ta6vagu877Skqh+7581tc1_pc8juLG3Bhm7UeHGb=+VQ@mail.gmail.com>
 <54AFF608.5030002@ro-che.info>
Message-ID: <CAKFCL4UPEPENsY3MP94BROQ1ZztxBQFEkLDYu4i-A6V7Bmru+g@mail.gmail.com>

On Fri, Jan 9, 2015 at 10:38 AM, Roman Cheplyaka <roma at ro-che.info> wrote:

> On 09/01/15 17:29, David Feuer wrote:
> >> The other cases are more arguable.  For example the change to Data.Ratio
> >> declares that the pair is kept in reduced form, but one could argue that
> >> requiring that is no bad thing.
> >
> > Disagreed. However, some have argued convincingly that the Ratio type as
> > it stands makes little sense anyway.
>
> [citation needed]


I believe this is referencing a past discussion (possibly on IRC) where it
was pointed out that Ratio is a type constructor, but the only instance
that makes any sense is Ratio Integer because any bounded integral type
will eventually (and usually rather quickly) exceed the bounds and fail
rather spectacularly given the lack of exceptions on bounded-integral
wraparound?

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150109/3171ef47/attachment.html>

From lemming at henning-thielemann.de  Fri Jan  9 16:01:23 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 9 Jan 2015 17:01:23 +0100 (CET)
Subject: removing constraints
In-Reply-To: <CAKFCL4UPEPENsY3MP94BROQ1ZztxBQFEkLDYu4i-A6V7Bmru+g@mail.gmail.com>
References: <20150109152529.GA5022@city.ac.uk>
 <CAMgWh9ta6vagu877Skqh+7581tc1_pc8juLG3Bhm7UeHGb=+VQ@mail.gmail.com>
 <54AFF608.5030002@ro-che.info>
 <CAKFCL4UPEPENsY3MP94BROQ1ZztxBQFEkLDYu4i-A6V7Bmru+g@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1501091700580.13377@sputnik>



On Fri, 9 Jan 2015, Brandon Allbery wrote:

> On Fri, Jan 9, 2015 at 10:38 AM, Roman Cheplyaka <roma at ro-che.info> wrote:
>
>       [citation needed]
> 
> I believe this is referencing a past discussion (possibly on IRC) where it was pointed out that Ratio is a
> type constructor, but the only instance that makes any sense is Ratio Integer because any bounded integral
> type will eventually (and usually rather quickly) exceed the bounds and fail rather spectacularly given the
> lack of exceptions on bounded-integral wraparound?

Maybe this one:
    https://www.haskell.org/pipermail/libraries/2014-November/024064.html

From david.feuer at gmail.com  Fri Jan  9 16:02:56 2015
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 9 Jan 2015 11:02:56 -0500
Subject: removing constraints
In-Reply-To: <CAKFCL4UPEPENsY3MP94BROQ1ZztxBQFEkLDYu4i-A6V7Bmru+g@mail.gmail.com>
References: <20150109152529.GA5022@city.ac.uk>
 <CAMgWh9ta6vagu877Skqh+7581tc1_pc8juLG3Bhm7UeHGb=+VQ@mail.gmail.com>
 <54AFF608.5030002@ro-che.info>
 <CAKFCL4UPEPENsY3MP94BROQ1ZztxBQFEkLDYu4i-A6V7Bmru+g@mail.gmail.com>
Message-ID: <CAMgWh9tu8c6KG17_Q=CXknJkt9UWxA+xqkt7WAtk2p-i=j1p1g@mail.gmail.com>

Yes, that is what I was referring to. I don't remember where it was, but
IRC is a possibility. The basic problem is that if you consider the types
that would make sense as numerators and denominators for a ratio, and you
consider the instances of Integral, then their intersection turns out to
be, to a close approximation, {Integer}. The problem Brandon Allbery points
out restricts things on one side, while the peculiar constraint that
Integral is a subclass of Real restricts things on the other.
On Jan 9, 2015 10:44 AM, "Brandon Allbery" <allbery.b at gmail.com> wrote:

> On Fri, Jan 9, 2015 at 10:38 AM, Roman Cheplyaka <roma at ro-che.info> wrote:
>
>> On 09/01/15 17:29, David Feuer wrote:
>> >> The other cases are more arguable.  For example the change to
>> Data.Ratio
>> >> declares that the pair is kept in reduced form, but one could argue
>> that
>> >> requiring that is no bad thing.
>> >
>> > Disagreed. However, some have argued convincingly that the Ratio type as
>> > it stands makes little sense anyway.
>>
>> [citation needed]
>
>
> I believe this is referencing a past discussion (possibly on IRC) where it
> was pointed out that Ratio is a type constructor, but the only instance
> that makes any sense is Ratio Integer because any bounded integral type
> will eventually (and usually rather quickly) exceed the bounds and fail
> rather spectacularly given the lack of exceptions on bounded-integral
> wraparound?
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150109/879450bd/attachment.html>

From roma at ro-che.info  Fri Jan  9 16:42:26 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Fri, 09 Jan 2015 18:42:26 +0200
Subject: removing constraints
In-Reply-To: <CAMgWh9tu8c6KG17_Q=CXknJkt9UWxA+xqkt7WAtk2p-i=j1p1g@mail.gmail.com>
References: <20150109152529.GA5022@city.ac.uk>	<CAMgWh9ta6vagu877Skqh+7581tc1_pc8juLG3Bhm7UeHGb=+VQ@mail.gmail.com>	<54AFF608.5030002@ro-che.info>	<CAKFCL4UPEPENsY3MP94BROQ1ZztxBQFEkLDYu4i-A6V7Bmru+g@mail.gmail.com>
 <CAMgWh9tu8c6KG17_Q=CXknJkt9UWxA+xqkt7WAtk2p-i=j1p1g@mail.gmail.com>
Message-ID: <54B004F2.6010800@ro-che.info>

Thank you all for explaining. I confused Ratio and Rational, as I always
do, hence my surprise.

On 09/01/15 18:02, David Feuer wrote:
> Yes, that is what I was referring to. I don't remember where it was, but
> IRC is a possibility. The basic problem is that if you consider the
> types that would make sense as numerators and denominators for a ratio,
> and you consider the instances of Integral, then their intersection
> turns out to be, to a close approximation, {Integer}. The problem
> Brandon Allbery points out restricts things on one side, while the
> peculiar constraint that Integral is a subclass of Real restricts things
> on the other.
> 
> On Jan 9, 2015 10:44 AM, "Brandon Allbery" <allbery.b at gmail.com
> <mailto:allbery.b at gmail.com>> wrote:
> 
>     On Fri, Jan 9, 2015 at 10:38 AM, Roman Cheplyaka <roma at ro-che.info
>     <mailto:roma at ro-che.info>> wrote:
> 
>         On 09/01/15 17:29, David Feuer wrote:
>         >> The other cases are more arguable.  For example the change to Data.Ratio
>         >> declares that the pair is kept in reduced form, but one could argue that
>         >> requiring that is no bad thing.
>         >
>         > Disagreed. However, some have argued convincingly that the Ratio type as
>         > it stands makes little sense anyway.
> 
>         [citation needed]
> 
> 
>     I believe this is referencing a past discussion (possibly on IRC)
>     where it was pointed out that Ratio is a type constructor, but the
>     only instance that makes any sense is Ratio Integer because any
>     bounded integral type will eventually (and usually rather quickly)
>     exceed the bounds and fail rather spectacularly given the lack of
>     exceptions on bounded-integral wraparound?
> 
>     -- 
>     brandon s allbery kf8nh                               sine nomine
>     associates
>     allbery.b at gmail.com <mailto:allbery.b at gmail.com>                    
>                  ballbery at sinenomine.net <mailto:ballbery at sinenomine.net>
>     unix, openafs, kerberos, infrastructure, xmonad      
>      http://sinenomine.net
> 


From asr at eafit.edu.co  Fri Jan  9 18:13:20 2015
From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Fri, 9 Jan 2015 13:13:20 -0500
Subject: Version of the pretty-printing library in GHC 7.10.1
Message-ID: <CAOUWSGBZKT4Ovbk4Rv2jhohAUvWKR-gD4uGv15QNJs4P+6b2AQ@mail.gmail.com>

Hi,

While preparing Agda for supporting GHC 7.10.1, I found the following
situation:

* In GHC 7.8.4, the version of the pretty library is 1.1.1.1.

* In GHC 7.10.1 RC1, the version of the pretty library is 1.1.1.3.

* I need to use conditional compilation when using GHC 7.10.1 RC1 because
in the version 1.1.1.2 of the pretty library was added a new Eq instance
which is currently defined in the Agda source code.

* I cannot use
?the ?
??
Cabal macro
? ?
MIN_VERSION_package_(A,B,C)
? because this macro only supports three components (A, B, C) in the
version number, and the change in the version of the pretty library was in
the fourth component, i.e. 1.1.1.1 -> 1.1.1.2.

(I could use the symbol __GLASGOW_HASKELL__ instead, but I don't want to
use this symbol for changes related to the libraries.)

Is going GHC 7.10.1 to be released with a version of the pretty library
where I can use the MIN_VERSION_package_(A,B,C)
?
macro?

Best,

-- 
Andr?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150109/5c89fb54/attachment.html>

From lemming at henning-thielemann.de  Fri Jan  9 18:23:26 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 9 Jan 2015 19:23:26 +0100 (CET)
Subject: Version of the pretty-printing library in GHC 7.10.1
In-Reply-To: <CAOUWSGBZKT4Ovbk4Rv2jhohAUvWKR-gD4uGv15QNJs4P+6b2AQ@mail.gmail.com>
References: <CAOUWSGBZKT4Ovbk4Rv2jhohAUvWKR-gD4uGv15QNJs4P+6b2AQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1501091917210.13377@sputnik>


On Fri, 9 Jan 2015, Andr?s Sicard-Ram?rez wrote:

> While preparing Agda for supporting GHC 7.10.1, I found the following situation:
> 
> * In GHC 7.8.4, the version of the pretty library is 1.1.1.1.
> 
> * In GHC 7.10.1 RC1, the version of the pretty library is 1.1.1.3.
> 
> * I need to use conditional compilation when using GHC 7.10.1 RC1 because in the version 1.1.1.2 of the
> pretty library was added a new Eq instance which is currently defined in the Agda source code.

Adding an Eq instance is an addition to the API and requires to increment 
version to 1.1.2 according to the PVP.

https://www.haskell.org/haskellwiki/Package_versioning_policy

From danburton.email at gmail.com  Fri Jan  9 18:45:07 2015
From: danburton.email at gmail.com (Dan Burton)
Date: Fri, 9 Jan 2015 10:45:07 -0800
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CAKRanNA0MrUKcWRSm4Y9ym90mxf_JMsKYb4xYH5gnFrpM29HUA@mail.gmail.com>
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
 <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
 <m8gt8o$6f3$1@ger.gmane.org> <455CD231-2D34-4E1E-B96B-50D923D3B737@me.com>
 <CAJumaK_T3x1e13oOMEtnkmJ5CPornwbH7S7FJWzAFB0cxmYKUw@mail.gmail.com>
 <54AC3A13.207@gmail.com>
 <CAMgWh9vUoqqmDYkUFKr7YavptKqS=_swziQXWr-Y_+g2hq7Z7g@mail.gmail.com>
 <CAK-tuPbDyV=O+ygRCEEYzknHBosZ0Z1-4vSQUE+whUnRT1ja2g@mail.gmail.com>
 <CAPeieQENQvpfMS_qT00vGTykfeQmHaAH-v9UHsT_RD9m34+CCw@mail.gmail.com>
 <CAK-tuPZgOOzPX4KgwMzMETokXg=2-5CCJHUCJCG6wOoxk2XRrQ@mail.gmail.com>
 <54AD71BB.50906@gmail.com>
 <CAKRanNA0MrUKcWRSm4Y9ym90mxf_JMsKYb4xYH5gnFrpM29HUA@mail.gmail.com>
Message-ID: <CALSygwd1b7N0zfU_W8DHBs3uXCEV7n3A7J364VuBMa8KMaOTCw@mail.gmail.com>

+1 as proposed.

There is no known concrete use case which takes advantage of the "follow
symlinks" behavior. There are some known use cases where symlinks are
simply expected not to be present as a precondition. Using this function as
though it were rm -rf (a very natural thing to do, imo) has the potential
for disastrous results.

For these reasons, I say *treat it as a bug*. No deprecation cycle.
Existing code using the library doesn't change and becomes automatically
safer just by upgrading the dependency.

-- Dan Burton

On Thu, Jan 8, 2015 at 4:06 PM, Greg Weber <greg at gregweber.info> wrote:

> We all agree that we should do something about this. For 99% of use cases
> this is a bug fix.
> So I would like to just leave it up to the implementer to decide what to
> do.
>
>
> On Wed, Jan 7, 2015 at 9:49 AM, Gabriel Gonzalez <gabriel439 at gmail.com>
> wrote:
>
>>  Actually, I might retract my recommendation to provided it under a
>> different name.  I'm neutral on this now and would consider it okay to
>> change in place.
>>
>> My reasoning is that this is a bug fix, so we can reasonably expect users
>> to put lower bounds on software in response to bug fixes like we do with
>> other software.
>>
>>
>> On 1/7/15, 1:47 AM, Johan Tibell wrote:
>>
>> I don't think so but if we change the function signature or name as some
>> suggested it all needs to be cpped still.
>> On Jan 6, 2015 9:39 PM, "Erik Hesselink" <hesselink at gmail.com> wrote:
>>
>>> Does cabal rely on this behavior?
>>>
>>> Erik
>>>
>>> On Tue, Jan 6, 2015 at 9:37 PM, Johan Tibell <johan.tibell at gmail.com>
>>> wrote:
>>> > Who volunteers to fix the breakages in Cabal and add all the needed
>>> CPP?
>>> >
>>> > On Tue, Jan 6, 2015 at 2:45 PM, David Feuer <david.feuer at gmail.com>
>>> wrote:
>>> >>
>>> >> This seems reasonable, but if we have a deprecation cycle, the old
>>> name
>>> >> should (temporarily) be a synonym for the new one, and the deprecation
>>> >> warning should indicate that code intended to work with older
>>> versions needs
>>> >> to be audited.
>>> >>
>>> >> On Jan 6, 2015 2:40 PM, "Gabriel Gonzalez" <gabriel439 at gmail.com>
>>> wrote:
>>> >>>
>>> >>> I think it's safer to remove the old function altogether (perhaps
>>> after
>>> >>> one deprecation cycle) and provide a new one under a different name,
>>> rather
>>> >>> than modify it in place.
>>> >>>
>>> >>> Modifying it in place risks the behavior that others mentioned where
>>> your
>>> >>> program is unsafe to compile against older library versions.  Yes,
>>> the user
>>> >>> could explicitly enforce that by putting a lower bound on the
>>> library, but
>>> >>> most users won't even realize that they need to do that.
>>> >>>
>>> >>>
>>> >>> On 1/6/15, 11:37 AM, Edward Kmett wrote:
>>> >>>
>>> >>> I'm +1 for fixing this, in place, on the current function.
>>> >>>
>>> >>> The specification we have here is doing a very very bad thing and
>>> needs
>>> >>> to be fixed, not slavishly copied forward because someone sometime
>>> once made
>>> >>> a mistake.
>>> >>>
>>> >>> The current behavior grievously violates the expectations of anyone
>>> who
>>> >>> would be in a situation to go and reach for it and has any prior
>>> experience
>>> >>> with any other such tool.
>>> >>>
>>> >>> -Edward
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Tue, Jan 6, 2015 at 11:14 AM, Malcolm Wallace <
>>> malcolm.wallace at me.com>
>>> >>> wrote:
>>> >>>>
>>> >>>>
>>> >>>> On 6 Jan 2015, at 14:59, Bardur Arantsson wrote:
>>> >>>>
>>> >>>> > On 2015-01-06 14:57, Mike Meyer wrote:
>>> >>>> >> On Tue, Jan 6, 2015 at 7:48 AM, Johan Tibell <
>>> johan.tibell at gmail.com>
>>> >>>> >> wrote:
>>> >>>> >>
>>> >>>> >>> This is not a bugfix. A bug is failing to follow the functions
>>> >>>> >>> specification, which *does* include following symlinks.
>>> >>>> >>>
>>> >>>> >>
>>> >>>> >> It's a bug in the design, not the code.
>>> >>>>
>>> >>>> > Because *nobody* wants to follow symlinks when doing "rm -rf".
>>> Even if
>>> >>>> > they think they do, they *really* don't.
>>> >>>>
>>> >>>> I agree 100%.  Even time I use this function, I worry briefly about
>>> >>>> whether it follows symlinks, then think to myself "no, no-one would
>>> be so
>>> >>>> stupid to implement that deliberately in a publically available
>>> API".  So it
>>> >>>> was a real shock to discover in this thread that I was wrong, and
>>> >>>> furthermore that the function is documented as doing the wrong
>>> thing.  We
>>> >>>> should fix both spec and implementation, as soon as possible.
>>> >>>>
>>> >>>> Regards,
>>> >>>>     Malcolm
>>> >>>> _______________________________________________
>>> >>>> Libraries mailing list
>>> >>>> Libraries at haskell.org
>>> >>>> http://www.haskell.org/mailman/listinfo/libraries
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> Libraries mailing list
>>> >>> Libraries at haskell.org
>>> >>> http://www.haskell.org/mailman/listinfo/libraries
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> Libraries mailing list
>>> >>> Libraries at haskell.org
>>> >>> http://www.haskell.org/mailman/listinfo/libraries
>>> >>>
>>> >>
>>> >> _______________________________________________
>>> >> Libraries mailing list
>>> >> Libraries at haskell.org
>>> >> http://www.haskell.org/mailman/listinfo/libraries
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > Libraries mailing list
>>> > Libraries at haskell.org
>>> > http://www.haskell.org/mailman/listinfo/libraries
>>> >
>>>
>>
>>
>> _______________________________________________
>> Libraries mailing listLibraries at haskell.orghttp://www.haskell.org/mailman/listinfo/libraries
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150109/262612b4/attachment.html>

From johnw at newartisans.com  Fri Jan  9 19:11:49 2015
From: johnw at newartisans.com (John Wiegley)
Date: Fri, 09 Jan 2015 13:11:49 -0600
Subject: Proposal: removeDirectoryRecursive should not follow symlinks
In-Reply-To: <CALSygwd1b7N0zfU_W8DHBs3uXCEV7n3A7J364VuBMa8KMaOTCw@mail.gmail.com>
 (Dan Burton's message of "Fri, 9 Jan 2015 10:45:07 -0800")
References: <1420496644-sup-4814@sabre>
 <CAJHA+wo-id5pL9MCy95HgCZw8yJjadtm0YjTKjXn0K5V3GnmuQ@mail.gmail.com>
 <CAK-tuPatDW_7LA1Cqt5KnaKctJa+vq6eKS=4JO5Egk4DuOtpUQ@mail.gmail.com>
 <CAD=7U2BSYpe6gWVraD-aj7AKHJtJDo8zv93XebyVUvoXXPGgbQ@mail.gmail.com>
 <m8gt8o$6f3$1@ger.gmane.org>
 <455CD231-2D34-4E1E-B96B-50D923D3B737@me.com>
 <CAJumaK_T3x1e13oOMEtnkmJ5CPornwbH7S7FJWzAFB0cxmYKUw@mail.gmail.com>
 <54AC3A13.207@gmail.com>
 <CAMgWh9vUoqqmDYkUFKr7YavptKqS=_swziQXWr-Y_+g2hq7Z7g@mail.gmail.com>
 <CAK-tuPbDyV=O+ygRCEEYzknHBosZ0Z1-4vSQUE+whUnRT1ja2g@mail.gmail.com>
 <CAPeieQENQvpfMS_qT00vGTykfeQmHaAH-v9UHsT_RD9m34+CCw@mail.gmail.com>
 <CAK-tuPZgOOzPX4KgwMzMETokXg=2-5CCJHUCJCG6wOoxk2XRrQ@mail.gmail.com>
 <54AD71BB.50906@gmail.com>
 <CAKRanNA0MrUKcWRSm4Y9ym90mxf_JMsKYb4xYH5gnFrpM29HUA@mail.gmail.com>
 <CALSygwd1b7N0zfU_W8DHBs3uXCEV7n3A7J364VuBMa8KMaOTCw@mail.gmail.com>
Message-ID: <m2h9vz6a6i.fsf@newartisans.com>

>>>>> Dan Burton <danburton.email at gmail.com> writes:

> For these reasons, I say treat it as a bug. No deprecation cycle. Existing
> code using the library doesn't change and becomes automatically safer just
> by upgrading the dependency.

+1 as proposed, and +1 on treating it as a bug.

John

From asr at eafit.edu.co  Fri Jan  9 19:15:18 2015
From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Fri, 9 Jan 2015 14:15:18 -0500
Subject: Version of the pretty-printing library in GHC 7.10.1
In-Reply-To: <CACHt1w9JgOd-7K1zSps_cBu5bk0O90WrtGzXDBs_Z3jex8aGWg@mail.gmail.com>
References: <CAOUWSGBZKT4Ovbk4Rv2jhohAUvWKR-gD4uGv15QNJs4P+6b2AQ@mail.gmail.com>
 <CACHt1w9JgOd-7K1zSps_cBu5bk0O90WrtGzXDBs_Z3jex8aGWg@mail.gmail.com>
Message-ID: <CAOUWSGB8RL6RCuZ7q3z-6g2CrujQsfgfxNC=NqPh_GPPok1_sQ@mail.gmail.com>

On 9 January 2015 at 13:33, David Terei <d at davidterei.com> wrote:

> I'd suggest GHC move to pretty 1.1.2.0. I'll shoot an email about that
> to see if we can get it changed.
>

?Thanks!?


-- 
Andr?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150109/0122ac88/attachment.html>

From chrisdone at gmail.com  Sat Jan 10 00:59:18 2015
From: chrisdone at gmail.com (Christopher Done)
Date: Sat, 10 Jan 2015 01:59:18 +0100
Subject: Stream type
Message-ID: <CAAJHNPADkG_NaiKQ7i466QWFTWnXFDjHw_Uc-7wGvAKryvSPCQ@mail.gmail.com>

Is this type defined anywhere in base or elsewhere standardish?

https://gist.github.com/chrisdone/516489f4f27846712225#file-type-hs-L52

data Stream a =
  Stream a (Stream a)

Ciao

From david.feuer at gmail.com  Sat Jan 10 01:02:45 2015
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 9 Jan 2015 20:02:45 -0500
Subject: Stream type
In-Reply-To: <CAAJHNPADkG_NaiKQ7i466QWFTWnXFDjHw_Uc-7wGvAKryvSPCQ@mail.gmail.com>
References: <CAAJHNPADkG_NaiKQ7i466QWFTWnXFDjHw_Uc-7wGvAKryvSPCQ@mail.gmail.com>
Message-ID: <CAMgWh9ub=6JfCbn_QahZpa_1_CDW9cjfF0rmWCgOBSeCgcYc-A@mail.gmail.com>

I don't know about standardish, but there's this:
https://hackage.haskell.org/package/streams/docs/Data-Stream-Infinite.html
On Jan 9, 2015 7:59 PM, "Christopher Done" <chrisdone at gmail.com> wrote:

> Is this type defined anywhere in base or elsewhere standardish?
>
> https://gist.github.com/chrisdone/516489f4f27846712225#file-type-hs-L52
>
> data Stream a =
>   Stream a (Stream a)
>
> Ciao
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150109/de40e45f/attachment.html>

From acowley at seas.upenn.edu  Sat Jan 10 01:05:59 2015
From: acowley at seas.upenn.edu (Anthony Cowley)
Date: Fri, 9 Jan 2015 20:05:59 -0500
Subject: Stream type
In-Reply-To: <CAMgWh9ub=6JfCbn_QahZpa_1_CDW9cjfF0rmWCgOBSeCgcYc-A@mail.gmail.com>
References: <CAAJHNPADkG_NaiKQ7i466QWFTWnXFDjHw_Uc-7wGvAKryvSPCQ@mail.gmail.com>
 <CAMgWh9ub=6JfCbn_QahZpa_1_CDW9cjfF0rmWCgOBSeCgcYc-A@mail.gmail.com>
Message-ID: <CADch-tJBRFbPj8cdSM8Fm-DSNMfB2kuV5g2_zxrP5oZm3qwx_Q@mail.gmail.com>

There's also the classic
http://hackage.haskell.org/package/Stream-0.4.7.1/docs/Data-Stream.html

Anthony

On Fri, Jan 9, 2015 at 8:02 PM, David Feuer <david.feuer at gmail.com> wrote:
> I don't know about standardish, but there's this:
> https://hackage.haskell.org/package/streams/docs/Data-Stream-Infinite.html
>
> On Jan 9, 2015 7:59 PM, "Christopher Done" <chrisdone at gmail.com> wrote:
>>
>> Is this type defined anywhere in base or elsewhere standardish?
>>
>> https://gist.github.com/chrisdone/516489f4f27846712225#file-type-hs-L52
>>
>> data Stream a =
>>   Stream a (Stream a)
>>
>> Ciao
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

From chrisdone at gmail.com  Sat Jan 10 01:11:15 2015
From: chrisdone at gmail.com (Christopher Done)
Date: Sat, 10 Jan 2015 02:11:15 +0100
Subject: Stream type
In-Reply-To: <CADch-tJBRFbPj8cdSM8Fm-DSNMfB2kuV5g2_zxrP5oZm3qwx_Q@mail.gmail.com>
References: <CAAJHNPADkG_NaiKQ7i466QWFTWnXFDjHw_Uc-7wGvAKryvSPCQ@mail.gmail.com>
 <CAMgWh9ub=6JfCbn_QahZpa_1_CDW9cjfF0rmWCgOBSeCgcYc-A@mail.gmail.com>
 <CADch-tJBRFbPj8cdSM8Fm-DSNMfB2kuV5g2_zxrP5oZm3qwx_Q@mail.gmail.com>
Message-ID: <CAAJHNPBJfdqns6u=fAn6-e=6mLTrf56F09d6J65-VbYu+Lsy6Q@mail.gmail.com>

Thanks chaps.

Ah, partial fromList. We meet again, old nemesis.

On 10 January 2015 at 02:05, Anthony Cowley <acowley at seas.upenn.edu> wrote:
> There's also the classic
> http://hackage.haskell.org/package/Stream-0.4.7.1/docs/Data-Stream.html
>
> Anthony
>
> On Fri, Jan 9, 2015 at 8:02 PM, David Feuer <david.feuer at gmail.com> wrote:
>> I don't know about standardish, but there's this:
>> https://hackage.haskell.org/package/streams/docs/Data-Stream-Infinite.html
>>
>> On Jan 9, 2015 7:59 PM, "Christopher Done" <chrisdone at gmail.com> wrote:
>>>
>>> Is this type defined anywhere in base or elsewhere standardish?
>>>
>>> https://gist.github.com/chrisdone/516489f4f27846712225#file-type-hs-L52
>>>
>>> data Stream a =
>>>   Stream a (Stream a)
>>>
>>> Ciao
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>

From mle+hs at mega-nerd.com  Sun Jan 11 00:15:34 2015
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Sat, 10 Jan 2015 16:15:34 -0800
Subject: System.Posix.IO.ByteString
Message-ID: <20150110161534.86fb2d2fd99be7dddd49c887@mega-nerd.com>

Hi All,

I'm playing around with some low level IO and found the following
function:

    System.Posix.IO.fdRead :: Fd -> ByteCount -> IO (String, ByteCount)

Ok, close, but what if I need a ByteString instead. I then found this:

    System.Posix.IO.ByteString.fdRead :: Fd -> ByteCount -> IO (String, ByteCount)

which is identical to the one above. The ByteString in the module name
suggests it would be using ByteString instead of String?

Can anyone explain this for me?

Cheers,
Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From allbery.b at gmail.com  Sun Jan 11 00:22:34 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 10 Jan 2015 19:22:34 -0500
Subject: System.Posix.IO.ByteString
In-Reply-To: <20150110161534.86fb2d2fd99be7dddd49c887@mega-nerd.com>
References: <20150110161534.86fb2d2fd99be7dddd49c887@mega-nerd.com>
Message-ID: <CAKFCL4V9GjopRKWxopCSpu2Sq9Jg73VCGuc47Z8RigBbaHoGAg@mail.gmail.com>

On Sat, Jan 10, 2015 at 7:15 PM, Erik de Castro Lopo <mle+hs at mega-nerd.com>
wrote:

>     System.Posix.IO.ByteString.fdRead :: Fd -> ByteCount -> IO (String,
> ByteCount)
>
> which is identical to the one above. The ByteString in the module name
> suggests it would be using ByteString instead of String?
>
> Can anyone explain this for me?
>

The "ByteString" in the SYstem.Posix.*.ByteString modules applies to the
pathnames (POSIX pathnames are byte strings, and there's lots of ways to
cause problems if you insist on pretending that they are in any particular
encoding), not the values being read/written, so functions like that are
basically carried along just to provide a mostly compatible API.

I would expect to find functions working with ByteString values under
Data.ByteString.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150110/456e9164/attachment.html>

From jessica.l.hamilton at gmail.com  Sun Jan 11 00:36:13 2015
From: jessica.l.hamilton at gmail.com (Jessica Hamilton)
Date: Sun, 11 Jan 2015 13:36:13 +1300
Subject: Cabal: Specify multiple package databases in config file
Message-ID: <CABCZxrDAeSvfc5R3eV3UBcYKfEqape05t_QR9Sf6gYaEyJAiYw@mail.gmail.com>

Hi All,

Is it possible to specify multiple package databases in Cabal's config file?

Currently, I have two installed package databases. One is the system
readonly package database, and the other is the system writable
package database. This structure is due to how packaging works on
Haiku, so can't be changed. A similar structure would also exist for
user package databases.

My Cabal config file currently looks like:
  package-db: /packages/ghc/.self/lib/package.conf.d

I need this to be something like:
  package-db: /packages/ghc/.self/lib/package.conf.d;
/system/non-packaged/lib/ghc/package.conf.d

Is this possible with the Cabal config file? If so, what is the
correct syntax to use?

Many Thanks,
Jessica

From lemming at henning-thielemann.de  Sun Jan 11 10:09:49 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Sun, 11 Jan 2015 11:09:49 +0100 (CET)
Subject: Cabal: Specify multiple package databases in config file
In-Reply-To: <CABCZxrDAeSvfc5R3eV3UBcYKfEqape05t_QR9Sf6gYaEyJAiYw@mail.gmail.com>
References: <CABCZxrDAeSvfc5R3eV3UBcYKfEqape05t_QR9Sf6gYaEyJAiYw@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1501111108550.6327@sputnik>


On Sun, 11 Jan 2015, Jessica Hamilton wrote:

> My Cabal config file currently looks like:
>  package-db: /packages/ghc/.self/lib/package.conf.d
>
> I need this to be something like:
>  package-db: /packages/ghc/.self/lib/package.conf.d;
> /system/non-packaged/lib/ghc/package.conf.d

I would try:

package-db: /packages/ghc/.self/lib/package.conf.d
package-db: /system/non-packaged/lib/ghc/package.conf.d

This worked for me at least for the remote-repo field.

From hvr at gnu.org  Sun Jan 11 13:18:23 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Sun, 11 Jan 2015 14:18:23 +0100
Subject: System.Posix.IO.ByteString
In-Reply-To: <CAKFCL4V9GjopRKWxopCSpu2Sq9Jg73VCGuc47Z8RigBbaHoGAg@mail.gmail.com>
 (Brandon Allbery's message of "Sat, 10 Jan 2015 19:22:34 -0500")
References: <20150110161534.86fb2d2fd99be7dddd49c887@mega-nerd.com>
 <CAKFCL4V9GjopRKWxopCSpu2Sq9Jg73VCGuc47Z8RigBbaHoGAg@mail.gmail.com>
Message-ID: <87mw5pzc9s.fsf@gnu.org>

On 2015-01-11 at 01:22:34 +0100, Brandon Allbery wrote:

[...]

> The "ByteString" in the SYstem.Posix.*.ByteString modules applies to the
> pathnames (POSIX pathnames are byte strings, and there's lots of ways to
> cause problems if you insist on pretending that they are in any particular
> encoding), not the values being read/written, so functions like that are
> basically carried along just to provide a mostly compatible API.
>
> I would expect to find functions working with ByteString values under
> Data.ByteString.

However those take [Char] as FilePath argument... where would you look
if you wanted to functions that used ByteStrings for both, filepaths and
content?

Cheers,
  hvr

From aslatter at gmail.com  Sun Jan 11 14:15:42 2015
From: aslatter at gmail.com (Antoine Latter)
Date: Sun, 11 Jan 2015 14:15:42 +0000
Subject: System.Posix.IO.ByteString
References: <20150110161534.86fb2d2fd99be7dddd49c887@mega-nerd.com>
 <CAKFCL4V9GjopRKWxopCSpu2Sq9Jg73VCGuc47Z8RigBbaHoGAg@mail.gmail.com>
 <87mw5pzc9s.fsf@gnu.org>
Message-ID: <CAKjSnQFGYS9op2aq9mDOnm84Mxx1Hdg3PSg6_Bcc6L=aEpFXQQ@mail.gmail.com>

The 'unix-bytestring' package looks like it can read a ByteString from the
file descriptor once you have it open:

http://hackage.haskell.org/package/unix-bytestring-0.3.7.2/docs/System-Posix-IO-ByteString.html

Sadly both 'unix' and 'unix-bytestring' define a module named
'System.Posix.IO.ByteString', and you need functionality from both to get
your job done - 'openFd' from 'unix' and then 'fdRead' from
'unix-bytestring'.

On Sun Jan 11 2015 at 7:18:30 AM Herbert Valerio Riedel <hvr at gnu.org> wrote:

> On 2015-01-11 at 01:22:34 +0100, Brandon Allbery wrote:
>
> [...]
>
> > The "ByteString" in the SYstem.Posix.*.ByteString modules applies to the
> > pathnames (POSIX pathnames are byte strings, and there's lots of ways to
> > cause problems if you insist on pretending that they are in any
> particular
> > encoding), not the values being read/written, so functions like that are
> > basically carried along just to provide a mostly compatible API.
> >
> > I would expect to find functions working with ByteString values under
> > Data.ByteString.
>
> However those take [Char] as FilePath argument... where would you look
> if you wanted to functions that used ByteStrings for both, filepaths and
> content?
>
> Cheers,
>   hvr
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150111/97c28305/attachment.html>

From jwlato at gmail.com  Sun Jan 11 17:13:38 2015
From: jwlato at gmail.com (John Lato)
Date: Sun, 11 Jan 2015 17:13:38 +0000
Subject: System.Posix.IO.ByteString
References: <20150110161534.86fb2d2fd99be7dddd49c887@mega-nerd.com>
 <CAKFCL4V9GjopRKWxopCSpu2Sq9Jg73VCGuc47Z8RigBbaHoGAg@mail.gmail.com>
 <87mw5pzc9s.fsf@gnu.org>
 <CAKjSnQFGYS9op2aq9mDOnm84Mxx1Hdg3PSg6_Bcc6L=aEpFXQQ@mail.gmail.com>
Message-ID: <CAJ727Ggp+wDUrrVfw_07CJRrwtw+g_agpetqm_1Ue82xUL1nHg@mail.gmail.com>

The naming collision is unfortunate, but solvable with the PackageImports
extension.

On 06:15, Sun, Jan 11, 2015 Antoine Latter <aslatter at gmail.com> wrote:

> The 'unix-bytestring' package looks like it can read a ByteString from the
> file descriptor once you have it open:
>
>
> http://hackage.haskell.org/package/unix-bytestring-0.3.7.2/docs/System-Posix-IO-ByteString.html
>
> Sadly both 'unix' and 'unix-bytestring' define a module named
> 'System.Posix.IO.ByteString', and you need functionality from both to get
> your job done - 'openFd' from 'unix' and then 'fdRead' from
> 'unix-bytestring'.
>
> On Sun Jan 11 2015 at 7:18:30 AM Herbert Valerio Riedel <hvr at gnu.org>
> wrote:
>
>> On 2015-01-11 at 01:22:34 +0100, Brandon Allbery wrote:
>>
>> [...]
>>
>> > The "ByteString" in the SYstem.Posix.*.ByteString modules applies to the
>> > pathnames (POSIX pathnames are byte strings, and there's lots of ways to
>> > cause problems if you insist on pretending that they are in any
>> particular
>> > encoding), not the values being read/written, so functions like that are
>> > basically carried along just to provide a mostly compatible API.
>> >
>> > I would expect to find functions working with ByteString values under
>> > Data.ByteString.
>>
>> However those take [Char] as FilePath argument... where would you look
>> if you wanted to functions that used ByteStrings for both, filepaths and
>> content?
>>
>> Cheers,
>>   hvr
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150111/37a895d0/attachment.html>

From mle+hs at mega-nerd.com  Sun Jan 11 22:16:53 2015
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Sun, 11 Jan 2015 14:16:53 -0800
Subject: System.Posix.IO.ByteString
In-Reply-To: <CAKjSnQFGYS9op2aq9mDOnm84Mxx1Hdg3PSg6_Bcc6L=aEpFXQQ@mail.gmail.com>
References: <20150110161534.86fb2d2fd99be7dddd49c887@mega-nerd.com>
 <CAKFCL4V9GjopRKWxopCSpu2Sq9Jg73VCGuc47Z8RigBbaHoGAg@mail.gmail.com>
 <87mw5pzc9s.fsf@gnu.org>
 <CAKjSnQFGYS9op2aq9mDOnm84Mxx1Hdg3PSg6_Bcc6L=aEpFXQQ@mail.gmail.com>
Message-ID: <20150111141653.4cf3e2ea5d41f01f458dd253@mega-nerd.com>

Antoine Latter wrote:

> The 'unix-bytestring' package looks like it can read a ByteString from the
> file descriptor once you have it open:
> 
> http://hackage.haskell.org/package/unix-bytestring-0.3.7.2/docs/System-Posix-IO-ByteString.html
> 
> Sadly both 'unix' and 'unix-bytestring' define a module named
> 'System.Posix.IO.ByteString', and you need functionality from both to get
> your job done - 'openFd' from 'unix' and then 'fdRead' from
> 'unix-bytestring'.

Ah, thanks for that. In the end, I ended up using `fdReadBuf` to
read the data into a buffer, followed by `unsafePackCStringFinalizer`
to get a ByteString.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From mle+hs at mega-nerd.com  Mon Jan 12 03:42:45 2015
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Sun, 11 Jan 2015 19:42:45 -0800
Subject: Data.ByteString.Unsafe.unsafeWipe
Message-ID: <20150111194245.22bea00e9bab8e3f15f8cbad@mega-nerd.com>

Discussion period: one month

When handling sensitive information (like a user's password) it is
desirable to only keep the data around for as short a time as possible.
Specifically, relying on the garbage collector to clean it up is simply
not good enough.

I therefore propose that the following function to be added to the
Data.ByteString.Unsafe module:

    -- | Overwrites the contents of a ByteString with \0 bytes.
    unsafeWipe :: ByteString -> IO ()
    unsafeWipe bs =
        BS.unsafeUseAsCStringLen bs $ \(ptr, len) ->
            let go i
                    | i < 0 = return ()
                    | otherwise = pokeElemOff ptr i 0 >> go (i - 1)
            in go (len - 1)

It is added to the Unsafe module because it break referential transparency
but since ByteStrings are always kept in pinned memory, it should not
otherwise be considered unsafe.

It could be used as follows:

    main = do
        passwd <- getPassword
        doSomethingWith passwd
        unsafeWipe passwd
        restOfProgram


Cheers,
Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From david.feuer at gmail.com  Mon Jan 12 03:48:42 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 11 Jan 2015 22:48:42 -0500
Subject: Data.ByteString.Unsafe.unsafeWipe
In-Reply-To: <20150111194245.22bea00e9bab8e3f15f8cbad@mega-nerd.com>
References: <20150111194245.22bea00e9bab8e3f15f8cbad@mega-nerd.com>
Message-ID: <CAMgWh9t3ZSY+vpHqbSJpez=OZsBy6mwFT4+yLU87f9oW+g2GOQ@mail.gmail.com>

-1. Breaking referential transparency is completely unnecessary here.
The correct way to accomplish this, I believe, is to add a mutable
ByteString interface, and then a SecureByteString module wrapping it
and actually making the promises you want.

On Sun, Jan 11, 2015 at 10:42 PM, Erik de Castro Lopo
<mle+hs at mega-nerd.com> wrote:
> Discussion period: one month
>
> When handling sensitive information (like a user's password) it is
> desirable to only keep the data around for as short a time as possible.
> Specifically, relying on the garbage collector to clean it up is simply
> not good enough.
>
> I therefore propose that the following function to be added to the
> Data.ByteString.Unsafe module:
>
>     -- | Overwrites the contents of a ByteString with \0 bytes.
>     unsafeWipe :: ByteString -> IO ()
>     unsafeWipe bs =
>         BS.unsafeUseAsCStringLen bs $ \(ptr, len) ->
>             let go i
>                     | i < 0 = return ()
>                     | otherwise = pokeElemOff ptr i 0 >> go (i - 1)
>             in go (len - 1)
>
> It is added to the Unsafe module because it break referential transparency
> but since ByteStrings are always kept in pinned memory, it should not
> otherwise be considered unsafe.
>
> It could be used as follows:
>
>     main = do
>         passwd <- getPassword
>         doSomethingWith passwd
>         unsafeWipe passwd
>         restOfProgram
>
>
> Cheers,
> Erik
> --
> ----------------------------------------------------------------------
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

From david.feuer at gmail.com  Mon Jan 12 04:02:05 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 11 Jan 2015 23:02:05 -0500
Subject: Data.ByteString.Unsafe.unsafeWipe
In-Reply-To: <CAMgWh9t3ZSY+vpHqbSJpez=OZsBy6mwFT4+yLU87f9oW+g2GOQ@mail.gmail.com>
References: <20150111194245.22bea00e9bab8e3f15f8cbad@mega-nerd.com>
 <CAMgWh9t3ZSY+vpHqbSJpez=OZsBy6mwFT4+yLU87f9oW+g2GOQ@mail.gmail.com>
Message-ID: <CAMgWh9tntWVQq_EMDFjuCo4R7QL2gGETQqmR_Bhj_UdFwjfyJg@mail.gmail.com>

In fact, it looks like Michael Snoyman has done some work on this
already: https://www.fpcomplete.com/user/chad/snippets/random-code-snippets/mutable-bytestring
 Perhaps he could be convinced to finish/release it.

David

On Sun, Jan 11, 2015 at 10:48 PM, David Feuer <david.feuer at gmail.com> wrote:
> -1. Breaking referential transparency is completely unnecessary here.
> The correct way to accomplish this, I believe, is to add a mutable
> ByteString interface, and then a SecureByteString module wrapping it
> and actually making the promises you want.
>
> On Sun, Jan 11, 2015 at 10:42 PM, Erik de Castro Lopo
> <mle+hs at mega-nerd.com> wrote:
>> Discussion period: one month
>>
>> When handling sensitive information (like a user's password) it is
>> desirable to only keep the data around for as short a time as possible.
>> Specifically, relying on the garbage collector to clean it up is simply
>> not good enough.
>>
>> I therefore propose that the following function to be added to the
>> Data.ByteString.Unsafe module:
>>
>>     -- | Overwrites the contents of a ByteString with \0 bytes.
>>     unsafeWipe :: ByteString -> IO ()
>>     unsafeWipe bs =
>>         BS.unsafeUseAsCStringLen bs $ \(ptr, len) ->
>>             let go i
>>                     | i < 0 = return ()
>>                     | otherwise = pokeElemOff ptr i 0 >> go (i - 1)
>>             in go (len - 1)
>>
>> It is added to the Unsafe module because it break referential transparency
>> but since ByteStrings are always kept in pinned memory, it should not
>> otherwise be considered unsafe.
>>
>> It could be used as follows:
>>
>>     main = do
>>         passwd <- getPassword
>>         doSomethingWith passwd
>>         unsafeWipe passwd
>>         restOfProgram
>>
>>
>> Cheers,
>> Erik
>> --
>> ----------------------------------------------------------------------
>> Erik de Castro Lopo
>> http://www.mega-nerd.com/
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries

From carter.schonwald at gmail.com  Mon Jan 12 04:08:24 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 11 Jan 2015 23:08:24 -0500
Subject: Data.ByteString.Unsafe.unsafeWipe
In-Reply-To: <CAMgWh9t3ZSY+vpHqbSJpez=OZsBy6mwFT4+yLU87f9oW+g2GOQ@mail.gmail.com>
References: <20150111194245.22bea00e9bab8e3f15f8cbad@mega-nerd.com>
 <CAMgWh9t3ZSY+vpHqbSJpez=OZsBy6mwFT4+yLU87f9oW+g2GOQ@mail.gmail.com>
Message-ID: <CAHYVw0x3L+VTqoME4XLdHpKgkKGoVRbC=egZp22eVYpujT1W6w@mail.gmail.com>

David's idea is pretty cool!

wrt Erik's suggestion, I'd rather suggest instead
something like what Vincent's secure memory does,
which provides finalization support to a bytestring interface

https://hackage.haskell.org/package/securemem-0.1.4/docs/src/Data-SecureMem.html



-- | Allocate a foreign ptr which will be scrubed before memory
free.-- the memory is allocated on the haskell
heapallocateScrubedForeignPtr :: Int -> IO (ForeignPtr
a)allocateScrubedForeignPtr sz = do#if MIN_VERSION_base(4,6,0)
fptr@(ForeignPtr addr _) <- mallocForeignPtrBytes sz
addForeignPtrConcFinalizer fptr (scruber (Ptr addr))    return fptr
where !scruber = szToScruber sz#else    mallocForeignPtrBytes sz#endif


this code can totally be adapted to provide a scrubing finalizer to any
foreign pointer of interest, and indeed, it could be done as a helper
function for bytestrings a la

addFinalizer :: ByteString -> IO () -> IO ()

or something


On Sun, Jan 11, 2015 at 10:48 PM, David Feuer <david.feuer at gmail.com> wrote:

> -1. Breaking referential transparency is completely unnecessary here.
> The correct way to accomplish this, I believe, is to add a mutable
> ByteString interface, and then a SecureByteString module wrapping it
> and actually making the promises you want.
>
> On Sun, Jan 11, 2015 at 10:42 PM, Erik de Castro Lopo
> <mle+hs at mega-nerd.com> wrote:
> > Discussion period: one month
> >
> > When handling sensitive information (like a user's password) it is
> > desirable to only keep the data around for as short a time as possible.
> > Specifically, relying on the garbage collector to clean it up is simply
> > not good enough.
> >
> > I therefore propose that the following function to be added to the
> > Data.ByteString.Unsafe module:
> >
> >     -- | Overwrites the contents of a ByteString with \0 bytes.
> >     unsafeWipe :: ByteString -> IO ()
> >     unsafeWipe bs =
> >         BS.unsafeUseAsCStringLen bs $ \(ptr, len) ->
> >             let go i
> >                     | i < 0 = return ()
> >                     | otherwise = pokeElemOff ptr i 0 >> go (i - 1)
> >             in go (len - 1)
> >
> > It is added to the Unsafe module because it break referential
> transparency
> > but since ByteStrings are always kept in pinned memory, it should not
> > otherwise be considered unsafe.
> >
> > It could be used as follows:
> >
> >     main = do
> >         passwd <- getPassword
> >         doSomethingWith passwd
> >         unsafeWipe passwd
> >         restOfProgram
> >
> >
> > Cheers,
> > Erik
> > --
> > ----------------------------------------------------------------------
> > Erik de Castro Lopo
> > http://www.mega-nerd.com/
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150111/d64d9de6/attachment-0001.html>

From david.feuer at gmail.com  Mon Jan 12 04:16:14 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 11 Jan 2015 23:16:14 -0500
Subject: Data.ByteString.Unsafe.unsafeWipe
In-Reply-To: <CAHYVw0x3L+VTqoME4XLdHpKgkKGoVRbC=egZp22eVYpujT1W6w@mail.gmail.com>
References: <20150111194245.22bea00e9bab8e3f15f8cbad@mega-nerd.com>
 <CAMgWh9t3ZSY+vpHqbSJpez=OZsBy6mwFT4+yLU87f9oW+g2GOQ@mail.gmail.com>
 <CAHYVw0x3L+VTqoME4XLdHpKgkKGoVRbC=egZp22eVYpujT1W6w@mail.gmail.com>
Message-ID: <CAMgWh9sakF+tvZCPNkOsjPeCMt0WR3Yq5=TYxeWxPUvfLj+xaw@mail.gmail.com>

I think this is a good idea too. I don't think a scrubbing finalizer
can give Erik the timing guarantees he wants (at least not without
forcing a major collection by hand, and worrying about stray
references), but it does seem likely to be a good thing to have around
anyway. Note that for something like a password, you also have to be
careful about things like input buffers. I imagine a hypothetical
SecureByteString and/or SecureText would have to offer special IO as
well.

On Sun, Jan 11, 2015 at 11:08 PM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> David's idea is pretty cool!
>
> wrt Erik's suggestion, I'd rather suggest instead
> something like what Vincent's secure memory does,
> which provides finalization support to a bytestring interface
>
> https://hackage.haskell.org/package/securemem-0.1.4/docs/src/Data-SecureMem.html
>
>
>
> -- | Allocate a foreign ptr which will be scrubed before memory free.
> -- the memory is allocated on the haskell heap
> allocateScrubedForeignPtr :: Int -> IO (ForeignPtr a)
> allocateScrubedForeignPtr sz = do
> #if MIN_VERSION_base(4,6,0)
>     fptr@(ForeignPtr addr _) <- mallocForeignPtrBytes sz
>     addForeignPtrConcFinalizer fptr (scruber (Ptr addr))
>     return fptr
>   where !scruber = szToScruber sz
> #else
>     mallocForeignPtrBytes sz
> #endif
>
>
> this code can totally be adapted to provide a scrubing finalizer to any
> foreign pointer of interest, and indeed, it could be done as a helper
> function for bytestrings a la
>
> addFinalizer :: ByteString -> IO () -> IO ()
>
> or something
>
>
> On Sun, Jan 11, 2015 at 10:48 PM, David Feuer <david.feuer at gmail.com> wrote:
>>
>> -1. Breaking referential transparency is completely unnecessary here.
>> The correct way to accomplish this, I believe, is to add a mutable
>> ByteString interface, and then a SecureByteString module wrapping it
>> and actually making the promises you want.
>>
>> On Sun, Jan 11, 2015 at 10:42 PM, Erik de Castro Lopo
>> <mle+hs at mega-nerd.com> wrote:
>> > Discussion period: one month
>> >
>> > When handling sensitive information (like a user's password) it is
>> > desirable to only keep the data around for as short a time as possible.
>> > Specifically, relying on the garbage collector to clean it up is simply
>> > not good enough.
>> >
>> > I therefore propose that the following function to be added to the
>> > Data.ByteString.Unsafe module:
>> >
>> >     -- | Overwrites the contents of a ByteString with \0 bytes.
>> >     unsafeWipe :: ByteString -> IO ()
>> >     unsafeWipe bs =
>> >         BS.unsafeUseAsCStringLen bs $ \(ptr, len) ->
>> >             let go i
>> >                     | i < 0 = return ()
>> >                     | otherwise = pokeElemOff ptr i 0 >> go (i - 1)
>> >             in go (len - 1)
>> >
>> > It is added to the Unsafe module because it break referential
>> > transparency
>> > but since ByteStrings are always kept in pinned memory, it should not
>> > otherwise be considered unsafe.
>> >
>> > It could be used as follows:
>> >
>> >     main = do
>> >         passwd <- getPassword
>> >         doSomethingWith passwd
>> >         unsafeWipe passwd
>> >         restOfProgram
>> >
>> >
>> > Cheers,
>> > Erik
>> > --
>> > ----------------------------------------------------------------------
>> > Erik de Castro Lopo
>> > http://www.mega-nerd.com/
>> > _______________________________________________
>> > Libraries mailing list
>> > Libraries at haskell.org
>> > http://www.haskell.org/mailman/listinfo/libraries
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>
>

From merijn at inconsistent.nl  Mon Jan 12 08:42:56 2015
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Mon, 12 Jan 2015 09:42:56 +0100
Subject: Data.ByteString.Unsafe.unsafeWipe
In-Reply-To: <CAMgWh9sakF+tvZCPNkOsjPeCMt0WR3Yq5=TYxeWxPUvfLj+xaw@mail.gmail.com>
References: <20150111194245.22bea00e9bab8e3f15f8cbad@mega-nerd.com>
 <CAMgWh9t3ZSY+vpHqbSJpez=OZsBy6mwFT4+yLU87f9oW+g2GOQ@mail.gmail.com>
 <CAHYVw0x3L+VTqoME4XLdHpKgkKGoVRbC=egZp22eVYpujT1W6w@mail.gmail.com>
 <CAMgWh9sakF+tvZCPNkOsjPeCMt0WR3Yq5=TYxeWxPUvfLj+xaw@mail.gmail.com>
Message-ID: <D9E4A292-857E-47F8-BD8B-841CB3B44B26@inconsistent.nl>

While I *think* GHC currently would do the right thing with a finaliser, these semantics aren't guaranteed anywhere and the correct way would really be to use something along the lines of "withSecureByteString :: (ByteString -> a) -> IO a" (whether the return value of the argument function should be 'a' or 'IO a' is open to discussion, although letting it be 'IO a' gives more opportunity to leak the secret.

Cheers,
Merijn

> On 12 Jan 2015, at 5:16, David Feuer <david.feuer at gmail.com> wrote:
> 
> I think this is a good idea too. I don't think a scrubbing finalizer
> can give Erik the timing guarantees he wants (at least not without
> forcing a major collection by hand, and worrying about stray
> references), but it does seem likely to be a good thing to have around
> anyway. Note that for something like a password, you also have to be
> careful about things like input buffers. I imagine a hypothetical
> SecureByteString and/or SecureText would have to offer special IO as
> well.
> 
> On Sun, Jan 11, 2015 at 11:08 PM, Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
>> David's idea is pretty cool!
>> 
>> wrt Erik's suggestion, I'd rather suggest instead
>> something like what Vincent's secure memory does,
>> which provides finalization support to a bytestring interface
>> 
>> https://hackage.haskell.org/package/securemem-0.1.4/docs/src/Data-SecureMem.html
>> 
>> 
>> 
>> -- | Allocate a foreign ptr which will be scrubed before memory free.
>> -- the memory is allocated on the haskell heap
>> allocateScrubedForeignPtr :: Int -> IO (ForeignPtr a)
>> allocateScrubedForeignPtr sz = do
>> #if MIN_VERSION_base(4,6,0)
>>    fptr@(ForeignPtr addr _) <- mallocForeignPtrBytes sz
>>    addForeignPtrConcFinalizer fptr (scruber (Ptr addr))
>>    return fptr
>>  where !scruber = szToScruber sz
>> #else
>>    mallocForeignPtrBytes sz
>> #endif
>> 
>> 
>> this code can totally be adapted to provide a scrubing finalizer to any
>> foreign pointer of interest, and indeed, it could be done as a helper
>> function for bytestrings a la
>> 
>> addFinalizer :: ByteString -> IO () -> IO ()
>> 
>> or something
>> 
>> 
>> On Sun, Jan 11, 2015 at 10:48 PM, David Feuer <david.feuer at gmail.com> wrote:
>>> 
>>> -1. Breaking referential transparency is completely unnecessary here.
>>> The correct way to accomplish this, I believe, is to add a mutable
>>> ByteString interface, and then a SecureByteString module wrapping it
>>> and actually making the promises you want.
>>> 
>>> On Sun, Jan 11, 2015 at 10:42 PM, Erik de Castro Lopo
>>> <mle+hs at mega-nerd.com> wrote:
>>>> Discussion period: one month
>>>> 
>>>> When handling sensitive information (like a user's password) it is
>>>> desirable to only keep the data around for as short a time as possible.
>>>> Specifically, relying on the garbage collector to clean it up is simply
>>>> not good enough.
>>>> 
>>>> I therefore propose that the following function to be added to the
>>>> Data.ByteString.Unsafe module:
>>>> 
>>>>    -- | Overwrites the contents of a ByteString with \0 bytes.
>>>>    unsafeWipe :: ByteString -> IO ()
>>>>    unsafeWipe bs =
>>>>        BS.unsafeUseAsCStringLen bs $ \(ptr, len) ->
>>>>            let go i
>>>>                    | i < 0 = return ()
>>>>                    | otherwise = pokeElemOff ptr i 0 >> go (i - 1)
>>>>            in go (len - 1)
>>>> 
>>>> It is added to the Unsafe module because it break referential
>>>> transparency
>>>> but since ByteStrings are always kept in pinned memory, it should not
>>>> otherwise be considered unsafe.
>>>> 
>>>> It could be used as follows:
>>>> 
>>>>    main = do
>>>>        passwd <- getPassword
>>>>        doSomethingWith passwd
>>>>        unsafeWipe passwd
>>>>        restOfProgram
>>>> 
>>>> 
>>>> Cheers,
>>>> Erik
>>>> --
>>>> ----------------------------------------------------------------------
>>>> Erik de Castro Lopo
>>>> http://www.mega-nerd.com/
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/libraries
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>> 
>> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150112/7f3c6248/attachment.sig>

From michael at snoyman.com  Mon Jan 12 08:47:31 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Mon, 12 Jan 2015 08:47:31 +0000
Subject: Data.ByteString.Unsafe.unsafeWipe
References: <20150111194245.22bea00e9bab8e3f15f8cbad@mega-nerd.com>
 <CAMgWh9t3ZSY+vpHqbSJpez=OZsBy6mwFT4+yLU87f9oW+g2GOQ@mail.gmail.com>
 <CAMgWh9tntWVQq_EMDFjuCo4R7QL2gGETQqmR_Bhj_UdFwjfyJg@mail.gmail.com>
Message-ID: <CAKA2JgLz2QcL81v7q7Phi2su_7F8Eb=nOj34wVFHvtSKWxZxbA@mail.gmail.com>

Actually, after writing that I realized I'd just reinvented storable
vectors, and that the entire API can really be summed up by just a pair of
functions for converting `ByteString`s with `Vector Word8`s:

http://www.stackage.org/haddock/nightly-2015-01-12/mono-traversable-0.7.0/Data-ByteVector.html

On Mon Jan 12 2015 at 6:02:06 AM David Feuer <david.feuer at gmail.com> wrote:

> In fact, it looks like Michael Snoyman has done some work on this
> already: https://www.fpcomplete.com/user/chad/snippets/random-
> code-snippets/mutable-bytestring
>  Perhaps he could be convinced to finish/release it.
>
> David
>
> On Sun, Jan 11, 2015 at 10:48 PM, David Feuer <david.feuer at gmail.com>
> wrote:
> > -1. Breaking referential transparency is completely unnecessary here.
> > The correct way to accomplish this, I believe, is to add a mutable
> > ByteString interface, and then a SecureByteString module wrapping it
> > and actually making the promises you want.
> >
> > On Sun, Jan 11, 2015 at 10:42 PM, Erik de Castro Lopo
> > <mle+hs at mega-nerd.com> wrote:
> >> Discussion period: one month
> >>
> >> When handling sensitive information (like a user's password) it is
> >> desirable to only keep the data around for as short a time as possible.
> >> Specifically, relying on the garbage collector to clean it up is simply
> >> not good enough.
> >>
> >> I therefore propose that the following function to be added to the
> >> Data.ByteString.Unsafe module:
> >>
> >>     -- | Overwrites the contents of a ByteString with \0 bytes.
> >>     unsafeWipe :: ByteString -> IO ()
> >>     unsafeWipe bs =
> >>         BS.unsafeUseAsCStringLen bs $ \(ptr, len) ->
> >>             let go i
> >>                     | i < 0 = return ()
> >>                     | otherwise = pokeElemOff ptr i 0 >> go (i - 1)
> >>             in go (len - 1)
> >>
> >> It is added to the Unsafe module because it break referential
> transparency
> >> but since ByteStrings are always kept in pinned memory, it should not
> >> otherwise be considered unsafe.
> >>
> >> It could be used as follows:
> >>
> >>     main = do
> >>         passwd <- getPassword
> >>         doSomethingWith passwd
> >>         unsafeWipe passwd
> >>         restOfProgram
> >>
> >>
> >> Cheers,
> >> Erik
> >> --
> >> ----------------------------------------------------------------------
> >> Erik de Castro Lopo
> >> http://www.mega-nerd.com/
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150112/8af1ac9d/attachment.html>

From tab at snarc.org  Mon Jan 12 09:31:09 2015
From: tab at snarc.org (Vincent Hanquez)
Date: Mon, 12 Jan 2015 09:31:09 +0000
Subject: Data.ByteString.Unsafe.unsafeWipe
In-Reply-To: <CAMgWh9sakF+tvZCPNkOsjPeCMt0WR3Yq5=TYxeWxPUvfLj+xaw@mail.gmail.com>
References: <20150111194245.22bea00e9bab8e3f15f8cbad@mega-nerd.com>
 <CAMgWh9t3ZSY+vpHqbSJpez=OZsBy6mwFT4+yLU87f9oW+g2GOQ@mail.gmail.com>
 <CAHYVw0x3L+VTqoME4XLdHpKgkKGoVRbC=egZp22eVYpujT1W6w@mail.gmail.com>
 <CAMgWh9sakF+tvZCPNkOsjPeCMt0WR3Yq5=TYxeWxPUvfLj+xaw@mail.gmail.com>
Message-ID: <54B3945D.3050708@snarc.org>


On 12/01/2015 04:16, David Feuer wrote:
> I think this is a good idea too. I don't think a scrubbing finalizer
> can give Erik the timing guarantees he wants (at least not without
> forcing a major collection by hand, and worrying about stray
> references), but it does seem likely to be a good thing to have around
> anyway. Note that for something like a password, you also have to be
> careful about things like input buffers. I imagine a hypothetical
> SecureByteString and/or SecureText would have to offer special IO as
> well.
securemem has a finalizeSecureMem [1] which is just a wrapper for 
finalizeForeignPtr, which
run the finalizer immediately.

I agree though, that you might want the whole package of secure 
input/output functions
to be able to handle it end-to-end, and securemem was always a paving 
stone in this direction for me.

[1] finalizeSecureMem

-- 
Vincent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150112/08fae090/attachment.html>

From ben at smart-cactus.org  Mon Jan 12 17:28:16 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 12 Jan 2015 12:28:16 -0500
Subject: System.Posix.IO.ByteString
In-Reply-To: <CAJ727Ggp+wDUrrVfw_07CJRrwtw+g_agpetqm_1Ue82xUL1nHg@mail.gmail.com>
References: <20150110161534.86fb2d2fd99be7dddd49c887@mega-nerd.com>
 <CAKFCL4V9GjopRKWxopCSpu2Sq9Jg73VCGuc47Z8RigBbaHoGAg@mail.gmail.com>
 <87mw5pzc9s.fsf@gnu.org>
 <CAKjSnQFGYS9op2aq9mDOnm84Mxx1Hdg3PSg6_Bcc6L=aEpFXQQ@mail.gmail.com>
 <CAJ727Ggp+wDUrrVfw_07CJRrwtw+g_agpetqm_1Ue82xUL1nHg@mail.gmail.com>
Message-ID: <87k30ryklr.fsf@gmail.com>

John Lato <jwlato at gmail.com> writes:

> The naming collision is unfortunate, but solvable with the PackageImports
> extension.
>
That being said, given that `unix` already has a dependency on
`bytestring`, is there any reason why `ByteString`-enabled `fdRead` and
friends from `unix-bytestring` shouldn't just be folded into `unix`?

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150112/2e641b3b/attachment.sig>

From asr at eafit.edu.co  Mon Jan 12 20:50:41 2015
From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Mon, 12 Jan 2015 15:50:41 -0500
Subject: New maintainer for the boxes library
Message-ID: <CAOUWSGB+E08N49DZmP=4eF=WRZRqxc0OTPTZBG1E_jXx_i=hRg@mail.gmail.com>

Hi,

The current maintainers (Eelis van der Weegen and Benno F?nfst?ck)
?of?
the boxes library (http://hackage.haskell.org/package/boxes) don't want to
be maintainers any
? ?
more.

Does someone want to become the new maintainer of this library?

Best,

-- 
Andr?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150112/2e3d0282/attachment.html>

From david.feuer at gmail.com  Mon Jan 12 22:18:36 2015
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 12 Jan 2015 17:18:36 -0500
Subject: New maintainer for the boxes library
In-Reply-To: <CAOUWSGB+E08N49DZmP=4eF=WRZRqxc0OTPTZBG1E_jXx_i=hRg@mail.gmail.com>
References: <CAOUWSGB+E08N49DZmP=4eF=WRZRqxc0OTPTZBG1E_jXx_i=hRg@mail.gmail.com>
Message-ID: <CAMgWh9tScbRi2bVxxqR=vkLTPqyH6oofFHtbjgZsssaB4D6urw@mail.gmail.com>

What's involved exactly? It looks like a small and manageable library, but
I wouldn't want to commit to coming up with lots of brilliant new ideas for
expanding it.
On Jan 12, 2015 3:51 PM, "Andr?s Sicard-Ram?rez" <asr at eafit.edu.co> wrote:

> Hi,
>
> The current maintainers (Eelis van der Weegen and Benno F?nfst?ck)
> ?of?
> the boxes library (http://hackage.haskell.org/package/boxes) don't want
> to be maintainers any
> ? ?
> more.
>
> Does someone want to become the new maintainer of this library?
>
> Best,
>
> --
> Andr?s
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150112/666b535d/attachment.html>

From david.feuer at gmail.com  Mon Jan 12 22:53:10 2015
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 12 Jan 2015 17:53:10 -0500
Subject: New maintainer for the boxes library
In-Reply-To: <CAMgWh9tScbRi2bVxxqR=vkLTPqyH6oofFHtbjgZsssaB4D6urw@mail.gmail.com>
References: <CAOUWSGB+E08N49DZmP=4eF=WRZRqxc0OTPTZBG1E_jXx_i=hRg@mail.gmail.com>
 <CAMgWh9tScbRi2bVxxqR=vkLTPqyH6oofFHtbjgZsssaB4D6urw@mail.gmail.com>
Message-ID: <CAMgWh9syANCbrBE9AB9FKa63WCg3ytk-QdZKKk=vrNobb5y5jg@mail.gmail.com>

Actually, I do have an idea or two. I'll take over maintainership.
On Jan 12, 2015 5:18 PM, "David Feuer" <david.feuer at gmail.com> wrote:

> What's involved exactly? It looks like a small and manageable library, but
> I wouldn't want to commit to coming up with lots of brilliant new ideas for
> expanding it.
> On Jan 12, 2015 3:51 PM, "Andr?s Sicard-Ram?rez" <asr at eafit.edu.co> wrote:
>
>> Hi,
>>
>> The current maintainers (Eelis van der Weegen and Benno F?nfst?ck)
>> ?of?
>> the boxes library (http://hackage.haskell.org/package/boxes) don't want
>> to be maintainers any
>> ? ?
>> more.
>>
>> Does someone want to become the new maintainer of this library?
>>
>> Best,
>>
>> --
>> Andr?s
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150112/cd81719c/attachment.html>

From asr at eafit.edu.co  Tue Jan 13 03:09:50 2015
From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Mon, 12 Jan 2015 22:09:50 -0500
Subject: New maintainer for the boxes library
In-Reply-To: <CAMgWh9syANCbrBE9AB9FKa63WCg3ytk-QdZKKk=vrNobb5y5jg@mail.gmail.com>
References: <CAOUWSGB+E08N49DZmP=4eF=WRZRqxc0OTPTZBG1E_jXx_i=hRg@mail.gmail.com>
 <CAMgWh9tScbRi2bVxxqR=vkLTPqyH6oofFHtbjgZsssaB4D6urw@mail.gmail.com>
 <CAMgWh9syANCbrBE9AB9FKa63WCg3ytk-QdZKKk=vrNobb5y5jg@mail.gmail.com>
Message-ID: <CAOUWSGD2gvhT7p793W_NVywaiVA1zo8+rbDsQmj=JdjC5tbg_Q@mail.gmail.com>

Thanks!

On 12 January 2015 at 17:53, David Feuer <david.feuer at gmail.com> wrote:

> Actually, I do have an idea or two. I'll take over maintainership.
> On Jan 12, 2015 5:18 PM, "David Feuer" <david.feuer at gmail.com> wrote:
>
>> What's involved exactly? It looks like a small and manageable library,
>> but I wouldn't want to commit to coming up with lots of brilliant new ideas
>> for expanding it.
>> On Jan 12, 2015 3:51 PM, "Andr?s Sicard-Ram?rez" <asr at eafit.edu.co>
>> wrote:
>>
>>> Hi,
>>>
>>> The current maintainers (Eelis van der Weegen and Benno F?nfst?ck)
>>> ?of?
>>> the boxes library (http://hackage.haskell.org/package/boxes) don't want
>>> to be maintainers any
>>> ? ?
>>> more.
>>>
>>> Does someone want to become the new maintainer of this library?
>>>
>>> Best,
>>>
>>> --
>>> Andr?s
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>>


-- 
Andr?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150112/b78c790f/attachment.html>

From asr at eafit.edu.co  Wed Jan 14 17:34:34 2015
From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Wed, 14 Jan 2015 12:34:34 -0500
Subject: New maintainer for the boxes library
In-Reply-To: <CAMgWh9syANCbrBE9AB9FKa63WCg3ytk-QdZKKk=vrNobb5y5jg@mail.gmail.com>
References: <CAOUWSGB+E08N49DZmP=4eF=WRZRqxc0OTPTZBG1E_jXx_i=hRg@mail.gmail.com>
 <CAMgWh9tScbRi2bVxxqR=vkLTPqyH6oofFHtbjgZsssaB4D6urw@mail.gmail.com>
 <CAMgWh9syANCbrBE9AB9FKa63WCg3ytk-QdZKKk=vrNobb5y5jg@mail.gmail.com>
Message-ID: <CAOUWSGCWiMmXZSmS1ydvuSRnmku4W2KhRB2X_aFQCDWt+35=Jg@mail.gmail.com>

On 12 January 2015 at 17:53, David Feuer <david.feuer at gmail.com> wrote:

> Actually, I do have an idea or two. I'll take over maintainership.


?Thanks for releasing boxes 0.1.4!

-- 
Andr?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150114/a8069faf/attachment.html>

From kyrab at mail.ru  Sun Jan 18 17:56:42 2015
From: kyrab at mail.ru (kyra)
Date: Sun, 18 Jan 2015 20:56:42 +0300
Subject: Hackage is flooded with old package versions reuploads
Message-ID: <54BBF3DA.9040700@mail.ru>

Hi, guys,

It looks old (and even ancient) versions of many packages gets uploaded 
to hackage over and over again in ever increasing amounts. The username 
of uploader for vast majority of these uploads is HerbertValerioRiedel.

While this is harmless I wonder what idea stands behind this?

Cheers,
Kyra

From allbery.b at gmail.com  Sun Jan 18 18:14:42 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 18 Jan 2015 13:14:42 -0500
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <54BBF3DA.9040700@mail.ru>
References: <54BBF3DA.9040700@mail.ru>
Message-ID: <CAKFCL4U7zwapiF+1nsWLj462NzJ__3_-VgHGz2m-j6H8zuxBtQ@mail.gmail.com>

On Sun, Jan 18, 2015 at 12:56 PM, kyra <kyrab at mail.ru> wrote:

> It looks old (and even ancient) versions of many packages gets uploaded to
> hackage over and over again in ever increasing amounts. The username of
> uploader for vast majority of these uploads is HerbertValerioRiedel.
>
> While this is harmless I wonder what idea stands behind this?
>

Correcting bad package dependency limits to avoid things trying to use
packages that can never work but whose loose versioning claims that it
will?

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150118/65958b37/attachment.html>

From ekmett at gmail.com  Sun Jan 18 22:58:23 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 18 Jan 2015 17:58:23 -0500
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <54BBF3DA.9040700@mail.ru>
References: <54BBF3DA.9040700@mail.ru>
Message-ID: <EF720846-0081-4905-8146-78E0820B9887@gmail.com>

Herbert patches old versions to fix up build plans and put in upper bounds that are shown to cause problems.

He's doing an awesome job and has greatly simplified my life.

Sent from my iPhone

> On Jan 18, 2015, at 12:56 PM, kyra <kyrab at mail.ru> wrote:
> 
> Hi, guys,
> 
> It looks old (and even ancient) versions of many packages gets uploaded to hackage over and over again in ever increasing amounts. The username of uploader for vast majority of these uploads is HerbertValerioRiedel.
> 
> While this is harmless I wonder what idea stands behind this?
> 
> Cheers,
> Kyra
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

From tab at snarc.org  Sun Jan 18 23:05:31 2015
From: tab at snarc.org (Vincent Hanquez)
Date: Sun, 18 Jan 2015 15:05:31 -0800
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <54BBF3DA.9040700@mail.ru>
References: <54BBF3DA.9040700@mail.ru>
Message-ID: <54BC3C3B.8060909@snarc.org>


On 18/01/2015 09:56, kyra wrote:
> Hi, guys,
>
> It looks old (and even ancient) versions of many packages gets 
> uploaded to hackage over and over again in ever increasing amounts. 
> The username of uploader for vast majority of these uploads is 
> HerbertValerioRiedel.
>
> While this is harmless I wonder what idea stands behind this?
This is not harmless. This is a security issue by itself, as now 
packages get changes transparently given a url, you might have a 
different package one day, which trigger hash check failure. or signed 
tag verification failure.

This has also the effect of not changing the bounds in the repository, 
so for example, next time you upload a tweak'ed packages, you 
effectively revert the change done on hackage only.

This is also done without the consent of the maintainer of a given 
package, nor that the maintainer is actually notified when that happens, 
or allow to prevent it happening. This is pretty big start from the 
other similar policy for taking over packages, that insist on a very 
long period of repeated communication with the author and then the 
community.

The whole thing is at best ill advised,
-- 
Vincent

From ekmett at gmail.com  Sun Jan 18 23:49:50 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 18 Jan 2015 18:49:50 -0500
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <54BC3C3B.8060909@snarc.org>
References: <54BBF3DA.9040700@mail.ru>
	<54BC3C3B.8060909@snarc.org>
Message-ID: <CAJumaK9GoFP=0N8oED0fGsmoRKOd8Em+be7HyEfeN-rh+ub7aw@mail.gmail.com>

The alternative is just that cabal will continue indefinitely to try to
install completely broken combinations, and more people will be driven to a
fixed package set like stackage LTS.

Most of these problems are caused by people being too optimistic about
upper bounds and when they realize their mistake and upload a new version,
they'll often leave the old versions with the lying bounds intact, which
causes cabal to pick old versions without bug fixes, and then give strange
build errors.

To my knowledge, the few cases where Herbert has actively done a patch to
the .cabal file like this without author communication is because the
package is in very very widespread use and the author has been
incommunicado for many months. As I recall, Max Bolingbroke has a some
packages that fit this bill.

At least in my case, and in the case of the Haskell core libraries, Herbert
has been very conscientious about talking to me, finding problems, auditing
what builds across all versions of GHC in recent and not-so-recent memory,
and working with me to find the best fix on a case by case basis. He has my
explicit consent for any tweaks he has had to make to the build
dependencies of my packages and has worked with the core libraries
committee very closely for patches to the core libraries.

If you have an example of a package you've written that he's patched that
you'd rather he left alone, I'm sure he'd be happy to oblige. I am,
however, as of yet unaware of any such overreach and I'm rather disinclined
to view the enormous amount of effort Herbert has poured into keeping the
ecosystem working smoothly as anything but a good thing. The price of doing
nothing here is quite high.

-Edward


On Sun, Jan 18, 2015 at 6:05 PM, Vincent Hanquez <tab at snarc.org> wrote:

>
> On 18/01/2015 09:56, kyra wrote:
>
>> Hi, guys,
>>
>> It looks old (and even ancient) versions of many packages gets uploaded
>> to hackage over and over again in ever increasing amounts. The username of
>> uploader for vast majority of these uploads is HerbertValerioRiedel.
>>
>> While this is harmless I wonder what idea stands behind this?
>>
> This is not harmless. This is a security issue by itself, as now packages
> get changes transparently given a url, you might have a different package
> one day, which trigger hash check failure. or signed tag verification
> failure.
>
> This has also the effect of not changing the bounds in the repository, so
> for example, next time you upload a tweak'ed packages, you effectively
> revert the change done on hackage only.
>
> This is also done without the consent of the maintainer of a given
> package, nor that the maintainer is actually notified when that happens, or
> allow to prevent it happening. This is pretty big start from the other
> similar policy for taking over packages, that insist on a very long period
> of repeated communication with the author and then the community.
>
> The whole thing is at best ill advised,
> --
> Vincent
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150118/1db6da8d/attachment.html>

From david.feuer at gmail.com  Sun Jan 18 23:51:32 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 18 Jan 2015 18:51:32 -0500
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <54BC3C3B.8060909@snarc.org>
References: <54BBF3DA.9040700@mail.ru>
	<54BC3C3B.8060909@snarc.org>
Message-ID: <CAMgWh9t0mwtvin1x5E5g5BFPm5efPFHjNF6+zXaw4fNqtHKXxA@mail.gmail.com>

It would be best to be sure to make the maintainer (if there is one) aware
of such changes. That said, not every package has a responsive maintainer,
and *someone* has to do this work, and do it promptly. A signed hash
failure does not introduce a security hole, unless you count a sort of
semi-manual, avoidable denial of service. If you don't trust Herbert and
Austin, you probably shouldn't bother trying to use Haskell anyway.
On Jan 18, 2015 6:05 PM, "Vincent Hanquez" <tab at snarc.org> wrote:

>
> On 18/01/2015 09:56, kyra wrote:
>
>> Hi, guys,
>>
>> It looks old (and even ancient) versions of many packages gets uploaded
>> to hackage over and over again in ever increasing amounts. The username of
>> uploader for vast majority of these uploads is HerbertValerioRiedel.
>>
>> While this is harmless I wonder what idea stands behind this?
>>
> This is not harmless. This is a security issue by itself, as now packages
> get changes transparently given a url, you might have a different package
> one day, which trigger hash check failure. or signed tag verification
> failure.
>
> This has also the effect of not changing the bounds in the repository, so
> for example, next time you upload a tweak'ed packages, you effectively
> revert the change done on hackage only.
>
> This is also done without the consent of the maintainer of a given
> package, nor that the maintainer is actually notified when that happens, or
> allow to prevent it happening. This is pretty big start from the other
> similar policy for taking over packages, that insist on a very long period
> of repeated communication with the author and then the community.
>
> The whole thing is at best ill advised,
> --
> Vincent
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150118/0a1bc585/attachment.html>

From tab at snarc.org  Mon Jan 19 00:39:09 2015
From: tab at snarc.org (Vincent Hanquez)
Date: Sun, 18 Jan 2015 16:39:09 -0800
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <CAJumaK9GoFP=0N8oED0fGsmoRKOd8Em+be7HyEfeN-rh+ub7aw@mail.gmail.com>
References: <54BBF3DA.9040700@mail.ru>	<54BC3C3B.8060909@snarc.org>
 <CAJumaK9GoFP=0N8oED0fGsmoRKOd8Em+be7HyEfeN-rh+ub7aw@mail.gmail.com>
Message-ID: <54BC522D.7040406@snarc.org>


On 18/01/2015 15:49, Edward Kmett wrote:
> The alternative is just that cabal will continue indefinitely to try 
> to install completely broken combinations, and more people will be 
> driven to a fixed package set like stackage LTS.
That strikes me as probably-a-good-thing.
> Most of these problems are caused by people being too optimistic about 
> upper bounds and when they realize their mistake and upload a new 
> version, they'll often leave the old versions with the lying bounds 
> intact, which causes cabal to pick old versions without bug fixes, and 
> then give strange build errors.
>
> To my knowledge, the few cases where Herbert has actively done a patch 
> to the .cabal file like this without author communication is because 
> the package is in very very widespread use and the author has been 
> incommunicado for many months. As I recall, Max Bolingbroke has a some 
> packages that fit this bill.
A simple counter example, that I noticed after the fact [1]
> If you have an example of a package you've written that he's patched 
> that you'd rather he left alone, I'm sure he'd be happy to oblige. I 
> am, however, as of yet unaware of any such overreach and I'm rather 
> disinclined to view the enormous amount of effort Herbert has poured 
> into keeping the ecosystem working smoothly as anything but a good 
> thing. The price of doing nothing here is quite high.
I strongly object to the current mechanism of silent updates (for the 
downloader), and I would much rather have all my packages left alone 
until this changes at the very least (if ever). The maintenance 
overriding is another sad point (which might be warranted in some case, 
although haskell already have a procedure in place for that), but in any 
case not as critical as the first point.

[1] https://hackage.haskell.org/package/hourglass

-- 
Vincent

From tab at snarc.org  Mon Jan 19 00:57:29 2015
From: tab at snarc.org (Vincent Hanquez)
Date: Sun, 18 Jan 2015 16:57:29 -0800
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <CAMgWh9t0mwtvin1x5E5g5BFPm5efPFHjNF6+zXaw4fNqtHKXxA@mail.gmail.com>
References: <54BBF3DA.9040700@mail.ru>	<54BC3C3B.8060909@snarc.org>
 <CAMgWh9t0mwtvin1x5E5g5BFPm5efPFHjNF6+zXaw4fNqtHKXxA@mail.gmail.com>
Message-ID: <54BC5679.7040807@snarc.org>


On 18/01/2015 15:51, David Feuer wrote:
>
> It would be best to be sure to make the maintainer (if there is one) 
> aware of such changes. That said, not every package has a responsive 
> maintainer, and *someone* has to do this work, and do it promptly. A 
> signed hash failure does not introduce a security hole, unless you 
> count a sort of semi-manual, avoidable denial of service.
>
Not sure how you got "security hole" from what I said, but a failing 
hash or signature, means that the build system breaks while cabal 
install stuff and that I have to manually inspect what the change is. If 
you can't pin down a special tarball when doing a download (i.e. it can 
changes under your feet, one day to the other), then it's an issue.

Lots of people would be *horrified* to download some 
{c,c++,python,ruby,...} library-a.b.c.tar.gz and found anything changed 
inside without changing the exact name for it.
>
> If you don't trust Herbert and Austin, you probably shouldn't bother 
> trying to use Haskell anyway.
>
lol ? Do you mean that I should switch language, if security is remotely 
important to me ?

As much as Herbert and Austin are doing awesome work in general, I 
certainly do not blindly trust them.

-- 
Vincent

From allbery.b at gmail.com  Mon Jan 19 01:00:05 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 18 Jan 2015 20:00:05 -0500
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <54BC5679.7040807@snarc.org>
References: <54BBF3DA.9040700@mail.ru> <54BC3C3B.8060909@snarc.org>
 <CAMgWh9t0mwtvin1x5E5g5BFPm5efPFHjNF6+zXaw4fNqtHKXxA@mail.gmail.com>
 <54BC5679.7040807@snarc.org>
Message-ID: <CAKFCL4X09Fqi_vapNnWWiHT3k-E4RWaM=RWFu3MX=gEQJFapog@mail.gmail.com>

On Sun, Jan 18, 2015 at 7:57 PM, Vincent Hanquez <tab at snarc.org> wrote:

> Lots of people would be *horrified* to download some
> {c,c++,python,ruby,...} library-a.b.c.tar.gz and found anything changed
> inside without changing the exact name for it.
>
>>
Funny thing, that, because it happens pretty often and packagers have to
have "silent update" (upstream silently repackaged without changing the
version) rules to deal with it.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150118/3d9d22c5/attachment.html>

From emertens at gmail.com  Mon Jan 19 01:25:56 2015
From: emertens at gmail.com (Eric Mertens)
Date: Mon, 19 Jan 2015 01:25:56 +0000
Subject: Hackage is flooded with old package versions reuploads
References: <54BBF3DA.9040700@mail.ru> <54BC3C3B.8060909@snarc.org>
 <CAMgWh9t0mwtvin1x5E5g5BFPm5efPFHjNF6+zXaw4fNqtHKXxA@mail.gmail.com>
 <54BC5679.7040807@snarc.org>
 <CAKFCL4X09Fqi_vapNnWWiHT3k-E4RWaM=RWFu3MX=gEQJFapog@mail.gmail.com>
Message-ID: <CALya092JZr3mMmdjY6mm76weqp98iNCgorcdOQY1L0pxHTNtFQ@mail.gmail.com>

Wow, I thought this was a joke at first. HVRs work is terribly useful for
enabling old and new versions of GHC to work with hackage, and I've very
much appreciated the build reports he generates.

I'm sure he'd be happy to leave packages alone for anyone who prefers their
packages remain broken.

Thanks hvr for fixing the dozens and dozens of versions of just the lens
package in order to sort the base-4.8 rollout in particular that would have
taken an age to do manually.

On Sun, Jan 18, 2015, 5:00 PM Brandon Allbery <allbery.b at gmail.com> wrote:

> On Sun, Jan 18, 2015 at 7:57 PM, Vincent Hanquez <tab at snarc.org> wrote:
>
>> Lots of people would be *horrified* to download some
>> {c,c++,python,ruby,...} library-a.b.c.tar.gz and found anything changed
>> inside without changing the exact name for it.
>>
>>>
> Funny thing, that, because it happens pretty often and packagers have to
> have "silent update" (upstream silently repackaged without changing the
> version) rules to deal with it.
>
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>  _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150119/29b02bf3/attachment.html>

From roma at ro-che.info  Mon Jan 19 04:23:59 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Mon, 19 Jan 2015 06:23:59 +0200
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <54BC3C3B.8060909@snarc.org>
References: <54BBF3DA.9040700@mail.ru> <54BC3C3B.8060909@snarc.org>
Message-ID: <54BC86DF.9000901@ro-che.info>

On 19/01/15 01:05, Vincent Hanquez wrote:
> This is not harmless. This is a security issue by itself, as now
> packages get changes transparently given a url, you might have a
> different package one day, which trigger hash check failure. or signed
> tag verification failure.

Correct me if I'm wrong, but editing version bounds on hackage doesn't
actually affect the tarball (and its checksum). The modified cabal file
is downloaded separately as part of the index.

Not saying it doesn't introduce its own problems, but the hash check
should continue to pass.

Roman


From nikita.y.volkov at gmail.com  Mon Jan 19 04:54:19 2015
From: nikita.y.volkov at gmail.com (Nikita Volkov)
Date: Mon, 19 Jan 2015 07:54:19 +0300
Subject: Announcing a solution to the records problem
Message-ID: <CACvKsMF0WQBnkq6kv_exebyrc9hvS6E9aftZ-jOLGpx01X_fJg@mail.gmail.com>

This thing seems to be going viral on social networks already, nonetheless
here's a link for those of you, who aren't yet informed:

http://nikita-volkov.github.io/record/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150119/1fbfc163/attachment.html>

From tab at snarc.org  Mon Jan 19 05:31:16 2015
From: tab at snarc.org (Vincent Hanquez)
Date: Sun, 18 Jan 2015 21:31:16 -0800
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <54BC86DF.9000901@ro-che.info>
References: <54BBF3DA.9040700@mail.ru> <54BC3C3B.8060909@snarc.org>
 <54BC86DF.9000901@ro-che.info>
Message-ID: <54BC96A4.4010208@snarc.org>


On 18/01/2015 20:23, Roman Cheplyaka wrote:
> On 19/01/15 01:05, Vincent Hanquez wrote:
>> This is not harmless. This is a security issue by itself, as now
>> packages get changes transparently given a url, you might have a
>> different package one day, which trigger hash check failure. or signed
>> tag verification failure.
> Correct me if I'm wrong, but editing version bounds on hackage doesn't
> actually affect the tarball (and its checksum). The modified cabal file
> is downloaded separately as part of the index.
yes, that's right. I meant to say that what you're downloading through 
cabal get
tweaked by cabal, but the end result is pretty much the same
> Not saying it doesn't introduce its own problems, but the hash check
> should continue to pass.
of the tarball yes, not of your compilation tree, and maybe not the 
resulting binary.

-- 
Vincent

From hvr at gnu.org  Mon Jan 19 08:31:41 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Mon, 19 Jan 2015 09:31:41 +0100
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <54BBF3DA.9040700@mail.ru> (kyra's message of "Sun, 18 Jan 2015
 20:56:42 +0300")
References: <54BBF3DA.9040700@mail.ru>
Message-ID: <87vbk3goia.fsf@gnu.org>

On 2015-01-18 at 18:56:42 +0100, kyra wrote:
> It looks old (and even ancient) versions of many packages gets
> uploaded to hackage over and over again in ever increasing
> amounts. The username of uploader for vast majority of these uploads
> is HerbertValerioRiedel.

That would be me...

Just to clarify: I those aren't re-uploads of existing package versions,
but rather meta-data revisions. The actual source-code is *not* touched,
(and Hackage is very restricting in what's allowed to be changed in a
.cabal file)

This is also mentioned on http://hackage.haskell.org/packages/trustees/

> While this is harmless I wonder what idea stands behind this?

The idea, as others in this thread have already pointed out, is to add
missing lower/upper package bounds to packages so that the Cabal
install-plan solver can fulfill its task.

Over the last week, I've been analyzing the current situation (motivated
by the upcoming GHC 7.10 release which trips up quite a few packages
with missing bounds on base/deepseq/time), and trying to come up with
some tooling[1] to help the otherwise IMO rather unmanageable job of a
Hackage trustee, as well as surgically fixing up the meta-data where I
had empirical proof that the .cabal meta-data was incorrect (and thus
leading the solver to select a broken install-plan).

Here's a very simple buildreport for illustration:

 https://ghc.haskell.org/~hvr/buildreports/pretty.html

The purpose of my meta-data edits were/are (in order of decreasing
priority):

 1. First and foremost, no currently working/valid install-plan was lost.

 2. A simple constraint-less `cabal install pretty` ought to result
    *either* in a valid install-plan, *or* cabal failing to find any
    install-plan.

 3. An major-version constraint `cabal install 'pretty == a.b.*'` ought
    to result *either* in a valid install-plan, *or* cabal failing to find
    any install-plan.

 4. A package shall not cause indirect *build*-failures of other
    packages directly or indirectly depending on this package[3]

The build-report linked helps directly with 2. and 3. as it shows that
`pretty` failed to `cabal install pretty` (as well as `cabal install
'pretty == 1.1.*'`) for GHC 7.0 and GHC 7.2.  Case 4. could be detected
by running the buildtool on many Hackage packages depending on `pretty`,
and look for failures to build `pretty` during the `cabal install --dep`
step (which would result in a "FAIL (deps)" cells).


I've encountered a couple of situations, where fixing the meta-data of
an important package low in the dependency graph fixed a couple of other
packages depending on that package. However, this also means that the
more popular a package is, the higher its responsibility is to make sure
its build-depend meta-data is correct, as such packages have the
potential to instantly break large branches of Hackage:

One example for that was the release of deepseq-1.4, which changes the
default-implementation of `rnf` which a few packages relied on, but the
rather important `text` package was among of those. This affected most
of the released ~50 `text` package versions, and since `deepseq` is
compatible with all GHC 7.* versions, as soon an install-plan was
selected which included `deepseq-1.4` with a non-latest version of
`text` the build would fail. And since it's not uncommon to restrict the
upper bound of `text`[2], all those packages depending on a non-latest
`text` would have broken install-plans (unless `deepseq < 1.4` was
selected).

I hope this answers your question.

Cheers,
  hvr


 [1]: https://github.com/hvr/hackage-matrix-builder

      (WIP example reports can be seen in

       https://ghc.haskell.org/~hvr/buildreports/0INDEX.html)


 [2]: http://packdeps.haskellers.com/reverse/text

 [3]: This can happen due to additional package-version constraints
      causing other (but broken) configurations to be selected by the
      solver not detected in case 2. and 3.

From R.Paterson at city.ac.uk  Mon Jan 19 10:08:49 2015
From: R.Paterson at city.ac.uk (Ross Paterson)
Date: Mon, 19 Jan 2015 10:08:49 +0000
Subject: removing constraints
In-Reply-To: <CAMgWh9ta6vagu877Skqh+7581tc1_pc8juLG3Bhm7UeHGb=+VQ@mail.gmail.com>
References: <20150109152529.GA5022@city.ac.uk>
 <CAMgWh9ta6vagu877Skqh+7581tc1_pc8juLG3Bhm7UeHGb=+VQ@mail.gmail.com>
Message-ID: <20150119100849.GA3477@city.ac.uk>

On Fri, Jan 09, 2015 at 10:29:43AM -0500, David Feuer wrote:
> 
> On Jan 9, 2015 10:25 AM, "Ross Paterson" <R.Paterson at city.ac.uk> wrote:
> > These constraints are not needed by the GHC implementations, but might be
> > needed for other possible implementations, so in a sense the changes are
> > leaking the GHC implementations.  This seems most clear in the Functor
> > and Foldable instances for Array, and elems.  Portable implementations
> > of these will require the Ix constraint -- I think it should be restored.
> 
> Agreed.
> 
> > The other cases are more arguable.  For example the change to Data.Ratio
> > declares that the pair is kept in reduced form, but one could argue that
> > requiring that is no bad thing.
> 
> Disagreed. However, some have argued convincingly that the Ratio type as it
> stands makes little sense anyway.

I'm not clear what you're disagreeing with here, since my original statement
was equivocal.

That also leaves the question of the Ix constraint on bounds.  Should it be
removed, and if so should it also be removed from the bounds methods in the
IArray and MArray classes?

From hvr at gnu.org  Mon Jan 19 10:51:58 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Mon, 19 Jan 2015 11:51:58 +0100
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <54BC3C3B.8060909@snarc.org> (Vincent Hanquez's message of "Sun, 
 18 Jan 2015 15:05:31 -0800")
References: <54BBF3DA.9040700@mail.ru> <54BC3C3B.8060909@snarc.org>
Message-ID: <87iog3gi0h.fsf@gnu.org>

On 2015-01-19 at 00:05:31 +0100, Vincent Hanquez wrote:

[...]

>> While this is harmless I wonder what idea stands behind this?

> This is not harmless. This is a security issue by itself, as now
> packages get changes transparently given a url, you might have a
> different package one day, which trigger hash check failure. or signed
> tag verification failure.

Just to clarify: the source tarball are *never* modified to specifically
make sure hashes don't randomly change (which would trip all sorts of
warnings for distribution packagers). In fact, there's also a
`cabal get` option if you want to unpack with the original unaltered .cabal
file:

    --pristine    Unpack the original pristine tarball,
                  rather than updating the .cabal file
                  with the latest revision from the
                  package archive.

> This has also the effect of not changing the bounds in the repository,
> so for example, next time you upload a tweak'ed packages, you
> effectively revert the change done on hackage only.
> This is also done without the consent of the maintainer of a given
> package, nor that the maintainer is actually notified when that
> happens, or allow to prevent it happening.

Fwiw, there's plans for an automated notification feature:

  https://github.com/haskell/hackage-server/issues/230

We're actively working on refining the system, and finding out where it
needs to be improved. For most of my edits I did in fact inform upstream
to make sure the broken install-plan issue was known so future uploads
could address the issue (or at least add missing bounds to avoid
regressing again).

> This is pretty big start from the other similar policy for taking over
> packages, that insist on a very long period of repeated communication
> with the author and then the community.

We probably need a broader discussion to clarify what Hackage's goal
shall be in terms of (various dimensions of) stability, what policies
Hackage trustees shall follow to help achieve these goals, and most
importantly, which responsibilities a package author agrees to (and
which (s)he delegates to trustees), when (s)he uploads a package to
Hackage, which is a shared and vital resource of our ecosystem and IMO
ought to be kept in good condition to ensure a good experience for all
its users.

Right now there's varying degrees of expectations of what Hackage is,
with one extreme being that Hackage is simply considered a storage-space
for dumping package source-tarballs to (and where .cabal meta-data
hygiene has low to no priority), and the other end of the spectrum being
the vision of Hackage as a somewhat curated (and yet bleeding-edge)
package repository.

The latter is not unlike Stackage (or the LTSHaskell idea), but with a
different priority of eliminating broken install plans (while retaining
the degree of freedom version-ranges for dependencies provide) rather
than providing a single vetted cross-section of Hackage.

Even with the legitimate existence of Stackage (and possibly
LTSHaskell), there's still the need for keeping Hackage in good shape
meta-data-wise:


 1) There's a significant amount of users which are stuck with an older
    GHC (Debian Stable currently ships with GHC 7.4.2, Debian Jessie
    will most likely ship with GHC 7.6.3 later this year; I've seen
    reports of RHEL6 users being stuck with GHC 7.0.4)

    Also, the Haskell Platform lags behind one major GHC version for
    some time till it picks up the latest stable GHC version. It'll be
    quite some time till we see a HP release featuring GHC 7.10.x after
    GHC 7.10.1 is released.

    While I don't consider it paramount for every latest package version
    to still be compatible with GHC 7.4.2 (or GHC 7.0), I do consider it
    important that a `cabal install $PKG` picks the latest still
    compatible package version (if one exists). The more popular $PKG
    is, the more important I consider this.

    Just consider a new Haskell user who doesn't know all the issues
    with Hackage who reads a blog-post (I'm thinking of something like
    "24 Days of Hackage"), then goes on to `cabal install $PKG` and is
    confronted with a compile-error (rather than picking an older but
    working version)... is that the first impression we want new users
    to have with Haskell & Hackage?
    
 2) Before a new package version can be cherry-picked into
    Stackage/LTSHaskell, it needs to be on something like Hackage first,
    also to allow other packages to be updated against the new version
    (which can result in a cascade of package version updates throughout
    the dependency-graph).

    This is IMO one killer feature Hackage has with its version-ranges
    instead of single-version pinned down package-sets. I think such
    update scenarios would be quite harder to perform if Stackage didn't
    have Hackage as the staging/integration area for version-update
    waves.

 3) As an extension of 2), library maintainers also need properly
    working build-plans for older GHCs for latest-versions of the
    build-deps they rely on, as otherwise they have a hard time
    providing and ensuring backward compatibility for their packages
    during development if e.g. their Travis-job-matrices start falling
    apart due to suddenly beaking install-plans.

    The alternative would be to have package versions restrict their
    support to single GHC major versions and provide bugfixes (and
    improvements) for older GHCs via backports to previous
    package-version branches.

    Personally, I consider it less effort to have the latest
    package-version support a couple of recent GHC version, and slowly
    phase out support for older GHCs if it becomes to costly to support
    those (because e.g. features from newer GHCs are exploited)

    That results in a "diagonal support corridor" in the build-reports
    as in e.g. 

      https://ghc.haskell.org/~hvr/buildreports/either.html

    Ideally, if you can support older GHCs, then the pattern looks like
    a lower-left support triangle as in

      https://ghc.haskell.org/~hvr/buildreports/unordered-containers.html


This email's already gotten much longer than I intended to and I started
digressing... so I'm better stop here... :-)

Cheers,
  hvr

From hvr at gnu.org  Mon Jan 19 12:06:48 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Mon, 19 Jan 2015 13:06:48 +0100
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <CALya092JZr3mMmdjY6mm76weqp98iNCgorcdOQY1L0pxHTNtFQ@mail.gmail.com>
 (Eric Mertens's message of "Mon, 19 Jan 2015 01:25:56 +0000")
References: <54BBF3DA.9040700@mail.ru> <54BC3C3B.8060909@snarc.org>
 <CAMgWh9t0mwtvin1x5E5g5BFPm5efPFHjNF6+zXaw4fNqtHKXxA@mail.gmail.com>
 <54BC5679.7040807@snarc.org>
 <CAKFCL4X09Fqi_vapNnWWiHT3k-E4RWaM=RWFu3MX=gEQJFapog@mail.gmail.com>
 <CALya092JZr3mMmdjY6mm76weqp98iNCgorcdOQY1L0pxHTNtFQ@mail.gmail.com>
Message-ID: <877fwjgejr.fsf@gnu.org>

Hello,

On 2015-01-19 at 02:25:56 +0100, Eric Mertens wrote:

[...]

> I'm sure he'd be happy to leave packages alone for anyone who prefers
> their packages remain broken.

I wouldn't say I'm "happy" to, but I'll certainly comply with the
request.

The reason I wouldn't be happy is that the effects of a "broken" package
(especially the more popular it becomes) can't be contained easily. The
breakage cascades through the build-dep graph (I already mentioned the
`text`-example in another reply). In some sense, "no package is an
island"...

Cheers,
  hvr

From allbery.b at gmail.com  Mon Jan 19 14:59:35 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 19 Jan 2015 09:59:35 -0500
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <877fwjgejr.fsf@gnu.org>
References: <54BBF3DA.9040700@mail.ru> <54BC3C3B.8060909@snarc.org>
 <CAMgWh9t0mwtvin1x5E5g5BFPm5efPFHjNF6+zXaw4fNqtHKXxA@mail.gmail.com>
 <54BC5679.7040807@snarc.org>
 <CAKFCL4X09Fqi_vapNnWWiHT3k-E4RWaM=RWFu3MX=gEQJFapog@mail.gmail.com>
 <CALya092JZr3mMmdjY6mm76weqp98iNCgorcdOQY1L0pxHTNtFQ@mail.gmail.com>
 <877fwjgejr.fsf@gnu.org>
Message-ID: <CAKFCL4VW7b57JuqwyXuuMR48sz8+tjE8rXkEEVgRemQwtqwU3w@mail.gmail.com>

On Mon, Jan 19, 2015 at 7:06 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> The reason I wouldn't be happy is that the effects of a "broken" package
> (especially the more popular it becomes) can't be contained easily. The
>

I wonder if Hackage can be extended to support an out-of-band "broken" flag
that can be applied to such packages, and cabal-install then refuse to use
those packages (possibly with an option to override).

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150119/c89264dd/attachment.html>

From carter.schonwald at gmail.com  Mon Jan 19 17:53:07 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 19 Jan 2015 12:53:07 -0500
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <CAKFCL4VW7b57JuqwyXuuMR48sz8+tjE8rXkEEVgRemQwtqwU3w@mail.gmail.com>
References: <54BBF3DA.9040700@mail.ru> <54BC3C3B.8060909@snarc.org>
 <CAMgWh9t0mwtvin1x5E5g5BFPm5efPFHjNF6+zXaw4fNqtHKXxA@mail.gmail.com>
 <54BC5679.7040807@snarc.org>
 <CAKFCL4X09Fqi_vapNnWWiHT3k-E4RWaM=RWFu3MX=gEQJFapog@mail.gmail.com>
 <CALya092JZr3mMmdjY6mm76weqp98iNCgorcdOQY1L0pxHTNtFQ@mail.gmail.com>
 <877fwjgejr.fsf@gnu.org>
 <CAKFCL4VW7b57JuqwyXuuMR48sz8+tjE8rXkEEVgRemQwtqwU3w@mail.gmail.com>
Message-ID: <CAHYVw0wNy38kJcD29U=xxjao9VnwzH=Q7fe4jFZqixUt9k2wwQ@mail.gmail.com>

I for one am immensely grateful for Herberts awesome work, and appreciate
it immensely and support it emphatically. (and I do a bit of similar work
in miniature as well as a hackage trustee). I dont think people realize how
many breakages/old issues have been resolved via the hard work of the
various hackage trustees. hackage trustee's doing their jobs well results
in a huge reduction in build problems by end users.

On Mon, Jan 19, 2015 at 9:59 AM, Brandon Allbery <allbery.b at gmail.com>
wrote:

> On Mon, Jan 19, 2015 at 7:06 AM, Herbert Valerio Riedel <hvr at gnu.org>
> wrote:
>
>> The reason I wouldn't be happy is that the effects of a "broken" package
>> (especially the more popular it becomes) can't be contained easily. The
>>
>
> I wonder if Hackage can be extended to support an out-of-band "broken"
> flag that can be applied to such packages, and cabal-install then refuse to
> use those packages (possibly with an option to override).
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150119/e3c3bc27/attachment.html>

From gabriel439 at gmail.com  Mon Jan 19 21:35:13 2015
From: gabriel439 at gmail.com (Gabriel Gonzalez)
Date: Mon, 19 Jan 2015 13:35:13 -0800
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <87vbk3goia.fsf@gnu.org>
References: <54BBF3DA.9040700@mail.ru> <87vbk3goia.fsf@gnu.org>
Message-ID: <54BD7891.9080505@gmail.com>

I just want to say that I appreciate your work.  You're a hero for doing 
this very thankless but very beneficial work.

On 01/19/2015 12:31 AM, Herbert Valerio Riedel wrote:
> On 2015-01-18 at 18:56:42 +0100, kyra wrote:
>> It looks old (and even ancient) versions of many packages gets
>> uploaded to hackage over and over again in ever increasing
>> amounts. The username of uploader for vast majority of these uploads
>> is HerbertValerioRiedel.
> That would be me...
>
> Just to clarify: I those aren't re-uploads of existing package versions,
> but rather meta-data revisions. The actual source-code is *not* touched,
> (and Hackage is very restricting in what's allowed to be changed in a
> .cabal file)
>
> This is also mentioned on http://hackage.haskell.org/packages/trustees/
>
>> While this is harmless I wonder what idea stands behind this?
> The idea, as others in this thread have already pointed out, is to add
> missing lower/upper package bounds to packages so that the Cabal
> install-plan solver can fulfill its task.
>
> Over the last week, I've been analyzing the current situation (motivated
> by the upcoming GHC 7.10 release which trips up quite a few packages
> with missing bounds on base/deepseq/time), and trying to come up with
> some tooling[1] to help the otherwise IMO rather unmanageable job of a
> Hackage trustee, as well as surgically fixing up the meta-data where I
> had empirical proof that the .cabal meta-data was incorrect (and thus
> leading the solver to select a broken install-plan).
>
> Here's a very simple buildreport for illustration:
>
>   https://ghc.haskell.org/~hvr/buildreports/pretty.html
>
> The purpose of my meta-data edits were/are (in order of decreasing
> priority):
>
>   1. First and foremost, no currently working/valid install-plan was lost.
>
>   2. A simple constraint-less `cabal install pretty` ought to result
>      *either* in a valid install-plan, *or* cabal failing to find any
>      install-plan.
>
>   3. An major-version constraint `cabal install 'pretty == a.b.*'` ought
>      to result *either* in a valid install-plan, *or* cabal failing to find
>      any install-plan.
>
>   4. A package shall not cause indirect *build*-failures of other
>      packages directly or indirectly depending on this package[3]
>
> The build-report linked helps directly with 2. and 3. as it shows that
> `pretty` failed to `cabal install pretty` (as well as `cabal install
> 'pretty == 1.1.*'`) for GHC 7.0 and GHC 7.2.  Case 4. could be detected
> by running the buildtool on many Hackage packages depending on `pretty`,
> and look for failures to build `pretty` during the `cabal install --dep`
> step (which would result in a "FAIL (deps)" cells).
>
>
> I've encountered a couple of situations, where fixing the meta-data of
> an important package low in the dependency graph fixed a couple of other
> packages depending on that package. However, this also means that the
> more popular a package is, the higher its responsibility is to make sure
> its build-depend meta-data is correct, as such packages have the
> potential to instantly break large branches of Hackage:
>
> One example for that was the release of deepseq-1.4, which changes the
> default-implementation of `rnf` which a few packages relied on, but the
> rather important `text` package was among of those. This affected most
> of the released ~50 `text` package versions, and since `deepseq` is
> compatible with all GHC 7.* versions, as soon an install-plan was
> selected which included `deepseq-1.4` with a non-latest version of
> `text` the build would fail. And since it's not uncommon to restrict the
> upper bound of `text`[2], all those packages depending on a non-latest
> `text` would have broken install-plans (unless `deepseq < 1.4` was
> selected).
>
> I hope this answers your question.
>
> Cheers,
>    hvr
>
>
>   [1]: https://github.com/hvr/hackage-matrix-builder
>
>        (WIP example reports can be seen in
>
>         https://ghc.haskell.org/~hvr/buildreports/0INDEX.html)
>
>
>   [2]: http://packdeps.haskellers.com/reverse/text
>
>   [3]: This can happen due to additional package-version constraints
>        causing other (but broken) configurations to be selected by the
>        solver not detected in case 2. and 3.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries


From ekmett at gmail.com  Mon Jan 19 22:07:45 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 19 Jan 2015 17:07:45 -0500
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <CAKFCL4VW7b57JuqwyXuuMR48sz8+tjE8rXkEEVgRemQwtqwU3w@mail.gmail.com>
References: <54BBF3DA.9040700@mail.ru> <54BC3C3B.8060909@snarc.org>
 <CAMgWh9t0mwtvin1x5E5g5BFPm5efPFHjNF6+zXaw4fNqtHKXxA@mail.gmail.com>
 <54BC5679.7040807@snarc.org>
 <CAKFCL4X09Fqi_vapNnWWiHT3k-E4RWaM=RWFu3MX=gEQJFapog@mail.gmail.com>
 <CALya092JZr3mMmdjY6mm76weqp98iNCgorcdOQY1L0pxHTNtFQ@mail.gmail.com>
 <877fwjgejr.fsf@gnu.org>
 <CAKFCL4VW7b57JuqwyXuuMR48sz8+tjE8rXkEEVgRemQwtqwU3w@mail.gmail.com>
Message-ID: <CAJumaK-edwaQ_4q8J0h1FW0cNLuwxoEJ5naQqJgvfiVhv=5_Ww@mail.gmail.com>

We have a deprecation flag on hackage now, it just doesn't do anything at
last check.

On Mon, Jan 19, 2015 at 9:59 AM, Brandon Allbery <allbery.b at gmail.com>
wrote:

> On Mon, Jan 19, 2015 at 7:06 AM, Herbert Valerio Riedel <hvr at gnu.org>
> wrote:
>
>> The reason I wouldn't be happy is that the effects of a "broken" package
>> (especially the more popular it becomes) can't be contained easily. The
>>
>
> I wonder if Hackage can be extended to support an out-of-band "broken"
> flag that can be applied to such packages, and cabal-install then refuse to
> use those packages (possibly with an option to override).
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150119/0c750fac/attachment.html>

From allbery.b at gmail.com  Mon Jan 19 22:34:04 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 19 Jan 2015 17:34:04 -0500
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <CAJumaK-edwaQ_4q8J0h1FW0cNLuwxoEJ5naQqJgvfiVhv=5_Ww@mail.gmail.com>
References: <54BBF3DA.9040700@mail.ru> <54BC3C3B.8060909@snarc.org>
 <CAMgWh9t0mwtvin1x5E5g5BFPm5efPFHjNF6+zXaw4fNqtHKXxA@mail.gmail.com>
 <54BC5679.7040807@snarc.org>
 <CAKFCL4X09Fqi_vapNnWWiHT3k-E4RWaM=RWFu3MX=gEQJFapog@mail.gmail.com>
 <CALya092JZr3mMmdjY6mm76weqp98iNCgorcdOQY1L0pxHTNtFQ@mail.gmail.com>
 <877fwjgejr.fsf@gnu.org>
 <CAKFCL4VW7b57JuqwyXuuMR48sz8+tjE8rXkEEVgRemQwtqwU3w@mail.gmail.com>
 <CAJumaK-edwaQ_4q8J0h1FW0cNLuwxoEJ5naQqJgvfiVhv=5_Ww@mail.gmail.com>
Message-ID: <CAKFCL4XhADnBn-sV_J_4ftU=0jQoiTc7sFD_JNSMLXhU8EpYKg@mail.gmail.com>

On Mon, Jan 19, 2015 at 5:07 PM, Edward Kmett <ekmett at gmail.com> wrote:

> We have a deprecation flag on hackage now, it just doesn't do anything at
> last check.


Which is exactly why I specified that it needs to be something that cabal
honors by default.

As a sysadmin, I'd actually prefer the flag to overwriting packages --- but
I find the Haskell community usually goes in other directions than what
makes sense to me from the standpoint of stability vs. usability vs.
flexibility. And given that the deprecation flag was added as more or less
documentation, I don't really expect that a proper disable option will be
added....

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150119/a0989bd6/attachment-0001.html>

From greg at gregweber.info  Tue Jan 20 03:03:10 2015
From: greg at gregweber.info (Greg Weber)
Date: Mon, 19 Jan 2015 19:03:10 -0800
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <87iog3gi0h.fsf@gnu.org>
References: <54BBF3DA.9040700@mail.ru> <54BC3C3B.8060909@snarc.org>
 <87iog3gi0h.fsf@gnu.org>
Message-ID: <CAKRanNDPNNa2WH1WXX5Nrhjv+LpP=sxtffyvH-j7iR1na602uA@mail.gmail.com>

On Mon, Jan 19, 2015 at 2:51 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> Just to clarify: the source tarball are *never* modified to specifically
> make sure hashes don't randomly change (which would trip all sorts of
> warnings for distribution packagers). In fact, there's also a
> `cabal get` option if you want to unpack with the original unaltered .cabal
> file:
>
>     --pristine    Unpack the original pristine tarball,
>                   rather than updating the .cabal file
>                   with the latest revision from the
>                   package archive.
>

Why is this option needed if the tarball is never modified?
This documentation states that cabal modifies the cabal file on the local
system.

We all appreciate Herbert's efforts. The problem is the tools he is working
with are limited.
The local cabal should operate the same way as hackage: always keeping the
meta-data separate.

Please correct me if I am mis-representing the situation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150119/7b6917c1/attachment.html>

From the.dead.shall.rise at gmail.com  Tue Jan 20 07:06:08 2015
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Tue, 20 Jan 2015 08:06:08 +0100
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <CAKRanNDPNNa2WH1WXX5Nrhjv+LpP=sxtffyvH-j7iR1na602uA@mail.gmail.com>
References: <54BBF3DA.9040700@mail.ru> <54BC3C3B.8060909@snarc.org>
 <87iog3gi0h.fsf@gnu.org>
 <CAKRanNDPNNa2WH1WXX5Nrhjv+LpP=sxtffyvH-j7iR1na602uA@mail.gmail.com>
Message-ID: <CA+tcxkBnKUw=TxetyquDP=FZf1RMGrgco642s9cdnk6dBZhd=w@mail.gmail.com>

Hi,

On 20 January 2015 at 04:03, Greg Weber <greg at gregweber.info> wrote:
>>     --pristine    Unpack the original pristine tarball,
>>                   rather than updating the .cabal file
>>                   with the latest revision from the
>>                   package archive.
>
>
> Why is this option needed if the tarball is never modified?
> This documentation states that cabal modifies the cabal file on the local
> system.

By default, `cabal unpack` replaces the .cabal file in the unpacked
tarball with the one from the index. With '--pristine' it doesn't do
that.

From duncan.coutts at googlemail.com  Tue Jan 20 11:47:35 2015
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Tue, 20 Jan 2015 11:47:35 +0000
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <54BBF3DA.9040700@mail.ru>
References: <54BBF3DA.9040700@mail.ru>
Message-ID: <1421754455.15800.20.camel@dunky.localdomain>

On Sun, 2015-01-18 at 20:56 +0300, kyra wrote:
> Hi, guys,
> 
> It looks old (and even ancient) versions of many packages gets uploaded 
> to hackage over and over again in ever increasing amounts. The username 
> of uploader for vast majority of these uploads is HerbertValerioRiedel.

BTW, where do you see these changes? I thought we had fixed the "latest
uploads" page and rss to only show real uploads, and not edits to
metadata.

Not that we want to hide the edits, they need to be visible, but we
shouldn't be confusing them with new package uploads in the UI anywhere.

Duncan


From duncan.coutts at googlemail.com  Tue Jan 20 12:00:34 2015
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Tue, 20 Jan 2015 12:00:34 +0000
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <54BC3C3B.8060909@snarc.org>
References: <54BBF3DA.9040700@mail.ru> <54BC3C3B.8060909@snarc.org>
Message-ID: <1421755234.15800.27.camel@dunky.localdomain>

On Sun, 2015-01-18 at 15:05 -0800, Vincent Hanquez wrote:
> On 18/01/2015 09:56, kyra wrote:
> > Hi, guys,
> >
> > It looks old (and even ancient) versions of many packages gets 
> > uploaded to hackage over and over again in ever increasing amounts. 
> > The username of uploader for vast majority of these uploads is 
> > HerbertValerioRiedel.
> >
> > While this is harmless I wonder what idea stands behind this?

> This is not harmless. This is a security issue by itself, as now 
> packages get changes transparently given a url, you might have a 
> different package one day, which trigger hash check failure. or signed 
> tag verification failure.

Note that hackage never changes the content of package tarballs. The
checksums on those are stable. Guaranteed.

> This has also the effect of not changing the bounds in the repository, 
> so for example, next time you upload a tweak'ed packages, you 
> effectively revert the change done on hackage only.

Communicating changes upstream is certainly something we need to work on
to be able to use this as widely as it'd be helpful.

Up until recently we've only used the metadata editing feature with core
packages (or the maintainers themselves have done it). Recently Herbert
has been going a bit wider and if we are now running into issues of
communication with maintainers then I think this says that now is the
time to address that properly.

So that includes:
      * this discussion
      * wider communication with maintainers of just what is and is not
        possible (since we're actually deliberately rather conservative)
      * a proper notification and opt-in/opt-out system for maintainers
        to avail themselves of the helpful service that the trustees can
        provide.

Duncan


From kyrab at mail.ru  Tue Jan 20 13:26:02 2015
From: kyrab at mail.ru (kyra)
Date: Tue, 20 Jan 2015 16:26:02 +0300
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <1421754455.15800.20.camel@dunky.localdomain>
References: <54BBF3DA.9040700@mail.ru>
 <1421754455.15800.20.camel@dunky.localdomain>
Message-ID: <54BE576A.60405@mail.ru>

On 20.01.2015 14:47, Duncan Coutts wrote:
> On Sun, 2015-01-18 at 20:56 +0300, kyra wrote:
>> Hi, guys,
>>
>> It looks old (and even ancient) versions of many packages gets uploaded
>> to hackage over and over again in ever increasing amounts. The username
>> of uploader for vast majority of these uploads is HerbertValerioRiedel.
> BTW, where do you see these changes? I thought we had fixed the "latest
> uploads" page and rss to only show real uploads, and not edits to
> metadata.
>
> Not that we want to hide the edits, they need to be visible, but we
> shouldn't be confusing them with new package uploads in the UI anywhere.
>
> Duncan
>
> .
>
I've wrote a small program producing old-hackage-log-like-file from 
hackage index file ("Recent additions" page is too short).

Regads,
Kyra


From duncan.coutts at googlemail.com  Tue Jan 20 16:39:10 2015
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Tue, 20 Jan 2015 16:39:10 +0000
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <54BC5679.7040807@snarc.org>
References: <54BBF3DA.9040700@mail.ru>	<54BC3C3B.8060909@snarc.org>
 <CAMgWh9t0mwtvin1x5E5g5BFPm5efPFHjNF6+zXaw4fNqtHKXxA@mail.gmail.com>
 <54BC5679.7040807@snarc.org>
Message-ID: <1421771950.15800.35.camel@dunky.localdomain>

On Sun, 2015-01-18 at 16:57 -0800, Vincent Hanquez wrote:
> On 18/01/2015 15:51, David Feuer wrote:
> >
> > It would be best to be sure to make the maintainer (if there is one) 
> > aware of such changes. That said, not every package has a responsive 
> > maintainer, and *someone* has to do this work, and do it promptly. A 
> > signed hash failure does not introduce a security hole, unless you 
> > count a sort of semi-manual, avoidable denial of service.
> >
> Not sure how you got "security hole" from what I said, but a failing 
> hash or signature, means that the build system breaks while cabal 
> install stuff and that I have to manually inspect what the change is. If 
> you can't pin down a special tarball when doing a download (i.e. it can 
> changes under your feet, one day to the other), then it's an issue.
> 
> Lots of people would be *horrified* to download some 
> {c,c++,python,ruby,...} library-a.b.c.tar.gz and found anything changed 
> inside without changing the exact name for it.

Indeed they would be horrified and quite rightly so.

Fear not, we're not completely nuts. We have been working with packaging
with distros and cabal/hackage for some years now :-)

Hackage has always followed the rule that package tarballs never change.
Distros must be able to rely on this. I used to work on gentoo packaging
and that was one of their big issues. Some annoying upstream
distributors would have a policy of changing their tarballs and that
would just force all downstream distributors to make their own snapshots
and mirrors. All very annoying. So, no, that's why hackage has always
and will always provide immutable package tarballs.

The metadata editing works by keeping the metadata separate from the
tarballs.

As for security, Austin and I are currently working on an improvement
for the IHG. We're following the approach of server-based index signing,
which will also rely on those stable tarball checksums.

Duncan


From duncan.coutts at googlemail.com  Tue Jan 20 16:43:24 2015
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Tue, 20 Jan 2015 16:43:24 +0000
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <CAKFCL4VW7b57JuqwyXuuMR48sz8+tjE8rXkEEVgRemQwtqwU3w@mail.gmail.com>
References: <54BBF3DA.9040700@mail.ru> <54BC3C3B.8060909@snarc.org>
 <CAMgWh9t0mwtvin1x5E5g5BFPm5efPFHjNF6+zXaw4fNqtHKXxA@mail.gmail.com>
 <54BC5679.7040807@snarc.org>
 <CAKFCL4X09Fqi_vapNnWWiHT3k-E4RWaM=RWFu3MX=gEQJFapog@mail.gmail.com>
 <CALya092JZr3mMmdjY6mm76weqp98iNCgorcdOQY1L0pxHTNtFQ@mail.gmail.com>
 <877fwjgejr.fsf@gnu.org>
 <CAKFCL4VW7b57JuqwyXuuMR48sz8+tjE8rXkEEVgRemQwtqwU3w@mail.gmail.com>
Message-ID: <1421772204.15800.39.camel@dunky.localdomain>

On Mon, 2015-01-19 at 09:59 -0500, Brandon Allbery wrote:
> On Mon, Jan 19, 2015 at 7:06 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:
> 
> > The reason I wouldn't be happy is that the effects of a "broken" package
> > (especially the more popular it becomes) can't be contained easily. The
> >
> 
> I wonder if Hackage can be extended to support an out-of-band "broken" flag
> that can be applied to such packages, and cabal-install then refuse to use
> those packages (possibly with an option to override).

This can be achieved by editing the .cabal file, and Herbert has done so
in at least one case. It's just a matter of making the constraints
impossible, e.g. base > 1 && < 1. It could possibly be done more
obviously or directly, e.g. adding a dep on something impossible (though
note that we don't currently allow adding deps).

Deprecation is orthogonal I'd say. People may need to rely on deprecated
packages while they migrate away.

Duncan


From duncan.coutts at googlemail.com  Tue Jan 20 16:52:36 2015
From: duncan.coutts at googlemail.com (Duncan Coutts)
Date: Tue, 20 Jan 2015 16:52:36 +0000
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <54BC96A4.4010208@snarc.org>
References: <54BBF3DA.9040700@mail.ru> <54BC3C3B.8060909@snarc.org>
 <54BC86DF.9000901@ro-che.info> <54BC96A4.4010208@snarc.org>
Message-ID: <1421772756.15800.47.camel@dunky.localdomain>

On Sun, 2015-01-18 at 21:31 -0800, Vincent Hanquez wrote:
> On 18/01/2015 20:23, Roman Cheplyaka wrote:
> > On 19/01/15 01:05, Vincent Hanquez wrote:
> >> This is not harmless. This is a security issue by itself, as now
> >> packages get changes transparently given a url, you might have a
> >> different package one day, which trigger hash check failure. or signed
> >> tag verification failure.
> > Correct me if I'm wrong, but editing version bounds on hackage doesn't
> > actually affect the tarball (and its checksum). The modified cabal file
> > is downloaded separately as part of the index.

> yes, that's right. I meant to say that what you're downloading through 
> cabal get
> tweaked by cabal, but the end result is pretty much the same

> > Not saying it doesn't introduce its own problems, but the hash check
> > should continue to pass.
> of the tarball yes, not of your compilation tree, and maybe not the 
> resulting binary.

So we have thought about it a bit when designing this feature and we
don't think that is correct.

If you freeze your solution (e.g. with cabal freeze) then changes to the
metadata should have no effect on compilation. We're pretty restrictive
about what changes are allowed and we don't think there's anything that
can cause changes except for the versions of deps picked (and hence if
you freeze then nothing).

Apart from version constraints we pretty much only allow tweaks to
metadata like description, maintainer email etc.

If you don't freeze then currently you have no guarantee that you'll not
get different solutions each time you "cabal update" to a new hackage
snapshot (or indeed installing things can change what solutions you get
since we prefer already installed instances).

One caveat is that it's possible to accidentally constrain deps and make
an existing working solution impossible. This could make a frozen
solution no longer build, which is annoying but doesn't make a broken
binary. If this proves to be a real issue then we can deal with it
(simply ignore constraints for frozen solutions).

Duncan


From hvr at gnu.org  Tue Jan 20 17:22:47 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 20 Jan 2015 18:22:47 +0100
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <1421772204.15800.39.camel@dunky.localdomain> (Duncan Coutts's
 message of "Tue, 20 Jan 2015 16:43:24 +0000")
References: <54BBF3DA.9040700@mail.ru> <54BC3C3B.8060909@snarc.org>
 <CAMgWh9t0mwtvin1x5E5g5BFPm5efPFHjNF6+zXaw4fNqtHKXxA@mail.gmail.com>
 <54BC5679.7040807@snarc.org>
 <CAKFCL4X09Fqi_vapNnWWiHT3k-E4RWaM=RWFu3MX=gEQJFapog@mail.gmail.com>
 <CALya092JZr3mMmdjY6mm76weqp98iNCgorcdOQY1L0pxHTNtFQ@mail.gmail.com>
 <877fwjgejr.fsf@gnu.org>
 <CAKFCL4VW7b57JuqwyXuuMR48sz8+tjE8rXkEEVgRemQwtqwU3w@mail.gmail.com>
 <1421772204.15800.39.camel@dunky.localdomain>
Message-ID: <87d269gye0.fsf@gnu.org>

On 2015-01-20 at 17:43:24 +0100, Duncan Coutts wrote:

[...]

> This can be achieved by editing the .cabal file, and Herbert has done so
> in at least one case. It's just a matter of making the constraints
> impossible, e.g. base > 1 && < 1. It could possibly be done more
> obviously or directly, e.g. adding a dep on something impossible (though
> note that we don't currently allow adding deps).

Fwiw, I've converged to using the following construct to blacklist a
package version:

  library
    -- [reason why this package version had to be blacklisted]
    build-depends: base<0
   
    [...rest of content...]


IMHO this is somewhat obvious than any other unsatisfiable constructs

Cheers,
  hvr

From magnus at therning.org  Tue Jan 20 21:37:48 2015
From: magnus at therning.org (Magnus Therning)
Date: Tue, 20 Jan 2015 22:37:48 +0100
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <87d269gye0.fsf@gnu.org>
References: <54BBF3DA.9040700@mail.ru> <54BC3C3B.8060909@snarc.org>
 <CAMgWh9t0mwtvin1x5E5g5BFPm5efPFHjNF6+zXaw4fNqtHKXxA@mail.gmail.com>
 <54BC5679.7040807@snarc.org>
 <CAKFCL4X09Fqi_vapNnWWiHT3k-E4RWaM=RWFu3MX=gEQJFapog@mail.gmail.com>
 <CALya092JZr3mMmdjY6mm76weqp98iNCgorcdOQY1L0pxHTNtFQ@mail.gmail.com>
 <877fwjgejr.fsf@gnu.org>
 <CAKFCL4VW7b57JuqwyXuuMR48sz8+tjE8rXkEEVgRemQwtqwU3w@mail.gmail.com>
 <1421772204.15800.39.camel@dunky.localdomain>
 <87d269gye0.fsf@gnu.org>
Message-ID: <20150120213748.GA19412@tatooine>

On Tue, Jan 20, 2015 at 06:22:47PM +0100, Herbert Valerio Riedel wrote:
> On 2015-01-20 at 17:43:24 +0100, Duncan Coutts wrote:
> 
> [...]
> 
> > This can be achieved by editing the .cabal file, and Herbert has done so
> > in at least one case. It's just a matter of making the constraints
> > impossible, e.g. base > 1 && < 1. It could possibly be done more
> > obviously or directly, e.g. adding a dep on something impossible (though
> > note that we don't currently allow adding deps).
> 
> Fwiw, I've converged to using the following construct to blacklist a
> package version:
> 
>   library
>     -- [reason why this package version had to be blacklisted]
>     build-depends: base<0
>    
>     [...rest of content...]
> 
> 
> IMHO this is somewhat obvious than any other unsatisfiable constructs

Indeed, that is a much better way to signal
blacklisting/deprecation/etc.  I first found the
unsatisfiable-dependencies solution in the random package.  It was
only due to being able to find a bug mentioning that the version in
question should be deprecated that I realised it was done on purpose.

/M

-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4 
email: magnus at therning.org   jabber: magnus at therning.org
twitter: magthe               http://therning.org/magnus

Code as if whoever maintains your program is a violent psychopath who knows
where you live.
     -- Anonymous
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150120/1bd98362/attachment.sig>

From kyrab at mail.ru  Tue Jan 20 21:58:29 2015
From: kyrab at mail.ru (kyra)
Date: Wed, 21 Jan 2015 00:58:29 +0300
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <54BE576A.60405@mail.ru>
References: <54BBF3DA.9040700@mail.ru>
 <1421754455.15800.20.camel@dunky.localdomain> <54BE576A.60405@mail.ru>
Message-ID: <54BECF85.1010503@mail.ru>

On 20.01.2015 16:26, kyra wrote:
> I've wrote a small program producing old-hackage-log-like-file from 
> hackage index file ("Recent additions" page is too short).
s/wrote/written

Sorry

From hvr at gnu.org  Wed Jan 21 10:24:36 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 21 Jan 2015 11:24:36 +0100
Subject: Hackage is flooded with old package versions reuploads
In-Reply-To: <54BC522D.7040406@snarc.org> (Vincent Hanquez's message of "Sun, 
 18 Jan 2015 16:39:09 -0800")
References: <54BBF3DA.9040700@mail.ru> <54BC3C3B.8060909@snarc.org>
 <CAJumaK9GoFP=0N8oED0fGsmoRKOd8Em+be7HyEfeN-rh+ub7aw@mail.gmail.com>
 <54BC522D.7040406@snarc.org>
Message-ID: <87r3uov3bv.fsf@gmail.com>

Hello Vincent,

On 2015-01-19 at 01:39:09 +0100, Vincent Hanquez wrote:

[...]

>> To my knowledge, the few cases where Herbert has actively done a
>> patch to the .cabal file like this without author communication is
>> because the package is in very very widespread use and the author
>> has been incommunicado for many months. As I recall, Max Bolingbroke
>> has a some packages that fit this bill.

> A simple counter example, that I noticed after the fact [1]

That was more of an oversight of mine as I got blocked on entropy being
broken[2] which transitively broke several of your packages for GHC
7.0/7.2 users (and this got fixed yesterday).  I usually did inform
upstreams in the cases I had to edit the meta-data (sometimes before,
and sometimes after the fact). 

However, now that entropy got fixed and I got a clearer picture of which
failures have to be fixed in your packages, I've filed a couple of
tickets[3] against your packages to record what actions are needed to
restore some install-plans.

Moreover, as already stated elsewhere in this thread, an email
notification system is in the works to automate informing upstreams to
some extent.[4]

Does this procedure meet your expectations better?

[...]

Cheers,
  hvr

 [2] https://github.com/TomMD/entropy/issues/23#issuecomment-70705615

 [3]: https://github.com/vincenthz/hs-tls/issues/99
      https://github.com/vincenthz/hs-certificate/issues/42
      https://github.com/vincenthz/hs-cprng-aes/issues/10
      https://github.com/vincenthz/hs-crypto-numbers/issues/16
      https://github.com/vincenthz/hs-crypto-pubkey/issues/19
      https://github.com/vincenthz/hs-cryptohash/issues/33
      https://github.com/vincenthz/hs-hourglass/issues/15

 [4]  https://github.com/haskell/hackage-server/issues/230

From lemming at henning-thielemann.de  Wed Jan 21 17:36:03 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed, 21 Jan 2015 18:36:03 +0100 (CET)
Subject: locale: decimal comma vs. point
Message-ID: <alpine.DEB.2.02.1501211829490.6473@sputnik>


If I export a label track from Audacity the time stamps are formatted with 
decimal commas instead of decimal points. E.g. 1.5s is formatted as "1,5" 
not "1.5". I guess this is because I have German locale as default. I want 
to write numbers from Haskell compatible to this format and thus I want to 
know whether I have to format numbers with decimal commas or decimal 
points. However an according information or even better, a locale-aware 
printf seems to be missing in old-locale. :-(

From emertens at gmail.com  Thu Jan 22 21:40:23 2015
From: emertens at gmail.com (Eric Mertens)
Date: Thu, 22 Jan 2015 13:40:23 -0800
Subject: removing constraints
In-Reply-To: <20150119100849.GA3477@city.ac.uk>
References: <20150109152529.GA5022@city.ac.uk>
 <CAMgWh9ta6vagu877Skqh+7581tc1_pc8juLG3Bhm7UeHGb=+VQ@mail.gmail.com>
 <20150119100849.GA3477@city.ac.uk>
Message-ID: <CALya090Rpked2ez5yv9n06Y7oz-hGdUVVNBANJ9eQ99PyTMtKQ@mail.gmail.com>

Hello,

The Core Libraries Committee was asked to discuss the question of removing
the unused Ix constraints from various classes and instances in the array
package.

We came to the consensus that the unused Ix constraint should be removed
from both the instances declarations and class method for reasons outlined
below.



For the constraints pertaining to top-level definitions and instance
declarations we agreed that the constraints should accurately reflect the
state of the code and that if in the future the constraint became necessary
again that it should be added.

The question about the class methods IArray.bounds and MArray.getBounds is
more interesting because these methods define open interfaces that external
instance might (now or in the future) depend on. In this particular case it
doesn't seem that the design of the Ix class could offer any interesting
methods that would be necessary to an instance of this class. Any such
instance would need to store the bounds alongside the array in some
fashion, and the Ix methods all have arguments requiring a pair of bounds.
Therefore we agreed that the constraint should be removed.

Regards,
Eric Mertens
Core Libraries Committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150122/a4d7d479/attachment.html>

From peter at activebilling.com.au  Sun Jan 25 23:29:54 2015
From: peter at activebilling.com.au (Peter Sumskas)
Date: Mon, 26 Jan 2015 10:29:54 +1100
Subject: Problem using Text.Regex on OS X.
Message-ID: <CAM1QNnB7VkcAHu7_xRN=7DAbQ47wFqMEwf4Rm8BchXZcS_TtuA@mail.gmail.com>

Hi,

I'm new to Haskell so I'm not sure how to solve this issue, yet. I was
directed to this list from the IRC channel.

Here's the issue:

Using GHCi on OS X:

Prelude Data.Text> :m Text.Regex
Prelude Text.Regex> let r = mkRegex "_"
... eliding successful "Loading package ..." lines ...
Loading package regex-compat-0.95.1 ... can't load .so/.DLL for:
/Library/Haskell/ghc-7.8.3-x86_64/lib/regex-compat-0.95.1/libHSregex-compat-0.95.1-ghc7.8.3.dylib
(dlopen(/Library/Haskell/ghc-7.8.3-x86_64/lib/regex-compat-0.95.1/libHSregex-compat-0.95.1-ghc7.8.3.dylib,
9): Library not loaded: @rpath/libHSmtl-2.1.3.1-ghc7.8.3.dylib
  Referenced from:
/Library/Haskell/ghc-7.8.3-x86_64/lib/regex-compat-0.95.1/libHSregex-compat-0.95.1-ghc7.8.3.dylib
  Reason: image not found)

After running otool over the regex-compat dylib I can see lines like:

...
Load command 24
          cmd LC_RPATH
      cmdsize 80
         path
/Users/mark/Projects/hp/build/package/mtl-2.1.3.1/build/dist/build (offset
12)
...

Which is not a path that is relevant to my installation. It was suggested
that this may be an error in the way packages are being built for OS X.

Whatever the cause, I'm bringing it to the attention of this list in order
to gain information on what course to take in addressing this issue.

Thanks for your help.

Kind regards,

Peter Sumskas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150126/608ed215/attachment.html>

From carter.schonwald at gmail.com  Mon Jan 26 01:52:38 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 25 Jan 2015 20:52:38 -0500
Subject: Problem using Text.Regex on OS X.
In-Reply-To: <CAM1QNnB7VkcAHu7_xRN=7DAbQ47wFqMEwf4Rm8BchXZcS_TtuA@mail.gmail.com>
References: <CAM1QNnB7VkcAHu7_xRN=7DAbQ47wFqMEwf4Rm8BchXZcS_TtuA@mail.gmail.com>
Message-ID: <CAHYVw0xaRWt0E=eURWUkv25wwWe7zP4c60BL2o_PdC8XQTNS=Q@mail.gmail.com>

What GHC installer on OSX did you use? i think we generally recommend
https://ghcformacosx.github.io/ these days


On Sun, Jan 25, 2015 at 6:29 PM, Peter Sumskas <peter at activebilling.com.au>
wrote:

> Hi,
>
> I'm new to Haskell so I'm not sure how to solve this issue, yet. I was
> directed to this list from the IRC channel.
>
> Here's the issue:
>
> Using GHCi on OS X:
>
> Prelude Data.Text> :m Text.Regex
> Prelude Text.Regex> let r = mkRegex "_"
> ... eliding successful "Loading package ..." lines ...
> Loading package regex-compat-0.95.1 ... can't load .so/.DLL for:
> /Library/Haskell/ghc-7.8.3-x86_64/lib/regex-compat-0.95.1/libHSregex-compat-0.95.1-ghc7.8.3.dylib
> (dlopen(/Library/Haskell/ghc-7.8.3-x86_64/lib/regex-compat-0.95.1/libHSregex-compat-0.95.1-ghc7.8.3.dylib,
> 9): Library not loaded: @rpath/libHSmtl-2.1.3.1-ghc7.8.3.dylib
>   Referenced from:
> /Library/Haskell/ghc-7.8.3-x86_64/lib/regex-compat-0.95.1/libHSregex-compat-0.95.1-ghc7.8.3.dylib
>   Reason: image not found)
>
> After running otool over the regex-compat dylib I can see lines like:
>
> ...
> Load command 24
>           cmd LC_RPATH
>       cmdsize 80
>          path
> /Users/mark/Projects/hp/build/package/mtl-2.1.3.1/build/dist/build (offset
> 12)
> ...
>
> Which is not a path that is relevant to my installation. It was suggested
> that this may be an error in the way packages are being built for OS X.
>
> Whatever the cause, I'm bringing it to the attention of this list in order
> to gain information on what course to take in addressing this issue.
>
> Thanks for your help.
>
> Kind regards,
>
> Peter Sumskas.
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150125/a364220e/attachment.html>

From david.feuer at gmail.com  Mon Jan 26 03:07:43 2015
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 25 Jan 2015 22:07:43 -0500
Subject: NumberSieves status/maintenance
Message-ID: <CAMgWh9tLuaV38pfEPJz=XnPa0ekP1Z-7FdN4Vdrw-NN_GCu+2A@mail.gmail.com>

This package was last updated in 2012, and the linked darcs repository
is inaccessible. Do you intend to continue to maintain this package?
If not, I would be happy to take over.

Thanks,
David Feuer

From Lennart.Augustsson at sc.com  Tue Jan 27 10:32:51 2015
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Tue, 27 Jan 2015 10:32:51 +0000
Subject: Drastic Prelude changes imminent
Message-ID: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>

The next version (7.10) of GHC is slated to have a drastically changed Prelude.
This message is very late in the release process, but I would urge caution before changing.

The changes are (aptly) named the Burning Bridges Proposal (BBP).
Even though the work has been going on for a while, it seems that this
change is coming as a surprise to many people (including Simon Peyton
Jones).  In summary, it generalizes many list operation, e.g., foldr,
to be overloaded.

There is much to welcome in BBP, but changing the Prelude cannot be
done lightly since it really is like changing the language.
So I think it's really important for a large number of people to be able to
try out such changes before they come into effect, and to have time
to let the changes stabilize (you rarely get it right the first time).

I've discussed this with a number of people, including Simon PJ, and
we have concrete proposals.

Proposal 1:
*    Add a new pragma
        {-# LANGUAGE Prelude=AlternativePrelude #-}
      *   This is a new feature, but it is easy and low-risk to implement.
      *   Which Prelude you use really is a language choice; appropriate for a LANGUAGE pragma.
      *   Semantics is name-space only: import Prelude (); import AlternativePrelude
      *   No effect on desugaring or typing of built-in syntax (list comprehensions, do-notation etc).
*    Ship with both old and new prelude.
*    So now old and new behaviour are easy to achieve, in the module or in a .cabal file.
*    The question becomes "what is the default".

Proposal 2:
*    Make the default be the old rather than the new.
      *   Altering the default Prelude API should be done slowly, with lots of warning; because all users get it willy-nilly.
      *   Unlike AMP, the change is controversial (clearly).
      *   Easier to make changes to New Prelude if it isn't the default.

That's it.




Discussing the BBP proposal we also came up with a number of technical questions:

Q1
An alternative to Foldable would be
  class Enumerable t where
    toList :: t a -> [a]   -- Implementations should use 'build'
Is Foldable more general (or efficient) than a Enumerable class, plus fusion?

Consider a new data type X a.  I write
     foldX :: (a -> b -> b) -> b -> X a -> b
     foldX = ...lots of code...

     toList :: X a -> [a]  {-# INLINE toList #-}
     toList x = build (\c n. foldX c n x)

So now toList is small and easy to inline.  Every good list consumer of a call to toList will turn into a call to foldX, which is what we want.

Q2
What are the criteria for being in Foldable?
For instance, why are 'sum', 'product' in Foldable, but not 'and', 'or'?


Q3
What's the relationship of Foldable to GHC.Exts.IsList?
Which also has toList, fromList, and does work with ByteString.
*  For example, could we use IsList instead of Foldable?
    Specifically, Foldable does not use its potential power to apply the type constructor t to different arguments.  (Unlike Traversable which does.)
        foldr :: IsList l => (Item l->b->b) -> b -> l -> b


  -- Lennart

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

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx  for important information with respect to derivative products.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/6fee4a73/attachment.html>

From hesselink at gmail.com  Tue Jan 27 11:10:49 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 27 Jan 2015 12:10:49 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <CAPeieQG9ZR0rp7pD1u3bCPjFZg3q6veo-aihWueY17TObuw9TA@mail.gmail.com>

On Tue, Jan 27, 2015 at 11:32 AM, Augustsson, Lennart
<Lennart.Augustsson at sc.com> wrote:
> *    Add a new pragma
>         {-# LANGUAGE Prelude=AlternativePrelude #-}
>       *   Semantics is name-space only: import Prelude (); import
> AlternativePrelude

I don't have any opinion on the full proposal yet, but I usually use
"{-# LANGUAGE NoImplicitPrelude #-}" when using an alternate prelude.
Is there any different between that and "import Prelude ()"?

Erik

From Lennart.Augustsson at sc.com  Tue Jan 27 11:26:44 2015
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Tue, 27 Jan 2015 11:26:44 +0000
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAPeieQG9ZR0rp7pD1u3bCPjFZg3q6veo-aihWueY17TObuw9TA@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQG9ZR0rp7pD1u3bCPjFZg3q6veo-aihWueY17TObuw9TA@mail.gmail.com>
Message-ID: <22B950C955F8AB4196E72698FBD00002B940325D@UKWPIPXMB01A.zone1.scb.net>

That's very different since it changes how desugaring works.
With NoImplicitPrelude desugaring uses unqualified names.  It's a rather fragile pragma.

-----Original Message-----
From: Erik Hesselink [mailto:hesselink at gmail.com] 
Sent: 27 January 2015 11:11
To: Augustsson, Lennart
Cc: libraries at haskell.org
Subject: Re: Drastic Prelude changes imminent

On Tue, Jan 27, 2015 at 11:32 AM, Augustsson, Lennart <Lennart.Augustsson at sc.com> wrote:
> *    Add a new pragma
>         {-# LANGUAGE Prelude=AlternativePrelude #-}
>       *   Semantics is name-space only: import Prelude (); import
> AlternativePrelude

I don't have any opinion on the full proposal yet, but I usually use "{-# LANGUAGE NoImplicitPrelude #-}" when using an alternate prelude.
Is there any different between that and "import Prelude ()"?

Erik

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

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

From hesselink at gmail.com  Tue Jan 27 12:00:36 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 27 Jan 2015 13:00:36 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B940325D@UKWPIPXMB01A.zone1.scb.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQG9ZR0rp7pD1u3bCPjFZg3q6veo-aihWueY17TObuw9TA@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940325D@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <CAPeieQFg8KQurLO1fyShGgf=pqYTYkt_JZ0BWUdajcq050Fzxw@mail.gmail.com>

What does that mean exactly? It sounds a bit like RebindableSyntax,
but I don't see it working that way. With NoImplicitPrelude, I can
locally define things like 'fromInteger' or '>>', but they are not
used in desugaring numeric literals or do notation.

Erik

On Tue, Jan 27, 2015 at 12:26 PM, Augustsson, Lennart
<Lennart.Augustsson at sc.com> wrote:
> That's very different since it changes how desugaring works.
> With NoImplicitPrelude desugaring uses unqualified names.  It's a rather fragile pragma.
>
> -----Original Message-----
> From: Erik Hesselink [mailto:hesselink at gmail.com]
> Sent: 27 January 2015 11:11
> To: Augustsson, Lennart
> Cc: libraries at haskell.org
> Subject: Re: Drastic Prelude changes imminent
>
> On Tue, Jan 27, 2015 at 11:32 AM, Augustsson, Lennart <Lennart.Augustsson at sc.com> wrote:
>> *    Add a new pragma
>>         {-# LANGUAGE Prelude=AlternativePrelude #-}
>>       *   Semantics is name-space only: import Prelude (); import
>> AlternativePrelude
>
> I don't have any opinion on the full proposal yet, but I usually use "{-# LANGUAGE NoImplicitPrelude #-}" when using an alternate prelude.
> Is there any different between that and "import Prelude ()"?
>
> Erik
>
> 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 a 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.
>
> Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx  for important information with respect to derivative products.

From Lennart.Augustsson at sc.com  Tue Jan 27 15:23:58 2015
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Tue, 27 Jan 2015 15:23:58 +0000
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>

We've made a Wiki page with some relevant information, https://ghc.haskell.org/trac/ghc/wiki/BurningBridgesSlowly


From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Augustsson, Lennart
Sent: 27 January 2015 10:33
To: libraries at haskell.org
Subject: Drastic Prelude changes imminent

The next version (7.10) of GHC is slated to have a drastically changed Prelude.
This message is very late in the release process, but I would urge caution before changing.

The changes are (aptly) named the Burning Bridges Proposal (BBP).
Even though the work has been going on for a while, it seems that this
change is coming as a surprise to many people (including Simon Peyton
Jones).  In summary, it generalizes many list operation, e.g., foldr,
to be overloaded.

There is much to welcome in BBP, but changing the Prelude cannot be
done lightly since it really is like changing the language.
So I think it's really important for a large number of people to be able to
try out such changes before they come into effect, and to have time
to let the changes stabilize (you rarely get it right the first time).

I've discussed this with a number of people, including Simon PJ, and
we have concrete proposals.

Proposal 1:
*    Add a new pragma
        {-# LANGUAGE Prelude=AlternativePrelude #-}
      *   This is a new feature, but it is easy and low-risk to implement.
      *   Which Prelude you use really is a language choice; appropriate for a LANGUAGE pragma.
      *   Semantics is name-space only: import Prelude (); import AlternativePrelude
      *   No effect on desugaring or typing of built-in syntax (list comprehensions, do-notation etc).
*    Ship with both old and new prelude.
*    So now old and new behaviour are easy to achieve, in the module or in a .cabal file.
*    The question becomes "what is the default".

Proposal 2:
*    Make the default be the old rather than the new.
      *   Altering the default Prelude API should be done slowly, with lots of warning; because all users get it willy-nilly.
      *   Unlike AMP, the change is controversial (clearly).
      *   Easier to make changes to New Prelude if it isn't the default.

That's it.




Discussing the BBP proposal we also came up with a number of technical questions:

Q1
An alternative to Foldable would be
  class Enumerable t where
    toList :: t a -> [a]   -- Implementations should use 'build'
Is Foldable more general (or efficient) than a Enumerable class, plus fusion?

Consider a new data type X a.  I write
     foldX :: (a -> b -> b) -> b -> X a -> b
     foldX = ...lots of code...

     toList :: X a -> [a]  {-# INLINE toList #-}
     toList x = build (\c n. foldX c n x)

So now toList is small and easy to inline.  Every good list consumer of a call to toList will turn into a call to foldX, which is what we want.

Q2
What are the criteria for being in Foldable?
For instance, why are 'sum', 'product' in Foldable, but not 'and', 'or'?


Q3
What's the relationship of Foldable to GHC.Exts.IsList?
Which also has toList, fromList, and does work with ByteString.
*  For example, could we use IsList instead of Foldable?
    Specifically, Foldable does not use its potential power to apply the type constructor t to different arguments.  (Unlike Traversable which does.)
        foldr :: IsList l => (Item l->b->b) -> b -> l -> b


  -- Lennart

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

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

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

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx  for important information with respect to derivative products.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/86c5e1b3/attachment.html>

From johan.tibell at gmail.com  Tue Jan 27 16:03:13 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 27 Jan 2015 08:03:13 -0800
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>

Looking at the generalizations in Data.List I find them pretty odd now when
I think about it. I'd expect Data.List functions to be monomorphic to
lists, just like I expect functions in Data.Map to be monomorphic to maps.
Now there might be generalized versions of these functions in e.g. the
Prelude, but generalizing Data.List means that I don't even have the
monomorphic versions available if I want to resolve ambiguity by using
them*.

* It turns out resolving ambiguity is pretty annoying. The type signatures
are awkward to write so I end having to write something akin to

    mymap :: (a -> b) -> [a] -> [b]
    mymap = map
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/a2a6bb8d/attachment.html>

From hesselink at gmail.com  Tue Jan 27 16:07:00 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 27 Jan 2015 17:07:00 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
Message-ID: <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>

That doesn't really sound feasible, as there would be name clashes
when importing both the Prelude (with generalized functions) and
Data.List (with monomorphic functions). The only way to get
generalized functions and minimize breakage is to also generalize
Data.List.

Erik

On Tue, Jan 27, 2015 at 5:03 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
> Looking at the generalizations in Data.List I find them pretty odd now when
> I think about it. I'd expect Data.List functions to be monomorphic to lists,
> just like I expect functions in Data.Map to be monomorphic to maps. Now
> there might be generalized versions of these functions in e.g. the Prelude,
> but generalizing Data.List means that I don't even have the monomorphic
> versions available if I want to resolve ambiguity by using them*.
>
> * It turns out resolving ambiguity is pretty annoying. The type signatures
> are awkward to write so I end having to write something akin to
>
>     mymap :: (a -> b) -> [a] -> [b]
>     mymap = map
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

From Lennart.Augustsson at sc.com  Tue Jan 27 16:10:34 2015
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Tue, 27 Jan 2015 16:10:34 +0000
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
Message-ID: <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>

But having Data.List export a non-list version of foldr is a terrible idea.

-----Original Message-----
From: Erik Hesselink [mailto:hesselink at gmail.com] 
Sent: 27 January 2015 16:07
To: Johan Tibell
Cc: Augustsson, Lennart; libraries at haskell.org
Subject: Re: Drastic Prelude changes imminent

That doesn't really sound feasible, as there would be name clashes when importing both the Prelude (with generalized functions) and Data.List (with monomorphic functions). The only way to get generalized functions and minimize breakage is to also generalize Data.List.

Erik

On Tue, Jan 27, 2015 at 5:03 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
> Looking at the generalizations in Data.List I find them pretty odd now 
> when I think about it. I'd expect Data.List functions to be 
> monomorphic to lists, just like I expect functions in Data.Map to be 
> monomorphic to maps. Now there might be generalized versions of these 
> functions in e.g. the Prelude, but generalizing Data.List means that I 
> don't even have the monomorphic versions available if I want to resolve ambiguity by using them*.
>
> * It turns out resolving ambiguity is pretty annoying. The type 
> signatures are awkward to write so I end having to write something 
> akin to
>
>     mymap :: (a -> b) -> [a] -> [b]
>     mymap = map
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/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 a 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.

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

From hesselink at gmail.com  Tue Jan 27 16:15:06 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 27 Jan 2015 17:15:06 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>

I don't see why from your email, but my only point was that having
both polymorphic versions of functions in the Prelude, and monomorphic
ones in Data.List, will probably be worse than either of the other two
options (the fully polymorphic version being prepared, and the status
quo you want to keep).

Erik

On Tue, Jan 27, 2015 at 5:10 PM, Augustsson, Lennart
<Lennart.Augustsson at sc.com> wrote:
> But having Data.List export a non-list version of foldr is a terrible idea.
>
> -----Original Message-----
> From: Erik Hesselink [mailto:hesselink at gmail.com]
> Sent: 27 January 2015 16:07
> To: Johan Tibell
> Cc: Augustsson, Lennart; libraries at haskell.org
> Subject: Re: Drastic Prelude changes imminent
>
> That doesn't really sound feasible, as there would be name clashes when importing both the Prelude (with generalized functions) and Data.List (with monomorphic functions). The only way to get generalized functions and minimize breakage is to also generalize Data.List.
>
> Erik
>
> On Tue, Jan 27, 2015 at 5:03 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
>> Looking at the generalizations in Data.List I find them pretty odd now
>> when I think about it. I'd expect Data.List functions to be
>> monomorphic to lists, just like I expect functions in Data.Map to be
>> monomorphic to maps. Now there might be generalized versions of these
>> functions in e.g. the Prelude, but generalizing Data.List means that I
>> don't even have the monomorphic versions available if I want to resolve ambiguity by using them*.
>>
>> * It turns out resolving ambiguity is pretty annoying. The type
>> signatures are awkward to write so I end having to write something
>> akin to
>>
>>     mymap :: (a -> b) -> [a] -> [b]
>>     mymap = map
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/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 a 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.
>
> Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx  for important information with respect to derivative products.

From Lennart.Augustsson at sc.com  Tue Jan 27 16:20:35 2015
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Tue, 27 Jan 2015 16:20:35 +0000
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
Message-ID: <22B950C955F8AB4196E72698FBD00002B940344F@UKWPIPXMB01A.zone1.scb.net>

I'm speaking in general terms, regardless of BBP.  Having Data.List export functions that are not list functions, but overloaded in the list type is so counter-intuitive that my brain hurts.
Where will I find the foldr with type (a->b->b) -> b -> [a] -> b, if not in Data.List?

-----Original Message-----
From: Erik Hesselink [mailto:hesselink at gmail.com] 
Sent: 27 January 2015 16:15
To: Augustsson, Lennart
Cc: Johan Tibell; libraries at haskell.org
Subject: Re: Drastic Prelude changes imminent

I don't see why from your email, but my only point was that having both polymorphic versions of functions in the Prelude, and monomorphic ones in Data.List, will probably be worse than either of the other two options (the fully polymorphic version being prepared, and the status quo you want to keep).

Erik



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

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

From chrisdone at gmail.com  Tue Jan 27 16:21:06 2015
From: chrisdone at gmail.com (Christopher Done)
Date: Tue, 27 Jan 2015 17:21:06 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
Message-ID: <CAAJHNPDMmTJXjOW8KQNZ2NY+P52ZKLp5nycqzgvvBs6iO6PmEg@mail.gmail.com>

There's precedence for this, I think: Data.Map, Data.Vector, Data.List
all export monomorphic functions. It's just we don't import Data.List
as L because lists are given special treatment by Haskell 2010. It
makes sense for Prelude to be polymorphic to me.

From hesselink at gmail.com  Tue Jan 27 16:31:39 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 27 Jan 2015 17:31:39 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAAJHNPDMmTJXjOW8KQNZ2NY+P52ZKLp5nycqzgvvBs6iO6PmEg@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAAJHNPDMmTJXjOW8KQNZ2NY+P52ZKLp5nycqzgvvBs6iO6PmEg@mail.gmail.com>
Message-ID: <CAPeieQFhSZ8XOsdXvZhweC0d6oMR=yE0_-T_KQFUD=AaSXs-hw@mail.gmail.com>

Oh, I agree in general. I just don't see the migration path towards
this, because as you say, Data.List is generally imported unqualified
and often without explicitly naming the imported identifiers.

The only thing I can think of is to generalize Data.List when
generalizing the prelude, but also introduce e.g. Data.List.Mono which
has all the monomorphic variants.

Erik

On Tue, Jan 27, 2015 at 5:21 PM, Christopher Done <chrisdone at gmail.com> wrote:
> There's precedence for this, I think: Data.Map, Data.Vector, Data.List
> all export monomorphic functions. It's just we don't import Data.List
> as L because lists are given special treatment by Haskell 2010. It
> makes sense for Prelude to be polymorphic to me.

From gale at sefer.org  Tue Jan 27 16:35:16 2015
From: gale at sefer.org (Yitzchak Gale)
Date: Tue, 27 Jan 2015 18:35:16 +0200
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
Message-ID: <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>

First of all, I am very strongly in favor of Lennart's proposal
of slowing down the BBP.

This discussion is now moving in the direction of changes or
alternatives to BBP itself. That is a worthwhile discussion,
but it's not practical until we first come to a conclusion about
Lennart's original proposal. For now, what is on the table is
to find a way to swap BBP, exactly as it is now, in or out
using some simple mechanism like a pragma.

The proposed syntax LANGUAGE Prelude=AlternativePrelude
is nice, but the difficulty in finding a Proposal 3 shows that
this syntax is not good enough. We need a combined
Proposal 1 and Proposal 3 that works something like this:

The base package comes with two versions of each of
the affected modules. Something like this:

Prelude.Traditional
Prelude.Alternative

Data.List.Traditional
Data.List.Alternative

etc.

Then we need some simple mechanism - a LANGUAGE
pragma, or whatever - that swaps all at once which of
the two sets are re-exported by the standard modules.

-Yitz

From david.feuer at gmail.com  Tue Jan 27 17:06:56 2015
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 27 Jan 2015 12:06:56 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
Message-ID: <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>

I'm trying to understand why people with (serious, legitimate)
concerns about BBP didn't come out of the woodwork until RC2. I fear
it's likely that nothing can be done to change this until 7.12 in any
case.

For the record, I'm not a huge fan of the Foldable abstraction myself;
I just don't think now is a good time for that discussion.

On Tue, Jan 27, 2015 at 11:35 AM, Yitzchak Gale <gale at sefer.org> wrote:
> First of all, I am very strongly in favor of Lennart's proposal
> of slowing down the BBP.
>
> This discussion is now moving in the direction of changes or
> alternatives to BBP itself. That is a worthwhile discussion,
> but it's not practical until we first come to a conclusion about
> Lennart's original proposal. For now, what is on the table is
> to find a way to swap BBP, exactly as it is now, in or out
> using some simple mechanism like a pragma.
>
> The proposed syntax LANGUAGE Prelude=AlternativePrelude
> is nice, but the difficulty in finding a Proposal 3 shows that
> this syntax is not good enough. We need a combined
> Proposal 1 and Proposal 3 that works something like this:
>
> The base package comes with two versions of each of
> the affected modules. Something like this:
>
> Prelude.Traditional
> Prelude.Alternative
>
> Data.List.Traditional
> Data.List.Alternative
>
> etc.
>
> Then we need some simple mechanism - a LANGUAGE
> pragma, or whatever - that swaps all at once which of
> the two sets are re-exported by the standard modules.
>
> -Yitz
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

From Lennart.Augustsson at sc.com  Tue Jan 27 17:13:36 2015
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Tue, 27 Jan 2015 17:13:36 +0000
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
Message-ID: <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>

Perhaps because a lot of people didn't know about it?
Simon PJ didn't know until we told him on Friday, so I don't think the change has been that well advertised.

-----Original Message-----
From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of David Feuer
Sent: 27 January 2015 17:07
To: Yitzchak Gale
Cc: libraries at haskell.org
Subject: Re: Drastic Prelude changes imminent

I'm trying to understand why people with (serious, legitimate) concerns about BBP didn't come out of the woodwork until RC2. I fear it's likely that nothing can be done to change this until 7.12 in any case.

For the record, I'm not a huge fan of the Foldable abstraction myself; I just don't think now is a good time for that discussion.


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

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

From gershomb at gmail.com  Tue Jan 27 17:25:21 2015
From: gershomb at gmail.com (Gershom B)
Date: Tue, 27 Jan 2015 12:25:21 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <etPan.54c7ca10.2ae8944a.1a69@mbp.local>

I think that _if_ there had been a better organized, more clarifying discussion on the scope of BBP earlier (one was promised after Neil raised concerns, but I think it fell by the wayside), then we might not be in this boat.

Now, whatever the ?right? thing is eventually, it does feel like we need to apply brakes until people can settle in further. I know people will be disappointed no matter what happens, and they will feel this stuff has moved slowly enough for long enough.

However, without having had that discussion, I don?t see how we can move forward.

The proposal Lennart and Simon have therefore seems good and necessary, save for the issue of how BBP infects Data.List in particular as well.?

I think we should go with it, and _also_ just have Data.List always export the monomorphic functions for now. I recognize that this means even with AlternativePrelude on, people will not get the full niceness of the ?BBP experience?. However, it seems as close as we can get, to my mind, without creating greater headaches and issues all around.

We could perhaps also insert a warning encouraging people to import Data.List qualified, either in this GHC of the next release. This would allow BBP to proceed in a relatively breakage-free way in the future without needing to generalize the Data.List module.

Cheers,
Gershom


On January 27, 2015 at 12:14:03 PM, Augustsson, Lennart (lennart.augustsson at sc.com) wrote:
> Perhaps because a lot of people didn't know about it?
> Simon PJ didn't know until we told him on Friday, so I don't think the change has been that  
> well advertised.
>  
> -----Original Message-----
> From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of David Feuer  
> Sent: 27 January 2015 17:07
> To: Yitzchak Gale
> Cc: libraries at haskell.org
> Subject: Re: Drastic Prelude changes imminent
>  
> I'm trying to understand why people with (serious, legitimate) concerns about BBP didn't  
> come out of the woodwork until RC2. I fear it's likely that nothing can be done to change  
> this until 7.12 in any case.
>  
> For the record, I'm not a huge fan of the Foldable abstraction myself; I just don't think  
> now is a good time for that discussion.
>  
>  
> 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 a 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.  
>  
> Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx  
> for important information with respect to derivative products.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>  


From allbery.b at gmail.com  Tue Jan 27 17:27:43 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 27 Jan 2015 12:27:43 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
Message-ID: <CAKFCL4V=ixwrjjR6RMXj2c_uMbAOtmf9aqNhLfVf6jKddtz-uA@mail.gmail.com>

On Tue, Jan 27, 2015 at 12:25 PM, Gershom B <gershomb at gmail.com> wrote:

> I think that _if_ there had been a better organized, more clarifying
> discussion on the scope of BBP earlier (one was promised after Neil raised
> concerns, but I think it fell by the wayside), then we might not be in this
> boat.


Agreed. I knew this was coming from various mentions, but there was not a
good overview of what was going on and what effects it would have until
this thread. This makes me think that it might be wise to back off until
7.12.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/99ebee2c/attachment.html>

From marlowsd at gmail.com  Tue Jan 27 17:30:58 2015
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 27 Jan 2015 17:30:58 +0000
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <54C7CB52.5060905@gmail.com>

On 27/01/2015 10:32, Augustsson, Lennart wrote:
> Proposal 1:
>
> *    Add a new pragma
>
>          {-# LANGUAGE Prelude=AlternativePrelude #-}

As I mentioned to Simon PJ, I don't think this is the best way to solve 
the problem, because adding a new extension brings new 
backwards-compatibility issues on top of the ones we're trying to solve. 
  Users will need to employ flags in their .cabal file, or #ifdefs in 
their source code, to account for the fact that only GHC 7.10 supports 
the new option.

Furthermore, every GHC version already has the necessary functionality 
to do this, so we don't need to add a new flag.  You can either (a) use 
{-# LANGUAGE NoImplicitPrelude #-} together with import MyPrelude, or 
(b) use import Prelude (); import MyPrelude.  Slightly more characters, 
but entirely backwards-compatible - I think that's a worthy tradeoff.

FWIW, I agreed with Neil when he brought up the issue of the new Prelude 
changes a while ago.

Cheers,
Simon






>        *   This is a new feature, but it is easy and low-risk to implement.
>
>        *   Which Prelude you use really is a language choice;
> appropriate for a LANGUAGE pragma.
>
>        *   Semantics is name-space only: import Prelude (); import
> AlternativePrelude
>
>        *   No effect on desugaring or typing of built-in syntax (list
> comprehensions, do-notation etc).
>
> *    Ship with both old and new prelude.
>
> *    So now old and new behaviour are easy to achieve, in the module or
> in a .cabal file.
>
> *    The question becomes "what is the default".
>
> Proposal 2:
>
> *    Make the default be the old rather than the new.
>
>        *   Altering the default Prelude API should be done slowly, with
> lots of warning; because all users get it willy-nilly.
>
>        *   Unlike AMP, the change is controversial (clearly).
>
>        *   Easier to make changes to New Prelude if it isn't the default.
>
> That's it.
>
> Discussing the BBP proposal we also came up with a number of technical
> questions:
>
> Q1
>
> An alternative to Foldable would be
>
>    class Enumerable t where
>
>      toList :: t a -> [a]   -- Implementations should use 'build'
>
> Is Foldable more general (or efficient) than a Enumerable class, plus
> fusion?
>
> Consider a new data type X a.  I write
>
>       foldX :: (a -> b -> b) -> b -> X a -> b
>
>       foldX = ...lots of code...
>
>       toList :: X a -> [a]  {-# INLINE toList #-}
>
>       toList x = build (\c n. foldX c n x)
>
> So now toList is small and easy to inline.  Every good list consumer of
> a call to toList will turn into a call to foldX, which is what we want.
>
> Q2
>
> What are the criteria for being in Foldable?
>
> For instance, why are 'sum', 'product' in Foldable, but not 'and', 'or'?
>
> Q3
>
> What's the relationship of Foldable to GHC.Exts.IsList?
>
> Which also has toList, fromList, and does work with ByteString.
>
> *  For example, could we use IsList instead of Foldable?
>
>      Specifically, Foldable does not use its potential power to apply
> the type constructor t to different arguments.  (Unlike Traversable
> which does.)
>
>          foldr :: IsList l => (Item l->b->b) -> b -> l -> b
>
>    -- Lennart
>
>
> 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 a 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.
>
> Please visit
> http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx
> for important information with respect to derivative products.
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

From marlowsd at gmail.com  Tue Jan 27 17:34:48 2015
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 27 Jan 2015 17:34:48 +0000
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B940325D@UKWPIPXMB01A.zone1.scb.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQG9ZR0rp7pD1u3bCPjFZg3q6veo-aihWueY17TObuw9TA@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940325D@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <54C7CC38.1090603@gmail.com>

On 27/01/2015 11:26, Augustsson, Lennart wrote:
> That's very different since it changes how desugaring works.
> With NoImplicitPrelude desugaring uses unqualified names.  It's a rather fragile pragma.

You're thinking of RebindableSyntax.  NoImplicitPrelude has no effect on 
desugaring.

Cheers,
Simon




> -----Original Message-----
> From: Erik Hesselink [mailto:hesselink at gmail.com]
> Sent: 27 January 2015 11:11
> To: Augustsson, Lennart
> Cc: libraries at haskell.org
> Subject: Re: Drastic Prelude changes imminent
>
> On Tue, Jan 27, 2015 at 11:32 AM, Augustsson, Lennart <Lennart.Augustsson at sc.com> wrote:
>> *    Add a new pragma
>>          {-# LANGUAGE Prelude=AlternativePrelude #-}
>>        *   Semantics is name-space only: import Prelude (); import
>> AlternativePrelude
>
> I don't have any opinion on the full proposal yet, but I usually use "{-# LANGUAGE NoImplicitPrelude #-}" when using an alternate prelude.
> Is there any different between that and "import Prelude ()"?
>
> Erik
>
> 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 a 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.
>
> Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx  for important information with respect to derivative products.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

From marlowsd at gmail.com  Tue Jan 27 17:39:26 2015
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 27 Jan 2015 17:39:26 +0000
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <54C7CD4E.1010506@gmail.com>

On 27/01/2015 17:13, Augustsson, Lennart wrote:
> Perhaps because a lot of people didn't know about it?
> Simon PJ didn't know until we told him on Friday, so I don't think the change has been that well advertised.

There was the reddit discussion of Neil's blogpost [1], where most of 
the people responding seemed to be in favour of the change.  I assumed 
the ship had sailed and decided to live with it.

http://www.reddit.com/r/haskell/comments/2hzqii/neil_mitchells_haskell_blog_why/

Cheers,
Simon



>
> -----Original Message-----
> From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of David Feuer
> Sent: 27 January 2015 17:07
> To: Yitzchak Gale
> Cc: libraries at haskell.org
> Subject: Re: Drastic Prelude changes imminent
>
> I'm trying to understand why people with (serious, legitimate) concerns about BBP didn't come out of the woodwork until RC2. I fear it's likely that nothing can be done to change this until 7.12 in any case.
>
> For the record, I'm not a huge fan of the Foldable abstraction myself; I just don't think now is a good time for that discussion.
>
>
> 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 a 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.
>
> Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx  for important information with respect to derivative products.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

From eir at cis.upenn.edu  Tue Jan 27 17:39:37 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 27 Jan 2015 12:39:37 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAKFCL4V=ixwrjjR6RMXj2c_uMbAOtmf9aqNhLfVf6jKddtz-uA@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
 <CAKFCL4V=ixwrjjR6RMXj2c_uMbAOtmf9aqNhLfVf6jKddtz-uA@mail.gmail.com>
Message-ID: <011CD61D-AA84-4C8A-A0C3-8069621A9559@cis.upenn.edu>

If memory serves, what became the BBP was initially introduced at the Haskell Implementors' Workshop in Boston in 2013. (Or, at least, that's when I became aware of it.) I know I'm a special case of a Haskell user, but I've seen mention of the BBP aplenty. However, I do think we should learn from this experience and perhaps establish a very-low-traffic list where we announce breaking language changes.

As for the BBP itself, my 1? is that I've never liked it much, but I don't like the status quo either. (Too much `hiding` and `qualified`!) Having neither a good alternative nor time/energy to develop one has kept me relatively quiet in the discussion, and is why I'm offering only 1? right now instead of 2?. (My chief concern is how it affects newcomers to Haskell, which is admittedly a different concern than others have expressed. It may be worth noting that my concern was addressed by suggesting newcomers use the `haskell2010` package... which is now defunct, due to fallout from the AMP.)

As a much more minor point, I believe
> {-# LANGUAGE NoImplicitPrelude #-}
and
> import Prelude ()
should have different behavior. Doesn't the latter import any Prelude instances? Might these be different (and conflicting with!) instances in an alternate prelude? So, I think we must mimic the pragma version as opposed to the empty import list.

Richard

On Jan 27, 2015, at 12:27 PM, Brandon Allbery <allbery.b at gmail.com> wrote:

> On Tue, Jan 27, 2015 at 12:25 PM, Gershom B <gershomb at gmail.com> wrote:
> I think that _if_ there had been a better organized, more clarifying discussion on the scope of BBP earlier (one was promised after Neil raised concerns, but I think it fell by the wayside), then we might not be in this boat.
> 
> Agreed. I knew this was coming from various mentions, but there was not a good overview of what was going on and what effects it would have until this thread. This makes me think that it might be wise to back off until 7.12.
> 
> -- 
> brandon s allbery kf8nh                               sine nomine associates
> allbery.b at gmail.com                                  ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/80def836/attachment-0001.html>

From ndmitchell at gmail.com  Tue Jan 27 17:44:29 2015
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Tue, 27 Jan 2015 17:44:29 +0000
Subject: Drastic Prelude changes imminent
In-Reply-To: <011CD61D-AA84-4C8A-A0C3-8069621A9559@cis.upenn.edu>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
 <CAKFCL4V=ixwrjjR6RMXj2c_uMbAOtmf9aqNhLfVf6jKddtz-uA@mail.gmail.com>
 <011CD61D-AA84-4C8A-A0C3-8069621A9559@cis.upenn.edu>
Message-ID: <CAKcFpmK8dUx8uYeqRS7UXzMwKQQVXD-oxR20Usk6zhsVA7dVGg@mail.gmail.com>

> now instead of 2?. (My chief concern is how it affects newcomers to Haskell,
> which is admittedly a different concern than others have expressed. It may
> be worth noting that my concern was addressed by suggesting newcomers use
> the `haskell2010` package... which is now defunct, due to fallout from the
> AMP.)

The haskell2010 package has always been unusable. Initially haskell98
reexposed a subset of base, and they worked together. Then some of the
modules were cloned and tweaked, and any time I put them in the same
package it all went terribly wrong.

I also have concerns about beginners, but it's clear everyone has
radically different opinions about what is good or bad for beginners.

I raised my concerns as soon as I found out about the changes (October
2014), argued my case, made a few blog posts, but seemingly lost. At
that point, much like Simon Marlow, I decided to live with it. I have
a feeling we might rehash the same discussion every time a new larger
set of people find out about the changes, especially as those people
are less likely to be connected to the cutting edge of libraries
development.

Thanks, Neil

From Lennart.Augustsson at sc.com  Tue Jan 27 17:49:03 2015
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Tue, 27 Jan 2015 17:49:03 +0000
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAKcFpmK8dUx8uYeqRS7UXzMwKQQVXD-oxR20Usk6zhsVA7dVGg@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
 <CAKFCL4V=ixwrjjR6RMXj2c_uMbAOtmf9aqNhLfVf6jKddtz-uA@mail.gmail.com>
 <011CD61D-AA84-4C8A-A0C3-8069621A9559@cis.upenn.edu>
 <CAKcFpmK8dUx8uYeqRS7UXzMwKQQVXD-oxR20Usk6zhsVA7dVGg@mail.gmail.com>
Message-ID: <22B950C955F8AB4196E72698FBD00002B940351F@UKWPIPXMB01A.zone1.scb.net>

A lot of people might have opinions about what is good for beginners, but the only opinions that matter are from those who have actually taught a large number of beginners.  I'm not one of them, so I'll keep my beginner opinions to myself.

-----Original Message-----
From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Neil Mitchell
Sent: 27 January 2015 17:44
To: Richard Eisenberg
Cc: cvs-libraries at haskell.org
Subject: Re: Drastic Prelude changes imminent

> now instead of 2?. (My chief concern is how it affects newcomers to 
> Haskell, which is admittedly a different concern than others have 
> expressed. It may be worth noting that my concern was addressed by 
> suggesting newcomers use the `haskell2010` package... which is now 
> defunct, due to fallout from the
> AMP.)

The haskell2010 package has always been unusable. Initially haskell98 reexposed a subset of base, and they worked together. Then some of the modules were cloned and tweaked, and any time I put them in the same package it all went terribly wrong.

I also have concerns about beginners, but it's clear everyone has radically different opinions about what is good or bad for beginners.

I raised my concerns as soon as I found out about the changes (October 2014), argued my case, made a few blog posts, but seemingly lost. At that point, much like Simon Marlow, I decided to live with it. I have a feeling we might rehash the same discussion every time a new larger set of people find out about the changes, especially as those people are less likely to be connected to the cutting edge of libraries development.

Thanks, Neil
_______________________________________________
Libraries mailing list
Libraries at haskell.org
http://www.haskell.org/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 a 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.

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

From greg at gregweber.info  Tue Jan 27 18:03:08 2015
From: greg at gregweber.info (Greg Weber)
Date: Tue, 27 Jan 2015 10:03:08 -0800
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B940351F@UKWPIPXMB01A.zone1.scb.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
 <CAKFCL4V=ixwrjjR6RMXj2c_uMbAOtmf9aqNhLfVf6jKddtz-uA@mail.gmail.com>
 <011CD61D-AA84-4C8A-A0C3-8069621A9559@cis.upenn.edu>
 <CAKcFpmK8dUx8uYeqRS7UXzMwKQQVXD-oxR20Usk6zhsVA7dVGg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940351F@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <CAKRanNAzzvZQ1nVP3v5he9O6PJyOCzZbxDm0Q3Ha0=LmpAL+Pg@mail.gmail.com>

I hope we can learn a lesson here that we need a clear specification to
point people to when there are major changes. I pointed this out when the
reddit discussion came up and everyone agreed it should be done, but I
don't think it was ever done. Perhaps we can be stringent on maintaining
such a policy in the future.

I always thought that generalizing Data.List was a mistake, but I figured
it was too late in the process to change it and I didn't understand the
motivation. Code examples for this would be something to put in the
specification.

On Tue, Jan 27, 2015 at 9:49 AM, Augustsson, Lennart <
Lennart.Augustsson at sc.com> wrote:

> A lot of people might have opinions about what is good for beginners, but
> the only opinions that matter are from those who have actually taught a
> large number of beginners.  I'm not one of them, so I'll keep my beginner
> opinions to myself.
>
> -----Original Message-----
> From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Neil
> Mitchell
> Sent: 27 January 2015 17:44
> To: Richard Eisenberg
> Cc: cvs-libraries at haskell.org
> Subject: Re: Drastic Prelude changes imminent
>
> > now instead of 2?. (My chief concern is how it affects newcomers to
> > Haskell, which is admittedly a different concern than others have
> > expressed. It may be worth noting that my concern was addressed by
> > suggesting newcomers use the `haskell2010` package... which is now
> > defunct, due to fallout from the
> > AMP.)
>
> The haskell2010 package has always been unusable. Initially haskell98
> reexposed a subset of base, and they worked together. Then some of the
> modules were cloned and tweaked, and any time I put them in the same
> package it all went terribly wrong.
>
> I also have concerns about beginners, but it's clear everyone has
> radically different opinions about what is good or bad for beginners.
>
> I raised my concerns as soon as I found out about the changes (October
> 2014), argued my case, made a few blog posts, but seemingly lost. At that
> point, much like Simon Marlow, I decided to live with it. I have a feeling
> we might rehash the same discussion every time a new larger set of people
> find out about the changes, especially as those people are less likely to
> be connected to the cutting edge of libraries development.
>
> Thanks, Neil
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/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 a 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.
>
> Please visit
> http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx
> for important information with respect to derivative products.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/949a2b29/attachment.html>

From dluposchainsky at googlemail.com  Tue Jan 27 18:22:22 2015
From: dluposchainsky at googlemail.com (David Luposchainsky)
Date: Tue, 27 Jan 2015 19:22:22 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <54C7D75E.2000304@gmail.com>

Hello *,

as much as I welcome these changes to the Prelude kitchen sink, I'm
confused about how this does not make the release a major version bump.
It changes half of the functions exposed by default in a dramatic way,
after all. Do we want to keep GHC 8 for a new Report?

Greetings,
David/quchen

From ekmett at gmail.com  Tue Jan 27 18:33:22 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 27 Jan 2015 13:33:22 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <CAJumaK-fE3OVupjNV5E2ZRXfkKUCHj8d8CkPkPM-kFpEeM1WpA@mail.gmail.com>

On Tue, Jan 27, 2015 at 5:32 AM, Augustsson, Lennart <
Lennart.Augustsson at sc.com> wrote:

>  The next version (7.10) of GHC is slated to have a drastically changed
> Prelude.
>
> This message is very late in the release process, but I would urge caution
> before changing.
>
>
>
> The changes are (aptly) named the Burning Bridges Proposal (BBP).
>
> Even though the work has been going on for a while, it seems that this
>
> change is coming as a surprise to many people (including Simon Peyton
>
> Jones).  In summary, it generalizes many list operation, e.g., foldr,
>
> to be overloaded.
>
>
>
> There is much to welcome in BBP, but changing the Prelude cannot be
>
> done lightly since it really is like changing the language.
>
> So I think it's really important for a large number of people to be able to
>
> try out such changes before they come into effect, and to have time
>
> to let the changes stabilize (you rarely get it right the first time).
>
>
>
> I've discussed this with a number of people, including Simon PJ, and
>
> we have concrete proposals.
>
>
>
> Proposal 1:
>
> *    Add a new pragma
>
>         {-# LANGUAGE Prelude=AlternativePrelude #-}
>
>       *   This is a new feature, but it is easy and low-risk to implement.
>
>       *   Which Prelude you use really is a language choice; appropriate
> for a LANGUAGE pragma.
>
>       *   Semantics is name-space only: import Prelude (); import
> AlternativePrelude
>
>       *   No effect on desugaring or typing of built-in syntax (list
> comprehensions, do-notation etc).
>
*    Ship with both old and new prelude.
>
*    So now old and new behaviour are easy to achieve, in the module or in
> a .cabal file.
>
>

This actually *doesn't work*. We seriously considered it, but the effects
have knock-on consequences that go far beyond the Prelude itself.

Control.Monad for instance re-exports `mapM`

Data.List re-exports most of the folds.

`mtl` re-exports the monad combinators as well, etc.

The list goes on and on.

We made a serious go at trying this proposal before we abandoned it as
unworkable, because of the re-export issue.

import Data.List

would have to collide or not collide with Prelude types based on whether or
not the Prelude was being used or this alternate Prelude.

import Control.Monad
import Data.Foldable
import Data.Traversable

etc.

the list goes on.

Under the scheme we've adopted all of these work unconditionally.

Q1
>
> An alternative to Foldable would be
>
>   class Enumerable t where
>
>     toList :: t a -> [a]   -- Implementations should use 'build'
>
> Is Foldable more general (or efficient) than a Enumerable class, plus
> fusion?
>
>
This is insufficient in a lazy language, it forces all folds to be
left-biased, and introduces bottoms that do not exist in a foldMap based
Foldable.

class Foldable f where
  foldMap :: Monoid m => (a -> m) -> f a -> m

on the other hand would be a very serious candidate for a minimalist
Foldable, but then we run afoul of Q2.


>  Consider a new data type X a.  I write
>
>      foldX :: (a -> b -> b) -> b -> X a -> b
>
>      foldX = ...lots of code...
>
>
>
>      toList :: X a -> [a]  {-# INLINE toList #-}
>
>      toList x = build (\c n. foldX c n x)
>
>
>
> So now toList is small and easy to inline.  Every good list consumer of a
> call to toList will turn into a call to foldX, which is what we want.
>
>
>
> Q2
>
> What are the criteria for being in Foldable?
>
> For instance, why are 'sum', 'product' in Foldable, but not 'and', 'or'?
>
>
sum and product went into Foldable because Prelude.sum and
Data.Foldable.sum folded in opposite directions.

and/or didn't have this problem.

For any new data type, defining foldMap alone is sufficient.

For [] on the other hand we decided that expanding Foldable to avoid
silently changing the semantics of all Haskell programs ever written was
the lesser of two evils.

It was considered _by far_ the lesser of evils to expand the class to
enable it to duplicate existing semantics where possible rather than
silently change the semantics of which way folks code associated for all
Haskell programs ever written.

Q3
>
> What's the relationship of Foldable to GHC.Exts.IsList?
>
> Which also has toList, fromList, and does work with ByteString.
>
> *  For example, could we use IsList instead of Foldable?
>
>     Specifically, Foldable does not use its potential power to apply the
> type constructor t to different arguments.  (Unlike Traversable which does.)
>
>         foldr :: IsList l => (Item l->b->b) -> b -> l -> b
>
>
Because IsList includes both fromList and toList, _and_ is over an argument
of kind * not an argument of kind * -> *, IsList has no connection to
Foldable.

At best what you can say is that the toList for Data.Foldable and the
toList for IsList should yield the same answer if you want to be sensible,
but remember IsList is on a different kind entirely, and there are usecases
that require it to have that kind.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/fc41909f/attachment-0001.html>

From ekmett at gmail.com  Tue Jan 27 18:36:17 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 27 Jan 2015 13:36:17 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
Message-ID: <CAJumaK8HmegBAUPHixsaKqzYgLxLP76VG8yKn7A1qR2DrG_jSA@mail.gmail.com>

There were several fixes offered:

1.)  Data.List could cease to re-export Prelude types

This would work, but it would cause code breakage.

2.) Data.List could export monomorphic types, while the Prelude types could
be generalized.

Now everyone who imports Data.List would get conflicts with Prelude types,
causing code breakage.

3.) Data.List could continue to needlessly re-export Prelude types but have
those generalized to match the Prelude.

This is the only option where existing code more or less universally
continues to work.

We can't actually deprecate a re-export at present, so we don't have a path
to #1 at the moment, but it'd be a more ideal situation in the long run.

-Edward

On Tue, Jan 27, 2015 at 11:03 AM, Johan Tibell <johan.tibell at gmail.com>
wrote:

> Looking at the generalizations in Data.List I find them pretty odd now
> when I think about it. I'd expect Data.List functions to be monomorphic to
> lists, just like I expect functions in Data.Map to be monomorphic to maps.
> Now there might be generalized versions of these functions in e.g. the
> Prelude, but generalizing Data.List means that I don't even have the
> monomorphic versions available if I want to resolve ambiguity by using
> them*.
>
> * It turns out resolving ambiguity is pretty annoying. The type signatures
> are awkward to write so I end having to write something akin to
>
>     mymap :: (a -> b) -> [a] -> [b]
>     mymap = map
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/91e03d72/attachment.html>

From voldermort at hotmail.com  Tue Jan 27 18:57:13 2015
From: voldermort at hotmail.com (harry)
Date: Tue, 27 Jan 2015 11:57:13 -0700 (MST)
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B940351F@UKWPIPXMB01A.zone1.scb.net>
References: <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
 <CAKFCL4V=ixwrjjR6RMXj2c_uMbAOtmf9aqNhLfVf6jKddtz-uA@mail.gmail.com>
 <011CD61D-AA84-4C8A-A0C3-8069621A9559@cis.upenn.edu>
 <CAKcFpmK8dUx8uYeqRS7UXzMwKQQVXD-oxR20Usk6zhsVA7dVGg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940351F@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <1422385033238-5764412.post@n5.nabble.com>

Augustsson, Lennart wrote
> A lot of people might have opinions about what is good for beginners, but
> the only opinions that matter are from those who have actually taught a
> large number of beginners.  I'm not one of them, so I'll keep my beginner
> opinions to myself.

When I was a beginner, I don't recall having trouble understanding the
polymorphic versions, but I was soundly confounded by the apparent
redundancy of map/fmap etc. Particularly when the answer was "to make things
easier for beginners"!



--
View this message in context: http://haskell.1045720.n5.nabble.com/Drastic-Prelude-changes-imminent-tp5764345p5764412.html
Sent from the Haskell - Libraries mailing list archive at Nabble.com.

From cma at bitemyapp.com  Tue Jan 27 19:06:19 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Tue, 27 Jan 2015 13:06:19 -0600
Subject: Drastic Prelude changes imminent
In-Reply-To: <1422385033238-5764412.post@n5.nabble.com>
References: <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
 <CAKFCL4V=ixwrjjR6RMXj2c_uMbAOtmf9aqNhLfVf6jKddtz-uA@mail.gmail.com>
 <011CD61D-AA84-4C8A-A0C3-8069621A9559@cis.upenn.edu>
 <CAKcFpmK8dUx8uYeqRS7UXzMwKQQVXD-oxR20Usk6zhsVA7dVGg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940351F@UKWPIPXMB01A.zone1.scb.net>
 <1422385033238-5764412.post@n5.nabble.com>
Message-ID: <CADnndOpWM6rsg8SKw+CLWLx2cAWHXW2RF+gRi=+EPwExkz_=rQ@mail.gmail.com>

This has been the experience of many (not all) beginners I've worked with
as well.

Confusion with redundancy more often than the concept embedded in the
polymorphic version. It should be said that Functor is usually a titch
easier to learn for new people than Foldable or Traversable even if they're
not complicated to experienced Haskellers.

Another problem is that most books for learning Haskell don't incorporate
much of the typeclasses under discussion, partly because of how new they
are.

I don't think these caveats are a good reason to block or mutilate the BBP.

--- Chris


On Tue, Jan 27, 2015 at 12:57 PM, harry <voldermort at hotmail.com> wrote:

> Augustsson, Lennart wrote
> > A lot of people might have opinions about what is good for beginners, but
> > the only opinions that matter are from those who have actually taught a
> > large number of beginners.  I'm not one of them, so I'll keep my beginner
> > opinions to myself.
>
> When I was a beginner, I don't recall having trouble understanding the
> polymorphic versions, but I was soundly confounded by the apparent
> redundancy of map/fmap etc. Particularly when the answer was "to make
> things
> easier for beginners"!
>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/Drastic-Prelude-changes-imminent-tp5764345p5764412.html
> Sent from the Haskell - Libraries mailing list archive at Nabble.com.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/5d142e99/attachment.html>

From carter.schonwald at gmail.com  Tue Jan 27 19:09:21 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 27 Jan 2015 14:09:21 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <CADnndOpWM6rsg8SKw+CLWLx2cAWHXW2RF+gRi=+EPwExkz_=rQ@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
 <CAKFCL4V=ixwrjjR6RMXj2c_uMbAOtmf9aqNhLfVf6jKddtz-uA@mail.gmail.com>
 <011CD61D-AA84-4C8A-A0C3-8069621A9559@cis.upenn.edu>
 <CAKcFpmK8dUx8uYeqRS7UXzMwKQQVXD-oxR20Usk6zhsVA7dVGg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940351F@UKWPIPXMB01A.zone1.scb.net>
 <1422385033238-5764412.post@n5.nabble.com>
 <CADnndOpWM6rsg8SKw+CLWLx2cAWHXW2RF+gRi=+EPwExkz_=rQ@mail.gmail.com>
Message-ID: <CAHYVw0xPXbdGd1bYkwM2sWgtOimX_io0o5DDM-oYZUmNgTtPMw@mail.gmail.com>

+1

On Tue, Jan 27, 2015 at 2:06 PM, Christopher Allen <cma at bitemyapp.com>
wrote:

> This has been the experience of many (not all) beginners I've worked with
> as well.
>
> Confusion with redundancy more often than the concept embedded in the
> polymorphic version. It should be said that Functor is usually a titch
> easier to learn for new people than Foldable or Traversable even if they're
> not complicated to experienced Haskellers.
>
> Another problem is that most books for learning Haskell don't incorporate
> much of the typeclasses under discussion, partly because of how new they
> are.
>
> I don't think these caveats are a good reason to block or mutilate the BBP.
>
> --- Chris
>
>
> On Tue, Jan 27, 2015 at 12:57 PM, harry <voldermort at hotmail.com> wrote:
>
>> Augustsson, Lennart wrote
>> > A lot of people might have opinions about what is good for beginners,
>> but
>> > the only opinions that matter are from those who have actually taught a
>> > large number of beginners.  I'm not one of them, so I'll keep my
>> beginner
>> > opinions to myself.
>>
>> When I was a beginner, I don't recall having trouble understanding the
>> polymorphic versions, but I was soundly confounded by the apparent
>> redundancy of map/fmap etc. Particularly when the answer was "to make
>> things
>> easier for beginners"!
>>
>>
>>
>> --
>> View this message in context:
>> http://haskell.1045720.n5.nabble.com/Drastic-Prelude-changes-imminent-tp5764345p5764412.html
>> Sent from the Haskell - Libraries mailing list archive at Nabble.com.
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/2337ea14/attachment.html>

From lemming at henning-thielemann.de  Tue Jan 27 20:05:51 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 27 Jan 2015 21:05:51 +0100 (CET)
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1501272102130.6362@sputnik>


On Tue, 27 Jan 2015, Erik Hesselink wrote:

> I don't see why from your email, but my only point was that having
> both polymorphic versions of functions in the Prelude, and monomorphic
> ones in Data.List, will probably be worse than either of the other two
> options (the fully polymorphic version being prepared, and the status
> quo you want to keep).

If you import from Data.List with qualification there is no name clash.

I predict that many arguments pro the intended changes in 7.10 in this 
thread will boil down to the habit of many Haskell programmers to neglect 
both qualified and explicit imports, which I find sad.

From lemming at henning-thielemann.de  Tue Jan 27 20:12:50 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 27 Jan 2015 21:12:50 +0100 (CET)
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <alpine.DEB.2.02.1501272111070.6362@sputnik>


On Tue, 27 Jan 2015, Augustsson, Lennart wrote:

> Perhaps because a lot of people didn't know about it?
> Simon PJ didn't know until we told him on Friday, so I don't think the change has been that well advertised.

When BBP was discussed my impression was that many people affected by the 
proposal did not take part in the discussion. E.g. I was concerned about 
Haskell beginners and they are certainly not subscribed to 
libraries at haskell.org.

From lemming at henning-thielemann.de  Tue Jan 27 20:17:09 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 27 Jan 2015 21:17:09 +0100 (CET)
Subject: Drastic Prelude changes imminent
In-Reply-To: <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
Message-ID: <alpine.DEB.2.02.1501272114140.6362@sputnik>


On Tue, 27 Jan 2015, Gershom B wrote:

> We could perhaps also insert a warning encouraging people to import 
> Data.List qualified, either in this GHC of the next release.

+10 for qualification.

Btw. you can already get a warning for every import using the option:
    -fwarn-missing-import-lists

From emertens at gmail.com  Tue Jan 27 20:18:58 2015
From: emertens at gmail.com (Eric Mertens)
Date: Tue, 27 Jan 2015 12:18:58 -0800
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>

-1 on both proposals.

I've been keeping up with the changes to GHC and specifically this BBP for
quite some time now, so none of this is coming as a surprise.

I'm in favor of the generalized types and I've found that updating to to
work with the new exports is a matter of jiggling my imports to not
generate redundancy warnings. I haven't found that the more general types
are creating inference problems for the kind of code I write.

I'm also uncomfortable with reducing Foldable to a mere "toList" method as
I find that that solution ends up being too "left-biased"  There might be a
discussion to be had about what is or isn't in Foldable, but I don't think
it's anything blocking.

I'm particularly excited about the Applicative being a super-class of Monad
change and the ability to have generalized operations on Traversables being
the default. The Traversable pattern happens to handle a lot of situations
and has become about as important to me as Functor.

I don't think it's fair to characterize any of these changes as a surprise.
The discussion has been open and the implementations have been visible for
a long time now.

I can certainly see the reasoning in wanting Data.List.foldr to actually be
the list-specific one, and this would be consistent with other cases like
Data.Map. Changing this might break some code, but it might be a more
reasonable situation in the end. If we're going to consider this it would
probably be better in its own thread so that it doesn't get drowned out by
the rest of the BBP discussion.

Sincerely,
Eric Mertens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/4f39e755/attachment.html>

From lemming at henning-thielemann.de  Tue Jan 27 20:20:15 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 27 Jan 2015 21:20:15 +0100 (CET)
Subject: Drastic Prelude changes imminent
In-Reply-To: <54C7CC38.1090603@gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQG9ZR0rp7pD1u3bCPjFZg3q6veo-aihWueY17TObuw9TA@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940325D@UKWPIPXMB01A.zone1.scb.net>
 <54C7CC38.1090603@gmail.com>
Message-ID: <alpine.DEB.2.02.1501272119420.6362@sputnik>


On Tue, 27 Jan 2015, Simon Marlow wrote:

> On 27/01/2015 11:26, Augustsson, Lennart wrote:
>> That's very different since it changes how desugaring works.
>> With NoImplicitPrelude desugaring uses unqualified names.  It's a rather 
>> fragile pragma.
>
> You're thinking of RebindableSyntax.  NoImplicitPrelude has no effect on 
> desugaring.

I guess that changed when RebindableSyntax was introduced around GHC-7.0.

From david.feuer at gmail.com  Tue Jan 27 20:23:33 2015
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 27 Jan 2015 15:23:33 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
Message-ID: <CAMgWh9vMgzHuHhLOqh5-74c-NkNZd8eEW5ukYQY-AhKnLM31Ww@mail.gmail.com>

On Tue, Jan 27, 2015 at 3:18 PM, Eric Mertens <emertens at gmail.com> wrote:
> I'm also uncomfortable with reducing Foldable to a mere "toList" method as I
> find that that solution ends up being too "left-biased"  There might be a
> discussion to be had about what is or isn't in Foldable, but I don't think
> it's anything blocking.

As one of the people who was involved in making some of these changes,
I should warn you that things are still quite biased in certain ways.
Some things, like concatMap, lack really sane unbiased defaults.

From lemming at henning-thielemann.de  Tue Jan 27 20:36:34 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 27 Jan 2015 21:36:34 +0100 (CET)
Subject: Drastic Prelude changes imminent
In-Reply-To: <CADnndOpWM6rsg8SKw+CLWLx2cAWHXW2RF+gRi=+EPwExkz_=rQ@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
 <CAKFCL4V=ixwrjjR6RMXj2c_uMbAOtmf9aqNhLfVf6jKddtz-uA@mail.gmail.com>
 <011CD61D-AA84-4C8A-A0C3-8069621A9559@cis.upenn.edu>
 <CAKcFpmK8dUx8uYeqRS7UXzMwKQQVXD-oxR20Usk6zhsVA7dVGg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940351F@UKWPIPXMB01A.zone1.scb.net>
 <1422385033238-5764412.post@n5.nabble.com>
 <CADnndOpWM6rsg8SKw+CLWLx2cAWHXW2RF+gRi=+EPwExkz_=rQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1501272132250.6362@sputnik>


On Tue, 27 Jan 2015, Christopher Allen wrote:

> This has been the experience of many (not all) beginners I've worked with as well.
> Confusion with redundancy more often than the concept embedded in the polymorphic version. It should be said
> that Functor is usually a titch easier to learn for new people than Foldable or Traversable even if they're
> not complicated to experienced Haskellers.

When we discussed beginner experiences last time I was already surprised 
how easy learning Haskell was for many of you ... However when I look at 
Hackage there is much code using explicit recursion instead of calling 
'foldl' or even 'map'. This indicates to me that even List.map and 
List.foldl is too much of abstraction for many Haskell beginners.

From malcolm.wallace at me.com  Tue Jan 27 20:36:29 2015
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Tue, 27 Jan 2015 20:36:29 +0000
Subject: Drastic Prelude changes imminent
In-Reply-To: <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
Message-ID: <87C918EB-FE80-46ED-A46C-715DAE0908E1@me.com>


On 27 Jan 2015, at 20:18, Eric Mertens wrote:

> I've been keeping up with the changes to GHC and specifically this BBP for quite some time now, so none of this is coming as a surprise.
> 
> I don't think it's fair to characterize any of these changes as a surprise. The discussion has been open and the implementations have been visible for a long time now.

If we are comparing experiences, I was aware of the Applicative/Monad changes that were going into the Prelude, and have already fixed my packages that required changes (I long for the day when a release of ghc does _not_ break existing libraries!), but since I am not a regular reader of all the mailing lists, I was totally unaware that the Foldable/Traversable stuff was even proposed for the Prelude, never mind had actually made it to a release.  The first I knew it was in Prelude was in the middle of last week, when someone reported code that would not compile with ghc-7.10rc1 because of it.  Everyone I work with was horrified to hear that something so essential as the Prelude was being changed so thoroughly without their being aware of it either.

I do think that the current social mechanisms for changing the Haskell base library are less than ideal.  It sometimes feels like someone can send a message to a mailing list with a "bright idea", and so long as only a few people see it, and those that do see it do not object, the proposal is automatically accepted.  That would be fine for any library _except_ base, which I think ought to be much more stable.

Regards,
    Malcolm


From lemming at henning-thielemann.de  Tue Jan 27 20:49:35 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 27 Jan 2015 21:49:35 +0100 (CET)
Subject: Drastic Prelude changes imminent
In-Reply-To: <87C918EB-FE80-46ED-A46C-715DAE0908E1@me.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
 <87C918EB-FE80-46ED-A46C-715DAE0908E1@me.com>
Message-ID: <alpine.DEB.2.02.1501272143120.6362@sputnik>


On Tue, 27 Jan 2015, Malcolm Wallace wrote:

> I do think that the current social mechanisms for changing the Haskell 
> base library are less than ideal.  It sometimes feels like someone can 
> send a message to a mailing list with a "bright idea", and so long as 
> only a few people see it, and those that do see it do not object, the 
> proposal is automatically accepted.  That would be fine for any library 
> _except_ base, which I think ought to be much more stable.


Maybe we should try a voting scheme that entirely relies on rejection 
rather than acceptance. In such a scheme the solution that causes the 
minimal overall resistance would win.

From johan.tibell at gmail.com  Tue Jan 27 20:54:23 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 27 Jan 2015 12:54:23 -0800
Subject: Drastic Prelude changes imminent
In-Reply-To: <alpine.DEB.2.02.1501272143120.6362@sputnik>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
 <87C918EB-FE80-46ED-A46C-715DAE0908E1@me.com>
 <alpine.DEB.2.02.1501272143120.6362@sputnik>
Message-ID: <CAK-tuPbVHSP4d0nTP832amZgj6zP_o-KdCjhsDo+qAwPF42e7w@mail.gmail.com>

A point about process: I've been aware of this change for quite some time
but I wasn't aware of the details (e.g. the changes to Data.List). It's
easier to judge proposals like this if the complete list of changes are
listed in some proposal page.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/19604d3e/attachment.html>

From hvr at gnu.org  Tue Jan 27 21:05:53 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 27 Jan 2015 22:05:53 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAPeieQFhSZ8XOsdXvZhweC0d6oMR=yE0_-T_KQFUD=AaSXs-hw@mail.gmail.com>
 (Erik Hesselink's message of "Tue, 27 Jan 2015 17:31:39 +0100")
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAAJHNPDMmTJXjOW8KQNZ2NY+P52ZKLp5nycqzgvvBs6iO6PmEg@mail.gmail.com>
 <CAPeieQFhSZ8XOsdXvZhweC0d6oMR=yE0_-T_KQFUD=AaSXs-hw@mail.gmail.com>
Message-ID: <878ugovsr2.fsf@gnu.org>

On 2015-01-27 at 17:31:39 +0100, Erik Hesselink wrote:

[...]

> The only thing I can think of is to generalize Data.List when
> generalizing the prelude, but also introduce e.g. Data.List.Mono which
> has all the monomorphic variants.

I moved the original `Data.List` into `Data.OldList` early on during the
refactoring, and it was exposed for some time to allow packages like
haskell98/2010 to re-export the list-specialised versions. However,
since the haskell98/2010 packages were dropped from GHC 7.10 (as
implementing for swapping out the prelude would have required more
effort to do properly), `Data.OldList` was hidden from `base`. We could
still expose it again as `Data.List.Mono` (or some other name) if it
helps anybody.

For details see also

 http://git.haskell.org/ghc.git/commitdiff/e888b943396c21db74ba2fc69bf3a89e2473ea2b


-- hvr

From gabriel439 at gmail.com  Tue Jan 27 21:09:38 2015
From: gabriel439 at gmail.com (Gabriel Gonzalez)
Date: Tue, 27 Jan 2015 13:09:38 -0800
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAK-tuPbVHSP4d0nTP832amZgj6zP_o-KdCjhsDo+qAwPF42e7w@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
 <87C918EB-FE80-46ED-A46C-715DAE0908E1@me.com>
 <alpine.DEB.2.02.1501272143120.6362@sputnik>
 <CAK-tuPbVHSP4d0nTP832amZgj6zP_o-KdCjhsDo+qAwPF42e7w@mail.gmail.com>
Message-ID: <54C7FE92.5090209@gmail.com>

I think that all breaking changes that are approved on this mailing list 
should be migrated to a much more visible Github issue (i.e. 
https://github.com/ghc/ghc) before final approval.  You can still do all 
actual pull requests and coding via Phabricator, but the discussion 
should be on Github, because the barrier for new people to join in on 
the discussion is lower.  You will get a lot more discussion and 
visibility into these changes purely by using Github as the central forum.

This mailing list is not an appropriate forum for discussion for several 
reasons:

A) The volume of email is too high.  Only people who are experts at 
managing their inbox subscribe here.
B) There is too little signal to noise (for a beginner).  Why would a 
beginner want to join a mailing list that debates such dry topics as 
whether or not to add Data.Intersperse.sequence?
C) There's no (easy) way to subscribe to (or mute) a particular thread 
(unlike Github where you can easily watch or mute specific issues)

Pretty much everybody on this mailing list is a die-hard Haskell expert 
and that's not representative of the Haskell community at large.  
Migrating important topics to Github will give us a more representative 
sampling of the community and will also help centralize the discussion 
better.

On 1/27/15, 12:54 PM, Johan Tibell wrote:
> A point about process: I've been aware of this change for quite some 
> time but I wasn't aware of the details (e.g. the changes to 
> Data.List). It's easier to judge proposals like this if the complete 
> list of changes are listed in some proposal page.
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/d9dea998/attachment.html>

From david.feuer at gmail.com  Tue Jan 27 21:40:27 2015
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 27 Jan 2015 16:40:27 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <54C7FE92.5090209@gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
 <87C918EB-FE80-46ED-A46C-715DAE0908E1@me.com>
 <alpine.DEB.2.02.1501272143120.6362@sputnik>
 <CAK-tuPbVHSP4d0nTP832amZgj6zP_o-KdCjhsDo+qAwPF42e7w@mail.gmail.com>
 <54C7FE92.5090209@gmail.com>
Message-ID: <CAMgWh9tAZHctvsOxQ32yA5ABL4M6rTV66_q1wn_TxNaPVkCrVw@mail.gmail.com>

Github is not and has never been a focus for GHC development. It seems a
bit odd to separate things into "noise" on Trac and the mailing lists and,
theoretically, "signal" on GitHub. I agree that important community
discussions should not be happening on Phabricator, but they generally
aren't anyway.
On Jan 27, 2015 4:09 PM, "Gabriel Gonzalez" <gabriel439 at gmail.com> wrote:

>  I think that all breaking changes that are approved on this mailing list
> should be migrated to a much more visible Github issue (i.e.
> https://github.com/ghc/ghc) before final approval.  You can still do all
> actual pull requests and coding via Phabricator, but the discussion should
> be on Github, because the barrier for new people to join in on the
> discussion is lower.  You will get a lot more discussion and visibility
> into these changes purely by using Github as the central forum.
>
> This mailing list is not an appropriate forum for discussion for several
> reasons:
>
> A) The volume of email is too high.  Only people who are experts at
> managing their inbox subscribe here.
> B) There is too little signal to noise (for a beginner).  Why would a
> beginner want to join a mailing list that debates such dry topics as
> whether or not to add Data.Intersperse.sequence?
> C) There's no (easy) way to subscribe to (or mute) a particular thread
> (unlike Github where you can easily watch or mute specific issues)
>
> Pretty much everybody on this mailing list is a die-hard Haskell expert
> and that's not representative of the Haskell community at large.  Migrating
> important topics to Github will give us a more representative sampling of
> the community and will also help centralize the discussion better.
>
> On 1/27/15, 12:54 PM, Johan Tibell wrote:
>
>  A point about process: I've been aware of this change for quite some
> time but I wasn't aware of the details (e.g. the changes to Data.List).
> It's easier to judge proposals like this if the complete list of changes
> are listed in some proposal page.
>
>
> _______________________________________________
> Libraries mailing listLibraries at haskell.orghttp://www.haskell.org/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/d701faee/attachment.html>

From hvr at gnu.org  Tue Jan 27 21:52:38 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 27 Jan 2015 22:52:38 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <etPan.54c7ca10.2ae8944a.1a69@mbp.local> (Gershom B.'s message of
 "Tue, 27 Jan 2015 12:25:21 -0500")
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
Message-ID: <87y4onvql5.fsf@gnu.org>

On 2015-01-27 at 18:25:21 +0100, Gershom B wrote:

[...]

> We could perhaps also insert a warning encouraging people to import
> Data.List qualified, either in this GHC of the next release. This
> would allow BBP to proceed in a relatively breakage-free way in the
> future without needing to generalize the Data.List module.

Ironically, the AMP-related warnings in GHC 7.8 weren't very effective
at getting noticed timely in order to have Hackage ready for the actual
AMP-changes occurring in GHC 7.10. By far the most breakages[1] I
encountered (and reported) over the last weeks in
popularly-depended-upon packages were due to missing Functor/Applicative
instances. It'd be interesting to know why those warnings weren't
acted upon during 2014.

Otoh, I don't have numbers how many packages were actually fixed up
*thanks* to the GHC 7.8 warnings...


 [1]: FWIW, the AMP is a serious breaking change due to its nature of
      introducing a superclass constraint *incompatible* with H2010 as
      H2010 doesn't even know anything about the Applicative class to
      begin with...

      The BBP, on the other hand, in its incarnation as of GHC 7.10.1RC2
      was designed to be a smooth upgrade path for existing H2010 code
      as it just generalises type-signatures, and does not even require
      any CPP to write code that compiles with both, a strict
      Haskell2010 compiler+base-library, as well with GHC 7.10.1RC2's
      F/T-generalised base-library.

Cheers,
  hvr

From gabriel439 at gmail.com  Tue Jan 27 21:53:35 2015
From: gabriel439 at gmail.com (Gabriel Gonzalez)
Date: Tue, 27 Jan 2015 13:53:35 -0800
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAMgWh9tAZHctvsOxQ32yA5ABL4M6rTV66_q1wn_TxNaPVkCrVw@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>	<CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>	<87C918EB-FE80-46ED-A46C-715DAE0908E1@me.com>	<alpine.DEB.2.02.1501272143120.6362@sputnik>	<CAK-tuPbVHSP4d0nTP832amZgj6zP_o-KdCjhsDo+qAwPF42e7w@mail.gmail.com>	<54C7FE92.5090209@gmail.com>
 <CAMgWh9tAZHctvsOxQ32yA5ABL4M6rTV66_q1wn_TxNaPVkCrVw@mail.gmail.com>
Message-ID: <54C808DF.3020208@gmail.com>

Whether or not we use Github, you have to admit that the development 
process for core libraries is not very transparent in its current form.  
We have evidence for this right now: lots of people have been 
complaining that they never realized that this change got into GHC-7.10.

You don't have to adopt my specific suggestion, but you can't just keep 
doing business as usual either and pretend that there isn't a problem.  
If you reject my Github suggestion then propose a better solution for 
increasing the transparency and visibility of the process.

On 1/27/15, 1:40 PM, David Feuer wrote:
>
> Github is not and has never been a focus for GHC development. It seems 
> a bit odd to separate things into "noise" on Trac and the mailing 
> lists and, theoretically, "signal" on GitHub. I agree that important 
> community discussions should not be happening on Phabricator, but they 
> generally aren't anyway.
>
> On Jan 27, 2015 4:09 PM, "Gabriel Gonzalez" <gabriel439 at gmail.com 
> <mailto:gabriel439 at gmail.com>> wrote:
>
>     I think that all breaking changes that are approved on this
>     mailing list should be migrated to a much more visible Github
>     issue (i.e. https://github.com/ghc/ghc) before final approval. 
>     You can still do all actual pull requests and coding via
>     Phabricator, but the discussion should be on Github, because the
>     barrier for new people to join in on the discussion is lower.  You
>     will get a lot more discussion and visibility into these changes
>     purely by using Github as the central forum.
>
>     This mailing list is not an appropriate forum for discussion for
>     several reasons:
>
>     A) The volume of email is too high.  Only people who are experts
>     at managing their inbox subscribe here.
>     B) There is too little signal to noise (for a beginner). Why would
>     a beginner want to join a mailing list that debates such dry
>     topics as whether or not to add Data.Intersperse.sequence?
>     C) There's no (easy) way to subscribe to (or mute) a particular
>     thread (unlike Github where you can easily watch or mute specific
>     issues)
>
>     Pretty much everybody on this mailing list is a die-hard Haskell
>     expert and that's not representative of the Haskell community at
>     large.  Migrating important topics to Github will give us a more
>     representative sampling of the community and will also help
>     centralize the discussion better.
>
>     On 1/27/15, 12:54 PM, Johan Tibell wrote:
>>     A point about process: I've been aware of this change for quite
>>     some time but I wasn't aware of the details (e.g. the changes to
>>     Data.List). It's easier to judge proposals like this if the
>>     complete list of changes are listed in some proposal page.
>>
>>
>>     _______________________________________________
>>     Libraries mailing list
>>     Libraries at haskell.org  <mailto:Libraries at haskell.org>
>>     http://www.haskell.org/mailman/listinfo/libraries
>
>
>     _______________________________________________
>     Libraries mailing list
>     Libraries at haskell.org <mailto:Libraries at haskell.org>
>     http://www.haskell.org/mailman/listinfo/libraries
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/c6acb64a/attachment-0001.html>

From lemming at henning-thielemann.de  Tue Jan 27 21:57:35 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 27 Jan 2015 22:57:35 +0100 (CET)
Subject: Drastic Prelude changes imminent
In-Reply-To: <87y4onvql5.fsf@gnu.org>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local> <87y4onvql5.fsf@gnu.org>
Message-ID: <alpine.DEB.2.02.1501272255470.6362@sputnik>


On Tue, 27 Jan 2015, Herbert Valerio Riedel wrote:

> Ironically, the AMP-related warnings in GHC 7.8 weren't very effective
> at getting noticed timely in order to have Hackage ready for the actual
> AMP-changes occurring in GHC 7.10. By far the most breakages[1] I
> encountered (and reported) over the last weeks in
> popularly-depended-upon packages were due to missing Functor/Applicative
> instances. It'd be interesting to know why those warnings weren't
> acted upon during 2014.
>
> Otoh, I don't have numbers how many packages were actually fixed up
> *thanks* to the GHC 7.8 warnings...

I have added Applicative instances whereever suggested by GHC-7.8, but I 
have not recompiled all my packages since then and I have not released all 
updated packages. Maybe a year is just too short?

From lemming at henning-thielemann.de  Tue Jan 27 21:59:14 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Tue, 27 Jan 2015 22:59:14 +0100 (CET)
Subject: Drastic Prelude changes imminent
In-Reply-To: <54C808DF.3020208@gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
 <87C918EB-FE80-46ED-A46C-715DAE0908E1@me.com>
 <alpine.DEB.2.02.1501272143120.6362@sputnik>
 <CAK-tuPbVHSP4d0nTP832amZgj6zP_o-KdCjhsDo+qAwPF42e7w@mail.gmail.com>
 <54C7FE92.5090209@gmail.com>
 <CAMgWh9tAZHctvsOxQ32yA5ABL4M6rTV66_q1wn_TxNaPVkCrVw@mail.gmail.com>
 <54C808DF.3020208@gmail.com>
Message-ID: <alpine.DEB.2.02.1501272258000.6362@sputnik>


On Tue, 27 Jan 2015, Gabriel Gonzalez wrote:

> Whether or not we use Github, you have to admit that the development process for core libraries is not very
> transparent in its current form.? We have evidence for this right now: lots of people have been complaining
> that they never realized that this change got into GHC-7.10.
> 
> You don't have to adopt my specific suggestion, but you can't just keep doing business as usual either and
> pretend that there isn't a problem.? If you reject my Github suggestion then propose a better solution for
> increasing the transparency and visibility of the process.

We could warn about such a discussion in other mailing lists such as 
haskell, haskell-cafe, haskell-beginner, ghc-dev.

From cma at bitemyapp.com  Tue Jan 27 22:01:49 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Tue, 27 Jan 2015 16:01:49 -0600
Subject: Drastic Prelude changes imminent
In-Reply-To: <alpine.DEB.2.02.1501272258000.6362@sputnik>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
 <87C918EB-FE80-46ED-A46C-715DAE0908E1@me.com>
 <alpine.DEB.2.02.1501272143120.6362@sputnik>
 <CAK-tuPbVHSP4d0nTP832amZgj6zP_o-KdCjhsDo+qAwPF42e7w@mail.gmail.com>
 <54C7FE92.5090209@gmail.com>
 <CAMgWh9tAZHctvsOxQ32yA5ABL4M6rTV66_q1wn_TxNaPVkCrVw@mail.gmail.com>
 <54C808DF.3020208@gmail.com>
 <alpine.DEB.2.02.1501272258000.6362@sputnik>
Message-ID: <CADnndOqkJSUNp4v35ithS-mMxBgVBsv89JNWQgXUb3JvkAV9Hg@mail.gmail.com>

Could we not do both? Link to the Github issue in the mailing list post?
The mailing lists aren't as visible to the wider community as you might
think anyway.

On Tue, Jan 27, 2015 at 3:59 PM, Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> On Tue, 27 Jan 2015, Gabriel Gonzalez wrote:
>
>  Whether or not we use Github, you have to admit that the development
>> process for core libraries is not very
>> transparent in its current form.  We have evidence for this right now:
>> lots of people have been complaining
>> that they never realized that this change got into GHC-7.10.
>>
>> You don't have to adopt my specific suggestion, but you can't just keep
>> doing business as usual either and
>> pretend that there isn't a problem.  If you reject my Github suggestion
>> then propose a better solution for
>> increasing the transparency and visibility of the process.
>>
>
> We could warn about such a discussion in other mailing lists such as
> haskell, haskell-cafe, haskell-beginner, ghc-dev.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/dfc1a2b8/attachment.html>

From gabriel439 at gmail.com  Tue Jan 27 22:02:02 2015
From: gabriel439 at gmail.com (Gabriel Gonzalez)
Date: Tue, 27 Jan 2015 14:02:02 -0800
Subject: Drastic Prelude changes imminent
In-Reply-To: <alpine.DEB.2.02.1501272258000.6362@sputnik>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
 <87C918EB-FE80-46ED-A46C-715DAE0908E1@me.com>
 <alpine.DEB.2.02.1501272143120.6362@sputnik>
 <CAK-tuPbVHSP4d0nTP832amZgj6zP_o-KdCjhsDo+qAwPF42e7w@mail.gmail.com>
 <54C7FE92.5090209@gmail.com>
 <CAMgWh9tAZHctvsOxQ32yA5ABL4M6rTV66_q1wn_TxNaPVkCrVw@mail.gmail.com>
 <54C808DF.3020208@gmail.com> <alpine.DEB.2.02.1501272258000.6362@sputnik>
Message-ID: <54C80ADA.5020203@gmail.com>

On 1/27/15, 1:59 PM, Henning Thielemann wrote:
>
> We could warn about such a discussion in other mailing lists such as 
> haskell, haskell-cafe, haskell-beginner, ghc-dev.

That's a good start, but I'd prefer to also add non-email solutions for 
promoting visibility (i.e. social networks like Twitter, Google+, and 
Reddit).  For example, most of the reason this issue got a lot of 
visibility was the post to /r/haskell earlier today.

From greg at gregweber.info  Tue Jan 27 22:05:38 2015
From: greg at gregweber.info (Greg Weber)
Date: Tue, 27 Jan 2015 14:05:38 -0800
Subject: Drastic Prelude changes imminent
In-Reply-To: <54C80ADA.5020203@gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
 <87C918EB-FE80-46ED-A46C-715DAE0908E1@me.com>
 <alpine.DEB.2.02.1501272143120.6362@sputnik>
 <CAK-tuPbVHSP4d0nTP832amZgj6zP_o-KdCjhsDo+qAwPF42e7w@mail.gmail.com>
 <54C7FE92.5090209@gmail.com>
 <CAMgWh9tAZHctvsOxQ32yA5ABL4M6rTV66_q1wn_TxNaPVkCrVw@mail.gmail.com>
 <54C808DF.3020208@gmail.com> <alpine.DEB.2.02.1501272258000.6362@sputnik>
 <54C80ADA.5020203@gmail.com>
Message-ID: <CAKRanNCoJgcpcXvzXdtjKdmPLWFozYz4h0q9h7B8bx4J8VNbiQ@mail.gmail.com>

We already have a process that works pretty well. Create a wiki page that
specifies the implementation. Notifying every Haskell user is pointless if
there is no specification for them to look at. I have no idea why the
specification step was skipped for this change.

On Tue, Jan 27, 2015 at 2:02 PM, Gabriel Gonzalez <gabriel439 at gmail.com>
wrote:

> On 1/27/15, 1:59 PM, Henning Thielemann wrote:
>
>>
>> We could warn about such a discussion in other mailing lists such as
>> haskell, haskell-cafe, haskell-beginner, ghc-dev.
>>
>
> That's a good start, but I'd prefer to also add non-email solutions for
> promoting visibility (i.e. social networks like Twitter, Google+, and
> Reddit).  For example, most of the reason this issue got a lot of
> visibility was the post to /r/haskell earlier today.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/b29c9011/attachment.html>

From hvr at gnu.org  Tue Jan 27 22:17:23 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 27 Jan 2015 23:17:23 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <54C808DF.3020208@gmail.com> (Gabriel Gonzalez's message of "Tue, 
 27 Jan 2015 13:53:35 -0800")
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
 <87C918EB-FE80-46ED-A46C-715DAE0908E1@me.com>
 <alpine.DEB.2.02.1501272143120.6362@sputnik>
 <CAK-tuPbVHSP4d0nTP832amZgj6zP_o-KdCjhsDo+qAwPF42e7w@mail.gmail.com>
 <54C7FE92.5090209@gmail.com>
 <CAMgWh9tAZHctvsOxQ32yA5ABL4M6rTV66_q1wn_TxNaPVkCrVw@mail.gmail.com>
 <54C808DF.3020208@gmail.com>
Message-ID: <87r3ufvpfw.fsf@gnu.org>

Hello Gabriel,

On 2015-01-27 at 22:53:35 +0100, Gabriel Gonzalez wrote:
> Whether or not we use Github, you have to admit that the development
> process for core libraries is not very transparent in its current
> form.  We have evidence for this right now: lots of people have been
> complaining that they never realized that this change got into
> GHC-7.10.

Fwiw, this is what I commented already a couple of months ago addressing
a complaint that the changes were hidden from the public (although the
complaint was then revised to refer to the decisions being
non-transparent):

http://www.reddit.com/r/haskell/comments/2if0fu/on_concerns_about_haskells_prelude_favoring/cl2o86z

> You don't have to adopt my specific suggestion, but you can't just
> keep doing business as usual either and pretend that there isn't a
> problem.  If you reject my Github suggestion then propose a better
> solution for increasing the transparency and visibility of the
> process.

Just a thought (I heard elsewhere): We already have "GHC Weekly News",
what about "Haskell Libraries Weekly News" to cover the highlights
(especially library proposal) of this mailing list (if we can find a
volunteer to do the weekly write-up)?

> On 1/27/15, 1:40 PM, David Feuer wrote:

[...]


From ekmett at gmail.com  Tue Jan 27 22:17:36 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 27 Jan 2015 17:17:36 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
Message-ID: <CAJumaK9HnhEy+wdDuGjmnD2Qo+BOBfjon2t76wi3hJp6BwSFBw@mail.gmail.com>

On Tue, Jan 27, 2015 at 3:18 PM, Eric Mertens <emertens at gmail.com> wrote:

> I can certainly see the reasoning in wanting Data.List.foldr to actually
> be the list-specific one, and this would be consistent with other cases
> like Data.Map. Changing this might break some code, but it might be a more
> reasonable situation in the end. If we're going to consider this it would
> probably be better in its own thread so that it doesn't get drowned out by
> the rest of the BBP discussion.
>

The main reason this wasn't done is that we ran quick trial balloon to see
which style broke less code.

Looking through hackage for usage of Data.List, quite a bit of it is done
unqualified.

Monomorphizing Data.List combinators would break code that is written as

import Data.List
foo = ... foldr ...

Removing them would break code that is written as

import qualified Data.List as List
foo = ... List.foldr ...

Both of these styles were fairly common, though the former more so.

In an ideal world we'd have never put them in Data.List in the first place,
same with mapM etc. in Control.Monad, etc. and then something like
Lennart's proposal here would have been viable.

The main thing we can learn from this is that having modules that
"conveniently" re-export stuff is a dangerous thing in terms of long term
API design.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/a895b6e1/attachment-0001.html>

From mikolaj at well-typed.com  Tue Jan 27 22:18:34 2015
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Tue, 27 Jan 2015 23:18:34 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAKRanNCoJgcpcXvzXdtjKdmPLWFozYz4h0q9h7B8bx4J8VNbiQ@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
 <87C918EB-FE80-46ED-A46C-715DAE0908E1@me.com>
 <alpine.DEB.2.02.1501272143120.6362@sputnik>
 <CAK-tuPbVHSP4d0nTP832amZgj6zP_o-KdCjhsDo+qAwPF42e7w@mail.gmail.com>
 <54C7FE92.5090209@gmail.com>
 <CAMgWh9tAZHctvsOxQ32yA5ABL4M6rTV66_q1wn_TxNaPVkCrVw@mail.gmail.com>
 <54C808DF.3020208@gmail.com>
 <alpine.DEB.2.02.1501272258000.6362@sputnik>
 <54C80ADA.5020203@gmail.com>
 <CAKRanNCoJgcpcXvzXdtjKdmPLWFozYz4h0q9h7B8bx4J8VNbiQ@mail.gmail.com>
Message-ID: <CAHFo2ury5fVkpy2CebM=zbcz7jZHh7y_VJ-wSUeMjD=zbuXTfA@mail.gmail.com>

> We already have a process that works pretty well. Create a wiki page that
> specifies the implementation. Notifying every Haskell user is pointless if
> there is no specification for them to look at. I have no idea why the
> specification step was skipped for this change.

Because code was the shortest specification in this case?
Or, alternatively, the specification was too vague, as in,
the most sensible set of changes that make these 5 imports
coexist without an error? Or because the best specification
was a set of detailed, readable commit messages that show
the road from this vague specification to the actual decisions
and code changes? With lots of time in between for others
to offer suggestion for subsequent commits and catch problems?

I don't mean there's no communication problem, but specifications
are not always a solution. Perhaps a wiki page should list the commits,
as they were created. Or perhaps they were listed somewhere?

From greg at gregweber.info  Tue Jan 27 22:31:30 2015
From: greg at gregweber.info (Greg Weber)
Date: Tue, 27 Jan 2015 14:31:30 -0800
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAHFo2uoB5=dMWHHXgEcii0XiPdpygM+3hBhcrFbND5OCcX2xyw@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
 <87C918EB-FE80-46ED-A46C-715DAE0908E1@me.com>
 <alpine.DEB.2.02.1501272143120.6362@sputnik>
 <CAK-tuPbVHSP4d0nTP832amZgj6zP_o-KdCjhsDo+qAwPF42e7w@mail.gmail.com>
 <54C7FE92.5090209@gmail.com>
 <CAMgWh9tAZHctvsOxQ32yA5ABL4M6rTV66_q1wn_TxNaPVkCrVw@mail.gmail.com>
 <54C808DF.3020208@gmail.com> <alpine.DEB.2.02.1501272258000.6362@sputnik>
 <54C80ADA.5020203@gmail.com>
 <CAKRanNCoJgcpcXvzXdtjKdmPLWFozYz4h0q9h7B8bx4J8VNbiQ@mail.gmail.com>
 <CAHFo2uoB5=dMWHHXgEcii0XiPdpygM+3hBhcrFbND5OCcX2xyw@mail.gmail.com>
Message-ID: <CAKRanNArpG8ZR8zVuwukBnuwxX4FP1MkmVh9xyb8ZwrjYef4ew@mail.gmail.com>

On Tue, Jan 27, 2015 at 2:17 PM, Mikolaj Konarski <
mikolaj.konarski at gmail.com> wrote:

> > We already have a process that works pretty well. Create a wiki page that
> > specifies the implementation. Notifying every Haskell user is pointless
> if
> > there is no specification for them to look at. I have no idea why the
> > specification step was skipped for this change.
>
> Because code was the shortest specification in this case?
> Or, alternatively, the specification was too vague, as in,
> the most sensible set of changes that make these 5 imports
> coexist without an error? Or because the best specification
> was a set of detailed, readable commit messages that show
> the road from this vague specification to the actual decisions
> and code changes? With lots of time in between for others
> to offer suggestion for subsequent commits and catch problems?
>
> I don't mean there's no communication problem, but specifications
> are not always a solution. Perhaps a wiki page should list the commits,
> as they were created. Or perhaps they were listed somewhere?
>

None of these rhetorical questions are satisfactory.
I understand the need to iterate on a design and start with a vague
specification.
But by the time something concrete is figured out, it should be explained.
Explaining the iteration process with a few of the code examples would
answer a lot of the questions here.
In the end, the changes have been explained many times over now, just not
coherently in one place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/6f88d2a8/attachment.html>

From mikolaj at well-typed.com  Tue Jan 27 22:51:33 2015
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Tue, 27 Jan 2015 23:51:33 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAKRanNArpG8ZR8zVuwukBnuwxX4FP1MkmVh9xyb8ZwrjYef4ew@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
 <87C918EB-FE80-46ED-A46C-715DAE0908E1@me.com>
 <alpine.DEB.2.02.1501272143120.6362@sputnik>
 <CAK-tuPbVHSP4d0nTP832amZgj6zP_o-KdCjhsDo+qAwPF42e7w@mail.gmail.com>
 <54C7FE92.5090209@gmail.com>
 <CAMgWh9tAZHctvsOxQ32yA5ABL4M6rTV66_q1wn_TxNaPVkCrVw@mail.gmail.com>
 <54C808DF.3020208@gmail.com>
 <alpine.DEB.2.02.1501272258000.6362@sputnik>
 <54C80ADA.5020203@gmail.com>
 <CAKRanNCoJgcpcXvzXdtjKdmPLWFozYz4h0q9h7B8bx4J8VNbiQ@mail.gmail.com>
 <CAHFo2uoB5=dMWHHXgEcii0XiPdpygM+3hBhcrFbND5OCcX2xyw@mail.gmail.com>
 <CAKRanNArpG8ZR8zVuwukBnuwxX4FP1MkmVh9xyb8ZwrjYef4ew@mail.gmail.com>
Message-ID: <CAHFo2urLc_QtjVg8oXi4XJggPJP1ectvv8DAPSJio4NqEdVOJQ@mail.gmail.com>

> None of these rhetorical questions are satisfactory.
> I understand the need to iterate on a design and start with a vague
> specification.
> But by the time something concrete is figured out, it should be explained.
> Explaining the iteration process with a few of the code examples would
> answer a lot of the questions here.
> In the end, the changes have been explained many times over now, just not
> coherently in one place.

Greg, if that ticket was (it almost is:) a wiki page, would that be
satisfactory?

https://ghc.haskell.org/trac/ghc/ticket/9586

I assume it wasn't linked to and advertised enough.
Where would we need to link to it, how often (e.g., after each
major commit?) and what modifications would be necessary,
if it's not clear enough?

From allbery.b at gmail.com  Tue Jan 27 22:56:25 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 27 Jan 2015 17:56:25 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <87r3ufvpfw.fsf@gnu.org>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
 <87C918EB-FE80-46ED-A46C-715DAE0908E1@me.com>
 <alpine.DEB.2.02.1501272143120.6362@sputnik>
 <CAK-tuPbVHSP4d0nTP832amZgj6zP_o-KdCjhsDo+qAwPF42e7w@mail.gmail.com>
 <54C7FE92.5090209@gmail.com>
 <CAMgWh9tAZHctvsOxQ32yA5ABL4M6rTV66_q1wn_TxNaPVkCrVw@mail.gmail.com>
 <54C808DF.3020208@gmail.com> <87r3ufvpfw.fsf@gnu.org>
Message-ID: <CAKFCL4XwGf0PFm3K3V8r0B5eywhTnLyq7=ts1hOsELPwSer1LA@mail.gmail.com>

On Tue, Jan 27, 2015 at 5:17 PM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> Just a thought (I heard elsewhere): We already have "GHC Weekly News",
> what about "Haskell Libraries Weekly News" to cover the highlights
> (especially library proposal) of this mailing list (if we can find a
> volunteer to do the weekly write-up)?
>

I would argue that pointers to important stuff like this belong in the
Haskell Weekly News, which currently is more a collection of pithy quotes
and Reddit posts than a useful listing of important Haskell-related news.
Likewise, some things in the GHC weekly news could probably stand being at
least linked to in HWN.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/42d0fdd2/attachment.html>

From greg at gregweber.info  Tue Jan 27 23:05:05 2015
From: greg at gregweber.info (Greg Weber)
Date: Tue, 27 Jan 2015 15:05:05 -0800
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAHFo2urLc_QtjVg8oXi4XJggPJP1ectvv8DAPSJio4NqEdVOJQ@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
 <87C918EB-FE80-46ED-A46C-715DAE0908E1@me.com>
 <alpine.DEB.2.02.1501272143120.6362@sputnik>
 <CAK-tuPbVHSP4d0nTP832amZgj6zP_o-KdCjhsDo+qAwPF42e7w@mail.gmail.com>
 <54C7FE92.5090209@gmail.com>
 <CAMgWh9tAZHctvsOxQ32yA5ABL4M6rTV66_q1wn_TxNaPVkCrVw@mail.gmail.com>
 <54C808DF.3020208@gmail.com> <alpine.DEB.2.02.1501272258000.6362@sputnik>
 <54C80ADA.5020203@gmail.com>
 <CAKRanNCoJgcpcXvzXdtjKdmPLWFozYz4h0q9h7B8bx4J8VNbiQ@mail.gmail.com>
 <CAHFo2uoB5=dMWHHXgEcii0XiPdpygM+3hBhcrFbND5OCcX2xyw@mail.gmail.com>
 <CAKRanNArpG8ZR8zVuwukBnuwxX4FP1MkmVh9xyb8ZwrjYef4ew@mail.gmail.com>
 <CAHFo2urLc_QtjVg8oXi4XJggPJP1ectvv8DAPSJio4NqEdVOJQ@mail.gmail.com>
Message-ID: <CAKRanNCaA9GC=bP_fiitG_Q=P+-24iQ+KWXaQLtcfs9RJXYtDw@mail.gmail.com>

On Tue, Jan 27, 2015 at 2:51 PM, Mikolaj Konarski <mikolaj at well-typed.com>
wrote:

> > None of these rhetorical questions are satisfactory.
> > I understand the need to iterate on a design and start with a vague
> > specification.
> > But by the time something concrete is figured out, it should be
> explained.
> > Explaining the iteration process with a few of the code examples would
> > answer a lot of the questions here.
> > In the end, the changes have been explained many times over now, just not
> > coherently in one place.
>
> Greg, if that ticket was (it almost is:) a wiki page, would that be
> satisfactory?
>
> https://ghc.haskell.org/trac/ghc/ticket/9586
>
>
Perhaps, if the discussion on the ticket was summarized into an
explantation. But it is too much to wade through right now.


> I assume it wasn't linked to and advertised enough.
> Where would we need to link to it, how often (e.g., after each
> major commit?) and what modifications would be necessary,
> if it's not clear enough?
>

At some point a link to the proposal would need to appear in the mail list.
Updating as iteration occurs is a good question. That is going to end up
being a judgement call. Every time there is a major change or decision,
particularly among alternatives that cause breakage, it would be good to
mention it on the mail list. I would imagine that ended up happening a few
times in this case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/ce3e1ea1/attachment.html>

From garious at gmail.com  Tue Jan 27 23:16:14 2015
From: garious at gmail.com (Greg Fitzgerald)
Date: Tue, 27 Jan 2015 15:16:14 -0800
Subject: Upcoming GHC version (was: Re: Drastic Prelude changes imminent)
Message-ID: <CAFLa5WPH2-7uwgGcJXZnkO9bCKvwbEanSPQswyHLmiYqjeVfiQ@mail.gmail.com>

If BBP is going to be released as-is, can we please call the next
release GHC 8.0?

Good stuff: http://semver.org/

Thanks,
Greg


On Tue, Jan 27, 2015 at 10:22 AM, David Luposchainsky
<dluposchainsky at googlemail.com> wrote:
> Hello *,
>
> as much as I welcome these changes to the Prelude kitchen sink, I'm
> confused about how this does not make the release a major version bump.
> It changes half of the functions exposed by default in a dramatic way,
> after all. Do we want to keep GHC 8 for a new Report?
>
> Greetings,
> David/quchen
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

From kili at outback.escape.de  Tue Jan 27 23:29:27 2015
From: kili at outback.escape.de (Matthias Kilian)
Date: Wed, 28 Jan 2015 00:29:27 +0100
Subject: Upcoming GHC version (was: Re: Drastic Prelude changes imminent)
In-Reply-To: <CAFLa5WPH2-7uwgGcJXZnkO9bCKvwbEanSPQswyHLmiYqjeVfiQ@mail.gmail.com>
References: <CAFLa5WPH2-7uwgGcJXZnkO9bCKvwbEanSPQswyHLmiYqjeVfiQ@mail.gmail.com>
Message-ID: <20150127232927.GA22319@nutty.outback.escape.de>

On Tue, Jan 27, 2015 at 03:16:14PM -0800, Greg Fitzgerald wrote:
> If BBP is going to be released as-is, can we please call the next
> release GHC 8.0?

Adding semantics to release numbers? IMHO that doesn't work.

Ciao,
	Kili

From johan.tibell at gmail.com  Wed Jan 28 00:50:52 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 27 Jan 2015 16:50:52 -0800
Subject: Upcoming GHC version (was: Re: Drastic Prelude changes imminent)
In-Reply-To: <20150127232927.GA22319@nutty.outback.escape.de>
References: <CAFLa5WPH2-7uwgGcJXZnkO9bCKvwbEanSPQswyHLmiYqjeVfiQ@mail.gmail.com>
 <20150127232927.GA22319@nutty.outback.escape.de>
Message-ID: <CAK-tuPZm9ZhOf2a2c+5GnPHy1V8v-i9MRFjdNTU7RXsYGpGtNA@mail.gmail.com>

Note that the first two components in GHC's version number are both major,
so bumping to 7.8 is ok according to semver.

On Tue, Jan 27, 2015 at 3:29 PM, Matthias Kilian <kili at outback.escape.de>
wrote:

> On Tue, Jan 27, 2015 at 03:16:14PM -0800, Greg Fitzgerald wrote:
> > If BBP is going to be released as-is, can we please call the next
> > release GHC 8.0?
>
> Adding semantics to release numbers? IMHO that doesn't work.
>
> Ciao,
>         Kili
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/be848a0a/attachment.html>

From ivan.miljenovic at gmail.com  Wed Jan 28 09:53:35 2015
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Wed, 28 Jan 2015 20:53:35 +1100
Subject: Upcoming GHC version (was: Re: Drastic Prelude changes imminent)
In-Reply-To: <CAFLa5WPH2-7uwgGcJXZnkO9bCKvwbEanSPQswyHLmiYqjeVfiQ@mail.gmail.com>
References: <CAFLa5WPH2-7uwgGcJXZnkO9bCKvwbEanSPQswyHLmiYqjeVfiQ@mail.gmail.com>
Message-ID: <CA+u6gbwGqqGssX6=y-CfWL63B3rWToLzYKxd0X3Vj4NJTAr2Nw@mail.gmail.com>

On 28 January 2015 at 10:16, Greg Fitzgerald <garious at gmail.com> wrote:
> If BBP is going to be released as-is, can we please call the next
> release GHC 8.0?

Isn't this actually detailing changes to base rather than GHC as a compiler?

>
> Good stuff: http://semver.org/
>
> Thanks,
> Greg
>
>
> On Tue, Jan 27, 2015 at 10:22 AM, David Luposchainsky
> <dluposchainsky at googlemail.com> wrote:
>> Hello *,
>>
>> as much as I welcome these changes to the Prelude kitchen sink, I'm
>> confused about how this does not make the release a major version bump.
>> It changes half of the functions exposed by default in a dramatic way,
>> after all. Do we want to keep GHC 8 for a new Report?
>>
>> Greetings,
>> David/quchen
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries



-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
http://IvanMiljenovic.wordpress.com

From shumovichy at gmail.com  Wed Jan 28 09:53:22 2015
From: shumovichy at gmail.com (Yuras Shumovich)
Date: Wed, 28 Jan 2015 12:53:22 +0300
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAJumaK9HnhEy+wdDuGjmnD2Qo+BOBfjon2t76wi3hJp6BwSFBw@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <CALya091yp2opFLPFvSMpS-xkZw4yhujLsa8AcCNUtth3T3vrFQ@mail.gmail.com>
 <CAJumaK9HnhEy+wdDuGjmnD2Qo+BOBfjon2t76wi3hJp6BwSFBw@mail.gmail.com>
Message-ID: <1422438802.2805.16.camel@gmail.com>

On Tue, 2015-01-27 at 17:17 -0500, Edward Kmett wrote:
> On Tue, Jan 27, 2015 at 3:18 PM, Eric Mertens <emertens at gmail.com> wrote:
> 
> > I can certainly see the reasoning in wanting Data.List.foldr to actually
> > be the list-specific one, and this would be consistent with other cases
> > like Data.Map. Changing this might break some code, but it might be a more
> > reasonable situation in the end. If we're going to consider this it would
> > probably be better in its own thread so that it doesn't get drowned out by
> > the rest of the BBP discussion.
> >
> 
> The main reason this wasn't done is that we ran quick trial balloon to see
> which style broke less code.
> 
> Looking through hackage for usage of Data.List, quite a bit of it is done
> unqualified.
> 
> Monomorphizing Data.List combinators would break code that is written as
> 
> import Data.List
> foo = ... foldr ...
> 
> Removing them would break code that is written as
> 
> import qualified Data.List as List
> foo = ... List.foldr ...
> 
> Both of these styles were fairly common, though the former more so.
> 
> In an ideal world we'd have never put them in Data.List in the first place,
> same with mapM etc. in Control.Monad, etc. and then something like
> Lennart's proposal here would have been viable.
> 
> The main thing we can learn from this is that having modules that
> "conveniently" re-export stuff is a dangerous thing in terms of long term
> API design.

That is probably the first thing I completely agree it this thread.
Reexporting is a pure evil.

The biggest "reexporter" is Prelude. It should be deprecated all
together. Polluting namespace and massive reexporting don't worth few
keystrokes to import Data.List or Data.Foldable (both qualified). That
way the FTP becomes unnecessary.

(IMO generalizing Data.List doesn't sound like a good idea)

Thanks,
Yuras

> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries



From malcolm.wallace at me.com  Wed Jan 28 09:58:55 2015
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Wed, 28 Jan 2015 09:58:55 +0000
Subject: Upcoming GHC version (was: Re: Drastic Prelude changes imminent)
In-Reply-To: <CA+u6gbwGqqGssX6=y-CfWL63B3rWToLzYKxd0X3Vj4NJTAr2Nw@mail.gmail.com>
References: <CAFLa5WPH2-7uwgGcJXZnkO9bCKvwbEanSPQswyHLmiYqjeVfiQ@mail.gmail.com>
 <CA+u6gbwGqqGssX6=y-CfWL63B3rWToLzYKxd0X3Vj4NJTAr2Nw@mail.gmail.com>
Message-ID: <0036398E-9CEB-4597-B98D-5659C0173AFA@me.com>


On 28 Jan 2015, at 09:53, Ivan Lazar Miljenovic wrote:

> On 28 January 2015 at 10:16, Greg Fitzgerald <garious at gmail.com> wrote:
>> If BBP is going to be released as-is, can we please call the next
>> release GHC 8.0?
> 
> Isn't this actually detailing changes to base rather than GHC as a compiler?

The versions of GHC and the base library are inextricably linked.  You can't change the base library and keep the same compiler version.  (I don't think that is a good situation, but it is the way things stand.)

Regards,
    Malcolm

From Lennart.Augustsson at sc.com  Wed Jan 28 10:14:50 2015
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Wed, 28 Jan 2015 10:14:50 +0000
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>

I've updated the Wiki page (https://ghc.haskell.org/trac/ghc/wiki/BurningBridgesSlowly)
with what I think would be a sensible course of actions:

Simon Marlow rightly points out that adding a new LANGUAGE pragma is full of backwards compatibility problems.
So, here's a different plan how to introduce BBP.

* Leave Data.List type signatures and exports alone.
* Make ghc 7.10 warn when Data.List has been imported in a way that will break with BBP.
* No changes to Prelude signatures, but ship ghc 7.10 with PreludeBBP (which uses Foldable).
* Make PreludeBBP the default in ghc 7.12 (or later).

This will give us time to discuss exactly what should go into Foldable.

The signature changes in Control.Monad and other modules are unrelated to BBP and should be in ghc 7.10.

The ghc warning for importing Data.List should be as helpful as possible, something like:
Foo:5:1  Warning: Data.List imported unqualified, this will conflict with BBP.
         Instead use 'import Data.List(maximumBy, sortBy)'



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

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx  for important information with respect to derivative products.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150128/80f4442d/attachment.html>

From simonpj at microsoft.com  Wed Jan 28 10:57:40 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 28 Jan 2015 10:57:40 +0000
Subject: Drastic Prelude changes imminent
In-Reply-To: <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF562B8D4A@DB3PRD3001MB020.064d.mgd.msft.net>

|  I think that _if_ there had been a better organized, more clarifying
|  discussion on the scope of BBP earlier (one was promised after Neil
|  raised concerns, but I think it fell by the wayside), then we might
|  not be in this boat.
|  
|  Now, whatever the ?right? thing is eventually, it does feel like we
|  need to apply brakes until people can settle in further. I know people
|  will be disappointed no matter what happens, and they will feel this
|  stuff has moved slowly enough for long enough.
|  
|  However, without having had that discussion, I don?t see how we can
|  move forward.
|  
|  The proposal Lennart and Simon have therefore seems good and
|  necessary, save for the issue of how BBP infects Data.List in
|  particular as well.

Just to be clear, this isn't my proposal: it's from Lennart and Neil.  They did come to see me; I had indeed entirely missed the fact that the Prelude was changing so much; I did encourage them to explicitly and clearly air their concerns.  But I don't feel ready to take a personal position on how best to move forward.

I very much value what the Core Libraries Committee does.  Good libraries are a foundational component of a language and, although it's not very glamourous, working on making the libraries (particularly the core ones) work smoothly is incredibly valuable.  So we all owe huge thank you to the Core Libraries Committee.

It's unfortunate that all this has arisen so late in the 7.10 release cycle.  Perhaps I should have been paying more attention.  Perhaps the CLC should have published the proposal, and with clearer signposting.  Perhaps Lennart and Neil should have been more vocal earlier. But it's unproductive to discuss who to blame, and we probably all carry some responsibility.  (We might want to learn some lessons for the future, though; one being that changes to the Prelude need particular care and advertising.)

More important is what to do next.  Let's talk about how to resolve this during this week.  A small group of us (including Edward K and Lennart) plan to have a Skype call on Monday.  But the more we have a clear set of alternatives, the better.

Simon


From mail at joachim-breitner.de  Wed Jan 28 12:19:20 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 28 Jan 2015 13:19:20 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF562B8D4A@DB3PRD3001MB020.064d.mgd.msft.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
 <618BE556AADD624C9C918AA5D5911BEF562B8D4A@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <1422447560.1928.23.camel@joachim-breitner.de>

Hi,

Simon PJ mentions the Core Library committee in this context, but ?
being a member of that ? I must admit that even I were not aware of the
changes until they were underway.

After I saw the commits coming in I searched for information on the
proposal, but only found the ticket #9586 titled ?Implement
Traversable/Foldable-Burning-Bridges Proposal?, which made me expect
some actual proposal somewhere usually in the wiki, but it seems there
was none. There is a thread on libraries on Burning Bridges from May
2013, but it was not clear to me that that turned into something
concrete.

I concluded that I simply missed some discussion somewhere but
everything went it?s orderly way. I was uneasy about these changes, but
if in doubt I trust those who invest their time.


Somewhere in the current thread it was mentioned that it was at the
Haskell Implementors Workshop 2013 where this plan was created. I was
not there, so that?d explain why I wasn?t aware of the changes at that
time.


What lessens can we learn from the BBP process?

 * Personal meetings are great, but please remember to actively
   communicate results.

 * Proposal wiki pages, with motivation, examples, alternatives,
   have served us well. I?m not sure why that was skipped here.
   We should have them in the future.


Greetings,
Joachim



-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150128/48582a7e/attachment.sig>

From hvr at gnu.org  Wed Jan 28 13:45:49 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 28 Jan 2015 14:45:49 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>
 (Lennart Augustsson's message of "Wed, 28 Jan 2015 10:14:50 +0000")
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <87sievrpbm.fsf@gnu.org>

Lennart,

On 2015-01-28 at 11:14:50 +0100, Augustsson, Lennart wrote:
> I've updated the Wiki page (https://ghc.haskell.org/trac/ghc/wiki/BurningBridgesSlowly)
> with what I think would be a sensible course of actions:

[..]

While I'm still in the process of thinking through the plans/proposals
layed out on that wiki page, I'm somewhat missing what actual problem(s)
those proposals are trying to solve.

What's the actual problem/risk we're running into, if we instead go with
a "Proposal 0" which consists in `base-4.8` as currently implemented in
GHC 7.10.1RC2 going forward becoming part of GHC 7.10.1? It's not like
having something implemented in GHC makes it magically become written
into stone for the next Haskell Report.

We've been already preparing Hackage for this change in `base` since
even before GHC 7.10.1RC1 was released last year[1], with the implicit
assumption that the release-candidate would be very representative of
what GHC 7.10.1 is going to look like so Hackage upstream authors could
adapt their packages with confidence. When RC1 came out, Michael was so
kind to throw the Stackage-machinery at testing GHC 7.10 and informing
even more package-authors in case their packages needed attention.

Reverting BBP may cause additional work for those package authors that
adapted their packages by removing now redundant imports to achieve
perfect `-Wall`-hygiene.

So what are the tangible problems with the current BBP? Code-breakage
doesn't seem to be the issue here. To the contrary, you seem to rather
suggest to actively cause a major compatibility breakage in order to do
BBP "right" (as you consider generalising the signatures in `Data.List`
to be "wrong"[2] -- it would help if you could elaborate more concretely
what the actual problem is, so I can actually try to address that
concern).

-- hvr.

 [1]: Edward states in

      https://www.reddit.com/r/haskell/comments/2ttvsj/major_prelude_changes_proposed/co2m5su

      that 569 packages of the Stackage-set are building with GHC 7.10.1
      just fine

 [2]: https://www.reddit.com/r/haskell/comments/2ttvsj/major_prelude_changes_proposed/co3doue

From Lennart.Augustsson at sc.com  Wed Jan 28 13:56:20 2015
From: Lennart.Augustsson at sc.com (Augustsson, Lennart)
Date: Wed, 28 Jan 2015 13:56:20 +0000
Subject: Drastic Prelude changes imminent
In-Reply-To: <87sievrpbm.fsf@gnu.org>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>
 <87sievrpbm.fsf@gnu.org>
Message-ID: <22B950C955F8AB4196E72698FBD00002B940393E@UKWPIPXMB01A.zone1.scb.net>

I see some problems:

 * The changes of types to Data.List functions.  This is very counter-intuitive.
 * I don't think the methods in Foldable are quite the right ones
   (e.g., sum, product should not be there).  This would give the rest of us time
   to experiment with BBP since it would be very easy use (import Prelude(); import PreludeBBP).
 * Peace of mind.  A lot of people (even some in the libraries committee) found these changes
   a surprise.  A ghc warning about Data.List will ensure that everyone knows about them.


-----Original Message-----
From: Herbert Valerio Riedel [mailto:hvr at gnu.org] 
Sent: 28 January 2015 13:46
To: Augustsson, Lennart
Cc: libraries at haskell.org
Subject: Re: Drastic Prelude changes imminent

Lennart,

On 2015-01-28 at 11:14:50 +0100, Augustsson, Lennart wrote:
> I've updated the Wiki page 
> (https://ghc.haskell.org/trac/ghc/wiki/BurningBridgesSlowly)
> with what I think would be a sensible course of actions:

[..]

While I'm still in the process of thinking through the plans/proposals layed out on that wiki page, I'm somewhat missing what actual problem(s) those proposals are trying to solve.

What's the actual problem/risk we're running into, if we instead go with a "Proposal 0" which consists in `base-4.8` as currently implemented in GHC 7.10.1RC2 going forward becoming part of GHC 7.10.1? It's not like having something implemented in GHC makes it magically become written into stone for the next Haskell Report.

We've been already preparing Hackage for this change in `base` since even before GHC 7.10.1RC1 was released last year[1], with the implicit assumption that the release-candidate would be very representative of what GHC 7.10.1 is going to look like so Hackage upstream authors could adapt their packages with confidence. When RC1 came out, Michael was so kind to throw the Stackage-machinery at testing GHC 7.10 and informing even more package-authors in case their packages needed attention.

Reverting BBP may cause additional work for those package authors that adapted their packages by removing now redundant imports to achieve perfect `-Wall`-hygiene.

So what are the tangible problems with the current BBP? Code-breakage doesn't seem to be the issue here. To the contrary, you seem to rather suggest to actively cause a major compatibility breakage in order to do BBP "right" (as you consider generalising the signatures in `Data.List` to be "wrong"[2] -- it would help if you could elaborate more concretely what the actual problem is, so I can actually try to address that concern).

-- hvr.

 [1]: Edward states in

      https://www.reddit.com/r/haskell/comments/2ttvsj/major_prelude_changes_proposed/co2m5su

      that 569 packages of the Stackage-set are building with GHC 7.10.1
      just fine

 [2]: https://www.reddit.com/r/haskell/comments/2ttvsj/major_prelude_changes_proposed/co3doue

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

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

From greg at gregweber.info  Wed Jan 28 14:32:39 2015
From: greg at gregweber.info (Greg Weber)
Date: Wed, 28 Jan 2015 06:32:39 -0800
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B940393E@UKWPIPXMB01A.zone1.scb.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>
 <87sievrpbm.fsf@gnu.org>
 <22B950C955F8AB4196E72698FBD00002B940393E@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <CAKRanNDH_4Qd2qufeh8nPO6p8aBhUbBx_rG+qbyeyErSsCAYaQ@mail.gmail.com>

Here is a rough idea for how monomorphic list functions could be handled

1) export monorphic list functions from a differently name module. One
possibility is a `List` module (no `Data` prefix)
2) at some point (perhaps the next GHC release), have a deprecation warning
for the Data.List module

On Wed, Jan 28, 2015 at 5:56 AM, Augustsson, Lennart <
Lennart.Augustsson at sc.com> wrote:

> I see some problems:
>
>  * The changes of types to Data.List functions.  This is very
> counter-intuitive.
>  * I don't think the methods in Foldable are quite the right ones
>    (e.g., sum, product should not be there).  This would give the rest of
> us time
>    to experiment with BBP since it would be very easy use (import
> Prelude(); import PreludeBBP).
>  * Peace of mind.  A lot of people (even some in the libraries committee)
> found these changes
>    a surprise.  A ghc warning about Data.List will ensure that everyone
> knows about them.
>
>
> -----Original Message-----
> From: Herbert Valerio Riedel [mailto:hvr at gnu.org]
> Sent: 28 January 2015 13:46
> To: Augustsson, Lennart
> Cc: libraries at haskell.org
> Subject: Re: Drastic Prelude changes imminent
>
> Lennart,
>
> On 2015-01-28 at 11:14:50 +0100, Augustsson, Lennart wrote:
> > I've updated the Wiki page
> > (https://ghc.haskell.org/trac/ghc/wiki/BurningBridgesSlowly)
> > with what I think would be a sensible course of actions:
>
> [..]
>
> While I'm still in the process of thinking through the plans/proposals
> layed out on that wiki page, I'm somewhat missing what actual problem(s)
> those proposals are trying to solve.
>
> What's the actual problem/risk we're running into, if we instead go with a
> "Proposal 0" which consists in `base-4.8` as currently implemented in GHC
> 7.10.1RC2 going forward becoming part of GHC 7.10.1? It's not like having
> something implemented in GHC makes it magically become written into stone
> for the next Haskell Report.
>
> We've been already preparing Hackage for this change in `base` since even
> before GHC 7.10.1RC1 was released last year[1], with the implicit
> assumption that the release-candidate would be very representative of what
> GHC 7.10.1 is going to look like so Hackage upstream authors could adapt
> their packages with confidence. When RC1 came out, Michael was so kind to
> throw the Stackage-machinery at testing GHC 7.10 and informing even more
> package-authors in case their packages needed attention.
>
> Reverting BBP may cause additional work for those package authors that
> adapted their packages by removing now redundant imports to achieve perfect
> `-Wall`-hygiene.
>
> So what are the tangible problems with the current BBP? Code-breakage
> doesn't seem to be the issue here. To the contrary, you seem to rather
> suggest to actively cause a major compatibility breakage in order to do BBP
> "right" (as you consider generalising the signatures in `Data.List` to be
> "wrong"[2] -- it would help if you could elaborate more concretely what the
> actual problem is, so I can actually try to address that concern).
>
> -- hvr.
>
>  [1]: Edward states in
>
>
> https://www.reddit.com/r/haskell/comments/2ttvsj/major_prelude_changes_proposed/co2m5su
>
>       that 569 packages of the Stackage-set are building with GHC 7.10.1
>       just fine
>
>  [2]:
> https://www.reddit.com/r/haskell/comments/2ttvsj/major_prelude_changes_proposed/co3doue
>
> 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 a 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.
>
> Please visit
> http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx
> for important information with respect to derivative products.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150128/eb1cf46a/attachment.html>

From gershomb at gmail.com  Wed Jan 28 16:02:09 2015
From: gershomb at gmail.com (Gershom B)
Date: Wed, 28 Jan 2015 11:02:09 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF562B8D4A@DB3PRD3001MB020.064d.mgd.msft.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
 <618BE556AADD624C9C918AA5D5911BEF562B8D4A@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <etPan.54c90810.41b71efb.1a69@mbp.local>

On January 28, 2015 at 5:57:56 AM, Simon Peyton Jones (simonpj at microsoft.com) wrote:
> > Just to be clear, this isn't my proposal: it's from Lennart and  
> Neil. They did come to see me; I had indeed entirely missed the  
> fact that the Prelude was changing so much; I did encourage them  
> to explicitly and clearly air their concerns. But I don't feel  
> ready to take a personal position on how best to move forward.  

Thanks for the clarity Simon. Apologies for contributing to noise by a sloppy reading of earlier messages in this thread.

I?ve been advocating that it is important that a FAQ be written up on the BBP to make the maze of (careful) choices more understandable to a lay audience. That will at least help the discussion to not repeatedly cover the same ground. If nobody else manages to step in and do it, I?ll see what I can get done myself in the next few days.

Cheers,
Gershom

> I very much value what the Core Libraries Committee does. Good  
> libraries are a foundational component of a language and, although  
> it's not very glamourous, working on making the libraries (particularly  
> the core ones) work smoothly is incredibly valuable. So we all  
> owe huge thank you to the Core Libraries Committee.
>  
> It's unfortunate that all this has arisen so late in the 7.10 release  
> cycle. Perhaps I should have been paying more attention. Perhaps  
> the CLC should have published the proposal, and with clearer  
> signposting. Perhaps Lennart and Neil should have been more  
> vocal earlier. But it's unproductive to discuss who to blame,  
> and we probably all carry some responsibility. (We might want  
> to learn some lessons for the future, though; one being that changes  
> to the Prelude need particular care and advertising.)
>  
> More important is what to do next. Let's talk about how to resolve  
> this during this week. A small group of us (including Edward K  
> and Lennart) plan to have a Skype call on Monday. But the more we  
> have a clear set of alternatives, the better.
>  
> Simon


From ekmett at gmail.com  Wed Jan 28 17:35:01 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 28 Jan 2015 12:35:01 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>
Message-ID: <CAJumaK8aJVDX0rnh5n0v3ZMa9UQ7O5UpkSep6ET6F1gBfShLVA@mail.gmail.com>

On Wed, Jan 28, 2015 at 5:14 AM, Augustsson, Lennart <
Lennart.Augustsson at sc.com> wrote:

>  I've updated the Wiki page (
> https://ghc.haskell.org/trac/ghc/wiki/BurningBridgesSlowly)
>
> with what I think would be a sensible course of actions:
>
>
>
> Simon Marlow rightly points out that adding a new LANGUAGE pragma is full
> of backwards compatibility problems.
>
> So, here's a different plan how to introduce BBP.
>
>
>
> * Leave Data.List type signatures and exports alone.
>
> * Make ghc 7.10 warn when Data.List has been imported in a way that will
> break with BBP.
>
> * No changes to Prelude signatures, but ship ghc 7.10 with PreludeBBP
> (which uses Foldable).
>
> * Make PreludeBBP the default in ghc 7.12 (or later).
>
>
>
> This will give us time to discuss exactly what should go into Foldable.
>
>
>
> The signature changes in Control.Monad and other modules are unrelated to
> BBP and should be in ghc 7.10.
>
>
>
> The ghc warning for importing Data.List should be as helpful as possible,
> something like:
>
> Foo:5:1  Warning: Data.List imported unqualified, this will conflict with
> BBP.
>
>          Instead use 'import Data.List(maximumBy, sortBy)'
>
>
Upon reflection, I am prepared to seriously consider this approach.

There is an aspect of this proposal that I quite like.

Deprecating the re-exports in Data.List and Control.Monad is definitely a
good thing in the long term.

There is, however,  a question of whether it makes more sense to leave the
monomorphic combinators in Data.List that collide with the Prelude at all
after such a deprecation cycle. The warning you give by way of example
there says that 'importing this module unqualified will conflict with the
BBP' on the other hand, looking forward at the state that results in the
least long term confusion, we might prefer to say that if we import the
module explicitly listing a combinator that is already exported by the
Prelude but which will be generalized that it will conflict with the BBP.

e.g. it is

import Data.List (foldr)

It seems to me that in the long term removing the redundant export entirely
from base is the avenue that leads to the least confusion.

I've been eyeballing deprecating the re-exports of combinators from the mtl
for a long time, but have lacked a mechanism in the language for expressing
it.

Even if we don't implement the rest of the proposal, I would love to have
the ability to express these things.


*However,* I'd like you to seriously consider an alternative viewpoint,
which is that I strongly believe that what you are asking for actually
forces considerably more work for more people over the course of the next
year for few reasons:


1.) A large number of folks have been proactive in responding to the
release candidates for 7.10.1 by updating their packages to be 7.10-ready.
Several hundred packages have already been patched and uploaded to hackage,
most of the packages in stackage are 7.10 ready today.

https://github.com/fpco/stackage/issues/378

A significant subset of those would be broken by your proposal. This means
that there would now be hundreds of packages on hackage by our most active
contributors with broken versions that need to be manually made
uninstallable by an arcane process using the package management tools.


2.) An _alarming_ amount of code imports Control.Monad and then uses mapM
or imports Data.List unqualified. This is why we didn't remove those
combinators or ask for tools for deprecating them earlier in 7.10. The
deprecation cycle you are proposing affects easily an order of magnitude
more code than the proposed changes in 7.10, and worse it is often the kind
of code that is written by those least prepared to understand what is
happening. This is why above, I mentioned that it might be better to
consider a version of the proposal where the explicit import of a
combinator we'd like to remove as a re-export is flagged.



Ultimately the ability to deprecate a re-export would be useful as a way to
mitigate future changes, even if we decided to let BBP roll on in 7.10 due
to issue #1 above. We could also apply it to Data.List and the re-exported
combinators in Control.Monad (and those in the mtl) to get to a state where
future language changes can go through something much closer to the process
you have envisioned in this article.


So as a concrete alternative proposal, I'd like to suggest that we consider:

Shipping the BBP as planned.

Adding to GHC the ability to complain if a given re-export is the only way
a symbol finds its way into scope that you use, and apply those flags to
Control.Monad.mapM and a bunch of combinators in Data.List.*.

This would build a path that would enable us to in the future enact release
plans closer to what you have here, but would avoid forcing a huge pile of
double-work on all the folks who have already adapted their code.


On the other hand, I'm happy to revisit through the libraries@ process if
we want to head back to a 7.8-style Foldable. It strikes me, though, that
the better time to do that would have been 3 months ago when we had long
threads on the topic on the mailing list, rather than after the release
candidate.

If we did revisit the current design, it wouldn't come without a cost: If
we do that it would means that a number of key combinators in Data.Foldable
will necessarily change their stack behavior as they fold in different
directions currently than the Prelude combinators.

Adding the members enabled the [] instance to retain the current semantics,
and allowed users who don't like the behavior of 'sum' and the like to fix
it on a one-off basis on their own containers.

It seems that pushing for such a change needs to reach a much higher bar of
acceptance, as it results in existing code yielding different answers with
very different stack behavior.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150128/ca635b71/attachment.html>

From ekmett at gmail.com  Wed Jan 28 17:52:25 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 28 Jan 2015 12:52:25 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAJumaK8aJVDX0rnh5n0v3ZMa9UQ7O5UpkSep6ET6F1gBfShLVA@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>
 <CAJumaK8aJVDX0rnh5n0v3ZMa9UQ7O5UpkSep6ET6F1gBfShLVA@mail.gmail.com>
Message-ID: <CAJumaK8oaXtDeBT47rTT2TO59mEst_L3=s_F-htCd5hL5bgSCQ@mail.gmail.com>

Here is the seed of the current actions w.r.t. generalizing the combinators
in Data.List.

http://osdir.com/ml/libraries at haskell.org/2013-05/msg00324.html

Notice how a few posts in I'd mentioned that if we could deprecate the
export it'd yield a better final state which I still happen to believe.

On Wed, Jan 28, 2015 at 12:35 PM, Edward Kmett <ekmett at gmail.com> wrote:

> On Wed, Jan 28, 2015 at 5:14 AM, Augustsson, Lennart <
> Lennart.Augustsson at sc.com> wrote:
>
>>  I've updated the Wiki page (
>> https://ghc.haskell.org/trac/ghc/wiki/BurningBridgesSlowly)
>>
>> with what I think would be a sensible course of actions:
>>
>>
>>
>> Simon Marlow rightly points out that adding a new LANGUAGE pragma is full
>> of backwards compatibility problems.
>>
>> So, here's a different plan how to introduce BBP.
>>
>>
>>
>> * Leave Data.List type signatures and exports alone.
>>
>> * Make ghc 7.10 warn when Data.List has been imported in a way that will
>> break with BBP.
>>
>> * No changes to Prelude signatures, but ship ghc 7.10 with PreludeBBP
>> (which uses Foldable).
>>
>> * Make PreludeBBP the default in ghc 7.12 (or later).
>>
>>
>>
>> This will give us time to discuss exactly what should go into Foldable.
>>
>>
>>
>> The signature changes in Control.Monad and other modules are unrelated to
>> BBP and should be in ghc 7.10.
>>
>>
>>
>> The ghc warning for importing Data.List should be as helpful as possible,
>> something like:
>>
>> Foo:5:1  Warning: Data.List imported unqualified, this will conflict with
>> BBP.
>>
>>          Instead use 'import Data.List(maximumBy, sortBy)'
>>
>>
> Upon reflection, I am prepared to seriously consider this approach.
>
> There is an aspect of this proposal that I quite like.
>
> Deprecating the re-exports in Data.List and Control.Monad is definitely a
> good thing in the long term.
>
> There is, however,  a question of whether it makes more sense to leave the
> monomorphic combinators in Data.List that collide with the Prelude at all
> after such a deprecation cycle. The warning you give by way of example
> there says that 'importing this module unqualified will conflict with the
> BBP' on the other hand, looking forward at the state that results in the
> least long term confusion, we might prefer to say that if we import the
> module explicitly listing a combinator that is already exported by the
> Prelude but which will be generalized that it will conflict with the BBP.
>
> e.g. it is
>
> import Data.List (foldr)
>
> It seems to me that in the long term removing the redundant export
> entirely from base is the avenue that leads to the least confusion.
>
> I've been eyeballing deprecating the re-exports of combinators from the
> mtl for a long time, but have lacked a mechanism in the language for
> expressing it.
>
> Even if we don't implement the rest of the proposal, I would love to have
> the ability to express these things.
>
>
> *However,* I'd like you to seriously consider an alternative viewpoint,
> which is that I strongly believe that what you are asking for actually
> forces considerably more work for more people over the course of the next
> year for few reasons:
>
>
> 1.) A large number of folks have been proactive in responding to the
> release candidates for 7.10.1 by updating their packages to be 7.10-ready.
> Several hundred packages have already been patched and uploaded to hackage,
> most of the packages in stackage are 7.10 ready today.
>
> https://github.com/fpco/stackage/issues/378
>
> A significant subset of those would be broken by your proposal. This means
> that there would now be hundreds of packages on hackage by our most active
> contributors with broken versions that need to be manually made
> uninstallable by an arcane process using the package management tools.
>
>
> 2.) An _alarming_ amount of code imports Control.Monad and then uses mapM
> or imports Data.List unqualified. This is why we didn't remove those
> combinators or ask for tools for deprecating them earlier in 7.10. The
> deprecation cycle you are proposing affects easily an order of magnitude
> more code than the proposed changes in 7.10, and worse it is often the kind
> of code that is written by those least prepared to understand what is
> happening. This is why above, I mentioned that it might be better to
> consider a version of the proposal where the explicit import of a
> combinator we'd like to remove as a re-export is flagged.
>
>
>
> Ultimately the ability to deprecate a re-export would be useful as a way
> to mitigate future changes, even if we decided to let BBP roll on in 7.10
> due to issue #1 above. We could also apply it to Data.List and the
> re-exported combinators in Control.Monad (and those in the mtl) to get to a
> state where future language changes can go through something much closer to
> the process you have envisioned in this article.
>
>
> So as a concrete alternative proposal, I'd like to suggest that we
> consider:
>
> Shipping the BBP as planned.
>
> Adding to GHC the ability to complain if a given re-export is the only way
> a symbol finds its way into scope that you use, and apply those flags to
> Control.Monad.mapM and a bunch of combinators in Data.List.*.
>
> This would build a path that would enable us to in the future enact
> release plans closer to what you have here, but would avoid forcing a huge
> pile of double-work on all the folks who have already adapted their code.
>
>
> On the other hand, I'm happy to revisit through the libraries@ process if
> we want to head back to a 7.8-style Foldable. It strikes me, though, that
> the better time to do that would have been 3 months ago when we had long
> threads on the topic on the mailing list, rather than after the release
> candidate.
>
> If we did revisit the current design, it wouldn't come without a cost: If
> we do that it would means that a number of key combinators in Data.Foldable
> will necessarily change their stack behavior as they fold in different
> directions currently than the Prelude combinators.
>
> Adding the members enabled the [] instance to retain the current
> semantics, and allowed users who don't like the behavior of 'sum' and the
> like to fix it on a one-off basis on their own containers.
>
> It seems that pushing for such a change needs to reach a much higher bar
> of acceptance, as it results in existing code yielding different answers
> with very different stack behavior.
>
> -Edward
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150128/c1af0d06/attachment-0001.html>

From spam at scientician.net  Wed Jan 28 18:48:37 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Wed, 28 Jan 2015 19:48:37 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAJumaK8aJVDX0rnh5n0v3ZMa9UQ7O5UpkSep6ET6F1gBfShLVA@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>
 <CAJumaK8aJVDX0rnh5n0v3ZMa9UQ7O5UpkSep6ET6F1gBfShLVA@mail.gmail.com>
Message-ID: <mabau5$mpr$1@ger.gmane.org>

On 01/28/15 18:35, Edward Kmett wrote:

> So as a concrete alternative proposal, I'd like to suggest that we consider:
> 
> Shipping the BBP as planned.
> 
> Adding to GHC the ability to complain if a given re-export is the only way
> a symbol finds its way into scope that you use, and apply those flags to
> Control.Monad.mapM and a bunch of combinators in Data.List.*.
> 

+1, for all reasons mentioned.

It would be a slap in the face to all the hard work of the people who've
adapted their packages to force *another* breaking change this late in
the game.

Regrettable as the situation is, it's just too late to change this so
late in a release cycle, IMO. Having better mechanisms in place for
future evolutions of "base" would obviously be very desirable.

Regards,


From gershomb at gmail.com  Wed Jan 28 19:56:03 2015
From: gershomb at gmail.com (Gershom B)
Date: Wed, 28 Jan 2015 14:56:03 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <etPan.54c90810.41b71efb.1a69@mbp.local>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
 <618BE556AADD624C9C918AA5D5911BEF562B8D4A@DB3PRD3001MB020.064d.mgd.msft.net>
 <etPan.54c90810.41b71efb.1a69@mbp.local>
Message-ID: <CAM8RHpFJBd6cZSBAjZ2-fN+-6ayL1OFv+HKahUcnrowP2KK1Vg@mail.gmail.com>

I have gone ahead and created a wiki page with a draft FAQ on the
Foldable/Traversable proposal:
https://wiki.haskell.org/Foldable_Traversable_In_Prelude

I've attempted to hit the highlights that I can think of, but I'm sure
there's stuff either wrong or missing, or perhaps that could just be marked
up better.

Please, everyone, feel free to expand, clarify, or make minor or formatting
edits as you desire. If you feel there is something substantial that is
unaddressed (especially of the form "Why not X?", please email me off-list
and I'll try to work to cook up a proper addition to the page. Or, if you
have any edits that you think should happen but aren't equipped to edit the
wiki at the moment, I'l try to act on that too :-)

Hopefully, this can serve as a resource not only for the current
discussion, but to point people to regarding the final form of the proposal
as it actually takes shape in GHC 7.10.

--Gershom

On Wed, Jan 28, 2015 at 11:02 AM, Gershom B <gershomb at gmail.com> wrote:

> On January 28, 2015 at 5:57:56 AM, Simon Peyton Jones (
> simonpj at microsoft.com) wrote:
> > > Just to be clear, this isn't my proposal: it's from Lennart and
> > Neil. They did come to see me; I had indeed entirely missed the
> > fact that the Prelude was changing so much; I did encourage them
> > to explicitly and clearly air their concerns. But I don't feel
> > ready to take a personal position on how best to move forward.
>
> Thanks for the clarity Simon. Apologies for contributing to noise by a
> sloppy reading of earlier messages in this thread.
>
> I?ve been advocating that it is important that a FAQ be written up on the
> BBP to make the maze of (careful) choices more understandable to a lay
> audience. That will at least help the discussion to not repeatedly cover
> the same ground. If nobody else manages to step in and do it, I?ll see what
> I can get done myself in the next few days.
>
> Cheers,
> Gershom
>
> > I very much value what the Core Libraries Committee does. Good
> > libraries are a foundational component of a language and, although
> > it's not very glamourous, working on making the libraries (particularly
> > the core ones) work smoothly is incredibly valuable. So we all
> > owe huge thank you to the Core Libraries Committee.
> >
> > It's unfortunate that all this has arisen so late in the 7.10 release
> > cycle. Perhaps I should have been paying more attention. Perhaps
> > the CLC should have published the proposal, and with clearer
> > signposting. Perhaps Lennart and Neil should have been more
> > vocal earlier. But it's unproductive to discuss who to blame,
> > and we probably all carry some responsibility. (We might want
> > to learn some lessons for the future, though; one being that changes
> > to the Prelude need particular care and advertising.)
> >
> > More important is what to do next. Let's talk about how to resolve
> > this during this week. A small group of us (including Edward K
> > and Lennart) plan to have a Skype call on Monday. But the more we
> > have a clear set of alternatives, the better.
> >
> > Simon
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150128/1b54f30d/attachment.html>

From ben at smart-cactus.org  Wed Jan 28 20:09:33 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 28 Jan 2015 15:09:33 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <1422447560.1928.23.camel@joachim-breitner.de>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
 <618BE556AADD624C9C918AA5D5911BEF562B8D4A@DB3PRD3001MB020.064d.mgd.msft.net>
 <1422447560.1928.23.camel@joachim-breitner.de>
Message-ID: <87h9va7jlu.fsf@gmail.com>

Joachim Breitner <mail at joachim-breitner.de> writes:

> Hi,
>

snip

>  * Proposal wiki pages, with motivation, examples, alternatives,
>    have served us well. I?m not sure why that was skipped here.
>    We should have them in the future.
>
Perhaps just as important is to maintain a Wiki page listing the
proposals being considered by the CLC as well as the release milestones
for adopted proposals. As someone who followed the BBP proposal fairly
carefully in 2013, I was also a bit surprised when patches started
showing up this cycle.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150128/62126205/attachment.sig>

From ekmett at gmail.com  Wed Jan 28 20:45:40 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 28 Jan 2015 15:45:40 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <87h9va7jlu.fsf@gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
 <618BE556AADD624C9C918AA5D5911BEF562B8D4A@DB3PRD3001MB020.064d.mgd.msft.net>
 <1422447560.1928.23.camel@joachim-breitner.de>
 <87h9va7jlu.fsf@gmail.com>
Message-ID: <CAJumaK-NwntCf_oLAQRdTb7X4NKcQotqFBKuRQXUYNfypL7oEg@mail.gmail.com>

We started work on the Foldable/Traversable issue during 7.8, right after
the BBP process burned down and it was clear there was a strong desire to
see motion on that topic, and the core libraries committee was formed, but
decided not to act on anything during 7.8, as 7.8's release seemed immanent
at the time. Little did we know it'd drag on for another 7 months. Overall,
that proved to be a good thing, as we spent much of that time trying to
understand how to retie the Gordian knot that is the set of hs boot files
that makes up base.

But there is definitely a process concern. We've now had proposals that
'passed' a year ago or six months ago, that we're able now to implement,
now that we finally have folks in place that know how to work through the
existing process.

Most of these are small fixes, broadly agreed upon. Do we make someone who
already jumped through all the hoops to get a coherent proposal through the
process run and jump through them all again?

Once 7.10 started we set to work in earnest. A large part of the committee
work that has happened in 7.10 has been un-log-jamming issues that have
been stuck in trac on the libraries@ process with or without a patch. Some
of the bugs that had made it into trac had languished for years.

Most of the complications in the current design came about because of
things that only became obvious once the framework was in place.

I do agree that it is quite difficult to keep abreast of all that is
happening in GHC.

Part of that is a consequence of having an order of magnitude more cooks in
the kitchen these days. At the same time you have core libraries work going
on, we have a bunch of independent work going on on the front of how to
deal with SIMD instructions, swizzling, folks who care deeply about the
fate of DPH, a ton of exciting work on the cabal side that centers around
how to deal with finally solving 'cabal hell', complications induced by
considering the impact of Kilpatrick and Yang's work on Backpack, work on
the RTS and garbage collector, etc.

There are a lot more people active now. There were something like 40+
people actively contributing code at the beginning of last year, and that
number can only have grown since. When it was just the two Simons and
whatever couple of graduate students happened to stumble in, things
proceeded at a much more gentle pace. But with Simon Marlow moving on to
facebook, a lot of folks decided to pitch in to pick up the slack. It is
easy to keep track of the head-space of a smaller pool of contributors.

A whole new toolchain has been built up around using phabricator for code
review that has greatly improved the quality of the patches going into GHC.
This has helped a great deal, but if you think the libraries@ process is
hard to keep up with, well, there have been several hundred phabricator
patch reviews since the process started last year, mostly dealing with the
minutiae of how to integrate pre-existing trac tickets raised by libraries@
proposals or flat out ghc bug reports. ;)

We absolutely do need to work out more effective ways to communicate what
is going on.

There will be growing pains, there will be surprises, but we are all
pulling towards a common goal, that of making GHC be the best compiler it
can be for Haskell, and making continuing to strive towards making Haskell
be the best version of itself that it can be.

-Edward

On Wed, Jan 28, 2015 at 3:09 PM, Ben Gamari <ben at smart-cactus.org> wrote:

> Joachim Breitner <mail at joachim-breitner.de> writes:
>
> > Hi,
> >
>
> snip
>
> >  * Proposal wiki pages, with motivation, examples, alternatives,
> >    have served us well. I?m not sure why that was skipped here.
> >    We should have them in the future.
> >
> Perhaps just as important is to maintain a Wiki page listing the
> proposals being considered by the CLC as well as the release milestones
> for adopted proposals. As someone who followed the BBP proposal fairly
> carefully in 2013, I was also a bit surprised when patches started
> showing up this cycle.
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150128/50f6c422/attachment.html>

From ekmett at gmail.com  Wed Jan 28 21:18:00 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 28 Jan 2015 16:18:00 -0500
Subject: Upcoming GHC version (was: Re: Drastic Prelude changes imminent)
In-Reply-To: <0036398E-9CEB-4597-B98D-5659C0173AFA@me.com>
References: <CAFLa5WPH2-7uwgGcJXZnkO9bCKvwbEanSPQswyHLmiYqjeVfiQ@mail.gmail.com>
 <CA+u6gbwGqqGssX6=y-CfWL63B3rWToLzYKxd0X3Vj4NJTAr2Nw@mail.gmail.com>
 <0036398E-9CEB-4597-B98D-5659C0173AFA@me.com>
Message-ID: <CAJumaK8dyrzGTHD3pmdXsgz_MdHe_bj0pRGp38aDgZVv9zxUeA@mail.gmail.com>

If we can eventually make some headway on the split base proposal, then
eventually we might be able to let parts of base split off into separate
packages that can update at different rates.

With that a change to the behavior of, say, something in STM, doesn't need
to affect code that is written to a much smaller subset of the library, and
so that people who are building Haskell compilers for non-posix-like
backends can perhaps have a smaller set of things they'd have to implement
out of the gate.

Alas, as you noted, that isn't the world we have to day.

-Edward

On Wed, Jan 28, 2015 at 4:58 AM, Malcolm Wallace <malcolm.wallace at me.com>
wrote:

>
> On 28 Jan 2015, at 09:53, Ivan Lazar Miljenovic wrote:
>
> > On 28 January 2015 at 10:16, Greg Fitzgerald <garious at gmail.com> wrote:
> >> If BBP is going to be released as-is, can we please call the next
> >> release GHC 8.0?
> >
> > Isn't this actually detailing changes to base rather than GHC as a
> compiler?
>
> The versions of GHC and the base library are inextricably linked.  You
> can't change the base library and keep the same compiler version.  (I don't
> think that is a good situation, but it is the way things stand.)
>
> Regards,
>     Malcolm
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150128/2613d43e/attachment-0001.html>

From mail at joachim-breitner.de  Wed Jan 28 21:20:46 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 28 Jan 2015 22:20:46 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAJumaK-NwntCf_oLAQRdTb7X4NKcQotqFBKuRQXUYNfypL7oEg@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
 <618BE556AADD624C9C918AA5D5911BEF562B8D4A@DB3PRD3001MB020.064d.mgd.msft.net>
 <1422447560.1928.23.camel@joachim-breitner.de> <87h9va7jlu.fsf@gmail.com>
 <CAJumaK-NwntCf_oLAQRdTb7X4NKcQotqFBKuRQXUYNfypL7oEg@mail.gmail.com>
Message-ID: <1422480046.5392.4.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 28.01.2015, 15:45 -0500 schrieb Edward Kmett:


> We absolutely do need to work out more effective ways to communicate 
> what is going on.

I?d like to point out that the AMP proposal and process can serve as a
positive example. It is a change of comparable impact, but has sired
much less noise. My impression was that there were more people aware of
it, and sooner in the process, and that has helped. 


Maybe every possibly far-reaching change should be advertised with a
comic from now on? https://ro-che.info/ccc/21 :-)

Greetings,
Joachim
> 

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150128/621626e8/attachment.sig>

From ndmitchell at gmail.com  Wed Jan 28 21:24:51 2015
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Wed, 28 Jan 2015 21:24:51 +0000
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAJumaK8aJVDX0rnh5n0v3ZMa9UQ7O5UpkSep6ET6F1gBfShLVA@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>
 <CAJumaK8aJVDX0rnh5n0v3ZMa9UQ7O5UpkSep6ET6F1gBfShLVA@mail.gmail.com>
Message-ID: <CAKcFpmLYmBygrKQ=vOF=Ftsbxv63wQmSXv+B8hhFqRnUZXBRrg@mail.gmail.com>

>>> Just to be clear, this isn't my proposal: it's from Lennart and Neil.
>>>
>> The ghc warning for importing Data.List should be as helpful as possible,
>> something like:
>>
>> Foo:5:1  Warning: Data.List imported unqualified, this will conflict with
>> BBP.
>>
>>          Instead use 'import Data.List(maximumBy, sortBy)'
>
> Upon reflection, I am prepared to seriously consider this approach.

It should be noted that while I was there with Lennart when we talked
about the problems, my viewpoints and Lennart's are not identical. I
think the decision was insufficiently communicated (as seems to be
universally agreed), I think it's probably a bad idea to ever make
this change (I may well be in the minority here), and that the change
was done in the wrong way (see
http://neilmitchell.blogspot.co.uk/2014/10/how-to-rewrite-prelude.html
for how I think it should have been approached).

However, I'm not a fan of importing List qualified (I find that deeply
ugly), and a warning that I can't disable compatibly in older version
of GHC without CPP is pretty annoying - the GHC warning checker will
then be dictating personal style, and (in my very personal opinion) be
in the wrong. I raised this issue in October, I fought my corner
through blog posts and reddit, and I lost - I considered that the end.
The Core libraries committee have done the work, and at this stage, to
back out will be a fantastic amount of work. I don't have the time to
put in that amount of work, and I think it unfair to demand those who
are for BBP to do the work for me.

At the same time, I have more than once picked the "easy option" in
the short term when coding, been warned by Lennart that I was making a
mistake, and then discovered down the line that Lennart was right.
Making mistakes with Prelude is going to be costly.

Thanks, Neil

From ekmett at gmail.com  Wed Jan 28 21:37:34 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 28 Jan 2015 16:37:34 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <1422480046.5392.4.camel@joachim-breitner.de>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
 <618BE556AADD624C9C918AA5D5911BEF562B8D4A@DB3PRD3001MB020.064d.mgd.msft.net>
 <1422447560.1928.23.camel@joachim-breitner.de>
 <87h9va7jlu.fsf@gmail.com>
 <CAJumaK-NwntCf_oLAQRdTb7X4NKcQotqFBKuRQXUYNfypL7oEg@mail.gmail.com>
 <1422480046.5392.4.camel@joachim-breitner.de>
Message-ID: <CAJumaK8V3vWZmSNjZi_quSyEn2zZxLrqFS1vK2v6NX-6-P5PdA@mail.gmail.com>

AMP started at the same time as the BBP, both were started by threads of
roughly the same size, with the same level of active participation. The
major difference is no warnings were added for the Foldable/Traversable
proposal as at the time, generalizing types was seen as pretty simple.

e.g. foldMap comes into scope without a warning in 7.10 due to BBP, but
then (<*>) also comes into scope in the AMP and we didn't warn for that,
either.

I do fully agree that the BBP could have gone in a bit cleaner if we'd
realized the full scope of the issues we would face during the 7.8
timeline. Most of the hiccups only came clear after Herbert had spent
months refactoring the internals of base to even make the change possible.

Just an aside, though, it does appear objectively that those warnings
actually did very little good in terms of getting folks to fix their code.
By far the vast majority of the 7.10 related breakage we've seen has come
from folks who still don't have Applicative instances for their Monad.

-Edward

On Wed, Jan 28, 2015 at 4:20 PM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Mittwoch, den 28.01.2015, 15:45 -0500 schrieb Edward Kmett:
>
>
> > We absolutely do need to work out more effective ways to communicate
> > what is going on.
>
> I?d like to point out that the AMP proposal and process can serve as a
> positive example. It is a change of comparable impact, but has sired
> much less noise. My impression was that there were more people aware of
> it, and sooner in the process, and that has helped.
>
>
> Maybe every possibly far-reaching change should be advertised with a
> comic from now on? https://ro-che.info/ccc/21 :-)
>
> Greetings,
> Joachim
> >
>
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150128/22285b49/attachment.html>

From hvr at gnu.org  Wed Jan 28 22:22:42 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 28 Jan 2015 23:22:42 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAJumaK-NwntCf_oLAQRdTb7X4NKcQotqFBKuRQXUYNfypL7oEg@mail.gmail.com>
 (Edward Kmett's message of "Wed, 28 Jan 2015 15:45:40 -0500")
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B94033F1@UKWPIPXMB01A.zone1.scb.net>
 <CAK-tuPbsCdw37tLS473+vx-o81CmyQaP414zUxtDb4+R7JFqyw@mail.gmail.com>
 <CAPeieQEy7WatJP-xh_e7a_aOJuGz2Y0GJ-Jt764jMmpwPjrF_w@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B940343A@UKWPIPXMB01A.zone1.scb.net>
 <CAPeieQH0O5qPVTAPAZ91-Gi4GP-XAvDVk6QrL=KnbBRNXofCFA@mail.gmail.com>
 <CAOrUaLbm=8KXX3fnNuvj++2nVcdAa2K8xEoLhHXz5R6s=f44aQ@mail.gmail.com>
 <CAMgWh9uS_YvSRpsG3Bmuc-ofV4p+A8jhJ10E8D1KA4zAqPEvsg@mail.gmail.com>
 <22B950C955F8AB4196E72698FBD00002B94034A8@UKWPIPXMB01A.zone1.scb.net>
 <etPan.54c7ca10.2ae8944a.1a69@mbp.local>
 <618BE556AADD624C9C918AA5D5911BEF562B8D4A@DB3PRD3001MB020.064d.mgd.msft.net>
 <1422447560.1928.23.camel@joachim-breitner.de>
 <87h9va7jlu.fsf@gmail.com>
 <CAJumaK-NwntCf_oLAQRdTb7X4NKcQotqFBKuRQXUYNfypL7oEg@mail.gmail.com>
Message-ID: <87egqesfyl.fsf@gnu.org>

On 2015-01-28 at 21:45:40 +0100, Edward Kmett wrote:
> We started work on the Foldable/Traversable issue during 7.8, right after
> the BBP process burned down and it was clear there was a strong desire to
> see motion on that topic, and the core libraries committee was formed, but
> decided not to act on anything during 7.8, as 7.8's release seemed immanent
> at the time. Little did we know it'd drag on for another 7 months. Overall,
> that proved to be a good thing, as we spent much of that time trying to
> understand how to retie the Gordian knot that is the set of hs boot files
> that makes up base.

[...]

On a technical note, there was also an inter-dependency with the AMP
implementation, as both needed many modifications in the same places. So
Austin went first with the AMP, and as soon as that was done (which
turned out to be quite more tricky and took much longer than
anticipated), I started addressing the BBP implementation based on the
post-AMP state (while trying to get this done quickly enough not cause
too many merge-conflicts with other commits that were being pushed to
HEAD as well as `base`-patches being submitted to Phabricator...)

Cheers,
  hvr

From hvr at gnu.org  Wed Jan 28 22:33:06 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 28 Jan 2015 23:33:06 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAJumaK8aJVDX0rnh5n0v3ZMa9UQ7O5UpkSep6ET6F1gBfShLVA@mail.gmail.com>
 (Edward Kmett's message of "Wed, 28 Jan 2015 12:35:01 -0500")
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>
 <CAJumaK8aJVDX0rnh5n0v3ZMa9UQ7O5UpkSep6ET6F1gBfShLVA@mail.gmail.com>
Message-ID: <87a912sfh9.fsf@gnu.org>

On 2015-01-28 at 18:35:01 +0100, Edward Kmett wrote:

[...]

> Adding to GHC the ability to complain if a given re-export is the only way
> a symbol finds its way into scope that you use, and apply those flags to
> Control.Monad.mapM and a bunch of combinators in Data.List.*.

...I think the 4-year-old #4879 GHC ticket covers that ability?

 [1]: https://ghc.haskell.org/trac/ghc/ticket/4879

From ekmett at gmail.com  Wed Jan 28 23:12:28 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 28 Jan 2015 18:12:28 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <87a912sfh9.fsf@gnu.org>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>
 <CAJumaK8aJVDX0rnh5n0v3ZMa9UQ7O5UpkSep6ET6F1gBfShLVA@mail.gmail.com>
 <87a912sfh9.fsf@gnu.org>
Message-ID: <CAJumaK-kD5jcw-Ef+YCLa7CxCL5DEUoeGxiOprfhp7S6Z2OdzA@mail.gmail.com>

That is the one. =)

My previous thinking on this had been to figure out how to get deprecated
exports implemented early in 7.12, so we could put in a proposal to
libraries@ to use it to clean up the nonsensical generalizations of the
Data.List combinators, and go back and address several Control.Monad
re-exports like, mapM and the mtl Monad re-exports in 7.14.

That would make it easier to use push towards a world where we _can_
implement something like an alternate Prelude as mostly an import-only
decision in the future.

For all that I don't see a good way to deal with Foldable/Traversable
changes in such a manner at this point, I happen to agree in general with
the approach that Neil espouses about how to evolve the language, and
removing barriers such as these to eventually following that model would be
more or less an unmitigatedly good thing.

Now, if we could get deprecated exports earlier we could theoretically put
those deprecations in place now.

But it seems to me that putting even that mechanism in place and agreeing
on a plan of action around how to use it would be a lot to cram in to try
to add here at the very end of 7.10 and risks missing cases, like we did
when we rushed out the AMP warnings at the end of 7.8.

The benefit of going down that road rather than a WEAK pragma is that it
avoids introducing a new mechanic for how name resolution works that
complicates the language, a deprecated export pragma by way of comparison
is generally useful and can be ignored by compilers that don't understand
it, even when used in third-party code.

The benefits of a WEAK pragma is that it _could_ be shored up and made a
part of the language, but it is admittedly a rather odd pragma. Adding such
a construction is a topic that has come up a few times before with lukewarm
reception. Most existing pragmas can be sensibly ignored by compilers that
don't know about them. By way of comparison existing pragmas like
SPECIALIZE, SOURCE, [NO]INLINE, UNPACK, WARNING, DEPRECATED, etc. don't
change the way names resolve for the entire program.

It seems a messy solution to rush a language extension in that we may
regret later and simultaneously break all of the code that has already been
made 7.10-ready.

-Edward

On Wed, Jan 28, 2015 at 5:33 PM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> On 2015-01-28 at 18:35:01 +0100, Edward Kmett wrote:
>
> [...]
>
> > Adding to GHC the ability to complain if a given re-export is the only
> way
> > a symbol finds its way into scope that you use, and apply those flags to
> > Control.Monad.mapM and a bunch of combinators in Data.List.*.
>
> ...I think the 4-year-old #4879 GHC ticket covers that ability?
>
>  [1]: https://ghc.haskell.org/trac/ghc/ticket/4879
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150128/e1162ec2/attachment-0001.html>

From mark.lentczner at gmail.com  Sat Jan 31 06:18:53 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Fri, 30 Jan 2015 22:18:53 -0800
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAJumaK-kD5jcw-Ef+YCLa7CxCL5DEUoeGxiOprfhp7S6Z2OdzA@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>
 <CAJumaK8aJVDX0rnh5n0v3ZMa9UQ7O5UpkSep6ET6F1gBfShLVA@mail.gmail.com>
 <87a912sfh9.fsf@gnu.org>
 <CAJumaK-kD5jcw-Ef+YCLa7CxCL5DEUoeGxiOprfhp7S6Z2OdzA@mail.gmail.com>
Message-ID: <CAAOoiFYuOpParQPeGX219EAVv5SBOOASwOnGP3Tr5LSFszWBMQ@mail.gmail.com>

I'm sorry for being so behind the times, and now have to write this at this
stage...

BBP deeply saddens me. While I understand the desire for a more generalized
Prelude (surely this is one of the seven stages of Haskell, along with
"need to write a Monad tutorial"....), I don't think the ends come anywhere
close to justifying the means.

I realize I'm often (always?) the voice of stodginess. But I'll tell where
I'm coming from: I want to get people to adopt Haskell for serious software
development. But that means I have get them to buy into an ecosystem and
for them to do so they need to feel it will be stable on the order decades.
They need to feel that before they're going to be willing to invest in the
tooling, the process development, and committing their work to Haskell.

In 1990 most shops wouldn't ship software in C++ because none of us trusted
the compilers, or that language (already C++ 2.0) wouldn't change in ways
that would be unpredictable and negatively affect our work. It took almost
another decade. In 2005 many places still wouldn't ship things using STL.
It takes a long time for people to trust that an ecosystem has stabilized.

"Burning Bridges". The name says it all. We cannot do this. We have to look
well beyond how a change like this affects compiling a bunch of code form
stackage... We have to think beyond the discussions on our mailing lists...
Think of the text books, the corse syllabuses, the in-house trainings,
think of work flow and deployment processes.. think of vast amounts of code
we can't see... We cannot undermine the Prelude and Data.List that they are
all built on.

If we make a change like this, we've just told the world to wait another 10
years before considering Haskell.


The sadder thing is that I don't think the proposal really adds much to
Haskell:

The value of generalizing the list functions greatly over estimated: There
have been alternate, more generalized Preludes for ages... and I don't see
much use of them. Sure, they require some futzing with imports to use - but
that isn't that high of a bar, and yet clearly their value rarely merits it
in people's minds. Maybe I don't write the most clever code (code golf
excepted), but I rarely pine for a more generalized length. Or for all to
work over Foldable... etc.

For the few times when I need something like Foldable I don't see what the
issue is with importing qualified and using prefixes. People here seem to
feel that a "F." is somehow an ugly wart on their code... but that is just
the way it is with most software: You need a lot of things in scope, you
use namespaces of one sort or another.


There's also a whole issue of commitment to forward and backward
compatibility that we as a community don't yet have. Littering our code
with CPP is not really acceptable. And all production code insists on clean
compilation with -Wall, so we can't be spewing warnings. Or for that matter
playing tricks with import orders. This stuff is tricky and hard... no
doubt, but it is the price of a bid at adoption.


All in all, what saddens me here is that this whole episode, like the
similar one around roles and 7.8, is indicative that on the whole, we as a
community, are not ready to hunker down and work toward making Haskell a
solid tool for software development. We are, instead, too fascinated with
making it more perfect.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150130/0db12cea/attachment.html>

From davean at xkcd.com  Sat Jan 31 06:43:03 2015
From: davean at xkcd.com (davean)
Date: Sat, 31 Jan 2015 01:43:03 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAAOoiFYuOpParQPeGX219EAVv5SBOOASwOnGP3Tr5LSFszWBMQ@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>
 <CAJumaK8aJVDX0rnh5n0v3ZMa9UQ7O5UpkSep6ET6F1gBfShLVA@mail.gmail.com>
 <87a912sfh9.fsf@gnu.org>
 <CAJumaK-kD5jcw-Ef+YCLa7CxCL5DEUoeGxiOprfhp7S6Z2OdzA@mail.gmail.com>
 <CAAOoiFYuOpParQPeGX219EAVv5SBOOASwOnGP3Tr5LSFszWBMQ@mail.gmail.com>
Message-ID: <CABFs2VjALRTCyMV=BKVDpAOus+VffpSbGdNQmRc7ygvxHhB4uw@mail.gmail.com>

On Sat, Jan 31, 2015 at 1:18 AM, Mark Lentczner <mark.lentczner at gmail.com>
wrote:

> I'm sorry for being so behind the times, and now have to write this at
> this stage...
>
> BBP deeply saddens me. While I understand the desire for a more
> generalized Prelude (surely this is one of the seven stages of Haskell,
> along with "need to write a Monad tutorial"....), I don't think the ends
> come anywhere close to justifying the means.
>

It is very painful the prelude isn't more generalized. Its the first thing
that bit me learning Haskell and its pained me the entire time I've used it.


> I realize I'm often (always?) the voice of stodginess. But I'll tell where
> I'm coming from: I want to get people to adopt Haskell for serious software
> development. But that means I have get them to buy into an ecosystem and
> for them to do so they need to feel it will be stable on the order decades.
> They need to feel that before they're going to be willing to invest in the
> tooling, the process development, and committing their work to Haskell.
>

Personally, I want a language thats good to use. That means constant
improvement. My life gets better by far more then it costs me to update
some code in fairly trivial ways when the language or libraries change. In
fact, Haskell makes updates easy. Why should we instead build up the need
to replace the language with a new one, how is that better? We can have
constant gradual improvement, or force an entire change of language. I for
one will take a constant improvement every time.


> In 1990 most shops wouldn't ship software in C++ because none of us
> trusted the compilers, or that language (already C++ 2.0) wouldn't change
> in ways that would be unpredictable and negatively affect our work. It took
> almost another decade. In 2005 many places still wouldn't ship things using
> STL. It takes a long time for people to trust that an ecosystem has
> stabilized.
>

I think they're exactly who not to take our queues from. I think they're
the perfect example of how to make bad software and I really don't want to
be them.


> "Burning Bridges". The name says it all. We cannot do this. We have to
> look well beyond how a change like this affects compiling a bunch of code
> form stackage... We have to think beyond the discussions on our mailing
> lists... Think of the text books, the corse syllabuses, the in-house
> trainings, think of work flow and deployment processes.. think of vast
> amounts of code we can't see... We cannot undermine the Prelude and
> Data.List that they are all built on.
>

Alternative we must do it to keep advancing.


> If we make a change like this, we've just told the world to wait another
> 10 years before considering Haskell.
>

Or told people who should consider Haskell. Perhaps that is good.

The sadder thing is that I don't think the proposal really adds much to
> Haskell:
>
> The value of generalizing the list functions greatly over estimated: There
> have been alternate, more generalized Preludes for ages... and I don't see
> much use of them. Sure, they require some futzing with imports to use - but
> that isn't that high of a bar, and yet clearly their value rarely merits it
> in people's minds. Maybe I don't write the most clever code (code golf
> excepted), but I rarely pine for a more generalized length. Or for all to
> work over Foldable... etc.
>
> For the few times when I need something like Foldable I don't see what the
> issue is with importing qualified and using prefixes. People here seem to
> feel that a "F." is somehow an ugly wart on their code... but that is just
> the way it is with most software: You need a lot of things in scope, you
> use namespaces of one sort or another.
>
>
> There's also a whole issue of commitment to forward and backward
> compatibility that we as a community don't yet have. Littering our code
> with CPP is not really acceptable. And all production code insists on clean
> compilation with -Wall, so we can't be spewing warnings. Or for that matter
> playing tricks with import orders. This stuff is tricky and hard... no
> doubt, but it is the price of a bid at adoption.
>

And we shouldn't have it. Its good we don't have it. Its why I'm here
frankly. The constant drive for improvement is how its solve the problems
that make it worth coding in. Lets instead of being adopted have the best
language possible and the most pleasant time programming in it. Lets not
tear our hair out because someone made a bad decision in the 1980s and now
we're stuck with it. I've done that. It was terrible. The world doesn't
need another language that makes that mistake.

All in all, what saddens me here is that this whole episode, like the
> similar one around roles and 7.8, is indicative that on the whole, we as a
> community, are not ready to hunker down and work toward making Haskell a
> solid tool for software development. We are, instead, too fascinated with
> making it more perfect.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150131/4ff74113/attachment.html>

From hvr at gnu.org  Sat Jan 31 09:57:04 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Sat, 31 Jan 2015 10:57:04 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAAOoiFYuOpParQPeGX219EAVv5SBOOASwOnGP3Tr5LSFszWBMQ@mail.gmail.com>
 (Mark Lentczner's message of "Fri, 30 Jan 2015 22:18:53 -0800")
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>
 <CAJumaK8aJVDX0rnh5n0v3ZMa9UQ7O5UpkSep6ET6F1gBfShLVA@mail.gmail.com>
 <87a912sfh9.fsf@gnu.org>
 <CAJumaK-kD5jcw-Ef+YCLa7CxCL5DEUoeGxiOprfhp7S6Z2OdzA@mail.gmail.com>
 <CAAOoiFYuOpParQPeGX219EAVv5SBOOASwOnGP3Tr5LSFszWBMQ@mail.gmail.com>
Message-ID: <87iofnxogf.fsf@gnu.org>

Hello Mark,

On 2015-01-31 at 07:18:53 +0100, Mark Lentczner wrote:

[...]

> The value of generalizing the list functions greatly over estimated:
> There have been alternate, more generalized Preludes for ages... and I
> don't see much use of them. Sure, they require some futzing with
> imports to use - but that isn't that high of a bar, and yet clearly
> their value rarely merits it in people's minds.

 * alternative (even more) generalised preludes exist
 * there isn't much use of them
 * the inconvenience of using them outweights their benefit
 -----------------
 -> the value of generalising list functions is greatly over-estimated

If I get your argument right (please correct me if I got it wrong), I'm
not convinced the argument to be valid.

IMHO it's rather a chicken-and-egg problem, that nobody wants to waste
time basing their project on some shaky experimental alternative prelude
which replaces `base` with no guarantee of future support/stability. And
the less users an alternative prelude has, the less there's incentive to
keep it supported/maintained. Also, if it's an experimental/research
prelude, chances are it's still evolving and changing in incompatible
ways. Another reason not to trust your project with it.

Finally, I'd rather interpret the argument to mean that alternative
preludes fail as a means to provide any meaningful feedback for
design-choices due to lack of use by a representable sample of users.

Otoh, the FTP-changes were continuously tested against packages on
Hackage to get empirical feedback on their impact, and if needed tweak
the design to have the most compatibility while achieving the goal of
making Foldable/Traversable more of a first-class citizen[1]. That's
probably more due diligence than any other alternative generalising
preludes can produce.

> Maybe I don't write the most clever code (code golf excepted), but I
> rarely pine for a more generalized length. Or for all to work over
> Foldable... etc.  For the few times when I need something like
> Foldable I don't see what the issue is with importing qualified and
> using prefixes. People here seem to feel that a "F." is somehow an
> ugly wart on their code... but that is just the way it is with most
> software: You need a lot of things in scope, you use namespaces of one
> sort or another.

[...]

 [1]: IMO, we either endorse the Traversable/Foldable abstraction as a
      recommended abstraction for Haskell code by making it a properly
      integrated first-class citizen (and integrating it in a future
      Haskell Report), or we deprecate it (and eventually remove it from
      `base` altogether, as what's its right to exist there
      otherwise?). The current situation in `base` doesn't give a clear
      picture about whether Foldable/Traversable is recommended or
      rather an historic artifact, IMO.

Cheers,
  hvr

From gershomb at gmail.com  Sat Jan 31 13:08:53 2015
From: gershomb at gmail.com (Gershom B)
Date: Sat, 31 Jan 2015 08:08:53 -0500
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAAOoiFYuOpParQPeGX219EAVv5SBOOASwOnGP3Tr5LSFszWBMQ@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>
 <CAJumaK8aJVDX0rnh5n0v3ZMa9UQ7O5UpkSep6ET6F1gBfShLVA@mail.gmail.com>
 <87a912sfh9.fsf@gnu.org>
 <CAJumaK-kD5jcw-Ef+YCLa7CxCL5DEUoeGxiOprfhp7S6Z2OdzA@mail.gmail.com>
 <CAAOoiFYuOpParQPeGX219EAVv5SBOOASwOnGP3Tr5LSFszWBMQ@mail.gmail.com>
Message-ID: <etPan.54ccd3f4.6b8b4567.10c@mbp.local>

Hiya Mark.

Your note was pretty passionate, so I hope you?ll forgive me if mine is a bit strongly worded as well. There?s a phenomenon, especially on the internet, where people don?t make arguments of the form ?I don?t like? or ?I don?t want? or even ?I think? but instead of ?Personally, I?m fine with X, but I can see how see how _others_ could??. ?I tend to think of this argument as a form of ?concern trolling? even though I know that is an overloaded term that maybe has too many other connotations.

In any case, I have seen a lot of this form of argumentation in the Foldable/Traversable discussions. ?I understand this stuff perfectly well, but I can see how ?a beginner could??. ?I of course can fix up my libraries in an afternoon, but I can see how this would cause trouble for others??. ?Patching my codebase to handle the change isn?t bad, but I can see how others who might want to adopt Haskell could??

So what?s the problem here? Bluntly, if somebody has an objection, we have a chance of convincing them. If imaginary rhetorical strawmen in somebody?s head have an objection, we don?t have a chance of convincing them, or even having a proper dialogue with them, because nobody can speak to these imaginary people outside of the person that is imagining them.

In this case, I know that you have a tremendous amount more industry experience than me, and in fact than many others of us, but I nonetheless think you?re engaging in a form of this advocacy on the part of invented parties. Let me explain why. In the course of writing ?industrial Haskell? I have discovered that one of the _first_ things that many Haskell shops do is to settle on a standardized, ?custom? import list for their stuff. Often, this list omits the partial functions from the import of Prelude. Sometimes, it is packaged up as a convenience module, sometimes it is just a chunk of import statements. These imports include chunks of Prelude, chunks of Base, and often, chunks of whatever homegrown ?enterprise glue? utilities that a given shop has come to rely on ? logging, parsing, configuration, sometimes communication, etc. So what affect does a change in Prelude have in such systems? Often, much less than if there were not such standards. And furthermore, if you?re using a custom convenience module anyway, you have a mechanism for managing the impact of changes in Prelude in a fairly modular way.

I?m not saying every ?Industrial Haskell? shop now does something like this ? but honestly, those that don?t should, and this is the sort of thing that, as industrial Haskell adoption grows, will clearly get adopted as a ?best practice.? On top of this, industrial shops, unlike library authors, have a much stronger set of controls on the environment they expect their code to work in. You can set a companywide standard for a version of GHC, and cutover to new versions on a controlled schedule of your choice, in a coordinated fashion. You can lock down package version numbers strongly and migrate them all at once. Etc. Again, even though some shops may not do this uniformly, it is certainly a best practice with many benefits, even absent any changes in the Prelude. And its implementation again strongly mitigates the effects of such changes.

In any case, let?s not set our sights too high. It may be that ?the 80%? of large shops won?t adopt Haskell anytime soon. Frankly, I don?t think that Prelude instability will be the reason why. How many developers at how many shops have heard of Haskell and take it seriously as more than a curiosity regardless? How many, even when they hear about Google or Facebook adoption say, ?Ah so it is a fancy language for big problems faced on the bleeding edge. Me? I?m just writing some typical stuff, who cares??

Let?s have some proportion. For all our adoption, for Haskell to become even a ?2%? language across industry would be a few orders of magnitude growth from where we are now. As far as I know, no other language with our current user base has felt the need to lock things down so tightly at this point on the growth curve. If, at this stage in its career, Java can get lambdas, that almost seems a constructive disproof in itself of the ?widely used things shouldn?t evolve? principle you seem to be describing.

From my standpoint, the ironic thing is that we have endured far more seriously and wide-ragingly breaking changes over the course of prior GHC releases for years, but they have not generated this much heat because they have _looked_ innocuous. So we finally have a core libraries committee that is tasked with trying to make changes in a smooth way. And the changes here proposed are _very_ smooth! But now, of course, the care that was taken to make sure everything works cleanly and smoothly itself has now generated backlash, because it makes the surface area of this change _look_ larger.

Honestly? The Prelude is just the set of stuff in scope by default. If the entire prelude consisted of one function that drew an ASCII fish and nothing else, I could live with that. My main inclination here is to trust the core libraries committee to do its job, and to see what benefits that brings over time, rather than killing off this entire direction of work before it even has a chance to begin to prove itself.

Cheers,
Gershom

On January 31, 2015 at 1:19:18 AM, Mark Lentczner (mark.lentczner at gmail.com) wrote:
> I'm sorry for being so behind the times, and now have to write this at this
> stage...
>  
> BBP deeply saddens me. While I understand the desire for a more generalized
> Prelude (surely this is one of the seven stages of Haskell, along with
> "need to write a Monad tutorial"....), I don't think the ends come anywhere
> close to justifying the means.
>  
> I realize I'm often (always?) the voice of stodginess. But I'll tell where
> I'm coming from: I want to get people to adopt Haskell for serious software
> development. But that means I have get them to buy into an ecosystem and
> for them to do so they need to feel it will be stable on the order decades.
> They need to feel that before they're going to be willing to invest in the
> tooling, the process development, and committing their work to Haskell.
>  
> In 1990 most shops wouldn't ship software in C++ because none of us trusted
> the compilers, or that language (already C++ 2.0) wouldn't change in ways
> that would be unpredictable and negatively affect our work. It took almost
> another decade. In 2005 many places still wouldn't ship things using STL.
> It takes a long time for people to trust that an ecosystem has stabilized.
>  
> "Burning Bridges". The name says it all. We cannot do this. We have to look
> well beyond how a change like this affects compiling a bunch of code form
> stackage... We have to think beyond the discussions on our mailing lists...
> Think of the text books, the corse syllabuses, the in-house trainings,
> think of work flow and deployment processes.. think of vast amounts of code
> we can't see... We cannot undermine the Prelude and Data.List that they are
> all built on.
>  
> If we make a change like this, we've just told the world to wait another 10
> years before considering Haskell.
>  
>  
> The sadder thing is that I don't think the proposal really adds much to
> Haskell:
>  
> The value of generalizing the list functions greatly over estimated: There
> have been alternate, more generalized Preludes for ages... and I don't see
> much use of them. Sure, they require some futzing with imports to use - but
> that isn't that high of a bar, and yet clearly their value rarely merits it
> in people's minds. Maybe I don't write the most clever code (code golf
> excepted), but I rarely pine for a more generalized length. Or for all to
> work over Foldable... etc.
>  
> For the few times when I need something like Foldable I don't see what the
> issue is with importing qualified and using prefixes. People here seem to
> feel that a "F." is somehow an ugly wart on their code... but that is just
> the way it is with most software: You need a lot of things in scope, you
> use namespaces of one sort or another.
>  
>  
> There's also a whole issue of commitment to forward and backward
> compatibility that we as a community don't yet have. Littering our code
> with CPP is not really acceptable. And all production code insists on clean
> compilation with -Wall, so we can't be spewing warnings. Or for that matter
> playing tricks with import orders. This stuff is tricky and hard... no
> doubt, but it is the price of a bid at adoption.
>  
>  
> All in all, what saddens me here is that this whole episode, like the
> similar one around roles and 7.8, is indicative that on the whole, we as a
> community, are not ready to hunker down and work toward making Haskell a
> solid tool for software development. We are, instead, too fascinated with
> making it more perfect.
>  
> - Mark
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>  


From johan.tibell at gmail.com  Sat Jan 31 17:59:31 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 31 Jan 2015 09:59:31 -0800
Subject: Drastic Prelude changes imminent
In-Reply-To: <etPan.54ccd3f4.6b8b4567.10c@mbp.local>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>
 <CAJumaK8aJVDX0rnh5n0v3ZMa9UQ7O5UpkSep6ET6F1gBfShLVA@mail.gmail.com>
 <87a912sfh9.fsf@gnu.org>
 <CAJumaK-kD5jcw-Ef+YCLa7CxCL5DEUoeGxiOprfhp7S6Z2OdzA@mail.gmail.com>
 <CAAOoiFYuOpParQPeGX219EAVv5SBOOASwOnGP3Tr5LSFszWBMQ@mail.gmail.com>
 <etPan.54ccd3f4.6b8b4567.10c@mbp.local>
Message-ID: <CAK-tuPbasNMkwfNBm_PYiTRiSb+YeM7O9qupcki2=D0+GW-sPw@mail.gmail.com>

I re-read the goals* of the proposal:
https://wiki.haskell.org/Foldable_Traversable_In_Prelude

"One goal here is that people should be able to use methods from these
modules without the need of a qualified import -- i.e. to prevent clash in
the namespace, by resolving such in favor of the more generalized versions.
Additionally, there are some new methods added to the Foldable class
because it seems to be the "right" thing."

Before FTP, I would have to write this to use Foldable/Traversable:

    import qualified Data.Foldable as F

The import is qualified as to not collide with the Prelude.

If I have code that needs to be compatible with more than one GHC release
(I typically need compatibility with the last 3 major releases), what do I
have to write post-FTP? Since I cannot rely on the Prelude being
generalized (because I might be compiling with a pre-FTP compiler) I need
to either write:

    #if MIN_VERSION_base(x,y,z)
    -- Get Foldable etc from Prelude
    #else
    import Data.Foldable (...)
    import Prelude hiding (...)  -- the same
    #endif

Which is terrible. Alternatively I can write

    import qualified Data.Foldable as F

but now nothing is gained over the pre-FTP state. Only after 3+ years (at
the current GHC release phase) I can drop that one extra import. One out of
perhaps 20. That seems quite a small gain given that we will then have made
Data.List a very confusing module (it's essentially Data.Foldable under a
different name), broken some code due to added type ambiguity, and also
removed one of the simpler ways to remove that ambiguity, which would have
been to import one of the monomorphic list functions that no longer exist.

* People tell me that there are other goals, but they aren't really stated
clearly anywhere.

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150131/688f771c/attachment.html>

From alec at deviant-logic.net  Sat Jan 31 19:37:04 2015
From: alec at deviant-logic.net (Alec)
Date: Sat, 31 Jan 2015 19:37:04 +0000
Subject: Drastic Prelude changes imminent
References: <mailman.1.1422705602.30393.libraries@haskell.org>
Message-ID: <CA+0GNnDbETN00iTZySc7rAXtzxri9bkE8n5tv02ppP9y9FcMAA@mail.gmail.com>

On Sat Jan 31 2015 at 01:43:03 AM davean <davean at xkcd.com> wrote:
>
> Personally, I want a language thats good to use. That means constant
> improvement. My life gets better by far more then it costs me to update
> some code in fairly trivial ways when the language or libraries change. In
> fact, Haskell makes updates easy. Why should we instead build up the need
> to replace the language with a new one, how is that better? [...]



> [...] Lets not
> tear our hair out because someone made a bad decision in the 1980s and now
> we're stuck with it. I've done that. It was terrible. The world doesn't
> need another language that makes that mistake.
>

+1, Haskell98 is not a suicide pact.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150131/6ed3be2e/attachment.html>

From shumovichy at gmail.com  Sat Jan 31 19:57:22 2015
From: shumovichy at gmail.com (Yuras Shumovich)
Date: Sat, 31 Jan 2015 22:57:22 +0300
Subject: Drastic Prelude changes imminent
In-Reply-To: <CAK-tuPbasNMkwfNBm_PYiTRiSb+YeM7O9qupcki2=D0+GW-sPw@mail.gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>
 <CAJumaK8aJVDX0rnh5n0v3ZMa9UQ7O5UpkSep6ET6F1gBfShLVA@mail.gmail.com>
 <87a912sfh9.fsf@gnu.org>
 <CAJumaK-kD5jcw-Ef+YCLa7CxCL5DEUoeGxiOprfhp7S6Z2OdzA@mail.gmail.com>
 <CAAOoiFYuOpParQPeGX219EAVv5SBOOASwOnGP3Tr5LSFszWBMQ@mail.gmail.com>
 <etPan.54ccd3f4.6b8b4567.10c@mbp.local>
 <CAK-tuPbasNMkwfNBm_PYiTRiSb+YeM7O9qupcki2=D0+GW-sPw@mail.gmail.com>
Message-ID: <1422734242.3249.11.camel@gmail.com>

On Sat, 2015-01-31 at 09:59 -0800, Johan Tibell wrote:
> I re-read the goals* of the proposal:
> https://wiki.haskell.org/Foldable_Traversable_In_Prelude
> 
> "One goal here is that people should be able to use methods from these
> modules without the need of a qualified import -- i.e. to prevent clash in
> the namespace, by resolving such in favor of the more generalized versions.
> Additionally, there are some new methods added to the Foldable class
> because it seems to be the "right" thing."
> 
> Before FTP, I would have to write this to use Foldable/Traversable:
> 
>     import qualified Data.Foldable as F
> 
> The import is qualified as to not collide with the Prelude.
> 
> If I have code that needs to be compatible with more than one GHC release
> (I typically need compatibility with the last 3 major releases), what do I
> have to write post-FTP? Since I cannot rely on the Prelude being
> generalized (because I might be compiling with a pre-FTP compiler) I need
> to either write:
> 
>     #if MIN_VERSION_base(x,y,z)
>     -- Get Foldable etc from Prelude
>     #else
>     import Data.Foldable (...)
>     import Prelude hiding (...)  -- the same
>     #endif
> 

You just create custom Prelude.hs and place all the ugly CPP inside it.
Then you continue writing code assuming the generalized prelude for all
`base` versions (or specialized prelude if you prefer.)

I already use custom prelude when I need portability because older base
exports incompatible `catch` from Prelude. That works OK for me so far,
and I don't see why it will not work for FTP.

(I personally hate FTP, but I probably will be able to live with it.)

> Which is terrible. Alternatively I can write
> 
>     import qualified Data.Foldable as F
> 
> but now nothing is gained over the pre-FTP state. Only after 3+ years (at
> the current GHC release phase) I can drop that one extra import. One out of
> perhaps 20. That seems quite a small gain given that we will then have made
> Data.List a very confusing module (it's essentially Data.Foldable under a
> different name), broken some code due to added type ambiguity, and also
> removed one of the simpler ways to remove that ambiguity, which would have
> been to import one of the monomorphic list functions that no longer exist.
> 
> * People tell me that there are other goals, but they aren't really stated
> clearly anywhere.

I'd like to known other goals. Right now it looks for me like saving few
keystrokes.

> 
> -- Johan
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries



From spam at scientician.net  Sat Jan 31 20:35:30 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Sat, 31 Jan 2015 21:35:30 +0100
Subject: Drastic Prelude changes imminent
In-Reply-To: <1422734242.3249.11.camel@gmail.com>
References: <22B950C955F8AB4196E72698FBD00002B94031A0@UKWPIPXMB01A.zone1.scb.net>
 <22B950C955F8AB4196E72698FBD00002B9403840@UKWPIPXMB01A.zone1.scb.net>
 <CAJumaK8aJVDX0rnh5n0v3ZMa9UQ7O5UpkSep6ET6F1gBfShLVA@mail.gmail.com>
 <87a912sfh9.fsf@gnu.org>
 <CAJumaK-kD5jcw-Ef+YCLa7CxCL5DEUoeGxiOprfhp7S6Z2OdzA@mail.gmail.com>
 <CAAOoiFYuOpParQPeGX219EAVv5SBOOASwOnGP3Tr5LSFszWBMQ@mail.gmail.com>
 <etPan.54ccd3f4.6b8b4567.10c@mbp.local>
 <CAK-tuPbasNMkwfNBm_PYiTRiSb+YeM7O9qupcki2=D0+GW-sPw@mail.gmail.com>
 <1422734242.3249.11.camel@gmail.com>
Message-ID: <majeaj$oib$1@ger.gmane.org>

On 01/31/2015 08:57 PM, Yuras Shumovich wrote:
> On Sat, 2015-01-31 at 09:59 -0800, Johan Tibell wrote:
>> Which is terrible. Alternatively I can write
>>
>>     import qualified Data.Foldable as F
>>
>> but now nothing is gained over the pre-FTP state. Only after 3+ years (at
>> the current GHC release phase) I can drop that one extra import. One out of
>> perhaps 20. That seems quite a small gain given that we will then have made
>> Data.List a very confusing module (it's essentially Data.Foldable under a
>> different name), broken some code due to added type ambiguity, and also
>> removed one of the simpler ways to remove that ambiguity, which would have
>> been to import one of the monomorphic list functions that no longer exist.
>>
>> * People tell me that there are other goals, but they aren't really stated
>> clearly anywhere.
> 
> I'd like to known other goals. Right now it looks for me like saving few
> keystrokes.

Personally, I think I've come to the conclusion (from the various
discussions around here and on Reddit) that there probably shouldn't
*be* any Prelude. Either that or Backpack is unfortunately about 5-10
years too late in the making. (Hopefully it'll get there!).

Universities and books could still have their own pre-built
"SitePrelude", but at least random re-exported modules wouldn't be
constrained so much by that.

Of course, then we'd probably be arguing about Data.List, but at least
"the world" wouldn't break. SitePrelude could also be a point to
"contain the damage", so to speak.

However, I certainly agree with Gershom B that the "enterprise" people
are exactly the kind of people who have the means to prevent these
problems affecting *them* too much. They probably should be (or are
already) doing due dilligence to that effect.

I'm sure I'm preaching to the choir, but one of the reasons Haskell is
so great is that *most* semantics-changing changes in libraries actually
break code *loudly* rather than *silently*. (And, I for one, appreciate
the HLCs efforts to avoid silent breaking changes due to this change.)
Usually, IME at least, loud breaking changes aren't actually that hard
to fix, though I definitely have sympathy for library authors with huge
numbers of revdeps :/.

I wonder if there's something to be learned from "go fix"[1] in terms of
making it a first-class citizen in the ecosystem. I suspect that a
Haskell equivalent could even be taught to maintain/remove "cpp+version"
blocks, etc.

[1] https://golang.org/cmd/fix/

Regards,