From ashley at semantic.org  Sun Jun  1 06:13:21 2014
From: ashley at semantic.org (Ashley Yakeley)
Date: Sat, 31 May 2014 23:13:21 -0700
Subject: Proposal: instance TestEquality IORef
Message-ID: <lmega8$hvr$1@ger.gmane.org>

The base package includes the class Data.Type.Equality.TestEquality, for 
types from which type equality can be deduced from values.

Given values ra rb of types "IORef a" and "IORef b", if they are the 
same value (i.e. ra == unsafeCoerce rb), then one can deduce "a ~ b". 
Therefore, IORef can be made an instance of TestEquality. The same is 
true for various other reference types.

I propose these instances in base:

   instance TestEquality IORef
   instance TestEquality (STRef s)

-- Ashley Yakeley


From eir at cis.upenn.edu  Sun Jun  1 14:45:52 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 1 Jun 2014 10:45:52 -0400
Subject: Proposal: instance TestEquality IORef
In-Reply-To: <lmega8$hvr$1@ger.gmane.org>
References: <lmega8$hvr$1@ger.gmane.org>
Message-ID: <AC9EF729-ED2A-4D06-92CD-570D93A96153@cis.upenn.edu>

This deduction is not true in the presence of `coerce`. Specifically, with

> newtype Age = MkAge Int
> x :: IORef Int

we can say

> y :: IORef Age
> y = coerce x

But, I do think Ashley's idea might work for TestCoercion, instead of TestEquality. I'm not 100% sure without More Thought, but it seems reasonable.

Richard

On Jun 1, 2014, at 2:13 AM, Ashley Yakeley <ashley at semantic.org> wrote:

> The base package includes the class Data.Type.Equality.TestEquality, for types from which type equality can be deduced from values.
> 
> Given values ra rb of types "IORef a" and "IORef b", if they are the same value (i.e. ra == unsafeCoerce rb), then one can deduce "a ~ b". Therefore, IORef can be made an instance of TestEquality. The same is true for various other reference types.
> 
> I propose these instances in base:
> 
>  instance TestEquality IORef
>  instance TestEquality (STRef s)
> 
> -- Ashley Yakeley
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries


From ekmett at gmail.com  Tue Jun  3 22:26:47 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 3 Jun 2014 18:26:47 -0400
Subject: [Haskell] Core libraries committee seeking self-nominations
Message-ID: <CAJumaK-teaX_L_faP_81X3BcXs9DA-XkyxqeOURfwN06wLzJeQ@mail.gmail.com>

The first year of the Haskell Core Libraries Committee
<http://www.haskell.org/haskellwiki/Core_Libraries_Committee> is winding
down, and we are seeking self-nominations to replace two outgoing committee
members.

Doug Beardsley and Brent Yorgey have offered to be the first two members of
the committee to have their slots come up for renewal.

To nominate yourself, please send an email to
core-libraries-committee at haskell.org by June 30th and include any
information that you think will help us reach a decision.

The core libraries committee acts as the collective maintainer of many
packages that glue together the Haskell Platform, but which otherwise do
not have an individual maintainer. See Library Submissions
<http://www.haskell.org/haskellwiki/Library_submissions> for more details
about which packages fall to the committee for maintenance.

As we are now talking on more of the implementation effort for the
Applicative-Monad Proposal, bringing Foldable and Traversable into Prelude,
performing active maintenance on vector, etc., you should be forewarned
that these are becoming increasingly active positions now that GHC 7.8 has
shipped and we are ramping up for more active participation in the GHC
release process.

Regards,
Edward Kmett
Haskell Core Libraries Committee Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140603/3353d78e/attachment.html>

From austin at well-typed.com  Thu Jun  5 13:31:00 2014
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 5 Jun 2014 08:31:00 -0500
Subject: 7.8.3 for the Platform
Message-ID: <CAEs96n1sG-K8y5_3guaopeg-HcQQu5MfU5WDvJb4M4mDaLds0A@mail.gmail.com>

Hi Mark,

I was planning on releasing GHC 7.8.3 very soon (in the next few
days,) and I'm wondering if it is still a possible candidate for the
next Haskell Platform?

To be clear, there are no library updates this time around - 7.8.3 is
almost 100% a pure compiler/runtime bugfix release, and some of the
fixes are quite bad.

https://ghc.haskell.org/trac/ghc/ticket/9078
https://ghc.haskell.org/trac/ghc/ticket/8768
https://ghc.haskell.org/trac/ghc/ticket/9148
https://ghc.haskell.org/trac/ghc/ticket/9001

The first one, #9078, would be particularly bad to let slip into the
release - it affects possibly all EDSLs using mkStableName for
sharing, and is very easy to trigger by allocating stable names
quickly. I'd say #8768 is somewhat nasty as well. Accelerate and SBV
are two examples of projects that will crash.

There are currently no plans to even bump the corresponding library
numbers - we didn't do so for 7.8.2, and there are no changes at all
that would warrant a bump for 7.8.3. It's really a stability release
more than anything and irons out several real bumps.

Do let me know what you think - I'll keep this thread updated as the
release gets closer if anything else goes in.

-- 
Regards,

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

From fuuzetsu at fuuzetsu.co.uk  Fri Jun  6 08:07:39 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Fri, 06 Jun 2014 10:07:39 +0200
Subject: 7.8.3 for the Platform
In-Reply-To: <CAEs96n1sG-K8y5_3guaopeg-HcQQu5MfU5WDvJb4M4mDaLds0A@mail.gmail.com>
References: <CAEs96n1sG-K8y5_3guaopeg-HcQQu5MfU5WDvJb4M4mDaLds0A@mail.gmail.com>
Message-ID: <539176CB.3010109@fuuzetsu.co.uk>

On 06/05/2014 03:31 PM, Austin Seipp wrote:
> Hi Mark,
> 
> I was planning on releasing GHC 7.8.3 very soon (in the next few
> days,) and I'm wondering if it is still a possible candidate for the
> next Haskell Platform?

Actually there are few commits of changes to Haddock which fix a rather
serious hyperlinking bug but I'm not sure whether this is relevant. It's
on the 7.8 branch already. Just piping up in case it matters.

> To be clear, there are no library updates this time around - 7.8.3 is
> almost 100% a pure compiler/runtime bugfix release, and some of the
> fixes are quite bad.
> 
> https://ghc.haskell.org/trac/ghc/ticket/9078
> https://ghc.haskell.org/trac/ghc/ticket/8768
> https://ghc.haskell.org/trac/ghc/ticket/9148
> https://ghc.haskell.org/trac/ghc/ticket/9001
> 
> The first one, #9078, would be particularly bad to let slip into the
> release - it affects possibly all EDSLs using mkStableName for
> sharing, and is very easy to trigger by allocating stable names
> quickly. I'd say #8768 is somewhat nasty as well. Accelerate and SBV
> are two examples of projects that will crash.
> 
> There are currently no plans to even bump the corresponding library
> numbers - we didn't do so for 7.8.2, and there are no changes at all
> that would warrant a bump for 7.8.3. It's really a stability release
> more than anything and irons out several real bumps.
> 
> Do let me know what you think - I'll keep this thread updated as the
> release gets closer if anything else goes in.
> 


-- 
Mateusz K.

From gale at sefer.org  Fri Jun  6 10:23:09 2014
From: gale at sefer.org (Yitzchak Gale)
Date: Fri, 6 Jun 2014 13:23:09 +0300
Subject: 7.8.3 for the Platform
In-Reply-To: <539176CB.3010109@fuuzetsu.co.uk>
References: <CAEs96n1sG-K8y5_3guaopeg-HcQQu5MfU5WDvJb4M4mDaLds0A@mail.gmail.com>
 <539176CB.3010109@fuuzetsu.co.uk>
Message-ID: <CAOrUaLZiiLwFaJzdxFwTpN=QOcga571pJfOzfiZ9YE_2XosZRQ@mail.gmail.com>

Actually, as Mateusz just pointed out a few minutes ago in
a thread on ghc-devs, it now looks quite likely that there will be a
version bump for Haddock. In the context of one of the bug
fixes for 7.8.3, Simon PJ would like to change the interface of
a GHC function that happens to be used by Haddock.

On Fri, Jun 6, 2014 at 11:07 AM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk> wrote:
> On 06/05/2014 03:31 PM, Austin Seipp wrote:
>> Hi Mark,
>>
>> I was planning on releasing GHC 7.8.3 very soon (in the next few
>> days,) and I'm wondering if it is still a possible candidate for the
>> next Haskell Platform?
>
> Actually there are few commits of changes to Haddock which fix a rather
> serious hyperlinking bug but I'm not sure whether this is relevant. It's
> on the 7.8 branch already. Just piping up in case it matters.
>
>> To be clear, there are no library updates this time around - 7.8.3 is
>> almost 100% a pure compiler/runtime bugfix release, and some of the
>> fixes are quite bad.
>>
>> https://ghc.haskell.org/trac/ghc/ticket/9078
>> https://ghc.haskell.org/trac/ghc/ticket/8768
>> https://ghc.haskell.org/trac/ghc/ticket/9148
>> https://ghc.haskell.org/trac/ghc/ticket/9001
>>
>> The first one, #9078, would be particularly bad to let slip into the
>> release - it affects possibly all EDSLs using mkStableName for
>> sharing, and is very easy to trigger by allocating stable names
>> quickly. I'd say #8768 is somewhat nasty as well. Accelerate and SBV
>> are two examples of projects that will crash.
>>
>> There are currently no plans to even bump the corresponding library
>> numbers - we didn't do so for 7.8.2, and there are no changes at all
>> that would warrant a bump for 7.8.3. It's really a stability release
>> more than anything and irons out several real bumps.
>>
>> Do let me know what you think - I'll keep this thread updated as the
>> release gets closer if anything else goes in.
>>
>
>
> --
> Mateusz K.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

From mark.lentczner at gmail.com  Mon Jun  9 17:24:55 2014
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Mon, 9 Jun 2014 10:24:55 -0700
Subject: Gearing up (again) for the next release: 2014.2.0.0
In-Reply-To: <CAEDGBqLPxqMtn9p59_JCxrEgDofYp+-iF84Mrdy4_iz0WH84bg@mail.gmail.com>
References: <CAAOoiFYq=rZtPKPKpur_cSB+brewg54qwoUdmc4nOB555d+Z_w@mail.gmail.com>
 <CAAOoiFYC5zVsyP7=xYvKnYnGUTMK8xyRd9EqFzfrP2Xuk=GoWQ@mail.gmail.com>
 <CAOrUaLb_iqJL-=rzOS6h+oFVT1657_7NMkpc1+nm4xJk6yaPCQ@mail.gmail.com>
 <CAAOoiFaJ-LX3vCucFkkVybaJM3ASa35iB+q=_i2_hJBYRU7LdA@mail.gmail.com>
 <CAAOoiFaNJbR=ebR+r0F7hOdULsXfUKg7Pa-es7RJeRzTj85_yw@mail.gmail.com>
 <CAKA2JgJJSi0wkO==0K03vbq7v4nZ27zr4COvZAQgs+fvMXzZBw@mail.gmail.com>
 <CANBN=msQ3gb2VtDV_kzbHawY59vgBUDeOWGReqNwEq-eFuaaQQ@mail.gmail.com>
 <CAAOoiFZHgVWCGdq1urEkYV2=_08dm=ZdgDsRW8rrL_9d07A0Fw@mail.gmail.com>
 <CA+u6gbxSQdk4sQU7-6+YNPXQtUzkaXm3MPjTpOJveherP1Pe2Q@mail.gmail.com>
 <CAK-tuPbQeDe1L6vrRk0O78egZKWtDfXC4d0uPqNQedGQqpfxfg@mail.gmail.com>
 <CAOrUaLZnFdTVATe4dCwfEKTS494TEoSbnAWkb6BCv6b=f-aFFw@mail.gmail.com>
 <CAOrUaLYwxFmg4U1Wrqooyos6mRvA1xGT4p2urR2t=xbkkzy4QA@mail.gmail.com>
 <CA+u6gbyUQxKDYuiO5keD=HxhyYv7jbmNhacmYukBc6hpekYv0g@mail.gmail.com>
 <CAOrUaLbx959h3=b67nL=dNuyV4BmfK9Y6RheYnmS1Cj3nsM1Ow@mail.gmail.com>
 <CA+u6gbzo7tV3C6Dqtjbtcdb5XGSZQ0G4f3XyuR3ZsbZNA9DnJQ@mail.gmail.com>
 <CAOrUaLaeSOGn1CK6M==FC1n3xjb-BRMGTU4wDH4mizgv-qE0xg@mail.gmail.com>
 <CAAOoiFYZrrJigMeD4q7P6S-sMvxe1sr=UPdyAxZQuyomswfU2g@mail.gmail.com>
 <CAEDGBqJpVykO+4aT2iXhtO+cVHpx3yD_HMcHBJD_HFB5XEcevA@mail.gmail.com>
 <CAAOoiFZiBgto1e_FjZGOad0UvcQcEbUwDmUt5Lrz=FPN5boszg@mail.gmail.com>
 <CAEDGBq+m+hjdgmdLZXZX_yN6qDyJwaAMktUUm=YMK4ZDFhzH=A@mail.gmail.com>
 <CAEDGBqLPxqMtn9p59_JCxrEgDofYp+-iF84Mrdy4_iz0WH84bg@mail.gmail.com>
Message-ID: <CAAOoiFZcBiykoGhbo6-tV7-noAF+u3YD120CPCaTN0kmQXZn6Q@mail.gmail.com>

All - I've been advised that GHC 7.8.3 is imminent and fixes some important
issues. No base package versions will change, except for a small bump in
haddock.
I plan to incorporate this into the HP as soon as they release it - and so
that will be the compiler in the upcoming HP release.
Any concerns?
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140609/db25fd85/attachment.html>

From bos at serpentine.com  Mon Jun  9 17:29:28 2014
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Mon, 9 Jun 2014 10:29:28 -0700
Subject: Gearing up (again) for the next release: 2014.2.0.0
In-Reply-To: <CAAOoiFZcBiykoGhbo6-tV7-noAF+u3YD120CPCaTN0kmQXZn6Q@mail.gmail.com>
References: <CAAOoiFYq=rZtPKPKpur_cSB+brewg54qwoUdmc4nOB555d+Z_w@mail.gmail.com>
 <CAAOoiFYC5zVsyP7=xYvKnYnGUTMK8xyRd9EqFzfrP2Xuk=GoWQ@mail.gmail.com>
 <CAOrUaLb_iqJL-=rzOS6h+oFVT1657_7NMkpc1+nm4xJk6yaPCQ@mail.gmail.com>
 <CAAOoiFaJ-LX3vCucFkkVybaJM3ASa35iB+q=_i2_hJBYRU7LdA@mail.gmail.com>
 <CAAOoiFaNJbR=ebR+r0F7hOdULsXfUKg7Pa-es7RJeRzTj85_yw@mail.gmail.com>
 <CAKA2JgJJSi0wkO==0K03vbq7v4nZ27zr4COvZAQgs+fvMXzZBw@mail.gmail.com>
 <CANBN=msQ3gb2VtDV_kzbHawY59vgBUDeOWGReqNwEq-eFuaaQQ@mail.gmail.com>
 <CAAOoiFZHgVWCGdq1urEkYV2=_08dm=ZdgDsRW8rrL_9d07A0Fw@mail.gmail.com>
 <CA+u6gbxSQdk4sQU7-6+YNPXQtUzkaXm3MPjTpOJveherP1Pe2Q@mail.gmail.com>
 <CAK-tuPbQeDe1L6vrRk0O78egZKWtDfXC4d0uPqNQedGQqpfxfg@mail.gmail.com>
 <CAOrUaLZnFdTVATe4dCwfEKTS494TEoSbnAWkb6BCv6b=f-aFFw@mail.gmail.com>
 <CAOrUaLYwxFmg4U1Wrqooyos6mRvA1xGT4p2urR2t=xbkkzy4QA@mail.gmail.com>
 <CA+u6gbyUQxKDYuiO5keD=HxhyYv7jbmNhacmYukBc6hpekYv0g@mail.gmail.com>
 <CAOrUaLbx959h3=b67nL=dNuyV4BmfK9Y6RheYnmS1Cj3nsM1Ow@mail.gmail.com>
 <CA+u6gbzo7tV3C6Dqtjbtcdb5XGSZQ0G4f3XyuR3ZsbZNA9DnJQ@mail.gmail.com>
 <CAOrUaLaeSOGn1CK6M==FC1n3xjb-BRMGTU4wDH4mizgv-qE0xg@mail.gmail.com>
 <CAAOoiFYZrrJigMeD4q7P6S-sMvxe1sr=UPdyAxZQuyomswfU2g@mail.gmail.com>
 <CAEDGBqJpVykO+4aT2iXhtO+cVHpx3yD_HMcHBJD_HFB5XEcevA@mail.gmail.com>
 <CAAOoiFZiBgto1e_FjZGOad0UvcQcEbUwDmUt5Lrz=FPN5boszg@mail.gmail.com>
 <CAEDGBq+m+hjdgmdLZXZX_yN6qDyJwaAMktUUm=YMK4ZDFhzH=A@mail.gmail.com>
 <CAEDGBqLPxqMtn9p59_JCxrEgDofYp+-iF84Mrdy4_iz0WH84bg@mail.gmail.com>
 <CAAOoiFZcBiykoGhbo6-tV7-noAF+u3YD120CPCaTN0kmQXZn6Q@mail.gmail.com>
Message-ID: <CACw0niJFX1k_5obDj-D0sZ5m77ouUmt5z6fXAppXV4=65x2+Bw@mail.gmail.com>

On Mon, Jun 9, 2014 at 10:24 AM, Mark Lentczner <mark.lentczner at gmail.com>
wrote:

> I plan to incorporate this into the HP as soon as they release it - and so
> that will be the compiler in the upcoming HP release.
> Any concerns?
>

Sounds great to me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140609/011b1ccf/attachment.html>

From danburton.email at gmail.com  Mon Jun  9 18:37:16 2014
From: danburton.email at gmail.com (Dan Burton)
Date: Mon, 9 Jun 2014 11:37:16 -0700
Subject: Gearing up (again) for the next release: 2014.2.0.0
In-Reply-To: <CAAOoiFZcBiykoGhbo6-tV7-noAF+u3YD120CPCaTN0kmQXZn6Q@mail.gmail.com>
References: <CAAOoiFYq=rZtPKPKpur_cSB+brewg54qwoUdmc4nOB555d+Z_w@mail.gmail.com>
 <CAAOoiFYC5zVsyP7=xYvKnYnGUTMK8xyRd9EqFzfrP2Xuk=GoWQ@mail.gmail.com>
 <CAOrUaLb_iqJL-=rzOS6h+oFVT1657_7NMkpc1+nm4xJk6yaPCQ@mail.gmail.com>
 <CAAOoiFaJ-LX3vCucFkkVybaJM3ASa35iB+q=_i2_hJBYRU7LdA@mail.gmail.com>
 <CAAOoiFaNJbR=ebR+r0F7hOdULsXfUKg7Pa-es7RJeRzTj85_yw@mail.gmail.com>
 <CAKA2JgJJSi0wkO==0K03vbq7v4nZ27zr4COvZAQgs+fvMXzZBw@mail.gmail.com>
 <CANBN=msQ3gb2VtDV_kzbHawY59vgBUDeOWGReqNwEq-eFuaaQQ@mail.gmail.com>
 <CAAOoiFZHgVWCGdq1urEkYV2=_08dm=ZdgDsRW8rrL_9d07A0Fw@mail.gmail.com>
 <CA+u6gbxSQdk4sQU7-6+YNPXQtUzkaXm3MPjTpOJveherP1Pe2Q@mail.gmail.com>
 <CAK-tuPbQeDe1L6vrRk0O78egZKWtDfXC4d0uPqNQedGQqpfxfg@mail.gmail.com>
 <CAOrUaLZnFdTVATe4dCwfEKTS494TEoSbnAWkb6BCv6b=f-aFFw@mail.gmail.com>
 <CAOrUaLYwxFmg4U1Wrqooyos6mRvA1xGT4p2urR2t=xbkkzy4QA@mail.gmail.com>
 <CA+u6gbyUQxKDYuiO5keD=HxhyYv7jbmNhacmYukBc6hpekYv0g@mail.gmail.com>
 <CAOrUaLbx959h3=b67nL=dNuyV4BmfK9Y6RheYnmS1Cj3nsM1Ow@mail.gmail.com>
 <CA+u6gbzo7tV3C6Dqtjbtcdb5XGSZQ0G4f3XyuR3ZsbZNA9DnJQ@mail.gmail.com>
 <CAOrUaLaeSOGn1CK6M==FC1n3xjb-BRMGTU4wDH4mizgv-qE0xg@mail.gmail.com>
 <CAAOoiFYZrrJigMeD4q7P6S-sMvxe1sr=UPdyAxZQuyomswfU2g@mail.gmail.com>
 <CAEDGBqJpVykO+4aT2iXhtO+cVHpx3yD_HMcHBJD_HFB5XEcevA@mail.gmail.com>
 <CAAOoiFZiBgto1e_FjZGOad0UvcQcEbUwDmUt5Lrz=FPN5boszg@mail.gmail.com>
 <CAEDGBq+m+hjdgmdLZXZX_yN6qDyJwaAMktUUm=YMK4ZDFhzH=A@mail.gmail.com>
 <CAEDGBqLPxqMtn9p59_JCxrEgDofYp+-iF84Mrdy4_iz0WH84bg@mail.gmail.com>
 <CAAOoiFZcBiykoGhbo6-tV7-noAF+u3YD120CPCaTN0kmQXZn6Q@mail.gmail.com>
Message-ID: <CALSygwf8g9S5donRY3xhfntzyLO1uL4Yidm4NT3718Qh6iByjQ@mail.gmail.com>

Two questions.

1. Do we have an ETA for the upcoming HP release?
2. Will incorporating 7.8.3 cause any additional delay, as opposed to
sticking with 7.8.2? How much?

-- Dan Burton


On Mon, Jun 9, 2014 at 10:24 AM, Mark Lentczner <mark.lentczner at gmail.com>
wrote:

> All - I've been advised that GHC 7.8.3 is imminent and fixes some
> important issues. No base package versions will change, except for a small
> bump in haddock.
> I plan to incorporate this into the HP as soon as they release it - and so
> that will be the compiler in the upcoming HP release.
> Any concerns?
> ?
>
> _______________________________________________
> 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/20140609/5a756653/attachment.html>

From ivan.miljenovic at gmail.com  Tue Jun 10 00:41:59 2014
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Tue, 10 Jun 2014 10:41:59 +1000
Subject: Gearing up (again) for the next release: 2014.2.0.0
In-Reply-To: <CAAOoiFZcBiykoGhbo6-tV7-noAF+u3YD120CPCaTN0kmQXZn6Q@mail.gmail.com>
References: <CAAOoiFYq=rZtPKPKpur_cSB+brewg54qwoUdmc4nOB555d+Z_w@mail.gmail.com>
 <CAAOoiFYC5zVsyP7=xYvKnYnGUTMK8xyRd9EqFzfrP2Xuk=GoWQ@mail.gmail.com>
 <CAOrUaLb_iqJL-=rzOS6h+oFVT1657_7NMkpc1+nm4xJk6yaPCQ@mail.gmail.com>
 <CAAOoiFaJ-LX3vCucFkkVybaJM3ASa35iB+q=_i2_hJBYRU7LdA@mail.gmail.com>
 <CAAOoiFaNJbR=ebR+r0F7hOdULsXfUKg7Pa-es7RJeRzTj85_yw@mail.gmail.com>
 <CAKA2JgJJSi0wkO==0K03vbq7v4nZ27zr4COvZAQgs+fvMXzZBw@mail.gmail.com>
 <CANBN=msQ3gb2VtDV_kzbHawY59vgBUDeOWGReqNwEq-eFuaaQQ@mail.gmail.com>
 <CAAOoiFZHgVWCGdq1urEkYV2=_08dm=ZdgDsRW8rrL_9d07A0Fw@mail.gmail.com>
 <CA+u6gbxSQdk4sQU7-6+YNPXQtUzkaXm3MPjTpOJveherP1Pe2Q@mail.gmail.com>
 <CAK-tuPbQeDe1L6vrRk0O78egZKWtDfXC4d0uPqNQedGQqpfxfg@mail.gmail.com>
 <CAOrUaLZnFdTVATe4dCwfEKTS494TEoSbnAWkb6BCv6b=f-aFFw@mail.gmail.com>
 <CAOrUaLYwxFmg4U1Wrqooyos6mRvA1xGT4p2urR2t=xbkkzy4QA@mail.gmail.com>
 <CA+u6gbyUQxKDYuiO5keD=HxhyYv7jbmNhacmYukBc6hpekYv0g@mail.gmail.com>
 <CAOrUaLbx959h3=b67nL=dNuyV4BmfK9Y6RheYnmS1Cj3nsM1Ow@mail.gmail.com>
 <CA+u6gbzo7tV3C6Dqtjbtcdb5XGSZQ0G4f3XyuR3ZsbZNA9DnJQ@mail.gmail.com>
 <CAOrUaLaeSOGn1CK6M==FC1n3xjb-BRMGTU4wDH4mizgv-qE0xg@mail.gmail.com>
 <CAAOoiFYZrrJigMeD4q7P6S-sMvxe1sr=UPdyAxZQuyomswfU2g@mail.gmail.com>
 <CAEDGBqJpVykO+4aT2iXhtO+cVHpx3yD_HMcHBJD_HFB5XEcevA@mail.gmail.com>
 <CAAOoiFZiBgto1e_FjZGOad0UvcQcEbUwDmUt5Lrz=FPN5boszg@mail.gmail.com>
 <CAEDGBq+m+hjdgmdLZXZX_yN6qDyJwaAMktUUm=YMK4ZDFhzH=A@mail.gmail.com>
 <CAEDGBqLPxqMtn9p59_JCxrEgDofYp+-iF84Mrdy4_iz0WH84bg@mail.gmail.com>
 <CAAOoiFZcBiykoGhbo6-tV7-noAF+u3YD120CPCaTN0kmQXZn6Q@mail.gmail.com>
Message-ID: <CA+u6gbxBJ1wbmFiPYz9nzdpdLQjUQ6YP+qDziab3aTEyofH7ng@mail.gmail.com>

On 10 June 2014 03:24, Mark Lentczner <mark.lentczner at gmail.com> wrote:
> All - I've been advised that GHC 7.8.3 is imminent and fixes some important
> issues. No base package versions will change, except for a small bump in
> haddock.
> I plan to incorporate this into the HP as soon as they release it - and so
> that will be the compiler in the upcoming HP release.
> Any concerns?

No concerns, but I think it would be nice if we could have Cabal 1.20
instead of 1.18 in there (though this might not be feasible as it
would require GHC to change which version of Cabal it ships with).

>
> _______________________________________________
> 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 mark.lentczner at gmail.com  Tue Jun 10 02:51:35 2014
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Mon, 9 Jun 2014 19:51:35 -0700
Subject: Gearing up (again) for the next release: 2014.2.0.0
In-Reply-To: <CALSygwf8g9S5donRY3xhfntzyLO1uL4Yidm4NT3718Qh6iByjQ@mail.gmail.com>
References: <CAAOoiFYq=rZtPKPKpur_cSB+brewg54qwoUdmc4nOB555d+Z_w@mail.gmail.com>
 <CAAOoiFYC5zVsyP7=xYvKnYnGUTMK8xyRd9EqFzfrP2Xuk=GoWQ@mail.gmail.com>
 <CAOrUaLb_iqJL-=rzOS6h+oFVT1657_7NMkpc1+nm4xJk6yaPCQ@mail.gmail.com>
 <CAAOoiFaJ-LX3vCucFkkVybaJM3ASa35iB+q=_i2_hJBYRU7LdA@mail.gmail.com>
 <CAAOoiFaNJbR=ebR+r0F7hOdULsXfUKg7Pa-es7RJeRzTj85_yw@mail.gmail.com>
 <CAKA2JgJJSi0wkO==0K03vbq7v4nZ27zr4COvZAQgs+fvMXzZBw@mail.gmail.com>
 <CANBN=msQ3gb2VtDV_kzbHawY59vgBUDeOWGReqNwEq-eFuaaQQ@mail.gmail.com>
 <CAAOoiFZHgVWCGdq1urEkYV2=_08dm=ZdgDsRW8rrL_9d07A0Fw@mail.gmail.com>
 <CA+u6gbxSQdk4sQU7-6+YNPXQtUzkaXm3MPjTpOJveherP1Pe2Q@mail.gmail.com>
 <CAK-tuPbQeDe1L6vrRk0O78egZKWtDfXC4d0uPqNQedGQqpfxfg@mail.gmail.com>
 <CAOrUaLZnFdTVATe4dCwfEKTS494TEoSbnAWkb6BCv6b=f-aFFw@mail.gmail.com>
 <CAOrUaLYwxFmg4U1Wrqooyos6mRvA1xGT4p2urR2t=xbkkzy4QA@mail.gmail.com>
 <CA+u6gbyUQxKDYuiO5keD=HxhyYv7jbmNhacmYukBc6hpekYv0g@mail.gmail.com>
 <CAOrUaLbx959h3=b67nL=dNuyV4BmfK9Y6RheYnmS1Cj3nsM1Ow@mail.gmail.com>
 <CA+u6gbzo7tV3C6Dqtjbtcdb5XGSZQ0G4f3XyuR3ZsbZNA9DnJQ@mail.gmail.com>
 <CAOrUaLaeSOGn1CK6M==FC1n3xjb-BRMGTU4wDH4mizgv-qE0xg@mail.gmail.com>
 <CAAOoiFYZrrJigMeD4q7P6S-sMvxe1sr=UPdyAxZQuyomswfU2g@mail.gmail.com>
 <CAEDGBqJpVykO+4aT2iXhtO+cVHpx3yD_HMcHBJD_HFB5XEcevA@mail.gmail.com>
 <CAAOoiFZiBgto1e_FjZGOad0UvcQcEbUwDmUt5Lrz=FPN5boszg@mail.gmail.com>
 <CAEDGBq+m+hjdgmdLZXZX_yN6qDyJwaAMktUUm=YMK4ZDFhzH=A@mail.gmail.com>
 <CAEDGBqLPxqMtn9p59_JCxrEgDofYp+-iF84Mrdy4_iz0WH84bg@mail.gmail.com>
 <CAAOoiFZcBiykoGhbo6-tV7-noAF+u3YD120CPCaTN0kmQXZn6Q@mail.gmail.com>
 <CALSygwf8g9S5donRY3xhfntzyLO1uL4Yidm4NT3718Qh6iByjQ@mail.gmail.com>
Message-ID: <CAAOoiFb8JxapSJUPDAs27iBLtav9dFfxD0w3M+vLJYoLOYzNzA@mail.gmail.com>

On Mon, Jun 9, 2014 at 11:37 AM, Dan Burton <danburton.email at gmail.com>
wrote:

> 1. Do we have an ETA for the upcoming HP release?
>

I'm very close to being done with the Mac build. This means that I can turn
Mac and src-tarball releases pretty much in an hour or two (for testing).
Yay!
What is left is:
  1) Windows build - I don't know if Mikhail is planning on doing this one
with his existing scripts, or if he plans to move to the new build
  2) Linux/BSD/UN*X builds - some folks have started exploring the new
build - it would be great to see this hammered on a bit
  3) New web site - we could go with the old this round, but there was some
motion to do a new one. If we can get those HTML/template files, then the
new site can go this round - otherwise, no need to wait, but it will take a
few hours to make the new site (always one of my pain points!)
  4) Testing! Once we have release in beta - we just need people to try it!

Basically, I'd love to aim for end of this month.



> 2. Will incorporating 7.8.3 cause any additional delay, as opposed to
> sticking with 7.8.2? How much?
>

None. So long as it remains true that the only version bump is haddock.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140609/82e5bde5/attachment.html>

From mark.lentczner at gmail.com  Tue Jun 10 02:53:06 2014
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Mon, 9 Jun 2014 19:53:06 -0700
Subject: Gearing up (again) for the next release: 2014.2.0.0
In-Reply-To: <CA+u6gbxBJ1wbmFiPYz9nzdpdLQjUQ6YP+qDziab3aTEyofH7ng@mail.gmail.com>
References: <CAAOoiFYq=rZtPKPKpur_cSB+brewg54qwoUdmc4nOB555d+Z_w@mail.gmail.com>
 <CAAOoiFYC5zVsyP7=xYvKnYnGUTMK8xyRd9EqFzfrP2Xuk=GoWQ@mail.gmail.com>
 <CAOrUaLb_iqJL-=rzOS6h+oFVT1657_7NMkpc1+nm4xJk6yaPCQ@mail.gmail.com>
 <CAAOoiFaJ-LX3vCucFkkVybaJM3ASa35iB+q=_i2_hJBYRU7LdA@mail.gmail.com>
 <CAAOoiFaNJbR=ebR+r0F7hOdULsXfUKg7Pa-es7RJeRzTj85_yw@mail.gmail.com>
 <CAKA2JgJJSi0wkO==0K03vbq7v4nZ27zr4COvZAQgs+fvMXzZBw@mail.gmail.com>
 <CANBN=msQ3gb2VtDV_kzbHawY59vgBUDeOWGReqNwEq-eFuaaQQ@mail.gmail.com>
 <CAAOoiFZHgVWCGdq1urEkYV2=_08dm=ZdgDsRW8rrL_9d07A0Fw@mail.gmail.com>
 <CA+u6gbxSQdk4sQU7-6+YNPXQtUzkaXm3MPjTpOJveherP1Pe2Q@mail.gmail.com>
 <CAK-tuPbQeDe1L6vrRk0O78egZKWtDfXC4d0uPqNQedGQqpfxfg@mail.gmail.com>
 <CAOrUaLZnFdTVATe4dCwfEKTS494TEoSbnAWkb6BCv6b=f-aFFw@mail.gmail.com>
 <CAOrUaLYwxFmg4U1Wrqooyos6mRvA1xGT4p2urR2t=xbkkzy4QA@mail.gmail.com>
 <CA+u6gbyUQxKDYuiO5keD=HxhyYv7jbmNhacmYukBc6hpekYv0g@mail.gmail.com>
 <CAOrUaLbx959h3=b67nL=dNuyV4BmfK9Y6RheYnmS1Cj3nsM1Ow@mail.gmail.com>
 <CA+u6gbzo7tV3C6Dqtjbtcdb5XGSZQ0G4f3XyuR3ZsbZNA9DnJQ@mail.gmail.com>
 <CAOrUaLaeSOGn1CK6M==FC1n3xjb-BRMGTU4wDH4mizgv-qE0xg@mail.gmail.com>
 <CAAOoiFYZrrJigMeD4q7P6S-sMvxe1sr=UPdyAxZQuyomswfU2g@mail.gmail.com>
 <CAEDGBqJpVykO+4aT2iXhtO+cVHpx3yD_HMcHBJD_HFB5XEcevA@mail.gmail.com>
 <CAAOoiFZiBgto1e_FjZGOad0UvcQcEbUwDmUt5Lrz=FPN5boszg@mail.gmail.com>
 <CAEDGBq+m+hjdgmdLZXZX_yN6qDyJwaAMktUUm=YMK4ZDFhzH=A@mail.gmail.com>
 <CAEDGBqLPxqMtn9p59_JCxrEgDofYp+-iF84Mrdy4_iz0WH84bg@mail.gmail.com>
 <CAAOoiFZcBiykoGhbo6-tV7-noAF+u3YD120CPCaTN0kmQXZn6Q@mail.gmail.com>
 <CA+u6gbxBJ1wbmFiPYz9nzdpdLQjUQ6YP+qDziab3aTEyofH7ng@mail.gmail.com>
Message-ID: <CAAOoiFZ+B2DKhSxuOL1Wkbo_Hx7JWBnCZssirtN7QBR4R5+f1g@mail.gmail.com>

On Mon, Jun 9, 2014 at 5:41 PM, Ivan Lazar Miljenovic <
ivan.miljenovic at gmail.com> wrote:

> No concerns, but I think it would be nice if we could have Cabal 1.20
>  instead of 1.18 in there


This has been discussed, and general concensus is that we need to stick
with what is shipped with GHC. And I don't want to ask GHC to bump cabal to
1.20 for 7.8.3, because that just opens the flood gates. Besides, I
understand that Johan has back-ported all the important fixes to 1.18, and
we'll surely use that patch version.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140609/46bc48d5/attachment-0001.html>

From gracjanpolak at gmail.com  Tue Jun 10 13:42:22 2014
From: gracjanpolak at gmail.com (Gracjan Polak)
Date: Tue, 10 Jun 2014 13:42:22 +0000 (UTC)
Subject: System.Directory.removeDirectoryRecursive and symlinks
Message-ID: <loom.20140610T152620-599@post.gmane.org>

Hi all,

A crime scene:

Prelude System.Directory> :!mkdir a-directory
Prelude System.Directory> :!touch a-directory/a-file.txt
Prelude System.Directory> :!ln -s "a-directory" "a-symlink-to-a-directory"
Prelude System.Directory> :!ls a-directory
a-file.txt
Prelude System.Directory> :!ls a-symlink-to-a-directory
a-file.txt
Prelude System.Directory> removeDirectoryRecursive
                             "a-symlink-to-a-directory"
*** Exception: a-symlink-to-a-directory: removeDirectory: 
    inappropriate type (Not a directory)
Prelude System.Directory> :!ls a-symlink-to-a-directory
Prelude System.Directory> :!ls a-directory
Prelude System.Directory> :!ls -a a-directory
.	..
Prelude System.Directory> :!ls -a a-symlink-to-a-directory
.	..
Prelude System.Directory> 

removeDirectoryRecursive is removing all contents *of the directory linked*
but is unable to remove the symlink itself.

This behavior is surprizing if not dangerous. I understand that this mimics
behavior of unlink/rmdir and DeleteFile/RemoveDirectory. but let me quote
relevant manuals:

man rm:
The rm utility removes symbolic links, not the files referenced by the links.

DeleteFile docs:
If the path points to a symbolic link, the symbolic link is deleted, not the
target. To delete a target, you must call CreateFile and specify
FILE_FLAG_DELETE_ON_CLOSE.

RemoveDirectory removes a directory junction, even if the contents of the
target are not empty; the function removes directory junctions regardless of
the state of the target object.

Note: doesDirectoryExist and doesFileExist follow symlinks so they add more
surprize to the scenario.

What can we do about this?

-- 
Gracjan



From ml at isaac.cedarswampstudios.org  Tue Jun 10 15:23:37 2014
From: ml at isaac.cedarswampstudios.org (Isaac Dupree)
Date: Tue, 10 Jun 2014 11:23:37 -0400
Subject: System.Directory.removeDirectoryRecursive and symlinks
In-Reply-To: <loom.20140610T152620-599@post.gmane.org>
References: <loom.20140610T152620-599@post.gmane.org>
Message-ID: <539722F9.70201@isaac.cedarswampstudios.org>

The documentation also says "Be careful, if the directory contains 
symlinks, the function will follow them.", which is dangerous and 
inappropriate but thankfully not actually what removeDirectoryRecursive 
does (based on testing and also on reading the code).  That statement 
should be removed from the documentation.

I'm indifferent on whether the argument path itself should be able to be 
a symlink to a directory, and if so, whether the target directory and/or 
the symlink should be removed, and whether this should differ based on 
whether the path ends in a "/" or not.  (Many Unix operations on 
symlinks, like `ls`, do differ based on a trailing slash. `rm -rf 
symlink` removes just the symlink; `rm -rf symlink/` appears to remove 
the contents of the target directory but neither the symlink nor the 
target directory itself...)

-Isaac

On 06/10/2014 09:42 AM, Gracjan Polak wrote:
> Hi all,
>
> A crime scene:
>
> Prelude System.Directory> :!mkdir a-directory
> Prelude System.Directory> :!touch a-directory/a-file.txt
> Prelude System.Directory> :!ln -s "a-directory" "a-symlink-to-a-directory"
> Prelude System.Directory> :!ls a-directory
> a-file.txt
> Prelude System.Directory> :!ls a-symlink-to-a-directory
> a-file.txt
> Prelude System.Directory> removeDirectoryRecursive
>                               "a-symlink-to-a-directory"
> *** Exception: a-symlink-to-a-directory: removeDirectory:
>      inappropriate type (Not a directory)
> Prelude System.Directory> :!ls a-symlink-to-a-directory
> Prelude System.Directory> :!ls a-directory
> Prelude System.Directory> :!ls -a a-directory
> .	..
> Prelude System.Directory> :!ls -a a-symlink-to-a-directory
> .	..
> Prelude System.Directory>
>
> removeDirectoryRecursive is removing all contents *of the directory linked*
> but is unable to remove the symlink itself.
>
> This behavior is surprizing if not dangerous. I understand that this mimics
> behavior of unlink/rmdir and DeleteFile/RemoveDirectory. but let me quote
> relevant manuals:
>
> man rm:
> The rm utility removes symbolic links, not the files referenced by the links.
>
> DeleteFile docs:
> If the path points to a symbolic link, the symbolic link is deleted, not the
> target. To delete a target, you must call CreateFile and specify
> FILE_FLAG_DELETE_ON_CLOSE.
>
> RemoveDirectory removes a directory junction, even if the contents of the
> target are not empty; the function removes directory junctions regardless of
> the state of the target object.
>
> Note: doesDirectoryExist and doesFileExist follow symlinks so they add more
> surprize to the scenario.
>
> What can we do about this?
>


From gracjanpolak at gmail.com  Tue Jun 10 15:37:12 2014
From: gracjanpolak at gmail.com (Gracjan Polak)
Date: Tue, 10 Jun 2014 15:37:12 +0000 (UTC)
Subject: System.Directory.removeDirectoryRecursive and symlinks
References: <loom.20140610T152620-599@post.gmane.org>
 <539722F9.70201@isaac.cedarswampstudios.org>
Message-ID: <loom.20140610T173349-315@post.gmane.org>

Isaac Dupree <ml <at> isaac.cedarswampstudios.org> writes:

> That statement should be removed from the documentation.

https://github.com/haskell/directory/pull/1
 
> Many Unix operations on 
> symlinks, like `ls`, do differ based on a trailing slash. `rm -rf 
> symlink` removes just the symlink; `rm -rf symlink/` appears to remove 
> the contents of the target directory but neither the symlink nor the 
> target directory itself...)

Sounds like a very reasonable idea and has prior art.

-- 
Gracjan



From ml at isaac.cedarswampstudios.org  Tue Jun 10 16:01:10 2014
From: ml at isaac.cedarswampstudios.org (Isaac Dupree)
Date: Tue, 10 Jun 2014 12:01:10 -0400
Subject: System.Directory.removeDirectoryRecursive and symlinks
In-Reply-To: <loom.20140610T173349-315@post.gmane.org>
References: <loom.20140610T152620-599@post.gmane.org>
 <539722F9.70201@isaac.cedarswampstudios.org>
 <loom.20140610T173349-315@post.gmane.org>
Message-ID: <53972BC6.2040307@isaac.cedarswampstudios.org>

On 06/10/2014 11:37 AM, Gracjan Polak wrote:
> Isaac Dupree <ml <at> isaac.cedarswampstudios.org> writes:
>> Many Unix operations on
>> symlinks, like `ls`, do differ based on a trailing slash. `rm -rf
>> symlink` removes just the symlink; `rm -rf symlink/` appears to remove
>> the contents of the target directory but neither the symlink nor the
>> target directory itself...)
>
> Sounds like a very reasonable idea and has prior art.

Should removeDirectoryRecursive also remove regular files when called on 
a file?  That's what `rm -r` does, but it might not be what we want 
`removeDirectoryRecursive` to do.
-Isaac


From gracjanpolak at gmail.com  Tue Jun 10 19:19:30 2014
From: gracjanpolak at gmail.com (Gracjan Polak)
Date: Tue, 10 Jun 2014 19:19:30 +0000 (UTC)
Subject: System.Directory.removeDirectoryRecursive and symlinks
References: <loom.20140610T152620-599@post.gmane.org>
 <539722F9.70201@isaac.cedarswampstudios.org>
 <loom.20140610T173349-315@post.gmane.org>
 <53972BC6.2040307@isaac.cedarswampstudios.org>
Message-ID: <loom.20140610T210451-98@post.gmane.org>

Isaac Dupree <ml <at> isaac.cedarswampstudios.org> writes:

> Should removeDirectoryRecursive also remove regular files when called on 
> a file?  That's what `rm -r` does, but it might not be what we want 
> `removeDirectoryRecursive` to do.

Easiest would be to removeLink, if that fails due to directory then empty
directory and then removeDirectory, but unlink man page says:

[EPERM] The named file is a directory and the effective user ID of the
process is not the super-user.

So unlink seems to sometimes be able to unlink directories. What happens to
such directories is not know to me. I also wasn't able to sucessfully unlink
directory, so hard to say what is going on. (Note that this bug is also
present in current implementation that recurses, tries removeFile, then
getDirectoryContents, then removeDirectory).

Who would have thought that removing directory would be that hard?

-- 
Gracjan



From gracjanpolak at gmail.com  Tue Jun 10 19:30:02 2014
From: gracjanpolak at gmail.com (Gracjan Polak)
Date: Tue, 10 Jun 2014 19:30:02 +0000 (UTC)
Subject: System.Directory.removeDirectoryRecursive and symlinks
References: <loom.20140610T152620-599@post.gmane.org>
 <539722F9.70201@isaac.cedarswampstudios.org>
 <loom.20140610T173349-315@post.gmane.org>
 <53972BC6.2040307@isaac.cedarswampstudios.org>
 <loom.20140610T210451-98@post.gmane.org>
Message-ID: <loom.20140610T212933-801@post.gmane.org>

Gracjan Polak <gracjanpolak <at> gmail.com> writes:

> Who would have thought that removing directory would be that hard?

http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/remove.c

-- 
Gracjan





From gtener at gmail.com  Tue Jun 10 20:00:31 2014
From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=)
Date: Tue, 10 Jun 2014 22:00:31 +0200
Subject: System.Directory.removeDirectoryRecursive and symlinks
In-Reply-To: <539722F9.70201@isaac.cedarswampstudios.org>
References: <loom.20140610T152620-599@post.gmane.org>
 <539722F9.70201@isaac.cedarswampstudios.org>
Message-ID: <CAM7aEVEJwqPVwJPu6nq1zwwT+8ZWCa-YzkThBAujNenWOoTixA@mail.gmail.com>

Following symlinks can be potentially dangerous/security exploit: symlink
to '/' can be created by non-priviliged user and then removed using
removeDirectoryRecursive called by priviliged user (example: root deleting
user account & directory). Catastrophic system damage can follow. Also
might be used for selective attacks, e.g. deleting files that contain
firewall settings or something alike.

All best,
Krzysztof Skrz?tnicki

On Tue, Jun 10, 2014 at 5:23 PM, Isaac Dupree <
ml at isaac.cedarswampstudios.org> wrote:

> The documentation also says "Be careful, if the directory contains
> symlinks, the function will follow them.", which is dangerous and
> inappropriate but thankfully not actually what removeDirectoryRecursive
> does (based on testing and also on reading the code).  That statement
> should be removed from the documentation.
>
> I'm indifferent on whether the argument path itself should be able to be a
> symlink to a directory, and if so, whether the target directory and/or the
> symlink should be removed, and whether this should differ based on whether
> the path ends in a "/" or not.  (Many Unix operations on symlinks, like
> `ls`, do differ based on a trailing slash. `rm -rf symlink` removes just
> the symlink; `rm -rf symlink/` appears to remove the contents of the target
> directory but neither the symlink nor the target directory itself...)
>
> -Isaac
>
>
> On 06/10/2014 09:42 AM, Gracjan Polak wrote:
>
>> Hi all,
>>
>> A crime scene:
>>
>> Prelude System.Directory> :!mkdir a-directory
>> Prelude System.Directory> :!touch a-directory/a-file.txt
>> Prelude System.Directory> :!ln -s "a-directory" "a-symlink-to-a-directory"
>> Prelude System.Directory> :!ls a-directory
>> a-file.txt
>> Prelude System.Directory> :!ls a-symlink-to-a-directory
>> a-file.txt
>> Prelude System.Directory> removeDirectoryRecursive
>>                               "a-symlink-to-a-directory"
>> *** Exception: a-symlink-to-a-directory: removeDirectory:
>>      inappropriate type (Not a directory)
>> Prelude System.Directory> :!ls a-symlink-to-a-directory
>> Prelude System.Directory> :!ls a-directory
>> Prelude System.Directory> :!ls -a a-directory
>> .       ..
>> Prelude System.Directory> :!ls -a a-symlink-to-a-directory
>> .       ..
>> Prelude System.Directory>
>>
>> removeDirectoryRecursive is removing all contents *of the directory
>> linked*
>> but is unable to remove the symlink itself.
>>
>> This behavior is surprizing if not dangerous. I understand that this
>> mimics
>> behavior of unlink/rmdir and DeleteFile/RemoveDirectory. but let me quote
>> relevant manuals:
>>
>> man rm:
>> The rm utility removes symbolic links, not the files referenced by the
>> links.
>>
>> DeleteFile docs:
>> If the path points to a symbolic link, the symbolic link is deleted, not
>> the
>> target. To delete a target, you must call CreateFile and specify
>> FILE_FLAG_DELETE_ON_CLOSE.
>>
>> RemoveDirectory removes a directory junction, even if the contents of the
>> target are not empty; the function removes directory junctions regardless
>> of
>> the state of the target object.
>>
>> Note: doesDirectoryExist and doesFileExist follow symlinks so they add
>> more
>> surprize to the scenario.
>>
>> What can we do about this?
>>
>>
> _______________________________________________
> 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/20140610/92570753/attachment-0001.html>

From allbery.b at gmail.com  Tue Jun 10 20:24:41 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 10 Jun 2014 16:24:41 -0400
Subject: System.Directory.removeDirectoryRecursive and symlinks
In-Reply-To: <loom.20140610T210451-98@post.gmane.org>
References: <loom.20140610T152620-599@post.gmane.org>
 <539722F9.70201@isaac.cedarswampstudios.org>
 <loom.20140610T173349-315@post.gmane.org>
 <53972BC6.2040307@isaac.cedarswampstudios.org>
 <loom.20140610T210451-98@post.gmane.org>
Message-ID: <CAKFCL4X-ujEVxUB4x-7qheOv1Fq7+4Ceox6HutbcP_wT_uoF0w@mail.gmail.com>

On Tue, Jun 10, 2014 at 3:19 PM, Gracjan Polak <gracjanpolak at gmail.com>
wrote:

> Easiest would be to removeLink, if that fails due to directory then empty
> directory and then removeDirectory, but unlink man page says:
>
> [EPERM] The named file is a directory and the effective user ID of the
> process is not the super-user.
>
> So unlink seems to sometimes be able to unlink directories. What happens to
>

unlink(2) can't unlink directories except as root, plus you have to follow
certain specific rules. rmdir(2) can. This is a historical thing.

(You must manually unlink(2) the '.' and '..' entries along with everything
else in the directory before you can unlink(2) the directory itself. except
on systems where this functionality was completely blocked in order to make
you use rmdir(2). This behavior is how directories worked in 7th research
edition and earlier, and AT&T System III; the syscalls were added primarily
for the benefit of NFS so that directory creation/removal would be atomic
and not involve root permissions vs. root squashing.)

-- 
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/20140610/20a441bf/attachment.html>

From abela at chalmers.se  Thu Jun 12 14:45:02 2014
From: abela at chalmers.se (Andreas Abel)
Date: Thu, 12 Jun 2014 16:45:02 +0200
Subject: List.or, List.any and List.elem
Message-ID: <5399BCEE.1070305@chalmers.se>

Curious on whether I should prefer

   List.any f

over

   List.or . List.map f

I consulted the source code at

http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-List.html

I found that according to the Report, they are identical, but there are 
fusion rules for List.any which look like I should prefer it to the said 
composition.

What puzzled me is that later,

   List.elem x

is

   List.any (x ==)

according to the Report, but GHC defines it recursively, *without* 
fusion rules.  I wonder

Q1: Should I prefer List.any (x==) then, since it gives opportunity to 
fusion?

Q2: Why is then List.elem defined recursively?

Q3: Where is the comment that justifies the taken design decisions??

Cheers,
Andreas


#ifdef USE_REPORT_PRELUDE
any p                   =  or . map p
all p                   =  and . map p
#else
any _ []        = False
any p (x:xs)    = p x || any p xs

all _ []        =  True
all p (x:xs)    =  p x && all p xs

{-# NOINLINE [1] any #-}
{-# NOINLINE [1] all #-}

{-# RULES
"any/build"     forall p (g::forall b.(a->b->b)->b->b) .
                 any p (build g) = g ((||) . p) False
"all/build"     forall p (g::forall b.(a->b->b)->b->b) .
                 all p (build g) = g ((&&) . p) True
  #-}
#endif

-- | 'elem' is the list membership predicate, usually written in infix form,
-- e.g., @x \`elem\` xs at .  For the result to be
-- 'False', the list must be finite; 'True', however, results from an 
element equal to @x@ found at a finite index of a finite or infinite list.
elem                    :: (Eq a) => a -> [a] -> Bool

-- | 'notElem' is the negation of 'elem'.
notElem                 :: (Eq a) => a -> [a] -> Bool
#ifdef USE_REPORT_PRELUDE
elem x                  =  any (== x)
notElem x               =  all (/= x)
#else
elem _ []       = False
elem x (y:ys)   = x==y || elem x ys

notElem _ []    =  True
notElem x (y:ys)=  x /= y && notElem x ys
#endif

-- 
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 vogt.adam at gmail.com  Sat Jun 14 19:30:04 2014
From: vogt.adam at gmail.com (adam vogt)
Date: Sat, 14 Jun 2014 15:30:04 -0400
Subject: setlocale maintainership
Message-ID: <CAHfjoWm0By6PLqhiTUTT+rCqD4GYcWj6fFndEHU+6MFJMbKGuw@mail.gmail.com>

Hello list.

http://hackage.haskell.org/package/setlocale does not compile with
ghc-7.8 because it has a manually written typeable instance. I emailed
the author about this one month ago (May 15), but I have received no
reply.

Let us wait until September 1 2014, and then I could be allowed to
upload a corrected version?

Regards,
Adam

From zcarterc at gmail.com  Sat Jun 14 20:15:01 2014
From: zcarterc at gmail.com (Carter Charbonneau)
Date: Sat, 14 Jun 2014 14:15:01 -0600
Subject: Proposal: Use (.) and id from Control.Category in Prelude
Message-ID: <lniag5$q8h$1@ger.gmane.org>

(.) and id are generalized in the Category class in Control.Category. In 
the past, many libraries have instructed users to use (.) and id from 
Control.Category for composition of their types. Importing these types 
into Prelude shouldn't break existing code, and makes libraries that use 
Category easier to use.

Discussion period: 4 weeks


From johan.tibell at gmail.com  Sat Jun 14 20:31:15 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Sat, 14 Jun 2014 22:31:15 +0200
Subject: Proposal: Use (.) and id from Control.Category in Prelude
In-Reply-To: <lniag5$q8h$1@ger.gmane.org>
References: <lniag5$q8h$1@ger.gmane.org>
Message-ID: <CAK-tuPbuxSpqVYnUS=xvPQAGrMsP_R1yqc5bXo2+Y6OGrmMjtA@mail.gmail.com>

On Sat, Jun 14, 2014 at 10:15 PM, Carter Charbonneau <zcarterc at gmail.com>
wrote:

> (.) and id are generalized in the Category class in Control.Category. In
> the past, many libraries have instructed users to use (.) and id from
> Control.Category for composition of their types. Importing these types into
> Prelude shouldn't break existing code, and makes libraries that use
> Category easier to use.
>
> Discussion period: 4 weeks
>

-1

This would benefit very few Haskell users and make error messages terrible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140614/df027714/attachment.html>

From zcarterc at gmail.com  Sat Jun 14 20:50:40 2014
From: zcarterc at gmail.com (Carter Charbonneau)
Date: Sat, 14 Jun 2014 14:50:40 -0600
Subject: Proposal: Use (.) and id from Control.Category in Prelude
In-Reply-To: <CAK-tuPbuxSpqVYnUS=xvPQAGrMsP_R1yqc5bXo2+Y6OGrmMjtA@mail.gmail.com>
References: <lniag5$q8h$1@ger.gmane.org>
 <CAK-tuPbuxSpqVYnUS=xvPQAGrMsP_R1yqc5bXo2+Y6OGrmMjtA@mail.gmail.com>
Message-ID: <lnicjp$kcd$1@ger.gmane.org>

On 06/14/2014 02:31 PM, Johan Tibell wrote:
> On Sat, Jun 14, 2014 at 10:15 PM, Carter Charbonneau <zcarterc at gmail.com
> <mailto:zcarterc at gmail.com>> wrote:
>
>     (.) and id are generalized in the Category class in
>     Control.Category. In the past, many libraries have instructed users
>     to use (.) and id from Control.Category for composition of their
>     types. Importing these types into Prelude shouldn't break existing
>     code, and makes libraries that use Category easier to use.
>
>     Discussion period: 4 weeks
>
>
> -1
>
> This would benefit very few Haskell users and make error messages terrible.
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

In real use of Category with only the (->) instance in scope, I don't 
run into complex error messages often, if ever. Do you have an example 
where complex error messages come into play?


From sjoerd at w3future.com  Sat Jun 14 21:10:26 2014
From: sjoerd at w3future.com (Sjoerd Visscher)
Date: Sat, 14 Jun 2014 23:10:26 +0200
Subject: Proposal: Use (.) and id from Control.Category in Prelude
In-Reply-To: <CAK-tuPbuxSpqVYnUS=xvPQAGrMsP_R1yqc5bXo2+Y6OGrmMjtA@mail.gmail.com>
References: <lniag5$q8h$1@ger.gmane.org>
 <CAK-tuPbuxSpqVYnUS=xvPQAGrMsP_R1yqc5bXo2+Y6OGrmMjtA@mail.gmail.com>
Message-ID: <10AB3E52-A2DC-4CE9-9936-56259BCBA936@w3future.com>

I strongly disagree, this would benefit all Haskell users, and will improve error messages!

Packages like lens now jump through hoops to be able to do composition with the Prelude (.), making proper abstraction impossible, resulting in horrible error messages spewing the internals of the library to the unsuspecting user.

Composition is very important for modular code, and should be made as accessible to all users as possible.

Sjoerd

On 14 Jun 2014, at 22:31, Johan Tibell <johan.tibell at gmail.com> wrote:

> On Sat, Jun 14, 2014 at 10:15 PM, Carter Charbonneau <zcarterc at gmail.com> wrote:
> (.) and id are generalized in the Category class in Control.Category. In the past, many libraries have instructed users to use (.) and id from Control.Category for composition of their types. Importing these types into Prelude shouldn't break existing code, and makes libraries that use Category easier to use.
> 
> Discussion period: 4 weeks
> 
> -1
> 
> This would benefit very few Haskell users and make error messages terrible.
>  
> _______________________________________________
> 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/20140614/bf376d49/attachment.html>

From iavor.diatchki at gmail.com  Sun Jun 15 01:18:47 2014
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sat, 14 Jun 2014 18:18:47 -0700
Subject: Proposal: Use (.) and id from Control.Category in Prelude
In-Reply-To: <10AB3E52-A2DC-4CE9-9936-56259BCBA936@w3future.com>
References: <lniag5$q8h$1@ger.gmane.org>
 <CAK-tuPbuxSpqVYnUS=xvPQAGrMsP_R1yqc5bXo2+Y6OGrmMjtA@mail.gmail.com>
 <10AB3E52-A2DC-4CE9-9936-56259BCBA936@w3future.com>
Message-ID: <CAGK9nurCiZ0uEcjU5kZTRKAw94hbqiLKD3+GcBRnaKPSEvjvTQ@mail.gmail.com>

-2.   Please don't.  The status quo works well enough, and is sufficient
for many many cases (in fact all I've ever encountered).  Folks who need
more already have a perfectly reasonable way to get it: simply use the
overloaded operators from `Control.Category`.

-Iavor


On Sat, Jun 14, 2014 at 2:10 PM, Sjoerd Visscher <sjoerd at w3future.com>
wrote:

> I strongly disagree, this would benefit all Haskell users, and will
> improve error messages!
>
> Packages like lens now jump through hoops to be able to do composition
> with the Prelude (.), making proper abstraction impossible, resulting in
> horrible error messages spewing the internals of the library to the
> unsuspecting user.
>
> Composition is very important for modular code, and should be made as
> accessible to all users as possible.
>
> Sjoerd
>
> On 14 Jun 2014, at 22:31, Johan Tibell <johan.tibell at gmail.com> wrote:
>
> On Sat, Jun 14, 2014 at 10:15 PM, Carter Charbonneau <zcarterc at gmail.com>
> wrote:
>
>> (.) and id are generalized in the Category class in Control.Category. In
>> the past, many libraries have instructed users to use (.) and id from
>> Control.Category for composition of their types. Importing these types into
>> Prelude shouldn't break existing code, and makes libraries that use
>> Category easier to use.
>>
>> Discussion period: 4 weeks
>>
>
> -1
>
> This would benefit very few Haskell users and make error messages terrible.
>
> _______________________________________________
> 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/20140614/256cb7cb/attachment.html>

From dan.doel at gmail.com  Sun Jun 15 02:43:06 2014
From: dan.doel at gmail.com (Dan Doel)
Date: Sat, 14 Jun 2014 22:43:06 -0400
Subject: Proposal: Use (.) and id from Control.Category in Prelude
In-Reply-To: <10AB3E52-A2DC-4CE9-9936-56259BCBA936@w3future.com>
References: <lniag5$q8h$1@ger.gmane.org>
 <CAK-tuPbuxSpqVYnUS=xvPQAGrMsP_R1yqc5bXo2+Y6OGrmMjtA@mail.gmail.com>
 <10AB3E52-A2DC-4CE9-9936-56259BCBA936@w3future.com>
Message-ID: <CAHEA9tOF7xLVcNRK6jVQ2H3X72vmhFbOEuW_4FdfjczzY4Ms=g@mail.gmail.com>

On Sat, Jun 14, 2014 at 5:10 PM, Sjoerd Visscher <sjoerd at w3future.com>
wrote:

> Packages like lens now jump through hoops to be able to do composition
> with the Prelude (.), making proper abstraction impossible, resulting in
> horrible error messages spewing the internals of the library to the
> unsuspecting user.
>

Category is inadequate for the type of composition that goes on in lens.
lens relies on the type class system to induce subtyping between the
various types it defines (aliases). If you create abstraction barriers
around things like Iso, Lens, Prism, Traversal, etc. then each of these
will only compose with like things, and one of the major features of lens
would be lost.

Category also doesn't work for the four-parameter versions of things
required for full generality.

So lens isn't a very compelling motivation for Category composition.

-- Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140614/77e2c1e3/attachment.html>

From john at repetae.net  Sun Jun 15 02:54:16 2014
From: john at repetae.net (John Meacham)
Date: Sat, 14 Jun 2014 19:54:16 -0700
Subject: Proposal: Use (.) and id from Control.Category in Prelude
In-Reply-To: <CAHEA9tOF7xLVcNRK6jVQ2H3X72vmhFbOEuW_4FdfjczzY4Ms=g@mail.gmail.com>
References: <lniag5$q8h$1@ger.gmane.org>
 <CAK-tuPbuxSpqVYnUS=xvPQAGrMsP_R1yqc5bXo2+Y6OGrmMjtA@mail.gmail.com>
 <10AB3E52-A2DC-4CE9-9936-56259BCBA936@w3future.com>
 <CAHEA9tOF7xLVcNRK6jVQ2H3X72vmhFbOEuW_4FdfjczzY4Ms=g@mail.gmail.com>
Message-ID: <CAM0WKeXTa2ZbhA+WR+A330JA8Ry0gaSfXRFTmuGb8+auTJ6=_w@mail.gmail.com>

Yeah, type errors get really confusing with too much overloading and
you start to have to use type annotations way more often. I recently
"de-overloaded" a fair bit of the jhc codebase I wrote back when I
thought it was cute to use typeclasses just to reuse syntax.

Actually, a change I'd like to see is just make sure that no modules
re-export anything that prelude exports. that way you can do a import
prelude hiding (blah) and not have to add the hiding clause to other
imports that happen to re-export prelude names.

    John

On Sat, Jun 14, 2014 at 7:43 PM, Dan Doel <dan.doel at gmail.com> wrote:
> On Sat, Jun 14, 2014 at 5:10 PM, Sjoerd Visscher <sjoerd at w3future.com>
> wrote:
>>
>> Packages like lens now jump through hoops to be able to do composition
>> with the Prelude (.), making proper abstraction impossible, resulting in
>> horrible error messages spewing the internals of the library to the
>> unsuspecting user.
>
>
> Category is inadequate for the type of composition that goes on in lens.
> lens relies on the type class system to induce subtyping between the various
> types it defines (aliases). If you create abstraction barriers around things
> like Iso, Lens, Prism, Traversal, etc. then each of these will only compose
> with like things, and one of the major features of lens would be lost.
>
> Category also doesn't work for the four-parameter versions of things
> required for full generality.
>
> So lens isn't a very compelling motivation for Category composition.
>
> -- Dan
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>



-- 
John Meacham - http://notanumber.net/

From roma at ro-che.info  Sun Jun 15 06:26:19 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Sun, 15 Jun 2014 09:26:19 +0300
Subject: Proposal: Use (.) and id from Control.Category in Prelude
In-Reply-To: <CAM0WKeXTa2ZbhA+WR+A330JA8Ry0gaSfXRFTmuGb8+auTJ6=_w@mail.gmail.com>
References: <lniag5$q8h$1@ger.gmane.org>
 <CAK-tuPbuxSpqVYnUS=xvPQAGrMsP_R1yqc5bXo2+Y6OGrmMjtA@mail.gmail.com>
 <10AB3E52-A2DC-4CE9-9936-56259BCBA936@w3future.com>
 <CAHEA9tOF7xLVcNRK6jVQ2H3X72vmhFbOEuW_4FdfjczzY4Ms=g@mail.gmail.com>
 <CAM0WKeXTa2ZbhA+WR+A330JA8Ry0gaSfXRFTmuGb8+auTJ6=_w@mail.gmail.com>
Message-ID: <20140615062619.GA10579@sniper>

* John Meacham <john at repetae.net> [2014-06-14 19:54:16-0700]
> Actually, a change I'd like to see is just make sure that no modules
> re-export anything that prelude exports.

Do you have any examples of this?

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140615/6b1ec865/attachment.sig>

From R.Paterson at city.ac.uk  Sun Jun 15 08:42:31 2014
From: R.Paterson at city.ac.uk (Ross Paterson)
Date: Sun, 15 Jun 2014 09:42:31 +0100
Subject: Proposal: Use (.) and id from Control.Category in Prelude
In-Reply-To: <20140615062619.GA10579@sniper>
References: <lniag5$q8h$1@ger.gmane.org>
 <CAK-tuPbuxSpqVYnUS=xvPQAGrMsP_R1yqc5bXo2+Y6OGrmMjtA@mail.gmail.com>
 <10AB3E52-A2DC-4CE9-9936-56259BCBA936@w3future.com>
 <CAHEA9tOF7xLVcNRK6jVQ2H3X72vmhFbOEuW_4FdfjczzY4Ms=g@mail.gmail.com>
 <CAM0WKeXTa2ZbhA+WR+A330JA8Ry0gaSfXRFTmuGb8+auTJ6=_w@mail.gmail.com>
 <20140615062619.GA10579@sniper>
Message-ID: <20140615084231.GA4554@city.ac.uk>

On Sun, Jun 15, 2014 at 09:26:19AM +0300, Roman Cheplyaka wrote:
> * John Meacham <john at repetae.net> [2014-06-14 19:54:16-0700]
> > Actually, a change I'd like to see is just make sure that no modules
> > re-export anything that prelude exports.
> 
> Do you have any examples of this?

Data.List has a lot of them.  Others include:

Control.Monad: Functor(fmap), Monad((>>=), (>>), return, fail)
Data.Functor: Functor(fmap)
Data.Maybe: Maybe(Nothing, Just), maybe
Data.Ratio: Rational

From ekmett at gmail.com  Sun Jun 15 11:04:30 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 15 Jun 2014 07:04:30 -0400
Subject: Proposal: Use (.) and id from Control.Category in Prelude
In-Reply-To: <CAM0WKeXTa2ZbhA+WR+A330JA8Ry0gaSfXRFTmuGb8+auTJ6=_w@mail.gmail.com>
References: <lniag5$q8h$1@ger.gmane.org>
 <CAK-tuPbuxSpqVYnUS=xvPQAGrMsP_R1yqc5bXo2+Y6OGrmMjtA@mail.gmail.com>
 <10AB3E52-A2DC-4CE9-9936-56259BCBA936@w3future.com>
 <CAHEA9tOF7xLVcNRK6jVQ2H3X72vmhFbOEuW_4FdfjczzY4Ms=g@mail.gmail.com>
 <CAM0WKeXTa2ZbhA+WR+A330JA8Ry0gaSfXRFTmuGb8+auTJ6=_w@mail.gmail.com>
Message-ID: <CAJumaK9k_aHLXW6gq_QVCCNmqebzYztmON_ZVqg_z9zRjtzqLA@mail.gmail.com>

On Sat, Jun 14, 2014 at 10:54 PM, John Meacham <john at repetae.net> wrote:

> Actually, a change I'd like to see is just make sure that no modules
> re-export anything that prelude exports. that way you can do a import
> prelude hiding (blah) and not have to add the hiding clause to other
> imports that happen to re-export prelude names.
>

I could personally get behind this policy.

mtl is probably the worst offender, and I receive regular complaints from
users about it. It is very hard to hide something when 10 of your imports
want to re-export it ;)

Moreover, many of these cases will cease to make sense in 7.8.

e.g. Data.List.foldr as a re-export would be a lot harder to motivate when
that is re-exporting the Foldable version, while having it export a
monomorphic version would break virtually every user of Data.List

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140615/4c6a7d48/attachment.html>

From roma at ro-che.info  Sun Jun 15 12:08:15 2014
From: roma at ro-che.info (Roman Cheplyaka)
Date: Sun, 15 Jun 2014 15:08:15 +0300
Subject: Proposal: Use (.) and id from Control.Category in Prelude
In-Reply-To: <20140615084231.GA4554@city.ac.uk>
References: <lniag5$q8h$1@ger.gmane.org>
 <CAK-tuPbuxSpqVYnUS=xvPQAGrMsP_R1yqc5bXo2+Y6OGrmMjtA@mail.gmail.com>
 <10AB3E52-A2DC-4CE9-9936-56259BCBA936@w3future.com>
 <CAHEA9tOF7xLVcNRK6jVQ2H3X72vmhFbOEuW_4FdfjczzY4Ms=g@mail.gmail.com>
 <CAM0WKeXTa2ZbhA+WR+A330JA8Ry0gaSfXRFTmuGb8+auTJ6=_w@mail.gmail.com>
 <20140615062619.GA10579@sniper> <20140615084231.GA4554@city.ac.uk>
Message-ID: <20140615120815.GA5920@sniper>

* Ross Paterson <R.Paterson at city.ac.uk> [2014-06-15 09:42:31+0100]
> On Sun, Jun 15, 2014 at 09:26:19AM +0300, Roman Cheplyaka wrote:
> > * John Meacham <john at repetae.net> [2014-06-14 19:54:16-0700]
> > > Actually, a change I'd like to see is just make sure that no modules
> > > re-export anything that prelude exports.
> > 
> > Do you have any examples of this?
> 
> Data.List has a lot of them.  Others include:
> 
> Control.Monad: Functor(fmap), Monad((>>=), (>>), return, fail)
> Data.Functor: Functor(fmap)
> Data.Maybe: Maybe(Nothing, Just), maybe
> Data.Ratio: Rational

Maybe I misunderstood the concern.

For me it looks more like Prelude re-exporting stuff from those modules, which
makes sense.

Would you prefer Data.List randomly lacking lists functions on the basis that
they are exported by Prelude?

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140615/745cb02e/attachment.sig>

From hvr at gnu.org  Sun Jun 15 14:13:46 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Sun, 15 Jun 2014 16:13:46 +0200
Subject: Proposal: Use (.) and id from Control.Category in Prelude
In-Reply-To: <CAGK9nurCiZ0uEcjU5kZTRKAw94hbqiLKD3+GcBRnaKPSEvjvTQ@mail.gmail.com>
 (Iavor Diatchki's message of "Sat, 14 Jun 2014 18:18:47 -0700")
References: <lniag5$q8h$1@ger.gmane.org>
 <CAK-tuPbuxSpqVYnUS=xvPQAGrMsP_R1yqc5bXo2+Y6OGrmMjtA@mail.gmail.com>
 <10AB3E52-A2DC-4CE9-9936-56259BCBA936@w3future.com>
 <CAGK9nurCiZ0uEcjU5kZTRKAw94hbqiLKD3+GcBRnaKPSEvjvTQ@mail.gmail.com>
Message-ID: <87k38ip8f9.fsf@gnu.org>

On 2014-06-15 at 03:18:47 +0200, Iavor Diatchki wrote:
> -2.   Please don't.  The status quo works well enough, and is sufficient
> for many many cases (in fact all I've ever encountered).  Folks who need
> more already have a perfectly reasonable way to get it: simply use the
> overloaded operators from `Control.Category`.

Maybe the underlying problem which prompts such proposals is that in
order to use more general versions of existing functions, like
e.g. Control.Categeroy or Data.Foldable, you have to go through a bit of
"ceremony" to hide the more specific versions.

I wonder if Haskell could be extended to be able to write something like

  import Data.Category

and have the more general versions of (.) and id automatically shadow
the monomorphic versions brought in scope by the Prelude.

Just a thought (which is probably not that new)

Cheers,
  hvr

From dgorin at dc.uba.ar  Sun Jun 15 14:43:44 2014
From: dgorin at dc.uba.ar (=?iso-8859-1?Q?Daniel_Gor=EDn?=)
Date: Sun, 15 Jun 2014 16:43:44 +0200
Subject: Proposal: Use (.) and id from Control.Category in Prelude
In-Reply-To: <87k38ip8f9.fsf@gnu.org>
References: <lniag5$q8h$1@ger.gmane.org>
 <CAK-tuPbuxSpqVYnUS=xvPQAGrMsP_R1yqc5bXo2+Y6OGrmMjtA@mail.gmail.com>
 <10AB3E52-A2DC-4CE9-9936-56259BCBA936@w3future.com>
 <CAGK9nurCiZ0uEcjU5kZTRKAw94hbqiLKD3+GcBRnaKPSEvjvTQ@mail.gmail.com>
 <87k38ip8f9.fsf@gnu.org>
Message-ID: <EDA8D0A0-4934-44C4-9B46-CCA6621FF515@dc.uba.ar>


On 15 Jun 2014, at 16:13, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> I wonder if Haskell could be extended to be able to write something like
> 
> import Data.Category
> 
> and have the more general versions of (.) and id automatically shadow
> the monomorphic versions brought in scope by the Prelude.
> 
> Just a thought (which is probably not that new)

There was a brief discussion about it some time ago:

http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/23719

From abela at chalmers.se  Mon Jun 16 08:14:17 2014
From: abela at chalmers.se (Andreas Abel)
Date: Mon, 16 Jun 2014 10:14:17 +0200
Subject: setlocale maintainership
In-Reply-To: <CAHfjoWm0By6PLqhiTUTT+rCqD4GYcWj6fFndEHU+6MFJMbKGuw@mail.gmail.com>
References: <CAHfjoWm0By6PLqhiTUTT+rCqD4GYcWj6fFndEHU+6MFJMbKGuw@mail.gmail.com>
Message-ID: <539EA759.6070807@chalmers.se>

 > Let us wait until September 1 2014, and then I could be allowed to
 > upload a corrected version?

Is this sarcarsm? (I guess so.)

I think in exceptional cases you should be allowed to fix a broken 
package earlier (which in general is a severe issue, due to the hazard 
of a psychological meltdown of the overstepped maintainer).

Maybe you can dig out a prophesy somewhere that the world ends on August 
31 2014?

On 14.06.2014 21:30, adam vogt wrote:
> Hello list.
>
> http://hackage.haskell.org/package/setlocale does not compile with
> ghc-7.8 because it has a manually written typeable instance. I emailed
> the author about this one month ago (May 15), but I have received no
> reply.
>
> Let us wait until September 1 2014, and then I could be allowed to
> upload a corrected version?
>
> Regards,
> Adam
> _______________________________________________
> 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 tab at snarc.org  Mon Jun 16 08:53:37 2014
From: tab at snarc.org (Vincent Hanquez)
Date: Mon, 16 Jun 2014 09:53:37 +0100
Subject: setlocale maintainership
In-Reply-To: <CAHfjoWm0By6PLqhiTUTT+rCqD4GYcWj6fFndEHU+6MFJMbKGuw@mail.gmail.com>
References: <CAHfjoWm0By6PLqhiTUTT+rCqD4GYcWj6fFndEHU+6MFJMbKGuw@mail.gmail.com>
Message-ID: <539EB091.8010206@snarc.org>

On 2014-06-14 20:30, adam vogt wrote:
> Hello list.
>
> http://hackage.haskell.org/package/setlocale does not compile with
> ghc-7.8 because it has a manually written typeable instance. I emailed
> the author about this one month ago (May 15), but I have received no
> reply.
Hi,

I think it would be more productive to merge this package into unix than 
keep this tiny module.

-- 
Vincent

From hvr at gnu.org  Mon Jun 16 08:57:53 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Mon, 16 Jun 2014 10:57:53 +0200
Subject: setlocale maintainership
In-Reply-To: <539EB091.8010206@snarc.org> (Vincent Hanquez's message of "Mon, 
 16 Jun 2014 09:53:37 +0100")
References: <CAHfjoWm0By6PLqhiTUTT+rCqD4GYcWj6fFndEHU+6MFJMbKGuw@mail.gmail.com>
 <539EB091.8010206@snarc.org>
Message-ID: <87a99d1bam.fsf@gnu.org>

On 2014-06-16 at 10:53:37 +0200, Vincent Hanquez wrote:
> On 2014-06-14 20:30, adam vogt wrote:
>> Hello list.
>>
>> http://hackage.haskell.org/package/setlocale does not compile with
>> ghc-7.8 because it has a manually written typeable instance. I emailed
>> the author about this one month ago (May 15), but I have received no
>> reply.
> Hi,
>
> I think it would be more productive to merge this package into unix
> than keep this tiny module.

Fwiw, you can submit bugs/issues at

  https://github.com/haskell/unix/issues


From hesselink at gmail.com  Mon Jun 16 09:09:06 2014
From: hesselink at gmail.com (Erik Hesselink)
Date: Mon, 16 Jun 2014 11:09:06 +0200
Subject: Proposal: Use (.) and id from Control.Category in Prelude
In-Reply-To: <87k38ip8f9.fsf@gnu.org>
References: <lniag5$q8h$1@ger.gmane.org>
 <CAK-tuPbuxSpqVYnUS=xvPQAGrMsP_R1yqc5bXo2+Y6OGrmMjtA@mail.gmail.com>
 <10AB3E52-A2DC-4CE9-9936-56259BCBA936@w3future.com>
 <CAGK9nurCiZ0uEcjU5kZTRKAw94hbqiLKD3+GcBRnaKPSEvjvTQ@mail.gmail.com>
 <87k38ip8f9.fsf@gnu.org>
Message-ID: <CAPeieQGP2bhFCkjn4F1zQpLMkEp2uEDo9x_xf8YC1bAgHXzTew@mail.gmail.com>

On Sun, Jun 15, 2014 at 4:13 PM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> I wonder if Haskell could be extended to be able to write something like
>
>   import Data.Category
>
> and have the more general versions of (.) and id automatically shadow
> the monomorphic versions brought in scope by the Prelude.

We use a custom prelude that almost gives us this. You have to do:

{-# LANGUAGE NoImplicitPrelude #-}

import Prelude.Polymorphic

This gives us Foldable/Traversable/Category polymorphic variants of
the prelude functions. It's been a pretty good experience. The largest
problem, as Edward already mentioned, are the re-exports of
Control.Monad from the mtl package.

I'm -1 on making (.) polymorphic by default though. The errors can be
kind of intimidating for the beginning Haskeller. Let's first see how
it goes with Foldable/Traversable in the prelude...

Erik

From hesselink at gmail.com  Mon Jun 16 09:10:45 2014
From: hesselink at gmail.com (Erik Hesselink)
Date: Mon, 16 Jun 2014 11:10:45 +0200
Subject: setlocale maintainership
In-Reply-To: <CAHfjoWm0By6PLqhiTUTT+rCqD4GYcWj6fFndEHU+6MFJMbKGuw@mail.gmail.com>
References: <CAHfjoWm0By6PLqhiTUTT+rCqD4GYcWj6fFndEHU+6MFJMbKGuw@mail.gmail.com>
Message-ID: <CAPeieQFDDuAGX32tpWagEd1TV7XEF9cz_PrO-=tysjyKOwfseA@mail.gmail.com>

If you upload your fix somewhere, I'm sure one of the hackage trustees
can upload a fixed version for you. No need to go through the whole
package takeover procedure.

Erik

On Sat, Jun 14, 2014 at 9:30 PM, adam vogt <vogt.adam at gmail.com> wrote:
> Hello list.
>
> http://hackage.haskell.org/package/setlocale does not compile with
> ghc-7.8 because it has a manually written typeable instance. I emailed
> the author about this one month ago (May 15), but I have received no
> reply.
>
> Let us wait until September 1 2014, and then I could be allowed to
> upload a corrected version?
>
> Regards,
> Adam
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

From ekmett at gmail.com  Mon Jun 16 09:37:37 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 16 Jun 2014 05:37:37 -0400
Subject: Proposal: Use (.) and id from Control.Category in Prelude
In-Reply-To: <CAPeieQGP2bhFCkjn4F1zQpLMkEp2uEDo9x_xf8YC1bAgHXzTew@mail.gmail.com>
References: <lniag5$q8h$1@ger.gmane.org>
 <CAK-tuPbuxSpqVYnUS=xvPQAGrMsP_R1yqc5bXo2+Y6OGrmMjtA@mail.gmail.com>
 <10AB3E52-A2DC-4CE9-9936-56259BCBA936@w3future.com>
 <CAGK9nurCiZ0uEcjU5kZTRKAw94hbqiLKD3+GcBRnaKPSEvjvTQ@mail.gmail.com>
 <87k38ip8f9.fsf@gnu.org>
 <CAPeieQGP2bhFCkjn4F1zQpLMkEp2uEDo9x_xf8YC1bAgHXzTew@mail.gmail.com>
Message-ID: <CAJumaK8jno-tENmdYsJVe_dHhM+kt7FThzEqcsDh0nMCh6MF8g@mail.gmail.com>

I'm somewhat neutral on the proposal.

On the plus side, generalizing Category fits with the current goal of
having base export one version of each combinator.

On the minus side, Category is far less used than the other abstractions
we're bringing into Prelude in 7.10.

Utimately? I'm ever so slightly in the 'we shouldn't do it' camp --  a very
weak -1 -- from the standpoint that Category is currently PolyKinded, which
is incredibly useful, and so far, nothing we export or are planning to
export from Prelude is.

It is currently very easy to propose the new Prelude we're building to the
folks on the Haskell' committee for standardization going forward.

With PolyKinds that becomes a rather bigger leap. Now, having implemented
PolyKinds in another compiler, they aren't too hard, just slightly tricky,
so that may be a thing we do want to do eventually, but I'd have a hard
time putting it forward for standardization with a straight face today.

I'd feel a bit more comfortable getting through the current wave of
generalization for 7.10, then revisiting if we should do this for 7.12 once
the community has had a chance to adapt.

If there was a huge upswell of support for this we could do it, but so far
the response has been one of measured indifference.

-Edward


On Mon, Jun 16, 2014 at 5:09 AM, Erik Hesselink <hesselink at gmail.com> wrote:

> On Sun, Jun 15, 2014 at 4:13 PM, Herbert Valerio Riedel <hvr at gnu.org>
> wrote:
>
> > I wonder if Haskell could be extended to be able to write something like
> >
> >   import Data.Category
> >
> > and have the more general versions of (.) and id automatically shadow
> > the monomorphic versions brought in scope by the Prelude.
>
> We use a custom prelude that almost gives us this. You have to do:
>
> {-# LANGUAGE NoImplicitPrelude #-}
>
> import Prelude.Polymorphic
>
> This gives us Foldable/Traversable/Category polymorphic variants of
> the prelude functions. It's been a pretty good experience. The largest
> problem, as Edward already mentioned, are the re-exports of
> Control.Monad from the mtl package.
>
> I'm -1 on making (.) polymorphic by default though. The errors can be
> kind of intimidating for the beginning Haskeller. Let's first see how
> it goes with Foldable/Traversable in the prelude...
>
> Erik
> _______________________________________________
> 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/20140616/4a2515f6/attachment-0001.html>

From eir at cis.upenn.edu  Mon Jun 16 13:46:12 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 16 Jun 2014 09:46:12 -0400
Subject: Polymorphism in the Prelude
Message-ID: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>

Hi libraries,

Let me try to sum up the general sentiment I've seen:

Having lots of polymorphism in the Prelude is great, but for two problems:
  1) It's very confusing to novices.
  2) In the case of using Control.Category definitions: kind-polymorphism is not portable

I wish to ignore (2) for now, as it's a smaller concern given that it affects only a portion of the proposed changes.

As a way to mitigate (1), I have been thinking of proposing something almost exactly along the lines of http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/23719 (thanks for posting that link -- saved me from writing up the same thing!). But, after reading that thread, I tend to agree that tweaking the module system seems the wrong way to deal with helping novices.

In designing my own libraries, my general guideline is to make the easy thing easy and make the hard thing only slightly less easy. Spurred on by Erik Hesselink's comment (http://www.haskell.org/pipermail/libraries/2014-June/023174.html), what if we just have two versions of `base` modules, the "normal" one that exports more monomorphic definitions (which novices are more likely to use) and a "Poly" one that exports more polymorphic definitions. For example:

{{{
{-# LANGUAGE NoImplicitPrelude #-}

import Prelude.Poly
import Data.List.Poly
import Data.Foldable
import Control.Monad.Poly
}}}

and then it just works.

Pros:
- Not disruptive to current status quo.
- No change in error messages for novices.
- Can actually be implemented without *any* changes to `base` -- I could upload this solution to Hackage today.

Cons:
- Maintaining two copies of export lists.
- Needs NoImplicitPrelude pragma.
- Overhead of remembering which modules have a "Poly" version and which don't.
- Somewhat ugly.

Even as I write this, I'm not sure that this is at all a good idea. But, to me, it's really intriguing that the solution is achievable today, with no difficulty. I would wager that if these Poly modules were out in the wild today, we might all grumble at them, but I don't know if there would be a movement to change the Prelude.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140616/589b50ef/attachment.html>

From ekmett at gmail.com  Mon Jun 16 14:07:22 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 16 Jun 2014 10:07:22 -0400
Subject: Polymorphism in the Prelude
In-Reply-To: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
Message-ID: <F46D6660-730B-47A1-9A91-7495C2A6930E@gmail.com>

Having attempted to program with NoImplicitPrelude "in anger", I personally think this fix is worse than the disease and I'm personally -1.

In some sense, the current path we're taking forward is actually substantially similar except the non-generalized versions are just the haskell2010 and haskell98 packages, which work well for the kind of trivial classroom exercises needed for the first semester worth of coursework, but desire to work with the rest of the library ecosystem provides gentle pressure to encourage people to learn the rest.

The difference is the vast majority of users aren't constantly plagued by the demand they use extensions to get what should really be baseline tools.

In the long term, yes we might want to embrace Category and other abstractions. The main issue I have is that it is very hard to motivate through Prelude in that there is only one Prelude type anyone can point to that is an instance.

-Edward

> On Jun 16, 2014, at 9:46 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> 
> Hi libraries,
> 
> Let me try to sum up the general sentiment I've seen:
> 
> Having lots of polymorphism in the Prelude is great, but for two problems:
>   1) It's very confusing to novices.
>   2) In the case of using Control.Category definitions: kind-polymorphism is not portable
> 
> I wish to ignore (2) for now, as it's a smaller concern given that it affects only a portion of the proposed changes.
> 
> As a way to mitigate (1), I have been thinking of proposing something almost exactly along the lines of http://comments.gmane.org/gmane.comp.lang.haskell.glasgow.user/23719 (thanks for posting that link -- saved me from writing up the same thing!). But, after reading that thread, I tend to agree that tweaking the module system seems the wrong way to deal with helping novices.
> 
> In designing my own libraries, my general guideline is to make the easy thing easy and make the hard thing only slightly less easy. Spurred on by Erik Hesselink's comment (http://www.haskell.org/pipermail/libraries/2014-June/023174.html), what if we just have two versions of `base` modules, the "normal" one that exports more monomorphic definitions (which novices are more likely to use) and a "Poly" one that exports more polymorphic definitions. For example:
> 
> {{{
> {-# LANGUAGE NoImplicitPrelude #-}
> 
> import Prelude.Poly
> import Data.List.Poly
> import Data.Foldable
> import Control.Monad.Poly
> }}}
> 
> and then it just works.
> 
> Pros:
> - Not disruptive to current status quo.
> - No change in error messages for novices.
> - Can actually be implemented without *any* changes to `base` -- I could upload this solution to Hackage today.
> 
> Cons:
> - Maintaining two copies of export lists.
> - Needs NoImplicitPrelude pragma.
> - Overhead of remembering which modules have a "Poly" version and which don't.
> - Somewhat ugly.
> 
> Even as I write this, I'm not sure that this is at all a good idea. But, to me, it's really intriguing that the solution is achievable today, with no difficulty. I would wager that if these Poly modules were out in the wild today, we might all grumble at them, but I don't know if there would be a movement to change the Prelude.
> 
> Richard
> _______________________________________________
> 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/20140616/c9467335/attachment.html>

From hesselink at gmail.com  Mon Jun 16 14:09:17 2014
From: hesselink at gmail.com (Erik Hesselink)
Date: Mon, 16 Jun 2014 16:09:17 +0200
Subject: Polymorphism in the Prelude
In-Reply-To: <F46D6660-730B-47A1-9A91-7495C2A6930E@gmail.com>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <F46D6660-730B-47A1-9A91-7495C2A6930E@gmail.com>
Message-ID: <CAPeieQH9a96wKV8mSB4ynD8OOS-jamNpqgSH7OrSaS7F3vsr3Q@mail.gmail.com>

On Mon, Jun 16, 2014 at 4:07 PM, Edward Kmett <ekmett at gmail.com> wrote:
> Having attempted to program with NoImplicitPrelude "in anger", I personally
> think this fix is worse than the disease and I'm personally -1.

Out of curiosity, what were the problems you encountered?

Erik

From ekmett at gmail.com  Mon Jun 16 14:20:18 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 16 Jun 2014 10:20:18 -0400
Subject: Polymorphism in the Prelude
In-Reply-To: <CAPeieQH9a96wKV8mSB4ynD8OOS-jamNpqgSH7OrSaS7F3vsr3Q@mail.gmail.com>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <F46D6660-730B-47A1-9A91-7495C2A6930E@gmail.com>
 <CAPeieQH9a96wKV8mSB4ynD8OOS-jamNpqgSH7OrSaS7F3vsr3Q@mail.gmail.com>
Message-ID: <F3F44926-506C-46B3-BFC6-9E1DED85D79A@gmail.com>

* The big issue I have is the one I already mentioned -- the fact that the price is born by every user going forward. You spend a line of boiler plate setting up NoImplicitPrelude, and an import of Prelude.Whatever so all users pay for it forever. The current plan on the other hand has 0 tax for users on an ongoing basis and most of the boilerplate users do have melts away.

* A far less compelling, but tedious technical issue is if you import a bunch of these Foo.Poly modules, on windows (with certain build tools?) with enough modules with the same final name .Poly you can run into linker problems, we've actually had users run into this with lens.

-Edward

> On Jun 16, 2014, at 10:09 AM, Erik Hesselink <hesselink at gmail.com> wrote:
> 
>> On Mon, Jun 16, 2014 at 4:07 PM, Edward Kmett <ekmett at gmail.com> wrote:
>> Having attempted to program with NoImplicitPrelude "in anger", I personally
>> think this fix is worse than the disease and I'm personally -1.
> 
> Out of curiosity, what were the problems you encountered?
> 
> Erik

From ekmett at gmail.com  Mon Jun 16 14:30:45 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 16 Jun 2014 10:30:45 -0400
Subject: Polymorphism in the Prelude
In-Reply-To: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
Message-ID: <721C24B1-AA28-46B0-AF8B-476B1F62FA31@gmail.com>

Note: we already have several of these alternate Preludes out there, which have gained little traction, largely because many users aren't willing to incur another package dependency for convenience.

prelude-prime
classy-prelude
fugue

-Edward

> On Jun 16, 2014, at 9:46 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> 
>  I would wager that if these Poly modules were out in the wild today, we might all grumble at them, but I don't know if there would be a movement to change the Prelude.
> 
> Richard
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

From greg at gregweber.info  Mon Jun 16 16:58:52 2014
From: greg at gregweber.info (Greg Weber)
Date: Mon, 16 Jun 2014 09:58:52 -0700
Subject: Polymorphism in the Prelude
In-Reply-To: <721C24B1-AA28-46B0-AF8B-476B1F62FA31@gmail.com>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <721C24B1-AA28-46B0-AF8B-476B1F62FA31@gmail.com>
Message-ID: <CAKRanNA34HtwPRKM9EYyDStuv5mEztVbTZdq4qdf22tmEwu2WA@mail.gmail.com>

How do you know if alternate prelude are gaining traction? Libraries
authors are always going to hesitate to include another package, but they
are really for application developers. Are you using download statistics?


On Mon, Jun 16, 2014 at 7:30 AM, Edward Kmett <ekmett at gmail.com> wrote:

> Note: we already have several of these alternate Preludes out there, which
> have gained little traction, largely because many users aren't willing to
> incur another package dependency for convenience.
>
> prelude-prime
> classy-prelude
> fugue
>
> -Edward
>
> > On Jun 16, 2014, at 9:46 AM, Richard Eisenberg <eir at cis.upenn.edu>
> wrote:
> >
> >  I would wager that if these Poly modules were out in the wild today, we
> might all grumble at them, but I don't know if there would be a movement to
> change the Prelude.
> >
> > Richard
> > _______________________________________________
> > 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/20140616/b522e7fc/attachment-0001.html>

From ekmett at gmail.com  Mon Jun 16 17:33:11 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 16 Jun 2014 13:33:11 -0400
Subject: Polymorphism in the Prelude
In-Reply-To: <CAKRanNA34HtwPRKM9EYyDStuv5mEztVbTZdq4qdf22tmEwu2WA@mail.gmail.com>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <721C24B1-AA28-46B0-AF8B-476B1F62FA31@gmail.com>
 <CAKRanNA34HtwPRKM9EYyDStuv5mEztVbTZdq4qdf22tmEwu2WA@mail.gmail.com>
Message-ID: <CAJumaK8iQmeZ8qUc=DMnhMuhnEJgXq6PS=a2JaDWdQym9QVD+w@mail.gmail.com>

Based on raw download stats:

basic-prelude has probably received the most traction. It has ~8k downloads.

classy-prelude decays to ~4k downloads.

general-prelude ~180.

The other two I mentioned have had ~100 each.

By way of comparison something like, say, 'profunctors' has ~50k downloads.

That said, I spend an awful lot of time talking to people at conventions
and hackathons, and my response was mostly anecdotal based on responses
I've received as I've asked around to find out what people want in the
Prelude going forward.

-Edward


On Mon, Jun 16, 2014 at 12:58 PM, Greg Weber <greg at gregweber.info> wrote:

> How do you know if alternate prelude are gaining traction? Libraries
> authors are always going to hesitate to include another package, but they
> are really for application developers. Are you using download statistics?
>
>
> On Mon, Jun 16, 2014 at 7:30 AM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> Note: we already have several of these alternate Preludes out there,
>> which have gained little traction, largely because many users aren't
>> willing to incur another package dependency for convenience.
>>
>> prelude-prime
>> classy-prelude
>> fugue
>>
>> -Edward
>>
>> > On Jun 16, 2014, at 9:46 AM, Richard Eisenberg <eir at cis.upenn.edu>
>> wrote:
>> >
>> >  I would wager that if these Poly modules were out in the wild today,
>> we might all grumble at them, but I don't know if there would be a movement
>> to change the Prelude.
>> >
>> > Richard
>> > _______________________________________________
>> > 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/20140616/5e813b09/attachment.html>

From carter.schonwald at gmail.com  Mon Jun 16 18:16:20 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 16 Jun 2014 14:16:20 -0400
Subject: setlocale maintainership
In-Reply-To: <CAPeieQFDDuAGX32tpWagEd1TV7XEF9cz_PrO-=tysjyKOwfseA@mail.gmail.com>
References: <CAHfjoWm0By6PLqhiTUTT+rCqD4GYcWj6fFndEHU+6MFJMbKGuw@mail.gmail.com>
 <CAPeieQFDDuAGX32tpWagEd1TV7XEF9cz_PrO-=tysjyKOwfseA@mail.gmail.com>
Message-ID: <CAHYVw0y=r-TveEAxfzoMR+OxiQONyW-BeJiLpyNFGWqdcQUHHQ@mail.gmail.com>

agreed with Erik


On Mon, Jun 16, 2014 at 5:10 AM, Erik Hesselink <hesselink at gmail.com> wrote:

> If you upload your fix somewhere, I'm sure one of the hackage trustees
> can upload a fixed version for you. No need to go through the whole
> package takeover procedure.
>
> Erik
>
> On Sat, Jun 14, 2014 at 9:30 PM, adam vogt <vogt.adam at gmail.com> wrote:
> > Hello list.
> >
> > http://hackage.haskell.org/package/setlocale does not compile with
> > ghc-7.8 because it has a manually written typeable instance. I emailed
> > the author about this one month ago (May 15), but I have received no
> > reply.
> >
> > Let us wait until September 1 2014, and then I could be allowed to
> > upload a corrected version?
> >
> > Regards,
> > Adam
> > _______________________________________________
> > 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/20140616/709c4231/attachment.html>

From vogt.adam at gmail.com  Mon Jun 16 18:24:34 2014
From: vogt.adam at gmail.com (adam vogt)
Date: Mon, 16 Jun 2014 14:24:34 -0400
Subject: setlocale maintainership
In-Reply-To: <CAHYVw0y=r-TveEAxfzoMR+OxiQONyW-BeJiLpyNFGWqdcQUHHQ@mail.gmail.com>
References: <CAHfjoWm0By6PLqhiTUTT+rCqD4GYcWj6fFndEHU+6MFJMbKGuw@mail.gmail.com>
 <CAPeieQFDDuAGX32tpWagEd1TV7XEF9cz_PrO-=tysjyKOwfseA@mail.gmail.com>
 <CAHYVw0y=r-TveEAxfzoMR+OxiQONyW-BeJiLpyNFGWqdcQUHHQ@mail.gmail.com>
Message-ID: <CAHfjoWmsgj2bfVDXcGMrG=ceicwaNi5GDJBDA0LEPL5EJWy7=Q@mail.gmail.com>

Hello,

You can find a fixed version at
http://code.haskell.org/~aavogt/setlocale-0.0.4.tar.gz

Regards,
Adam

On Mon, Jun 16, 2014 at 2:16 PM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> agreed with Erik
>
>
> On Mon, Jun 16, 2014 at 5:10 AM, Erik Hesselink <hesselink at gmail.com> wrote:
>>
>> If you upload your fix somewhere, I'm sure one of the hackage trustees
>> can upload a fixed version for you. No need to go through the whole
>> package takeover procedure.
>>
>> Erik
>>
>> On Sat, Jun 14, 2014 at 9:30 PM, adam vogt <vogt.adam at gmail.com> wrote:
>> > Hello list.
>> >
>> > http://hackage.haskell.org/package/setlocale does not compile with
>> > ghc-7.8 because it has a manually written typeable instance. I emailed
>> > the author about this one month ago (May 15), but I have received no
>> > reply.
>> >
>> > Let us wait until September 1 2014, and then I could be allowed to
>> > upload a corrected version?
>> >
>> > Regards,
>> > Adam
>> > _______________________________________________
>> > 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 carter.schonwald at gmail.com  Mon Jun 16 18:39:06 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 16 Jun 2014 14:39:06 -0400
Subject: setlocale maintainership
In-Reply-To: <CAHfjoWmsgj2bfVDXcGMrG=ceicwaNi5GDJBDA0LEPL5EJWy7=Q@mail.gmail.com>
References: <CAHfjoWm0By6PLqhiTUTT+rCqD4GYcWj6fFndEHU+6MFJMbKGuw@mail.gmail.com>
 <CAPeieQFDDuAGX32tpWagEd1TV7XEF9cz_PrO-=tysjyKOwfseA@mail.gmail.com>
 <CAHYVw0y=r-TveEAxfzoMR+OxiQONyW-BeJiLpyNFGWqdcQUHHQ@mail.gmail.com>
 <CAHfjoWmsgj2bfVDXcGMrG=ceicwaNi5GDJBDA0LEPL5EJWy7=Q@mail.gmail.com>
Message-ID: <CAHYVw0wQsOsSuH5AtV045eRkh4VagoKH7HPO9BuBvQsvSn_Zrg@mail.gmail.com>

great, do you have a diff/patch of the fix on hand? (if a trustee uploads a
fix, they should probably eyeball what changes first :) )


On Mon, Jun 16, 2014 at 2:24 PM, adam vogt <vogt.adam at gmail.com> wrote:

> Hello,
>
> You can find a fixed version at
> http://code.haskell.org/~aavogt/setlocale-0.0.4.tar.gz
>
> Regards,
> Adam
>
> On Mon, Jun 16, 2014 at 2:16 PM, Carter Schonwald
> <carter.schonwald at gmail.com> wrote:
> > agreed with Erik
> >
> >
> > On Mon, Jun 16, 2014 at 5:10 AM, Erik Hesselink <hesselink at gmail.com>
> wrote:
> >>
> >> If you upload your fix somewhere, I'm sure one of the hackage trustees
> >> can upload a fixed version for you. No need to go through the whole
> >> package takeover procedure.
> >>
> >> Erik
> >>
> >> On Sat, Jun 14, 2014 at 9:30 PM, adam vogt <vogt.adam at gmail.com> wrote:
> >> > Hello list.
> >> >
> >> > http://hackage.haskell.org/package/setlocale does not compile with
> >> > ghc-7.8 because it has a manually written typeable instance. I emailed
> >> > the author about this one month ago (May 15), but I have received no
> >> > reply.
> >> >
> >> > Let us wait until September 1 2014, and then I could be allowed to
> >> > upload a corrected version?
> >> >
> >> > Regards,
> >> > Adam
> >> > _______________________________________________
> >> > 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/20140616/fbd38de5/attachment.html>

From vogt.adam at gmail.com  Mon Jun 16 19:13:59 2014
From: vogt.adam at gmail.com (adam vogt)
Date: Mon, 16 Jun 2014 15:13:59 -0400
Subject: setlocale maintainership
In-Reply-To: <CAHYVw0wQsOsSuH5AtV045eRkh4VagoKH7HPO9BuBvQsvSn_Zrg@mail.gmail.com>
References: <CAHfjoWm0By6PLqhiTUTT+rCqD4GYcWj6fFndEHU+6MFJMbKGuw@mail.gmail.com>
 <CAPeieQFDDuAGX32tpWagEd1TV7XEF9cz_PrO-=tysjyKOwfseA@mail.gmail.com>
 <CAHYVw0y=r-TveEAxfzoMR+OxiQONyW-BeJiLpyNFGWqdcQUHHQ@mail.gmail.com>
 <CAHfjoWmsgj2bfVDXcGMrG=ceicwaNi5GDJBDA0LEPL5EJWy7=Q@mail.gmail.com>
 <CAHYVw0wQsOsSuH5AtV045eRkh4VagoKH7HPO9BuBvQsvSn_Zrg@mail.gmail.com>
Message-ID: <CAHfjoWkrb7OwaTageH_Bq29KCi+emRDmdShMLuc=_V+o=uFBgw@mail.gmail.com>

Sure. Take a look at <http://code.haskell.org/~aavogt/setlocale.diff>.

On Mon, Jun 16, 2014 at 2:39 PM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> great, do you have a diff/patch of the fix on hand? (if a trustee uploads a
> fix, they should probably eyeball what changes first :) )
>
>
> On Mon, Jun 16, 2014 at 2:24 PM, adam vogt <vogt.adam at gmail.com> wrote:
>>
>> Hello,
>>
>> You can find a fixed version at
>> http://code.haskell.org/~aavogt/setlocale-0.0.4.tar.gz
>>
>> Regards,
>> Adam
>>
>> On Mon, Jun 16, 2014 at 2:16 PM, Carter Schonwald
>> <carter.schonwald at gmail.com> wrote:
>> > agreed with Erik
>> >
>> >
>> > On Mon, Jun 16, 2014 at 5:10 AM, Erik Hesselink <hesselink at gmail.com>
>> > wrote:
>> >>
>> >> If you upload your fix somewhere, I'm sure one of the hackage trustees
>> >> can upload a fixed version for you. No need to go through the whole
>> >> package takeover procedure.
>> >>
>> >> Erik
>> >>
>> >> On Sat, Jun 14, 2014 at 9:30 PM, adam vogt <vogt.adam at gmail.com> wrote:
>> >> > Hello list.
>> >> >
>> >> > http://hackage.haskell.org/package/setlocale does not compile with
>> >> > ghc-7.8 because it has a manually written typeable instance. I
>> >> > emailed
>> >> > the author about this one month ago (May 15), but I have received no
>> >> > reply.
>> >> >
>> >> > Let us wait until September 1 2014, and then I could be allowed to
>> >> > upload a corrected version?
>> >> >
>> >> > Regards,
>> >> > Adam
>> >> > _______________________________________________
>> >> > 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 greg at gregweber.info  Tue Jun 17 07:59:08 2014
From: greg at gregweber.info (Greg Weber)
Date: Tue, 17 Jun 2014 00:59:08 -0700
Subject: Polymorphism in the Prelude
In-Reply-To: <CAJumaK8iQmeZ8qUc=DMnhMuhnEJgXq6PS=a2JaDWdQym9QVD+w@mail.gmail.com>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <721C24B1-AA28-46B0-AF8B-476B1F62FA31@gmail.com>
 <CAKRanNA34HtwPRKM9EYyDStuv5mEztVbTZdq4qdf22tmEwu2WA@mail.gmail.com>
 <CAJumaK8iQmeZ8qUc=DMnhMuhnEJgXq6PS=a2JaDWdQym9QVD+w@mail.gmail.com>
Message-ID: <CAKRanNCM5bO=-TN-ziZo6pCxF2GJ=RAMebZMohZxhkg5Bn6hzA@mail.gmail.com>

On Mon, Jun 16, 2014 at 10:33 AM, Edward Kmett <ekmett at gmail.com> wrote:

> Based on raw download stats:
>
> basic-prelude has probably received the most traction. It has ~8k
> downloads.
>
> classy-prelude decays to ~4k downloads.
>
> general-prelude ~180.
>
> The other two I mentioned have had ~100 each.
>
> By way of comparison something like, say, 'profunctors' has ~50k downloads.
>

That is interesting, thank you for sharing! Are you using direct downlaods
of profunctor? because profunctor is designed to be a library dependency
(lens depends on it as do 20+ other packages), whereas with classy-prelude
users are advised to not use it as a library dependency and only use it for
their applications. There is only really one library with usage that depend
on classy-prelude, classy-prelude-conduit, and only classy-prelude-yesod
depends on that, and nothing depends on that, they are all designed for
application writers, not as library dependencies.

Does it makes sense to make a direct comparison of total downloads for
these 2 different use cases?


> That said, I spend an awful lot of time talking to people at conventions
> and hackathons, and my response was mostly anecdotal based on responses
> I've received as I've asked around to find out what people want in the
> Prelude going forward.
>
> -Edward
>
>
> On Mon, Jun 16, 2014 at 12:58 PM, Greg Weber <greg at gregweber.info> wrote:
>
>> How do you know if alternate prelude are gaining traction? Libraries
>> authors are always going to hesitate to include another package, but they
>> are really for application developers. Are you using download statistics?
>>
>>
>> On Mon, Jun 16, 2014 at 7:30 AM, Edward Kmett <ekmett at gmail.com> wrote:
>>
>>> Note: we already have several of these alternate Preludes out there,
>>> which have gained little traction, largely because many users aren't
>>> willing to incur another package dependency for convenience.
>>>
>>> prelude-prime
>>> classy-prelude
>>> fugue
>>>
>>> -Edward
>>>
>>> > On Jun 16, 2014, at 9:46 AM, Richard Eisenberg <eir at cis.upenn.edu>
>>> wrote:
>>> >
>>> >  I would wager that if these Poly modules were out in the wild today,
>>> we might all grumble at them, but I don't know if there would be a movement
>>> to change the Prelude.
>>> >
>>> > Richard
>>> > _______________________________________________
>>> > 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/20140617/f5eecdd0/attachment-0001.html>

From ekmett at gmail.com  Tue Jun 17 11:58:00 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 17 Jun 2014 07:58:00 -0400
Subject: Polymorphism in the Prelude
In-Reply-To: <CAKRanNCM5bO=-TN-ziZo6pCxF2GJ=RAMebZMohZxhkg5Bn6hzA@mail.gmail.com>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <721C24B1-AA28-46B0-AF8B-476B1F62FA31@gmail.com>
 <CAKRanNA34HtwPRKM9EYyDStuv5mEztVbTZdq4qdf22tmEwu2WA@mail.gmail.com>
 <CAJumaK8iQmeZ8qUc=DMnhMuhnEJgXq6PS=a2JaDWdQym9QVD+w@mail.gmail.com>
 <CAKRanNCM5bO=-TN-ziZo6pCxF2GJ=RAMebZMohZxhkg5Bn6hzA@mail.gmail.com>
Message-ID: <CAJumaK-5yxcVNMY79AhumQF5vckYrQuLCPgDcw4z1LAkJvDc8g@mail.gmail.com>

On Tue, Jun 17, 2014 at 3:59 AM, Greg Weber <greg at gregweber.info> wrote:

>
> On Mon, Jun 16, 2014 at 10:33 AM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> Based on raw download stats:
>>
>> basic-prelude has probably received the most traction. It has ~8k
>> downloads.
>>
>> classy-prelude decays to ~4k downloads.
>>
>> general-prelude ~180.
>>
>> The other two I mentioned have had ~100 each.
>>
>> By way of comparison something like, say, 'profunctors' has ~50k
>> downloads.
>>
>
> That is interesting, thank you for sharing! Are you using direct downlaods
> of profunctor? because profunctor is designed to be a library dependency
> (lens depends on it as do 20+ other packages), whereas with classy-prelude
> users are advised to not use it as a library dependency and only use it for
> their applications. There is only really one library with usage that depend
> on classy-prelude, classy-prelude-conduit, and only classy-prelude-yesod
> depends on that, and nothing depends on that, they are all designed for
> application writers, not as library dependencies.
>
> Does it makes sense to make a direct comparison of total downloads for
> these 2 different use cases?
>

It isn't a perfect comparison, but if we're looking at adoption, adoption
is adoption regardless of whether the library is sold for a very limited
application-oriented usecase. Haskell is the sum of library authors and
application authors (and students who will probably never write a library).
All we're doing is bringing the non-controversial parts of base that people
already use every day into the standard Prelude, where it can benefit each
group.

A proposal that says "well, application authors can just use X" ignores the
large mass of library authors out there when it just doesn't have to. we
have a straightforward path to monotonic improvement over the status quo,
lets take it.

Again, my reaction is mostly measured by the fact that I've actively asked
folks in person about this as I travel around to user groups and ask "what
is it that the core library committee could do that would make Haskell
better for you" and have received a lot of feedback, it isn't just driven
by those numbers.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140617/1bdbdc49/attachment.html>

From eir at cis.upenn.edu  Tue Jun 17 14:24:16 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 17 Jun 2014 10:24:16 -0400
Subject: Polymorphism in the Prelude
In-Reply-To: <CAJumaK-5yxcVNMY79AhumQF5vckYrQuLCPgDcw4z1LAkJvDc8g@mail.gmail.com>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <721C24B1-AA28-46B0-AF8B-476B1F62FA31@gmail.com>
 <CAKRanNA34HtwPRKM9EYyDStuv5mEztVbTZdq4qdf22tmEwu2WA@mail.gmail.com>
 <CAJumaK8iQmeZ8qUc=DMnhMuhnEJgXq6PS=a2JaDWdQym9QVD+w@mail.gmail.com>
 <CAKRanNCM5bO=-TN-ziZo6pCxF2GJ=RAMebZMohZxhkg5Bn6hzA@mail.gmail.com>
 <CAJumaK-5yxcVNMY79AhumQF5vckYrQuLCPgDcw4z1LAkJvDc8g@mail.gmail.com>
Message-ID: <F9E619F1-5013-466F-A449-2AE3AAEACB80@cis.upenn.edu>

Forgive a perhaps newbie question, but: How do I use the haskell2010 package? An earlier recommendation in this thread for novices is to "use haskell2010" to reduce the upcoming extra polymorphism in the prelude. How is this done, in practice? My guess is that we have to use several command-line flags to hide the `base` package and make the `haskell2010` package visible. Some experimenting got `ghc -package haskell2010 -hide-package base Foo.hs` to work. These flags can't even be embedded in an OPTIONS_GHC pragma.

In any case, it's a bit of a hoop for novices to jump through, especially if they aren't being guided by a teacher.

I tend to agree that taxing the large quantity of experienced users for the benefit of novices is wrong-headed. But, I still think we need a nice, simple story to get new folks off the ground. Haskell prides itself on its beauty, and requiring several obscure and (at first) inscrutable command line flags to get decent error messages for a novice is not beautiful.

Richard

On Jun 17, 2014, at 7:58 AM, Edward Kmett <ekmett at gmail.com> wrote:

> On Tue, Jun 17, 2014 at 3:59 AM, Greg Weber <greg at gregweber.info> wrote:
> 
> On Mon, Jun 16, 2014 at 10:33 AM, Edward Kmett <ekmett at gmail.com> wrote:
> Based on raw download stats:
> 
> basic-prelude has probably received the most traction. It has ~8k downloads.
> 
> classy-prelude decays to ~4k downloads.
> 
> general-prelude ~180.
> 
> The other two I mentioned have had ~100 each.
> 
> By way of comparison something like, say, 'profunctors' has ~50k downloads.
> 
> That is interesting, thank you for sharing! Are you using direct downlaods of profunctor? because profunctor is designed to be a library dependency (lens depends on it as do 20+ other packages), whereas with classy-prelude users are advised to not use it as a library dependency and only use it for their applications. There is only really one library with usage that depend on classy-prelude, classy-prelude-conduit, and only classy-prelude-yesod depends on that, and nothing depends on that, they are all designed for application writers, not as library dependencies.
> 
> Does it makes sense to make a direct comparison of total downloads for these 2 different use cases?
> 
> It isn't a perfect comparison, but if we're looking at adoption, adoption is adoption regardless of whether the library is sold for a very limited application-oriented usecase. Haskell is the sum of library authors and application authors (and students who will probably never write a library). All we're doing is bringing the non-controversial parts of base that people already use every day into the standard Prelude, where it can benefit each group. 
> 
> A proposal that says "well, application authors can just use X" ignores the large mass of library authors out there when it just doesn't have to. we have a straightforward path to monotonic improvement over the status quo, lets take it.
> 
> Again, my reaction is mostly measured by the fact that I've actively asked folks in person about this as I travel around to user groups and ask "what is it that the core library committee could do that would make Haskell better for you" and have received a lot of feedback, it isn't just driven by those numbers.
> 
> -Edward

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140617/910655bd/attachment.html>

From ekmett at gmail.com  Tue Jun 17 14:29:13 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 17 Jun 2014 10:29:13 -0400
Subject: Polymorphism in the Prelude
In-Reply-To: <F9E619F1-5013-466F-A449-2AE3AAEACB80@cis.upenn.edu>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <721C24B1-AA28-46B0-AF8B-476B1F62FA31@gmail.com>
 <CAKRanNA34HtwPRKM9EYyDStuv5mEztVbTZdq4qdf22tmEwu2WA@mail.gmail.com>
 <CAJumaK8iQmeZ8qUc=DMnhMuhnEJgXq6PS=a2JaDWdQym9QVD+w@mail.gmail.com>
 <CAKRanNCM5bO=-TN-ziZo6pCxF2GJ=RAMebZMohZxhkg5Bn6hzA@mail.gmail.com>
 <CAJumaK-5yxcVNMY79AhumQF5vckYrQuLCPgDcw4z1LAkJvDc8g@mail.gmail.com>
 <F9E619F1-5013-466F-A449-2AE3AAEACB80@cis.upenn.edu>
Message-ID: <CAJumaK_vUOrkC20Zitx1yRXTkFc04MOt+SrfF3ckEDpGKq6ANg@mail.gmail.com>

ghc-pkg hide base
ghc-pkg expose haskell2010

Now when you run ghc from the command line or start ghci you'll get
haskell2010 by default.

Vice versa to switch back.

-Edward


On Tue, Jun 17, 2014 at 10:24 AM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

> Forgive a perhaps newbie question, but: How do I use the haskell2010
> package? An earlier recommendation in this thread for novices is to "use
> haskell2010" to reduce the upcoming extra polymorphism in the prelude. How
> is this done, in practice? My guess is that we have to use several
> command-line flags to hide the `base` package and make the `haskell2010`
> package visible. Some experimenting got `ghc -package haskell2010
> -hide-package base Foo.hs` to work. These flags can't even be embedded in
> an OPTIONS_GHC pragma.
>
> In any case, it's a bit of a hoop for novices to jump through, especially
> if they aren't being guided by a teacher.
>
> I tend to agree that taxing the large quantity of experienced users for
> the benefit of novices is wrong-headed. But, I still think we need a nice,
> simple story to get new folks off the ground. Haskell prides itself on its
> beauty, and requiring several obscure and (at first) inscrutable command
> line flags to get decent error messages for a novice is not beautiful.
>
> Richard
>
> On Jun 17, 2014, at 7:58 AM, Edward Kmett <ekmett at gmail.com> wrote:
>
> On Tue, Jun 17, 2014 at 3:59 AM, Greg Weber <greg at gregweber.info> wrote:
>
>>
>> On Mon, Jun 16, 2014 at 10:33 AM, Edward Kmett <ekmett at gmail.com> wrote:
>>
>>> Based on raw download stats:
>>>
>>> basic-prelude has probably received the most traction. It has ~8k
>>> downloads.
>>>
>>> classy-prelude decays to ~4k downloads.
>>>
>>> general-prelude ~180.
>>>
>>> The other two I mentioned have had ~100 each.
>>>
>>> By way of comparison something like, say, 'profunctors' has ~50k
>>> downloads.
>>>
>>
>> That is interesting, thank you for sharing! Are you using direct
>> downlaods of profunctor? because profunctor is designed to be a library
>> dependency (lens depends on it as do 20+ other packages), whereas with
>> classy-prelude users are advised to not use it as a library dependency and
>> only use it for their applications. There is only really one library with
>> usage that depend on classy-prelude, classy-prelude-conduit, and only
>> classy-prelude-yesod depends on that, and nothing depends on that, they are
>> all designed for application writers, not as library dependencies.
>>
>> Does it makes sense to make a direct comparison of total downloads for
>> these 2 different use cases?
>>
>
> It isn't a perfect comparison, but if we're looking at adoption, adoption
> is adoption regardless of whether the library is sold for a very limited
> application-oriented usecase. Haskell is the sum of library authors and
> application authors (and students who will probably never write a library).
> All we're doing is bringing the non-controversial parts of base that people
> already use every day into the standard Prelude, where it can benefit each
> group.
>
> A proposal that says "well, application authors can just use X" ignores
> the large mass of library authors out there when it just doesn't have to.
> we have a straightforward path to monotonic improvement over the status
> quo, lets take it.
>
> Again, my reaction is mostly measured by the fact that I've actively asked
> folks in person about this as I travel around to user groups and ask "what
> is it that the core library committee could do that would make Haskell
> better for you" and have received a lot of feedback, it isn't just driven
> by those numbers.
>
> -Edward
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140617/046b006e/attachment.html>

From sol at typeful.net  Wed Jun 18 04:45:50 2014
From: sol at typeful.net (Simon Hengel)
Date: Wed, 18 Jun 2014 12:45:50 +0800
Subject: Use -Werror by default on travis-ci
Message-ID: <20140618044550.GA24895@x200>

Hi,
I created a PR to use -Werror by default on travis-ci.  If you think
this is a good idea, see any issue or have any other input, get involved
in the discussion on GitHub [1].

Cheers,
Simon

[1] https://github.com/travis-ci/travis-build/pull/250

From hvr at gnu.org  Wed Jun 18 08:05:32 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 18 Jun 2014 10:05:32 +0200
Subject: Polymorphism in the Prelude
In-Reply-To: <F9E619F1-5013-466F-A449-2AE3AAEACB80@cis.upenn.edu> (Richard
 Eisenberg's message of "Tue, 17 Jun 2014 10:24:16 -0400")
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <721C24B1-AA28-46B0-AF8B-476B1F62FA31@gmail.com>
 <CAKRanNA34HtwPRKM9EYyDStuv5mEztVbTZdq4qdf22tmEwu2WA@mail.gmail.com>
 <CAJumaK8iQmeZ8qUc=DMnhMuhnEJgXq6PS=a2JaDWdQym9QVD+w@mail.gmail.com>
 <CAKRanNCM5bO=-TN-ziZo6pCxF2GJ=RAMebZMohZxhkg5Bn6hzA@mail.gmail.com>
 <CAJumaK-5yxcVNMY79AhumQF5vckYrQuLCPgDcw4z1LAkJvDc8g@mail.gmail.com>
 <F9E619F1-5013-466F-A449-2AE3AAEACB80@cis.upenn.edu>
Message-ID: <87wqcezlpv.fsf@gnu.org>

On 2014-06-17 at 16:24:16 +0200, Richard Eisenberg wrote:

[...]

> In any case, it's a bit of a hoop for novices to jump through,
> especially if they aren't being guided by a teacher.
>
> I tend to agree that taxing the large quantity of experienced users
> for the benefit of novices is wrong-headed. But, I still think we need
> a nice, simple story to get new folks off the ground. Haskell prides
> itself on its beauty, and requiring several obscure and (at first)
> inscrutable command line flags to get decent error messages for a
> novice is not beautiful.

Fwiw, something related was brought up by John Meacham at

  http://www.haskell.org/pipermail/glasgow-haskell-users/2014-June/025047.html


Or maybe one could do something similiar to what was done with
/usr/bin/c99, i.e. provide a '/usr/bin/hc2010' (or ghc2010) wrapper for
ghc, that would by default force Haskell2010 mode and pull the
'haskell2010' pkg into scope while hiding 'base'

From gale at sefer.org  Wed Jun 18 10:09:56 2014
From: gale at sefer.org (Yitzchak Gale)
Date: Wed, 18 Jun 2014 13:09:56 +0300
Subject: Polymorphism in the Prelude
In-Reply-To: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
Message-ID: <CAOrUaLZ_UcsVDG042Dh4bbenhUdxdw9N_S9P-T6sEQfAzLvD1A@mail.gmail.com>

Richard Eisenberg wrote:
> Having lots of polymorphism in the Prelude is great, but for two problems:
>   1) It's very confusing to novices.
>   2) In the case of using Control.Category definitions: kind-polymorphism is
> not portable
>
> I wish to ignore (2) for now, as it's a smaller concern given that it
> affects only a portion of the proposed changes.

In my opinion, Richard missed the most important reason:

3) Gratuitous polymorphism makes code much less readable
   and much costlier to maintain, usually for almost no gain.

One of the biggest strengths of Haskell is semantic clarity.
You can often look at a Haskell expression, recognize its type,
and then immediately understand exactly what the expression
is doing. That is immensely valuable, not only for writing code,
but for maintaining and refactoring it over the lifetime of an
application, often by people other than the original author.

Adding polymorphism to code is semantically lossy.
One of the biggest disasters I have ever suffered in software
engineering was when someone went through an entire fairly
large code base and changed it to use a more polymorphic
Prelude, then left the company. Adding the polymorphism was
mostly mechanical, but undoing it required hours upon hours of
puzzling out the meaning of the code, line by line.

And do not relegate Richard's point #1 to CS 101 at university.
Most software maintenance is done by the developers with
the least Haskell experience. And that is the largest cost
of software over time.

Polymorphism can be very powerful, of course, and there are
a lot of great tools and techniques that use it in various ways.
But why force some particular polymorphic generalization
down everyone's throat when the cost of enabling it if you
want it is essentially zero?

If you use a different Prelude in a large project, or in many small
projects, take a few minutes to set up your dev environment
accordingly.

As a case in point: Yesod uses many GHC extensions universally,
among them NoImplicitPrelude. These are all listed in the
automatically-generated default cabal file; they never need to be
typed, and never appear in any source files. There is a single extra
line in each file which sets up the whole environment:

import Import

You can bind that to an editor key if you'd like. You can write
scripts. There are packages on Haskell which automate a lot
of things. Need I go on with these trivialities?

A lot of thought went into making it easy to use GHC extensions.
Advanced and experienced developers who need them should
have no trouble at all using them, including alternative Preludes.

That is not to say that no changes should be made to the Prelude.
Now that people are using a number of different alternative Preludes
more regularly, I would hope we can use that experience to
make much-needed improvements to the default Prelude.
But the principal design considerations should be simplicity,
ease of use even for beginners, and semantic clarity of code
using it.

Thanks,
Yitz

From jake.mcarthur at gmail.com  Wed Jun 18 12:49:00 2014
From: jake.mcarthur at gmail.com (Jake McArthur)
Date: Wed, 18 Jun 2014 08:49:00 -0400
Subject: Polymorphism in the Prelude
In-Reply-To: <CAOrUaLZ_UcsVDG042Dh4bbenhUdxdw9N_S9P-T6sEQfAzLvD1A@mail.gmail.com>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <CAOrUaLZ_UcsVDG042Dh4bbenhUdxdw9N_S9P-T6sEQfAzLvD1A@mail.gmail.com>
Message-ID: <CACN--9CbCvU0oB2k8fw+wuXhy_Q1dShnJSKve9BoVapvpf0kBg@mail.gmail.com>

I find this argument against polymorphism baffling. Do I really have to
state the benefits of parametricity here? Probably not. Most likely, there
is some specific style of polymorphism in mind going unsaid here, such as
ListLike type classes that have tons of methods and don't really have any
meaningful laws. Is this the case, or do you *really* mean to argue that
polymorphism makes code confusing? If the latter, would you mind explaining
why?

Please forgive me for any weird autocorrections, typos, or bad grammar.
This was written on my phone, which is hard to write and proofread on.
Richard Eisenberg wrote:
> Having lots of polymorphism in the Prelude is great, but for two problems:
>   1) It's very confusing to novices.
>   2) In the case of using Control.Category definitions: kind-polymorphism
is
> not portable
>
> I wish to ignore (2) for now, as it's a smaller concern given that it
> affects only a portion of the proposed changes.

In my opinion, Richard missed the most important reason:

3) Gratuitous polymorphism makes code much less readable
   and much costlier to maintain, usually for almost no gain.

One of the biggest strengths of Haskell is semantic clarity.
You can often look at a Haskell expression, recognize its type,
and then immediately understand exactly what the expression
is doing. That is immensely valuable, not only for writing code,
but for maintaining and refactoring it over the lifetime of an
application, often by people other than the original author.

Adding polymorphism to code is semantically lossy.
One of the biggest disasters I have ever suffered in software
engineering was when someone went through an entire fairly
large code base and changed it to use a more polymorphic
Prelude, then left the company. Adding the polymorphism was
mostly mechanical, but undoing it required hours upon hours of
puzzling out the meaning of the code, line by line.

And do not relegate Richard's point #1 to CS 101 at university.
Most software maintenance is done by the developers with
the least Haskell experience. And that is the largest cost
of software over time.

Polymorphism can be very powerful, of course, and there are
a lot of great tools and techniques that use it in various ways.
But why force some particular polymorphic generalization
down everyone's throat when the cost of enabling it if you
want it is essentially zero?

If you use a different Prelude in a large project, or in many small
projects, take a few minutes to set up your dev environment
accordingly.

As a case in point: Yesod uses many GHC extensions universally,
among them NoImplicitPrelude. These are all listed in the
automatically-generated default cabal file; they never need to be
typed, and never appear in any source files. There is a single extra
line in each file which sets up the whole environment:

import Import

You can bind that to an editor key if you'd like. You can write
scripts. There are packages on Haskell which automate a lot
of things. Need I go on with these trivialities?

A lot of thought went into making it easy to use GHC extensions.
Advanced and experienced developers who need them should
have no trouble at all using them, including alternative Preludes.

That is not to say that no changes should be made to the Prelude.
Now that people are using a number of different alternative Preludes
more regularly, I would hope we can use that experience to
make much-needed improvements to the default Prelude.
But the principal design considerations should be simplicity,
ease of use even for beginners, and semantic clarity of code
using it.

Thanks,
Yitz
_______________________________________________
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/20140618/ad5930b7/attachment.html>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Wed Jun 18 13:06:29 2014
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 18 Jun 2014 14:06:29 +0100
Subject: Polymorphism in the Prelude
In-Reply-To: <CACN--9CbCvU0oB2k8fw+wuXhy_Q1dShnJSKve9BoVapvpf0kBg@mail.gmail.com>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <CAOrUaLZ_UcsVDG042Dh4bbenhUdxdw9N_S9P-T6sEQfAzLvD1A@mail.gmail.com>
 <CACN--9CbCvU0oB2k8fw+wuXhy_Q1dShnJSKve9BoVapvpf0kBg@mail.gmail.com>
Message-ID: <20140618130629.GL6633@henry>

On Wed, Jun 18, 2014 at 08:49:00AM -0400, Jake McArthur wrote:
> I find this argument against polymorphism baffling. Do I really have to
> state the benefits of parametricity here? Probably not. Most likely, there
> is some specific style of polymorphism in mind going unsaid here, such as
> ListLike type classes that have tons of methods and don't really have any
> meaningful laws. Is this the case, or do you *really* mean to argue that
> polymorphism makes code confusing? If the latter, would you mind explaining
> why?

Looking back through this thread it seems to me that it is typeclass
polymorphism that is being discussed, not parametric polymorphism.

Tom

From hesselink at gmail.com  Wed Jun 18 13:06:44 2014
From: hesselink at gmail.com (Erik Hesselink)
Date: Wed, 18 Jun 2014 15:06:44 +0200
Subject: Polymorphism in the Prelude
In-Reply-To: <CACN--9CbCvU0oB2k8fw+wuXhy_Q1dShnJSKve9BoVapvpf0kBg@mail.gmail.com>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <CAOrUaLZ_UcsVDG042Dh4bbenhUdxdw9N_S9P-T6sEQfAzLvD1A@mail.gmail.com>
 <CACN--9CbCvU0oB2k8fw+wuXhy_Q1dShnJSKve9BoVapvpf0kBg@mail.gmail.com>
Message-ID: <CAPeieQEbEHtpJoQsCqxYE-BwzjyqfwSTY=Z4E+ZOaxNqK8ViSQ@mail.gmail.com>

I think it's a pretty clear tradeoff: if you write 'map f xs' you know
that 'xs' must be a list. If you write 'fmap f xs', you know only that
'xs' is a Functor. So you gain flexibility in when you can use 'fmap',
but you lose the local information you get from the more constrained
type of 'map'. The same argument applies when generalizing 'mapM' and
friends. I'm still in favor of generalizing the Prelude functions to
their Foldable/Traversable variants, but the downside is also clear to
me.

This seems like a perfect problem for an IDE to solve, by the way.

Erik

On Wed, Jun 18, 2014 at 2:49 PM, Jake McArthur <jake.mcarthur at gmail.com> wrote:
> I find this argument against polymorphism baffling. Do I really have to
> state the benefits of parametricity here? Probably not. Most likely, there
> is some specific style of polymorphism in mind going unsaid here, such as
> ListLike type classes that have tons of methods and don't really have any
> meaningful laws. Is this the case, or do you *really* mean to argue that
> polymorphism makes code confusing? If the latter, would you mind explaining
> why?
>
> Please forgive me for any weird autocorrections, typos, or bad grammar. This
> was written on my phone, which is hard to write and proofread on.
>
> Richard Eisenberg wrote:
>> Having lots of polymorphism in the Prelude is great, but for two problems:
>>   1) It's very confusing to novices.
>>   2) In the case of using Control.Category definitions: kind-polymorphism
>> is
>> not portable
>>
>> I wish to ignore (2) for now, as it's a smaller concern given that it
>> affects only a portion of the proposed changes.
>
> In my opinion, Richard missed the most important reason:
>
> 3) Gratuitous polymorphism makes code much less readable
>    and much costlier to maintain, usually for almost no gain.
>
> One of the biggest strengths of Haskell is semantic clarity.
> You can often look at a Haskell expression, recognize its type,
> and then immediately understand exactly what the expression
> is doing. That is immensely valuable, not only for writing code,
> but for maintaining and refactoring it over the lifetime of an
> application, often by people other than the original author.
>
> Adding polymorphism to code is semantically lossy.
> One of the biggest disasters I have ever suffered in software
> engineering was when someone went through an entire fairly
> large code base and changed it to use a more polymorphic
> Prelude, then left the company. Adding the polymorphism was
> mostly mechanical, but undoing it required hours upon hours of
> puzzling out the meaning of the code, line by line.
>
> And do not relegate Richard's point #1 to CS 101 at university.
> Most software maintenance is done by the developers with
> the least Haskell experience. And that is the largest cost
> of software over time.
>
> Polymorphism can be very powerful, of course, and there are
> a lot of great tools and techniques that use it in various ways.
> But why force some particular polymorphic generalization
> down everyone's throat when the cost of enabling it if you
> want it is essentially zero?
>
> If you use a different Prelude in a large project, or in many small
> projects, take a few minutes to set up your dev environment
> accordingly.
>
> As a case in point: Yesod uses many GHC extensions universally,
> among them NoImplicitPrelude. These are all listed in the
> automatically-generated default cabal file; they never need to be
> typed, and never appear in any source files. There is a single extra
> line in each file which sets up the whole environment:
>
> import Import
>
> You can bind that to an editor key if you'd like. You can write
> scripts. There are packages on Haskell which automate a lot
> of things. Need I go on with these trivialities?
>
> A lot of thought went into making it easy to use GHC extensions.
> Advanced and experienced developers who need them should
> have no trouble at all using them, including alternative Preludes.
>
> That is not to say that no changes should be made to the Prelude.
> Now that people are using a number of different alternative Preludes
> more regularly, I would hope we can use that experience to
> make much-needed improvements to the default Prelude.
> But the principal design considerations should be simplicity,
> ease of use even for beginners, and semantic clarity of code
> using it.
>
> Thanks,
> Yitz
> _______________________________________________
> 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 davidleothomas at gmail.com  Wed Jun 18 16:00:03 2014
From: davidleothomas at gmail.com (David Thomas)
Date: Wed, 18 Jun 2014 09:00:03 -0700
Subject: Polymorphism in the Prelude
In-Reply-To: <CAPeieQEbEHtpJoQsCqxYE-BwzjyqfwSTY=Z4E+ZOaxNqK8ViSQ@mail.gmail.com>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <CAOrUaLZ_UcsVDG042Dh4bbenhUdxdw9N_S9P-T6sEQfAzLvD1A@mail.gmail.com>
 <CACN--9CbCvU0oB2k8fw+wuXhy_Q1dShnJSKve9BoVapvpf0kBg@mail.gmail.com>
 <CAPeieQEbEHtpJoQsCqxYE-BwzjyqfwSTY=Z4E+ZOaxNqK8ViSQ@mail.gmail.com>
Message-ID: <CAJUDvciuY8CxxsQADJfjZ8urmVErUeQihupsZ1w=kv0s04cgNQ@mail.gmail.com>

Of course, you can always add type annotations to be more specific
about your types.  And that actually might be clearer than having to
remember all the various names for all the various monomorphic
variants.  Or it might not.

On Wed, Jun 18, 2014 at 6:06 AM, Erik Hesselink <hesselink at gmail.com> wrote:
> I think it's a pretty clear tradeoff: if you write 'map f xs' you know
> that 'xs' must be a list. If you write 'fmap f xs', you know only that
> 'xs' is a Functor. So you gain flexibility in when you can use 'fmap',
> but you lose the local information you get from the more constrained
> type of 'map'. The same argument applies when generalizing 'mapM' and
> friends. I'm still in favor of generalizing the Prelude functions to
> their Foldable/Traversable variants, but the downside is also clear to
> me.
>
> This seems like a perfect problem for an IDE to solve, by the way.
>
> Erik
>
> On Wed, Jun 18, 2014 at 2:49 PM, Jake McArthur <jake.mcarthur at gmail.com> wrote:
>> I find this argument against polymorphism baffling. Do I really have to
>> state the benefits of parametricity here? Probably not. Most likely, there
>> is some specific style of polymorphism in mind going unsaid here, such as
>> ListLike type classes that have tons of methods and don't really have any
>> meaningful laws. Is this the case, or do you *really* mean to argue that
>> polymorphism makes code confusing? If the latter, would you mind explaining
>> why?
>>
>> Please forgive me for any weird autocorrections, typos, or bad grammar. This
>> was written on my phone, which is hard to write and proofread on.
>>
>> Richard Eisenberg wrote:
>>> Having lots of polymorphism in the Prelude is great, but for two problems:
>>>   1) It's very confusing to novices.
>>>   2) In the case of using Control.Category definitions: kind-polymorphism
>>> is
>>> not portable
>>>
>>> I wish to ignore (2) for now, as it's a smaller concern given that it
>>> affects only a portion of the proposed changes.
>>
>> In my opinion, Richard missed the most important reason:
>>
>> 3) Gratuitous polymorphism makes code much less readable
>>    and much costlier to maintain, usually for almost no gain.
>>
>> One of the biggest strengths of Haskell is semantic clarity.
>> You can often look at a Haskell expression, recognize its type,
>> and then immediately understand exactly what the expression
>> is doing. That is immensely valuable, not only for writing code,
>> but for maintaining and refactoring it over the lifetime of an
>> application, often by people other than the original author.
>>
>> Adding polymorphism to code is semantically lossy.
>> One of the biggest disasters I have ever suffered in software
>> engineering was when someone went through an entire fairly
>> large code base and changed it to use a more polymorphic
>> Prelude, then left the company. Adding the polymorphism was
>> mostly mechanical, but undoing it required hours upon hours of
>> puzzling out the meaning of the code, line by line.
>>
>> And do not relegate Richard's point #1 to CS 101 at university.
>> Most software maintenance is done by the developers with
>> the least Haskell experience. And that is the largest cost
>> of software over time.
>>
>> Polymorphism can be very powerful, of course, and there are
>> a lot of great tools and techniques that use it in various ways.
>> But why force some particular polymorphic generalization
>> down everyone's throat when the cost of enabling it if you
>> want it is essentially zero?
>>
>> If you use a different Prelude in a large project, or in many small
>> projects, take a few minutes to set up your dev environment
>> accordingly.
>>
>> As a case in point: Yesod uses many GHC extensions universally,
>> among them NoImplicitPrelude. These are all listed in the
>> automatically-generated default cabal file; they never need to be
>> typed, and never appear in any source files. There is a single extra
>> line in each file which sets up the whole environment:
>>
>> import Import
>>
>> You can bind that to an editor key if you'd like. You can write
>> scripts. There are packages on Haskell which automate a lot
>> of things. Need I go on with these trivialities?
>>
>> A lot of thought went into making it easy to use GHC extensions.
>> Advanced and experienced developers who need them should
>> have no trouble at all using them, including alternative Preludes.
>>
>> That is not to say that no changes should be made to the Prelude.
>> Now that people are using a number of different alternative Preludes
>> more regularly, I would hope we can use that experience to
>> make much-needed improvements to the default Prelude.
>> But the principal design considerations should be simplicity,
>> ease of use even for beginners, and semantic clarity of code
>> using it.
>>
>> Thanks,
>> Yitz
>> _______________________________________________
>> 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 carter.schonwald at gmail.com  Wed Jun 18 17:23:09 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 18 Jun 2014 13:23:09 -0400
Subject: Polymorphism in the Prelude
In-Reply-To: <CAJUDvciuY8CxxsQADJfjZ8urmVErUeQihupsZ1w=kv0s04cgNQ@mail.gmail.com>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <CAOrUaLZ_UcsVDG042Dh4bbenhUdxdw9N_S9P-T6sEQfAzLvD1A@mail.gmail.com>
 <CACN--9CbCvU0oB2k8fw+wuXhy_Q1dShnJSKve9BoVapvpf0kBg@mail.gmail.com>
 <CAPeieQEbEHtpJoQsCqxYE-BwzjyqfwSTY=Z4E+ZOaxNqK8ViSQ@mail.gmail.com>
 <CAJUDvciuY8CxxsQADJfjZ8urmVErUeQihupsZ1w=kv0s04cgNQ@mail.gmail.com>
Message-ID: <CAHYVw0wbSJk2zBarJwDO-mEqmzkjokzh-_U=Z7-NFJ+z2b4SKw@mail.gmail.com>

I think polymorphic code, subject to it "obeying laws/equations" is
generally a win. Fewer ways to have funny corner cases. :)


On Wed, Jun 18, 2014 at 12:00 PM, David Thomas <davidleothomas at gmail.com>
wrote:

> Of course, you can always add type annotations to be more specific
> about your types.  And that actually might be clearer than having to
> remember all the various names for all the various monomorphic
> variants.  Or it might not.
>
> On Wed, Jun 18, 2014 at 6:06 AM, Erik Hesselink <hesselink at gmail.com>
> wrote:
> > I think it's a pretty clear tradeoff: if you write 'map f xs' you know
> > that 'xs' must be a list. If you write 'fmap f xs', you know only that
> > 'xs' is a Functor. So you gain flexibility in when you can use 'fmap',
> > but you lose the local information you get from the more constrained
> > type of 'map'. The same argument applies when generalizing 'mapM' and
> > friends. I'm still in favor of generalizing the Prelude functions to
> > their Foldable/Traversable variants, but the downside is also clear to
> > me.
> >
> > This seems like a perfect problem for an IDE to solve, by the way.
> >
> > Erik
> >
> > On Wed, Jun 18, 2014 at 2:49 PM, Jake McArthur <jake.mcarthur at gmail.com>
> wrote:
> >> I find this argument against polymorphism baffling. Do I really have to
> >> state the benefits of parametricity here? Probably not. Most likely,
> there
> >> is some specific style of polymorphism in mind going unsaid here, such
> as
> >> ListLike type classes that have tons of methods and don't really have
> any
> >> meaningful laws. Is this the case, or do you *really* mean to argue that
> >> polymorphism makes code confusing? If the latter, would you mind
> explaining
> >> why?
> >>
> >> Please forgive me for any weird autocorrections, typos, or bad grammar.
> This
> >> was written on my phone, which is hard to write and proofread on.
> >>
> >> Richard Eisenberg wrote:
> >>> Having lots of polymorphism in the Prelude is great, but for two
> problems:
> >>>   1) It's very confusing to novices.
> >>>   2) In the case of using Control.Category definitions:
> kind-polymorphism
> >>> is
> >>> not portable
> >>>
> >>> I wish to ignore (2) for now, as it's a smaller concern given that it
> >>> affects only a portion of the proposed changes.
> >>
> >> In my opinion, Richard missed the most important reason:
> >>
> >> 3) Gratuitous polymorphism makes code much less readable
> >>    and much costlier to maintain, usually for almost no gain.
> >>
> >> One of the biggest strengths of Haskell is semantic clarity.
> >> You can often look at a Haskell expression, recognize its type,
> >> and then immediately understand exactly what the expression
> >> is doing. That is immensely valuable, not only for writing code,
> >> but for maintaining and refactoring it over the lifetime of an
> >> application, often by people other than the original author.
> >>
> >> Adding polymorphism to code is semantically lossy.
> >> One of the biggest disasters I have ever suffered in software
> >> engineering was when someone went through an entire fairly
> >> large code base and changed it to use a more polymorphic
> >> Prelude, then left the company. Adding the polymorphism was
> >> mostly mechanical, but undoing it required hours upon hours of
> >> puzzling out the meaning of the code, line by line.
> >>
> >> And do not relegate Richard's point #1 to CS 101 at university.
> >> Most software maintenance is done by the developers with
> >> the least Haskell experience. And that is the largest cost
> >> of software over time.
> >>
> >> Polymorphism can be very powerful, of course, and there are
> >> a lot of great tools and techniques that use it in various ways.
> >> But why force some particular polymorphic generalization
> >> down everyone's throat when the cost of enabling it if you
> >> want it is essentially zero?
> >>
> >> If you use a different Prelude in a large project, or in many small
> >> projects, take a few minutes to set up your dev environment
> >> accordingly.
> >>
> >> As a case in point: Yesod uses many GHC extensions universally,
> >> among them NoImplicitPrelude. These are all listed in the
> >> automatically-generated default cabal file; they never need to be
> >> typed, and never appear in any source files. There is a single extra
> >> line in each file which sets up the whole environment:
> >>
> >> import Import
> >>
> >> You can bind that to an editor key if you'd like. You can write
> >> scripts. There are packages on Haskell which automate a lot
> >> of things. Need I go on with these trivialities?
> >>
> >> A lot of thought went into making it easy to use GHC extensions.
> >> Advanced and experienced developers who need them should
> >> have no trouble at all using them, including alternative Preludes.
> >>
> >> That is not to say that no changes should be made to the Prelude.
> >> Now that people are using a number of different alternative Preludes
> >> more regularly, I would hope we can use that experience to
> >> make much-needed improvements to the default Prelude.
> >> But the principal design considerations should be simplicity,
> >> ease of use even for beginners, and semantic clarity of code
> >> using it.
> >>
> >> Thanks,
> >> Yitz
> >> _______________________________________________
> >> 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/20140618/743ca956/attachment-0001.html>

From dgorin at dc.uba.ar  Wed Jun 18 19:04:21 2014
From: dgorin at dc.uba.ar (=?windows-1252?Q?Daniel_Gor=EDn?=)
Date: Wed, 18 Jun 2014 21:04:21 +0200
Subject: Polymorphism in the Prelude
In-Reply-To: <CAOrUaLZ_UcsVDG042Dh4bbenhUdxdw9N_S9P-T6sEQfAzLvD1A@mail.gmail.com>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <CAOrUaLZ_UcsVDG042Dh4bbenhUdxdw9N_S9P-T6sEQfAzLvD1A@mail.gmail.com>
Message-ID: <DC8B203C-C4A1-4B00-8E0D-CE98FA97E733@dc.uba.ar>


On 18 Jun 2014, at 12:09, Yitzchak Gale <gale at sefer.org> wrote:

> Richard Eisenberg wrote:
>> Having lots of polymorphism in the Prelude is great, but for two problems:
>> 1) It's very confusing to novices.
>> 2) In the case of using Control.Category definitions: kind-polymorphism is
>> not portable
>> 
>> I wish to ignore (2) for now, as it's a smaller concern given that it
>> affects only a portion of the proposed changes.
> 
> In my opinion, Richard missed the most important reason:
> 
> 3) Gratuitous polymorphism makes code much less readable
>  and much costlier to maintain, usually for almost no gain.

The crucial problem for me would be:

4) Instance-based APIs are currently very difficult to  discover.

Just to name a few examples of useful but hidden functions:

- looking at the Haddock for Data.Maybe, it is very hard to find:
    forM :: Monad m => Maybe a -> (a -> m b) -> m (Maybe b)

- looking at the Haddock for Data.Either, it is *impossible* to discover:
    (+++) :: (a -> a') -> (b -> b') -> Either a b -> Either a? b?

- looking at the Haddock for Data.Tuple, it is *impossible* to discover:
   (***) :: (a -> a?) -> (b -> b?) -> (a,b) -> (a?,b?)

- looking at the Haddock for Data.Map , it is hard to spot:
   sequenceA_ :: Applicative f => Map a (f b) -> f ()

It helps if one knows in advance what Foldable, Traversable or Arrow are, but it is
easier to  understand a generalization if you were first exposed to concrete cases.
So whenever we replace a concrete function by a typeclass-based generalization,
we hurt the available documentation and make the learning curve even steeper.

This is perhaps ?just? a tooling problem that could be solved by haddock in some
way, but until then it is my main concern with these proposals.

Daniel


From jwlato at gmail.com  Fri Jun 20 00:46:38 2014
From: jwlato at gmail.com (John Lato)
Date: Thu, 19 Jun 2014 17:46:38 -0700
Subject: Polymorphism in the Prelude
In-Reply-To: <CAHYVw0wbSJk2zBarJwDO-mEqmzkjokzh-_U=Z7-NFJ+z2b4SKw@mail.gmail.com>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <CAOrUaLZ_UcsVDG042Dh4bbenhUdxdw9N_S9P-T6sEQfAzLvD1A@mail.gmail.com>
 <CACN--9CbCvU0oB2k8fw+wuXhy_Q1dShnJSKve9BoVapvpf0kBg@mail.gmail.com>
 <CAPeieQEbEHtpJoQsCqxYE-BwzjyqfwSTY=Z4E+ZOaxNqK8ViSQ@mail.gmail.com>
 <CAJUDvciuY8CxxsQADJfjZ8urmVErUeQihupsZ1w=kv0s04cgNQ@mail.gmail.com>
 <CAHYVw0wbSJk2zBarJwDO-mEqmzkjokzh-_U=Z7-NFJ+z2b4SKw@mail.gmail.com>
Message-ID: <CAJ727GiKq=gEwzWkKkkhJsXAO5raxXF4GtTD3cryN8fEY9bYwQ@mail.gmail.com>

Polymorphic code is not always a win.  When I see e.g. "x * x" it's very
clear what's happening.  But when someone instead uses "join (*) x"[1], it
takes a while to piece together what's going on[2].  First you need to
figure out what "join" is, and then you need to unify types:

join :: Monad m => m (m a) -> m a
(*) :: Num a => a -> a -> a

I hate unifying types.  That's what the compiler is for.

I'm not against polymorphic functions, but it's not always a win.  If your
polymorphism is making a maintenance programmer invoke their mental type
inferencer, you can expect a poor outcome.

John

[1] Why would anyone do that?  What possible advantage does this form
provide?  Paid by the character?  And yes, I've actually seen exactly this,
I don't mean the slightly-more-defensible "join (*)" in a pipeline.
[2] Unless you've already done this once and therefore are familiar with
the idiom.


On Wed, Jun 18, 2014 at 10:23 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> I think polymorphic code, subject to it "obeying laws/equations" is
> generally a win. Fewer ways to have funny corner cases. :)
>
>
> On Wed, Jun 18, 2014 at 12:00 PM, David Thomas <davidleothomas at gmail.com>
> wrote:
>
>> Of course, you can always add type annotations to be more specific
>> about your types.  And that actually might be clearer than having to
>> remember all the various names for all the various monomorphic
>> variants.  Or it might not.
>>
>> On Wed, Jun 18, 2014 at 6:06 AM, Erik Hesselink <hesselink at gmail.com>
>> wrote:
>> > I think it's a pretty clear tradeoff: if you write 'map f xs' you know
>> > that 'xs' must be a list. If you write 'fmap f xs', you know only that
>> > 'xs' is a Functor. So you gain flexibility in when you can use 'fmap',
>> > but you lose the local information you get from the more constrained
>> > type of 'map'. The same argument applies when generalizing 'mapM' and
>> > friends. I'm still in favor of generalizing the Prelude functions to
>> > their Foldable/Traversable variants, but the downside is also clear to
>> > me.
>> >
>> > This seems like a perfect problem for an IDE to solve, by the way.
>> >
>> > Erik
>> >
>> > On Wed, Jun 18, 2014 at 2:49 PM, Jake McArthur <jake.mcarthur at gmail.com>
>> wrote:
>> >> I find this argument against polymorphism baffling. Do I really have to
>> >> state the benefits of parametricity here? Probably not. Most likely,
>> there
>> >> is some specific style of polymorphism in mind going unsaid here, such
>> as
>> >> ListLike type classes that have tons of methods and don't really have
>> any
>> >> meaningful laws. Is this the case, or do you *really* mean to argue
>> that
>> >> polymorphism makes code confusing? If the latter, would you mind
>> explaining
>> >> why?
>> >>
>> >> Please forgive me for any weird autocorrections, typos, or bad
>> grammar. This
>> >> was written on my phone, which is hard to write and proofread on.
>> >>
>> >> Richard Eisenberg wrote:
>> >>> Having lots of polymorphism in the Prelude is great, but for two
>> problems:
>> >>>   1) It's very confusing to novices.
>> >>>   2) In the case of using Control.Category definitions:
>> kind-polymorphism
>> >>> is
>> >>> not portable
>> >>>
>> >>> I wish to ignore (2) for now, as it's a smaller concern given that it
>> >>> affects only a portion of the proposed changes.
>> >>
>> >> In my opinion, Richard missed the most important reason:
>> >>
>> >> 3) Gratuitous polymorphism makes code much less readable
>> >>    and much costlier to maintain, usually for almost no gain.
>> >>
>> >> One of the biggest strengths of Haskell is semantic clarity.
>> >> You can often look at a Haskell expression, recognize its type,
>> >> and then immediately understand exactly what the expression
>> >> is doing. That is immensely valuable, not only for writing code,
>> >> but for maintaining and refactoring it over the lifetime of an
>> >> application, often by people other than the original author.
>> >>
>> >> Adding polymorphism to code is semantically lossy.
>> >> One of the biggest disasters I have ever suffered in software
>> >> engineering was when someone went through an entire fairly
>> >> large code base and changed it to use a more polymorphic
>> >> Prelude, then left the company. Adding the polymorphism was
>> >> mostly mechanical, but undoing it required hours upon hours of
>> >> puzzling out the meaning of the code, line by line.
>> >>
>> >> And do not relegate Richard's point #1 to CS 101 at university.
>> >> Most software maintenance is done by the developers with
>> >> the least Haskell experience. And that is the largest cost
>> >> of software over time.
>> >>
>> >> Polymorphism can be very powerful, of course, and there are
>> >> a lot of great tools and techniques that use it in various ways.
>> >> But why force some particular polymorphic generalization
>> >> down everyone's throat when the cost of enabling it if you
>> >> want it is essentially zero?
>> >>
>> >> If you use a different Prelude in a large project, or in many small
>> >> projects, take a few minutes to set up your dev environment
>> >> accordingly.
>> >>
>> >> As a case in point: Yesod uses many GHC extensions universally,
>> >> among them NoImplicitPrelude. These are all listed in the
>> >> automatically-generated default cabal file; they never need to be
>> >> typed, and never appear in any source files. There is a single extra
>> >> line in each file which sets up the whole environment:
>> >>
>> >> import Import
>> >>
>> >> You can bind that to an editor key if you'd like. You can write
>> >> scripts. There are packages on Haskell which automate a lot
>> >> of things. Need I go on with these trivialities?
>> >>
>> >> A lot of thought went into making it easy to use GHC extensions.
>> >> Advanced and experienced developers who need them should
>> >> have no trouble at all using them, including alternative Preludes.
>> >>
>> >> That is not to say that no changes should be made to the Prelude.
>> >> Now that people are using a number of different alternative Preludes
>> >> more regularly, I would hope we can use that experience to
>> >> make much-needed improvements to the default Prelude.
>> >> But the principal design considerations should be simplicity,
>> >> ease of use even for beginners, and semantic clarity of code
>> >> using it.
>> >>
>> >> Thanks,
>> >> Yitz
>> >> _______________________________________________
>> >> 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/20140619/02f47a18/attachment.html>

From fuuzetsu at fuuzetsu.co.uk  Tue Jun 24 10:42:32 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Tue, 24 Jun 2014 12:42:32 +0200
Subject: Polymorphism in the Prelude
In-Reply-To: <DC8B203C-C4A1-4B00-8E0D-CE98FA97E733@dc.uba.ar>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <CAOrUaLZ_UcsVDG042Dh4bbenhUdxdw9N_S9P-T6sEQfAzLvD1A@mail.gmail.com>
 <DC8B203C-C4A1-4B00-8E0D-CE98FA97E733@dc.uba.ar>
Message-ID: <53A95618.6000100@fuuzetsu.co.uk>

On 06/18/2014 09:04 PM, Daniel Gor?n wrote:
> 
> On 18 Jun 2014, at 12:09, Yitzchak Gale <gale at sefer.org> wrote:
> 
>> Richard Eisenberg wrote:
>>> Having lots of polymorphism in the Prelude is great, but for two problems:
>>> 1) It's very confusing to novices.
>>> 2) In the case of using Control.Category definitions: kind-polymorphism is
>>> not portable
>>>
>>> I wish to ignore (2) for now, as it's a smaller concern given that it
>>> affects only a portion of the proposed changes.
>>
>> In my opinion, Richard missed the most important reason:
>>
>> 3) Gratuitous polymorphism makes code much less readable
>>  and much costlier to maintain, usually for almost no gain.
> 
> The crucial problem for me would be:
> 
> 4) Instance-based APIs are currently very difficult to  discover.
> 
> Just to name a few examples of useful but hidden functions:
> 
> - looking at the Haddock for Data.Maybe, it is very hard to find:
>     forM :: Monad m => Maybe a -> (a -> m b) -> m (Maybe b)
> 
> - looking at the Haddock for Data.Either, it is *impossible* to discover:
>     (+++) :: (a -> a') -> (b -> b') -> Either a b -> Either a? b?
> 
> - looking at the Haddock for Data.Tuple, it is *impossible* to discover:
>    (***) :: (a -> a?) -> (b -> b?) -> (a,b) -> (a?,b?)
> 
> - looking at the Haddock for Data.Map , it is hard to spot:
>    sequenceA_ :: Applicative f => Map a (f b) -> f ()
> 
> It helps if one knows in advance what Foldable, Traversable or Arrow are, but it is
> easier to  understand a generalization if you were first exposed to concrete cases.
> So whenever we replace a concrete function by a typeclass-based generalization,
> we hurt the available documentation and make the learning curve even steeper.
> 
> This is perhaps ?just? a tooling problem that could be solved by haddock in some
> way, but until then it is my main concern with these proposals.
> 

Regarding Haddock doing something:

Do you have anything specific in mind here? At first I was just going to
dismiss this as wishful thinking but perhaps we could actually do
something about this.

Maybe we could provide ?alternative? signatures which would make types
more specific with some (which? all of known ones?) instances.

Example:

fmap :: Functor f => (a -> b) -> f a -> f b

knowing that Maybe and [] and (Either c) are all instance of Functor,
maybe there could be an option to show extra signatures such as

fmap :: (a -> b) -> Maybe a -> Maybe b
fmap :: (a -> b) -> [a] -> [b]
fmap :: (a -> b) -> Either c a -> Either c b

Is this what you had in mind? I thought lambdabot on IRC was able to do
this but after asking around, it seems I was mistaken.

I can certainly see its usefulness but it seems tricky to implement:

Which instances to use? Should a user be able to say which instances
should show in docs and if yes, how? How to implement this in the
back-end? How should it look to the user? A something that is a stretch
would be allowing the user to specify what ?f? was on the page and have
it perform syntax substitution but that seems less useful: more user
work and if they are going to do that then they might as well load it up
into GHCi.

If this isn't what you meant then I'd be interested to hear. A much
easier way of course is to simply document some example instances. I
think pipes does something like this as you can see at [1]. The downside
of course is that it's not automated, has to be manually kept up to date
and the implementer might not have thought about a particular instance
you want to see.

[1]: https://hackage.haskell.org/package/pipes-4.1.2/docs/Pipes.html#v:for

> Daniel
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
> 


-- 
Mateusz K.

From davean at xkcd.com  Tue Jun 24 11:55:50 2014
From: davean at xkcd.com (davean)
Date: Tue, 24 Jun 2014 07:55:50 -0400
Subject: fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
Message-ID: <CABFs2Vg+3shmSqVrYZhdTcjtUC_cGq3GiinbX=QXPLcg7zaCBQ@mail.gmail.com>

I can't find a reason https://ghc.haskell.org/trac/ghc/ticket/8621 might
have stalled but it seems like it has from my perspective. Can someone tell
me I'm wrong or what to do to unstall it?

This is very useful functionality that is actually part of IEEE Std 1003.1.

-davean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140624/5870d473/attachment.html>

From johan.tibell at gmail.com  Tue Jun 24 12:15:11 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 24 Jun 2014 14:15:11 +0200
Subject: fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
In-Reply-To: <CABFs2Vg+3shmSqVrYZhdTcjtUC_cGq3GiinbX=QXPLcg7zaCBQ@mail.gmail.com>
References: <CABFs2Vg+3shmSqVrYZhdTcjtUC_cGq3GiinbX=QXPLcg7zaCBQ@mail.gmail.com>
Message-ID: <CAK-tuPYV2-A7CyTeX98yb0eiy3mw4uO2i1YnD7DHC4vrqggADw@mail.gmail.com>

It was in the wrong state. Tickets with attached patches that need to be
review should be put in the "Please review" state. It might also help to
actually attach the patch to the ticket.


On Tue, Jun 24, 2014 at 1:55 PM, davean <davean at xkcd.com> wrote:

> I can't find a reason https://ghc.haskell.org/trac/ghc/ticket/8621 might
> have stalled but it seems like it has from my perspective. Can someone tell
> me I'm wrong or what to do to unstall it?
>
> This is very useful functionality that is actually part of IEEE Std
> 1003.1.
>
> -davean
>
> _______________________________________________
> 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/20140624/162cf9ef/attachment.html>

From davean at xkcd.com  Tue Jun 24 12:24:20 2014
From: davean at xkcd.com (davean)
Date: Tue, 24 Jun 2014 08:24:20 -0400
Subject: fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
In-Reply-To: <CAK-tuPYV2-A7CyTeX98yb0eiy3mw4uO2i1YnD7DHC4vrqggADw@mail.gmail.com>
References: <CABFs2Vg+3shmSqVrYZhdTcjtUC_cGq3GiinbX=QXPLcg7zaCBQ@mail.gmail.com>
 <CAK-tuPYV2-A7CyTeX98yb0eiy3mw4uO2i1YnD7DHC4vrqggADw@mail.gmail.com>
Message-ID: <CABFs2ViPJkRHMxTjWQg_uf3ZFat9EhFjAGAos7s1ZHJ+NDxG7w@mail.gmail.com>

A patch is attached, right there as is a pull location. Not sure what else
you could want.

Also, the only valid states seem to be (according to trac): closed,
infoneeded, merge, new, patch. I see no "Please review" state. Is how to
use this documented somewhere?

-davean


On Tue, Jun 24, 2014 at 8:15 AM, Johan Tibell <johan.tibell at gmail.com>
wrote:

> It was in the wrong state. Tickets with attached patches that need to be
> review should be put in the "Please review" state. It might also help to
> actually attach the patch to the ticket.
>
>
> On Tue, Jun 24, 2014 at 1:55 PM, davean <davean at xkcd.com> wrote:
>
>>  I can't find a reason https://ghc.haskell.org/trac/ghc/ticket/8621
>> might have stalled but it seems like it has from my perspective. Can
>> someone tell me I'm wrong or what to do to unstall it?
>>
>> This is very useful functionality that is actually part of IEEE Std
>> 1003.1.
>>
>> -davean
>>
>> _______________________________________________
>> 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/20140624/e5309921/attachment.html>

From johan.tibell at gmail.com  Tue Jun 24 13:07:11 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 24 Jun 2014 15:07:11 +0200
Subject: fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
In-Reply-To: <CABFs2ViPJkRHMxTjWQg_uf3ZFat9EhFjAGAos7s1ZHJ+NDxG7w@mail.gmail.com>
References: <CABFs2Vg+3shmSqVrYZhdTcjtUC_cGq3GiinbX=QXPLcg7zaCBQ@mail.gmail.com>
 <CAK-tuPYV2-A7CyTeX98yb0eiy3mw4uO2i1YnD7DHC4vrqggADw@mail.gmail.com>
 <CABFs2ViPJkRHMxTjWQg_uf3ZFat9EhFjAGAos7s1ZHJ+NDxG7w@mail.gmail.com>
Message-ID: <CAK-tuPZr98tHXfxtAd+M0rzZFFaVnw3dZyk3oJJWR-4KFy==OA@mail.gmail.com>

patch = "Please review"

Attachments as in Trac attachments, not links to other websites. This is
probably not terribly important, but people tend to not tickets with
attachments more.


On Tue, Jun 24, 2014 at 2:24 PM, davean <davean at xkcd.com> wrote:

> A patch is attached, right there as is a pull location. Not sure what else
> you could want.
>
> Also, the only valid states seem to be (according to trac): closed,
> infoneeded, merge, new, patch. I see no "Please review" state. Is how to
> use this documented somewhere?
>
> -davean
>
>
> On Tue, Jun 24, 2014 at 8:15 AM, Johan Tibell <johan.tibell at gmail.com>
> wrote:
>
>> It was in the wrong state. Tickets with attached patches that need to be
>> review should be put in the "Please review" state. It might also help to
>> actually attach the patch to the ticket.
>>
>>
>> On Tue, Jun 24, 2014 at 1:55 PM, davean <davean at xkcd.com> wrote:
>>
>>>  I can't find a reason https://ghc.haskell.org/trac/ghc/ticket/8621
>>> might have stalled but it seems like it has from my perspective. Can
>>> someone tell me I'm wrong or what to do to unstall it?
>>>
>>> This is very useful functionality that is actually part of IEEE Std
>>> 1003.1.
>>>
>>> -davean
>>>
>>> _______________________________________________
>>> 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/20140624/19e4f41c/attachment.html>

From davean at xkcd.com  Tue Jun 24 13:12:17 2014
From: davean at xkcd.com (davean)
Date: Tue, 24 Jun 2014 09:12:17 -0400
Subject: fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
In-Reply-To: <CAK-tuPZr98tHXfxtAd+M0rzZFFaVnw3dZyk3oJJWR-4KFy==OA@mail.gmail.com>
References: <CABFs2Vg+3shmSqVrYZhdTcjtUC_cGq3GiinbX=QXPLcg7zaCBQ@mail.gmail.com>
 <CAK-tuPYV2-A7CyTeX98yb0eiy3mw4uO2i1YnD7DHC4vrqggADw@mail.gmail.com>
 <CABFs2ViPJkRHMxTjWQg_uf3ZFat9EhFjAGAos7s1ZHJ+NDxG7w@mail.gmail.com>
 <CAK-tuPZr98tHXfxtAd+M0rzZFFaVnw3dZyk3oJJWR-4KFy==OA@mail.gmail.com>
Message-ID: <CABFs2ViSEb+2DV8qK==NCBZ6RYjKRy+RMYRym3VgepkzRF=qCA@mail.gmail.com>

Is this documented somewhere? It seems both I and the original submitter
assumed that tickets would start in the "new" state (and likely be triage
from there).

-davean


On Tue, Jun 24, 2014 at 9:07 AM, Johan Tibell <johan.tibell at gmail.com>
wrote:

> patch = "Please review"
>
> Attachments as in Trac attachments, not links to other websites. This is
> probably not terribly important, but people tend to not tickets with
> attachments more.
>
>
> On Tue, Jun 24, 2014 at 2:24 PM, davean <davean at xkcd.com> wrote:
>
>> A patch is attached, right there as is a pull location. Not sure what
>> else you could want.
>>
>> Also, the only valid states seem to be (according to trac): closed,
>> infoneeded, merge, new, patch. I see no "Please review" state. Is how to
>> use this documented somewhere?
>>
>> -davean
>>
>>
>> On Tue, Jun 24, 2014 at 8:15 AM, Johan Tibell <johan.tibell at gmail.com>
>> wrote:
>>
>>> It was in the wrong state. Tickets with attached patches that need to be
>>> review should be put in the "Please review" state. It might also help to
>>> actually attach the patch to the ticket.
>>>
>>>
>>> On Tue, Jun 24, 2014 at 1:55 PM, davean <davean at xkcd.com> wrote:
>>>
>>>>  I can't find a reason https://ghc.haskell.org/trac/ghc/ticket/8621
>>>> might have stalled but it seems like it has from my perspective. Can
>>>> someone tell me I'm wrong or what to do to unstall it?
>>>>
>>>> This is very useful functionality that is actually part of IEEE Std
>>>> 1003.1.
>>>>
>>>> -davean
>>>>
>>>> _______________________________________________
>>>> 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/20140624/efabaa71/attachment.html>

From johan.tibell at gmail.com  Tue Jun 24 13:41:58 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Tue, 24 Jun 2014 15:41:58 +0200
Subject: fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
In-Reply-To: <CABFs2ViSEb+2DV8qK==NCBZ6RYjKRy+RMYRym3VgepkzRF=qCA@mail.gmail.com>
References: <CABFs2Vg+3shmSqVrYZhdTcjtUC_cGq3GiinbX=QXPLcg7zaCBQ@mail.gmail.com>
 <CAK-tuPYV2-A7CyTeX98yb0eiy3mw4uO2i1YnD7DHC4vrqggADw@mail.gmail.com>
 <CABFs2ViPJkRHMxTjWQg_uf3ZFat9EhFjAGAos7s1ZHJ+NDxG7w@mail.gmail.com>
 <CAK-tuPZr98tHXfxtAd+M0rzZFFaVnw3dZyk3oJJWR-4KFy==OA@mail.gmail.com>
 <CABFs2ViSEb+2DV8qK==NCBZ6RYjKRy+RMYRym3VgepkzRF=qCA@mail.gmail.com>
Message-ID: <CAK-tuPbvGkEiOa2Dt1j8iwbmTA0JrwnNgXf=5jUZoFc4OTrrcQ@mail.gmail.com>

I don't know to be honest.


On Tue, Jun 24, 2014 at 3:12 PM, davean <davean at xkcd.com> wrote:

> Is this documented somewhere? It seems both I and the original submitter
> assumed that tickets would start in the "new" state (and likely be triage
> from there).
>
> -davean
>
>
> On Tue, Jun 24, 2014 at 9:07 AM, Johan Tibell <johan.tibell at gmail.com>
> wrote:
>
>> patch = "Please review"
>>
>> Attachments as in Trac attachments, not links to other websites. This is
>> probably not terribly important, but people tend to not tickets with
>> attachments more.
>>
>>
>> On Tue, Jun 24, 2014 at 2:24 PM, davean <davean at xkcd.com> wrote:
>>
>>> A patch is attached, right there as is a pull location. Not sure what
>>> else you could want.
>>>
>>> Also, the only valid states seem to be (according to trac): closed,
>>> infoneeded, merge, new, patch. I see no "Please review" state. Is how to
>>> use this documented somewhere?
>>>
>>> -davean
>>>
>>>
>>> On Tue, Jun 24, 2014 at 8:15 AM, Johan Tibell <johan.tibell at gmail.com>
>>> wrote:
>>>
>>>> It was in the wrong state. Tickets with attached patches that need to
>>>> be review should be put in the "Please review" state. It might also help to
>>>> actually attach the patch to the ticket.
>>>>
>>>>
>>>> On Tue, Jun 24, 2014 at 1:55 PM, davean <davean at xkcd.com> wrote:
>>>>
>>>>>  I can't find a reason https://ghc.haskell.org/trac/ghc/ticket/8621
>>>>> might have stalled but it seems like it has from my perspective. Can
>>>>> someone tell me I'm wrong or what to do to unstall it?
>>>>>
>>>>> This is very useful functionality that is actually part of IEEE Std
>>>>> 1003.1.
>>>>>
>>>>> -davean
>>>>>
>>>>> _______________________________________________
>>>>> 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/20140624/7ba6e6ba/attachment-0001.html>

From bos at serpentine.com  Tue Jun 24 16:20:41 2014
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Tue, 24 Jun 2014 09:20:41 -0700
Subject: Polymorphism in the Prelude
In-Reply-To: <53A95618.6000100@fuuzetsu.co.uk>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <CAOrUaLZ_UcsVDG042Dh4bbenhUdxdw9N_S9P-T6sEQfAzLvD1A@mail.gmail.com>
 <DC8B203C-C4A1-4B00-8E0D-CE98FA97E733@dc.uba.ar>
 <53A95618.6000100@fuuzetsu.co.uk>
Message-ID: <CACw0niLmhNhQvak2Li6PK7Hw0nOdk0Q7C-wPat+yztJ9eLQENA@mail.gmail.com>

On Tue, Jun 24, 2014 at 3:42 AM, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk>
wrote:

> Do you have anything specific in mind here? At first I was just going to
> dismiss this as wishful thinking but perhaps we could actually do
> something about this.
>
> Maybe we could provide ?alternative? signatures which would make types
> more specific with some (which? all of known ones?) instances.
>

You can already see how that works out with Scala documentation, which is
an incomprehensible mess.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140624/62668ae7/attachment.html>

From vogt.adam at gmail.com  Tue Jun 24 16:41:26 2014
From: vogt.adam at gmail.com (adam vogt)
Date: Tue, 24 Jun 2014 12:41:26 -0400
Subject: Polymorphism in the Prelude
In-Reply-To: <53A95618.6000100@fuuzetsu.co.uk>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <CAOrUaLZ_UcsVDG042Dh4bbenhUdxdw9N_S9P-T6sEQfAzLvD1A@mail.gmail.com>
 <DC8B203C-C4A1-4B00-8E0D-CE98FA97E733@dc.uba.ar>
 <53A95618.6000100@fuuzetsu.co.uk>
Message-ID: <CAHfjoWmd6SuYJ_tu-aosQF2NQmfc+Sv4KZO1hEqFEY-yh0=gEw@mail.gmail.com>

On Tue, Jun 24, 2014 at 6:42 AM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk> wrote:
> If this isn't what you meant then I'd be interested to hear. A much
> easier way of course is to simply document some example instances. I
> think pipes does something like this as you can see at [1]. The downside
> of course is that it's not automated, has to be manually kept up to date
> and the implementer might not have thought about a particular instance
> you want to see.
>
> [1]: https://hackage.haskell.org/package/pipes-4.1.2/docs/Pipes.html#v:for

As far as keeping things "manually up to date", it is possible to use
doctest to show and confirm things like:

>>> let f  x y = (x :: Int) + y
>>> :t f
f :: Int -> Int -> Int

But different ghc versions print types differently (type variable
names change, constraints come out in a different order, etc.), so
keeping the output up-to-date might be the same effort as manually
checking type signatures like the ones in the Pipes documentation.

From igloo at earth.li  Tue Jun 24 19:00:41 2014
From: igloo at earth.li (Ian Lynagh)
Date: Tue, 24 Jun 2014 20:00:41 +0100
Subject: fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
In-Reply-To: <CAK-tuPbvGkEiOa2Dt1j8iwbmTA0JrwnNgXf=5jUZoFc4OTrrcQ@mail.gmail.com>
References: <CABFs2Vg+3shmSqVrYZhdTcjtUC_cGq3GiinbX=QXPLcg7zaCBQ@mail.gmail.com>
 <CAK-tuPYV2-A7CyTeX98yb0eiy3mw4uO2i1YnD7DHC4vrqggADw@mail.gmail.com>
 <CABFs2ViPJkRHMxTjWQg_uf3ZFat9EhFjAGAos7s1ZHJ+NDxG7w@mail.gmail.com>
 <CAK-tuPZr98tHXfxtAd+M0rzZFFaVnw3dZyk3oJJWR-4KFy==OA@mail.gmail.com>
 <CABFs2ViSEb+2DV8qK==NCBZ6RYjKRy+RMYRym3VgepkzRF=qCA@mail.gmail.com>
 <CAK-tuPbvGkEiOa2Dt1j8iwbmTA0JrwnNgXf=5jUZoFc4OTrrcQ@mail.gmail.com>
Message-ID: <20140624190041.GA11822@matrix.chaos.earth.li>

On Tue, Jun 24, 2014 at 03:41:58PM +0200, Johan Tibell wrote:
> On Tue, Jun 24, 2014 at 3:12 PM, davean <davean at xkcd.com> wrote:
> 
> > Is this documented somewhere? It seems both I and the original submitter
> > assumed that tickets would start in the "new" state (and likely be triage
> > from there).

Near the end of step 7 on
    https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs


Thanks
Ian


From dgorin at dc.uba.ar  Tue Jun 24 19:08:12 2014
From: dgorin at dc.uba.ar (=?windows-1252?Q?Daniel_Gor=EDn?=)
Date: Tue, 24 Jun 2014 21:08:12 +0200
Subject: Polymorphism in the Prelude
In-Reply-To: <CACw0niLmhNhQvak2Li6PK7Hw0nOdk0Q7C-wPat+yztJ9eLQENA@mail.gmail.com>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <CAOrUaLZ_UcsVDG042Dh4bbenhUdxdw9N_S9P-T6sEQfAzLvD1A@mail.gmail.com>
 <DC8B203C-C4A1-4B00-8E0D-CE98FA97E733@dc.uba.ar>
 <53A95618.6000100@fuuzetsu.co.uk>
 <CACw0niLmhNhQvak2Li6PK7Hw0nOdk0Q7C-wPat+yztJ9eLQENA@mail.gmail.com>
Message-ID: <F34F704C-CC84-45C7-8E4D-CA81DF8A47C2@dc.uba.ar>


On Tue, Jun 24, 2014 at 3:42 AM, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk> wrote:
> Do you have anything specific in mind here? At first I was just going to
> dismiss this as wishful thinking but perhaps we could actually do
> something about this.
> 
> Maybe we could provide ?alternative? signatures which would make types
> more specific with some (which? all of known ones?) instances.

One thing that might help is to list the specific type of methods below instance declarations, in a collapsible view to avoid cluttering. An example rendering (in "expanded view")  would be:

> [-] instance Functor ((->) r) where
>      fmap :: (a -> b) -> (r -> a) -> (r -> b) 


Non-methods, could be handled with documentation pragmas, so the library maintainer could pick which functions to document with specialized types. One could, for example, define Data.Either as:

> module Data.Either (  ? ,  (+++) )
> 
> where
> import Control.Arrow ( (+++) ) 
> ?
> {#- SPECIALIZE DOC (+++) :: (a -> a') -> (b -> b') -> Either a b -> Either a? b? #-}
> ?

which would be rendered by haddock as, say:

> (+++) :: (a -> a?) -> (b -> b?) -> Either a b -> Either a? b?
>   Specialized signature of [Control.Arrow.(+++)]

with a suitable link. I?d prefer the module system being able to export more specific instances of functions, but this could be a decent compromise.


On 24 Jun 2014, at 18:20, Bryan O'Sullivan <bos at serpentine.com> wrote:
> You can already see how that works out with Scala documentation, which is an incomprehensible mess.

I?m not familiar with Scala documentation, do you think something like this would get messy?



From ekmett at gmail.com  Tue Jun 24 23:10:00 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 24 Jun 2014 19:10:00 -0400
Subject: Polymorphism in the Prelude
In-Reply-To: <F34F704C-CC84-45C7-8E4D-CA81DF8A47C2@dc.uba.ar>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <CAOrUaLZ_UcsVDG042Dh4bbenhUdxdw9N_S9P-T6sEQfAzLvD1A@mail.gmail.com>
 <DC8B203C-C4A1-4B00-8E0D-CE98FA97E733@dc.uba.ar>
 <53A95618.6000100@fuuzetsu.co.uk>
 <CACw0niLmhNhQvak2Li6PK7Hw0nOdk0Q7C-wPat+yztJ9eLQENA@mail.gmail.com>
 <F34F704C-CC84-45C7-8E4D-CA81DF8A47C2@dc.uba.ar>
Message-ID: <563D86C1-2E58-44A0-AB2F-17B619559B8C@gmail.com>



> On Jun 24, 2014, at 3:08 PM, Daniel Gor?n <dgorin at dc.uba.ar> wrote:
> 
> 
>> On Tue, Jun 24, 2014 at 3:42 AM, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk> wrote:
>> Do you have anything specific in mind here? At first I was just going to
>> dismiss this as wishful thinking but perhaps we could actually do
>> something about this.
>> 
>> Maybe we could provide ?alternative? signatures which would make types
>> more specific with some (which? all of known ones?) instances.
> 
> One thing that might help is to list the specific type of methods below instance declarations, in a collapsible view to avoid cluttering. An example rendering (in "expanded view")  would be:
> 
>> [-] instance Functor ((->) r) where
>>     fmap :: (a -> b) -> (r -> a) -> (r -> b)
> 
> 

Being able to "open" an instance line in haddock to see what it means could be quite useful. It'd likely require a fair bit of work in haddock though as it'd have to synthesize that information somehow.

From davean at xkcd.com  Wed Jun 25 11:11:45 2014
From: davean at xkcd.com (davean)
Date: Wed, 25 Jun 2014 07:11:45 -0400
Subject: fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
In-Reply-To: <20140624190041.GA11822@matrix.chaos.earth.li>
References: <CABFs2Vg+3shmSqVrYZhdTcjtUC_cGq3GiinbX=QXPLcg7zaCBQ@mail.gmail.com>
 <CAK-tuPYV2-A7CyTeX98yb0eiy3mw4uO2i1YnD7DHC4vrqggADw@mail.gmail.com>
 <CABFs2ViPJkRHMxTjWQg_uf3ZFat9EhFjAGAos7s1ZHJ+NDxG7w@mail.gmail.com>
 <CAK-tuPZr98tHXfxtAd+M0rzZFFaVnw3dZyk3oJJWR-4KFy==OA@mail.gmail.com>
 <CABFs2ViSEb+2DV8qK==NCBZ6RYjKRy+RMYRym3VgepkzRF=qCA@mail.gmail.com>
 <CAK-tuPbvGkEiOa2Dt1j8iwbmTA0JrwnNgXf=5jUZoFc4OTrrcQ@mail.gmail.com>
 <20140624190041.GA11822@matrix.chaos.earth.li>
Message-ID: <CABFs2Vg6jpV571sXq0RCVjecFX8uVcm-kOR2gkwRdaiC33U5Pw@mail.gmail.com>

Thank you.

-davean


On Tue, Jun 24, 2014 at 3:00 PM, Ian Lynagh <igloo at earth.li> wrote:

> On Tue, Jun 24, 2014 at 03:41:58PM +0200, Johan Tibell wrote:
> > On Tue, Jun 24, 2014 at 3:12 PM, davean <davean at xkcd.com> wrote:
> >
> > > Is this documented somewhere? It seems both I and the original
> submitter
> > > assumed that tickets would start in the "new" state (and likely be
> triage
> > > from there).
>
> Near the end of step 7 on
>     https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/FixingBugs
>
>
> Thanks
> Ian
>
> _______________________________________________
> 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/20140625/00c660fa/attachment.html>

From fuuzetsu at fuuzetsu.co.uk  Wed Jun 25 13:51:46 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Wed, 25 Jun 2014 15:51:46 +0200
Subject: Polymorphism in the Prelude
In-Reply-To: <563D86C1-2E58-44A0-AB2F-17B619559B8C@gmail.com>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <CAOrUaLZ_UcsVDG042Dh4bbenhUdxdw9N_S9P-T6sEQfAzLvD1A@mail.gmail.com>
 <DC8B203C-C4A1-4B00-8E0D-CE98FA97E733@dc.uba.ar>
 <53A95618.6000100@fuuzetsu.co.uk>
 <CACw0niLmhNhQvak2Li6PK7Hw0nOdk0Q7C-wPat+yztJ9eLQENA@mail.gmail.com>
 <F34F704C-CC84-45C7-8E4D-CA81DF8A47C2@dc.uba.ar>
 <563D86C1-2E58-44A0-AB2F-17B619559B8C@gmail.com>
Message-ID: <53AAD3F2.7090707@fuuzetsu.co.uk>

On 06/25/2014 01:10 AM, Edward Kmett wrote:
> 
> 
>> On Jun 24, 2014, at 3:08 PM, Daniel Gor?n <dgorin at dc.uba.ar> wrote:
>>
>>
>>> On Tue, Jun 24, 2014 at 3:42 AM, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk> wrote:
>>> Do you have anything specific in mind here? At first I was just going to
>>> dismiss this as wishful thinking but perhaps we could actually do
>>> something about this.
>>>
>>> Maybe we could provide ?alternative? signatures which would make types
>>> more specific with some (which? all of known ones?) instances.
>>
>> One thing that might help is to list the specific type of methods below instance declarations, in a collapsible view to avoid cluttering. An example rendering (in "expanded view")  would be:
>>
>>> [-] instance Functor ((->) r) where
>>>     fmap :: (a -> b) -> (r -> a) -> (r -> b)
>>
>>
> 
> Being able to "open" an instance line in haddock to see what it means could be quite useful. It'd likely require a fair bit of work in haddock though as it'd have to synthesize that information somehow.
> 

I think that it might not be very hard to get this information from GHC
for regular typeclasses although it might be harder for TFs &c. I think
presentation is a big problem here and the rest is just figuring out how
to use the GHC API to spit out what we need.

-- 
Mateusz K.

From fuuzetsu at fuuzetsu.co.uk  Wed Jun 25 13:54:24 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Wed, 25 Jun 2014 15:54:24 +0200
Subject: Polymorphism in the Prelude
In-Reply-To: <CACw0niLmhNhQvak2Li6PK7Hw0nOdk0Q7C-wPat+yztJ9eLQENA@mail.gmail.com>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <CAOrUaLZ_UcsVDG042Dh4bbenhUdxdw9N_S9P-T6sEQfAzLvD1A@mail.gmail.com>
 <DC8B203C-C4A1-4B00-8E0D-CE98FA97E733@dc.uba.ar>
 <53A95618.6000100@fuuzetsu.co.uk>
 <CACw0niLmhNhQvak2Li6PK7Hw0nOdk0Q7C-wPat+yztJ9eLQENA@mail.gmail.com>
Message-ID: <53AAD490.3090803@fuuzetsu.co.uk>

On 06/24/2014 06:20 PM, Bryan O'Sullivan wrote:
> On Tue, Jun 24, 2014 at 3:42 AM, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk>
> wrote:
> 
>> Do you have anything specific in mind here? At first I was just going to
>> dismiss this as wishful thinking but perhaps we could actually do
>> something about this.
>>
>> Maybe we could provide ?alternative? signatures which would make types
>> more specific with some (which? all of known ones?) instances.
>>
> 
> You can already see how that works out with Scala documentation, which is
> an incomprehensible mess.
> 

Can you link to a specific example? I looked up the API docs but I have
no idea what I should be looking for here.

I think that expandable instance lines would be the best without getting
in the way as they won't use up any new space which would let us avoid
clutter. If we generate this info automagically then there is no clutter
in the source itself either.

-- 
Mateusz K.

From alois.cochard at gmail.com  Wed Jun 25 14:02:57 2014
From: alois.cochard at gmail.com (Alois Cochard)
Date: Wed, 25 Jun 2014 15:02:57 +0100
Subject: Polymorphism in the Prelude
In-Reply-To: <CACw0niLmhNhQvak2Li6PK7Hw0nOdk0Q7C-wPat+yztJ9eLQENA@mail.gmail.com>
References: <60BF8877-DBAB-4719-94BA-ECF69A391D2E@cis.upenn.edu>
 <CAOrUaLZ_UcsVDG042Dh4bbenhUdxdw9N_S9P-T6sEQfAzLvD1A@mail.gmail.com>
 <DC8B203C-C4A1-4B00-8E0D-CE98FA97E733@dc.uba.ar>
 <53A95618.6000100@fuuzetsu.co.uk>
 <CACw0niLmhNhQvak2Li6PK7Hw0nOdk0Q7C-wPat+yztJ9eLQENA@mail.gmail.com>
Message-ID: <CAJHA+wooK_O6AEcRb9jBU-BTvuKOnvLyc5tf6rDhJAxqvHDfOg@mail.gmail.com>

Just to add my 2ct that it definitely don't work well for Scala.

That being said, it should be possible to have some nice UI/UX to help
investigate such things... but the approach Scala documentation is using is
definitely not ideal.


On 24 June 2014 17:20, Bryan O'Sullivan <bos at serpentine.com> wrote:

>
> On Tue, Jun 24, 2014 at 3:42 AM, Mateusz Kowalczyk <
> fuuzetsu at fuuzetsu.co.uk> wrote:
>
>> Do you have anything specific in mind here? At first I was just going to
>> dismiss this as wishful thinking but perhaps we could actually do
>> something about this.
>>
>> Maybe we could provide ?alternative? signatures which would make types
>> more specific with some (which? all of known ones?) instances.
>>
>
> You can already see how that works out with Scala documentation, which is
> an incomprehensible mess.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>


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

From greg at gregorycollins.net  Thu Jun 26 14:42:03 2014
From: greg at gregorycollins.net (Gregory Collins)
Date: Thu, 26 Jun 2014 16:42:03 +0200
Subject: New version of vector + discussion
Message-ID: <CAHZrzdrDSAn5kPSB1ryJ9J4ajk14GgZzE6iMphUsLMWWna=mkg@mail.gmail.com>

Hi all,

I've prepped a new minor version (0.10.12.0) of the 0.10 branch of vector
so that we can release https://github.com/haskell/vector/pull/31, which I
cherry-picked from master. Could someone please review this and do the
upload? I'm not sure I have the right bit set.

Also, in a related topic, an aside: I tried to merge 0.10 into master and
got a horrorshow:

# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified:      Data/Vector.hs
# deleted by them:    Data/Vector/Fusion/Bundle/Monadic.hs
# both modified:      Data/Vector/Fusion/Stream.hs
# both modified:      Data/Vector/Fusion/Stream/Monadic.hs
# both modified:      Data/Vector/Fusion/Stream/Size.hs
# both modified:      Data/Vector/Generic.hs
# both modified:      Data/Vector/Generic/Mutable.hs
# deleted by them:    Data/Vector/Generic/Mutable/Base.hs
# both modified:      Data/Vector/Generic/New.hs
# both modified:      Data/Vector/Mutable.hs
# both modified:      Data/Vector/Storable.hs
# both modified:      Data/Vector/Unboxed.hs
# both modified:      Data/Vector/Unboxed/Base.hs
# both added:         README.md
# both modified:      benchmarks/vector-benchmarks.cabal
# both added:         changelog
# both modified:      internal/unbox-tuple-instances
# both modified:      tests/vector-tests.cabal
# both modified:      vector.cabal


I'm curious why these branches have diverged like this, it doesn't smell
good to me. Does anyone want to tackle doing this merge?

G
-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140626/f78341ad/attachment.html>

From johan.tibell at gmail.com  Thu Jun 26 15:02:11 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 26 Jun 2014 17:02:11 +0200
Subject: New version of vector + discussion
In-Reply-To: <CAHZrzdrDSAn5kPSB1ryJ9J4ajk14GgZzE6iMphUsLMWWna=mkg@mail.gmail.com>
References: <CAHZrzdrDSAn5kPSB1ryJ9J4ajk14GgZzE6iMphUsLMWWna=mkg@mail.gmail.com>
Message-ID: <CAK-tuPYoekmE6rRz2LCTHQ9UhhMPV2LatC82yhNkr9=NSpp82w@mail.gmail.com>

Geoffrey, you did a bunch of hacking on vector at some point, right? Do you
have an idea why the branches have diverged?


On Thu, Jun 26, 2014 at 4:42 PM, Gregory Collins <greg at gregorycollins.net>
wrote:

> Hi all,
>
> I've prepped a new minor version (0.10.12.0) of the 0.10 branch of vector
> so that we can release https://github.com/haskell/vector/pull/31, which I
> cherry-picked from master. Could someone please review this and do the
> upload? I'm not sure I have the right bit set.
>
> Also, in a related topic, an aside: I tried to merge 0.10 into master and
> got a horrorshow:
>
> # Unmerged paths:
> #   (use "git add/rm <file>..." as appropriate to mark resolution)
> #
> # both modified:      Data/Vector.hs
> # deleted by them:    Data/Vector/Fusion/Bundle/Monadic.hs
> # both modified:      Data/Vector/Fusion/Stream.hs
> # both modified:      Data/Vector/Fusion/Stream/Monadic.hs
> # both modified:      Data/Vector/Fusion/Stream/Size.hs
> # both modified:      Data/Vector/Generic.hs
> # both modified:      Data/Vector/Generic/Mutable.hs
> # deleted by them:    Data/Vector/Generic/Mutable/Base.hs
> # both modified:      Data/Vector/Generic/New.hs
> # both modified:      Data/Vector/Mutable.hs
> # both modified:      Data/Vector/Storable.hs
> # both modified:      Data/Vector/Unboxed.hs
> # both modified:      Data/Vector/Unboxed/Base.hs
> # both added:         README.md
> # both modified:      benchmarks/vector-benchmarks.cabal
> # both added:         changelog
> # both modified:      internal/unbox-tuple-instances
> # both modified:      tests/vector-tests.cabal
> # both modified:      vector.cabal
>
>
> I'm curious why these branches have diverged like this, it doesn't smell
> good to me. Does anyone want to tackle doing this merge?
>
> G
> --
> Gregory Collins <greg at gregorycollins.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/20140626/f3e3c2c7/attachment.html>

From ekmett at gmail.com  Thu Jun 26 15:06:10 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 26 Jun 2014 11:06:10 -0400
Subject: New version of vector + discussion
In-Reply-To: <CAHZrzdrDSAn5kPSB1ryJ9J4ajk14GgZzE6iMphUsLMWWna=mkg@mail.gmail.com>
References: <CAHZrzdrDSAn5kPSB1ryJ9J4ajk14GgZzE6iMphUsLMWWna=mkg@mail.gmail.com>
Message-ID: <8572647A-32BE-45D7-A731-BE5921F470DB@gmail.com>

_Please_ talk to Dan Doel before another version of vector goes out through back channels as it were.

Sent from my iPhone

> On Jun 26, 2014, at 10:42 AM, Gregory Collins <greg at gregorycollins.net> wrote:
> 
> Hi all,
> 
> I've prepped a new minor version (0.10.12.0) of the 0.10 branch of vector so that we can release https://github.com/haskell/vector/pull/31, which I cherry-picked from master. Could someone please review this and do the upload? I'm not sure I have the right bit set.
> 
> Also, in a related topic, an aside: I tried to merge 0.10 into master and got a horrorshow:
> 
> # Unmerged paths:
> #   (use "git add/rm <file>..." as appropriate to mark resolution)
> #
> #	both modified:      Data/Vector.hs
> #	deleted by them:    Data/Vector/Fusion/Bundle/Monadic.hs
> #	both modified:      Data/Vector/Fusion/Stream.hs
> #	both modified:      Data/Vector/Fusion/Stream/Monadic.hs
> #	both modified:      Data/Vector/Fusion/Stream/Size.hs
> #	both modified:      Data/Vector/Generic.hs
> #	both modified:      Data/Vector/Generic/Mutable.hs
> #	deleted by them:    Data/Vector/Generic/Mutable/Base.hs
> #	both modified:      Data/Vector/Generic/New.hs
> #	both modified:      Data/Vector/Mutable.hs
> #	both modified:      Data/Vector/Storable.hs
> #	both modified:      Data/Vector/Unboxed.hs
> #	both modified:      Data/Vector/Unboxed/Base.hs
> #	both added:         README.md
> #	both modified:      benchmarks/vector-benchmarks.cabal
> #	both added:         changelog
> #	both modified:      internal/unbox-tuple-instances
> #	both modified:      tests/vector-tests.cabal
> #	both modified:      vector.cabal
> 
> I'm curious why these branches have diverged like this, it doesn't smell good to me. Does anyone want to tackle doing this merge?
> 
> G
> -- 
> Gregory Collins <greg at gregorycollins.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/20140626/2f168a95/attachment.html>

From johan.tibell at gmail.com  Thu Jun 26 15:08:20 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 26 Jun 2014 17:08:20 +0200
Subject: New version of vector + discussion
In-Reply-To: <8572647A-32BE-45D7-A731-BE5921F470DB@gmail.com>
References: <CAHZrzdrDSAn5kPSB1ryJ9J4ajk14GgZzE6iMphUsLMWWna=mkg@mail.gmail.com>
 <8572647A-32BE-45D7-A731-BE5921F470DB@gmail.com>
Message-ID: <CAK-tuPZUe40LGGiEOKm8vZ84SufF-OKy-ESY2ibXptpJcBB3KA@mail.gmail.com>

Dan, are you maintaining vector now? Do you want yourself listed as the
maintainer in the .cabal file (right now it's libraries at haskell.org)?


On Thu, Jun 26, 2014 at 5:06 PM, Edward Kmett <ekmett at gmail.com> wrote:

> _Please_ talk to Dan Doel before another version of vector goes out
> through back channels as it were.
>
> Sent from my iPhone
>
> On Jun 26, 2014, at 10:42 AM, Gregory Collins <greg at gregorycollins.net>
> wrote:
>
> Hi all,
>
> I've prepped a new minor version (0.10.12.0) of the 0.10 branch of vector
> so that we can release https://github.com/haskell/vector/pull/31, which I
> cherry-picked from master. Could someone please review this and do the
> upload? I'm not sure I have the right bit set.
>
> Also, in a related topic, an aside: I tried to merge 0.10 into master and
> got a horrorshow:
>
> # Unmerged paths:
> #   (use "git add/rm <file>..." as appropriate to mark resolution)
> #
> # both modified:      Data/Vector.hs
> # deleted by them:    Data/Vector/Fusion/Bundle/Monadic.hs
> # both modified:      Data/Vector/Fusion/Stream.hs
> # both modified:      Data/Vector/Fusion/Stream/Monadic.hs
> # both modified:      Data/Vector/Fusion/Stream/Size.hs
> # both modified:      Data/Vector/Generic.hs
> # both modified:      Data/Vector/Generic/Mutable.hs
> # deleted by them:    Data/Vector/Generic/Mutable/Base.hs
> # both modified:      Data/Vector/Generic/New.hs
> # both modified:      Data/Vector/Mutable.hs
> # both modified:      Data/Vector/Storable.hs
> # both modified:      Data/Vector/Unboxed.hs
> # both modified:      Data/Vector/Unboxed/Base.hs
> # both added:         README.md
> # both modified:      benchmarks/vector-benchmarks.cabal
> # both added:         changelog
> # both modified:      internal/unbox-tuple-instances
> # both modified:      tests/vector-tests.cabal
> # both modified:      vector.cabal
>
>
> I'm curious why these branches have diverged like this, it doesn't smell
> good to me. Does anyone want to tackle doing this merge?
>
> G
> --
> Gregory Collins <greg at gregorycollins.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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140626/6e523422/attachment-0001.html>

From mainland at apeiron.net  Thu Jun 26 15:22:52 2014
From: mainland at apeiron.net (Geoffrey Mainland)
Date: Thu, 26 Jun 2014 11:22:52 -0400
Subject: New version of vector + discussion
In-Reply-To: <CAK-tuPYoekmE6rRz2LCTHQ9UhhMPV2LatC82yhNkr9=NSpp82w@mail.gmail.com>
References: <CAHZrzdrDSAn5kPSB1ryJ9J4ajk14GgZzE6iMphUsLMWWna=mkg@mail.gmail.com>
 <CAK-tuPYoekmE6rRz2LCTHQ9UhhMPV2LatC82yhNkr9=NSpp82w@mail.gmail.com>
Message-ID: <53AC3ACC.4050704@apeiron.net>

Yes. The difficulty is a3a65b56a7d09.

Roman changed the stream representation in vector. These changes were
part of what led to our ICFP paper.

BOS made a giant patch that undid all these changes in the 0.10 branch,
but they lived on in master.

One issue with the change in representation is that they break
compatibility with DPH. I have patches to fix this. However, the change
in representation has not been extensively performance tested, so there
may be performance regressions.

Geoff

On 06/26/2014 11:02 AM, Johan Tibell wrote:
> Geoffrey, you did a bunch of hacking on vector at some point, right?
> Do you have an idea why the branches have diverged?
>
>
> On Thu, Jun 26, 2014 at 4:42 PM, Gregory Collins
> <greg at gregorycollins.net <mailto:greg at gregorycollins.net>> wrote:
>
>     Hi all,
>
>     I've prepped a new minor version (0.10.12.0) of the 0.10 branch of
>     vector so that we can release
>     https://github.com/haskell/vector/pull/31, which I cherry-picked
>     from master. Could someone please review this and do the upload?
>     I'm not sure I have the right bit set.
>
>     Also, in a related topic, an aside: I tried to merge 0.10 into
>     master and got a horrorshow:
>
>         # Unmerged paths:
>         #   (use "git add/rm <file>..." as appropriate to mark resolution)
>         #
>         #both modified:      Data/Vector.hs
>         #deleted by them:    Data/Vector/Fusion/Bundle/Monadic.hs
>         #both modified:      Data/Vector/Fusion/Stream.hs
>         #both modified:      Data/Vector/Fusion/Stream/Monadic.hs
>         #both modified:      Data/Vector/Fusion/Stream/Size.hs
>         #both modified:      Data/Vector/Generic.hs
>         #both modified:      Data/Vector/Generic/Mutable.hs
>         #deleted by them:    Data/Vector/Generic/Mutable/Base.hs
>         #both modified:      Data/Vector/Generic/New.hs
>         #both modified:      Data/Vector/Mutable.hs
>         #both modified:      Data/Vector/Storable.hs
>         #both modified:      Data/Vector/Unboxed.hs
>         #both modified:      Data/Vector/Unboxed/Base.hs
>         #both added:         README.md
>         #both modified:      benchmarks/vector-benchmarks.cabal
>         #both added:         changelog
>         #both modified:      internal/unbox-tuple-instances
>         #both modified:      tests/vector-tests.cabal
>         #both modified:      vector.cabal
>
>
>     I'm curious why these branches have diverged like this, it doesn't
>     smell good to me. Does anyone want to tackle doing this merge?
>
>     G
>     -- 
>     Gregory Collins <greg at gregorycollins.net
>     <mailto:greg at gregorycollins.net>>
>
>     _______________________________________________
>     Libraries mailing list
>     Libraries at haskell.org <mailto:Libraries at haskell.org>
>     http://www.haskell.org/mailman/listinfo/libraries
>
>


From ekmett at gmail.com  Thu Jun 26 15:25:51 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 26 Jun 2014 11:25:51 -0400
Subject: New version of vector + discussion
In-Reply-To: <CAK-tuPZUe40LGGiEOKm8vZ84SufF-OKy-ESY2ibXptpJcBB3KA@mail.gmail.com>
References: <CAHZrzdrDSAn5kPSB1ryJ9J4ajk14GgZzE6iMphUsLMWWna=mkg@mail.gmail.com>
 <8572647A-32BE-45D7-A731-BE5921F470DB@gmail.com>
 <CAK-tuPZUe40LGGiEOKm8vZ84SufF-OKy-ESY2ibXptpJcBB3KA@mail.gmail.com>
Message-ID: <5ADEDAF4-6BF2-480B-B45A-E2A8166935E9@gmail.com>

Maintainership of vector was transferred to the core libraries committee from Geoffrey Mainland; it is listed as such on the Library Submissions page now.

Dan, as the member of the committee most familiar with the vector internals has been actively curating the master branch in preparation for a release. Given the way the last ad hoc release of vector went out and the problems that ensued I'd really appreciate it if he was the one to push any vector releases for now.

He's done a ton of work cleaning it up, and we've already gone behind his back once.

-Edward

> On Jun 26, 2014, at 11:08 AM, Johan Tibell <johan.tibell at gmail.com> wrote:
> 
> Dan, are you maintaining vector now? Do you want yourself listed as the maintainer in the .cabal file (right now it's libraries at haskell.org)?
> 
> 
>> On Thu, Jun 26, 2014 at 5:06 PM, Edward Kmett <ekmett at gmail.com> wrote:
>> _Please_ talk to Dan Doel before another version of vector goes out through back channels as it were.
>> 
>> Sent from my iPhone
>> 
>>> On Jun 26, 2014, at 10:42 AM, Gregory Collins <greg at gregorycollins.net> wrote:
>>> 
>>> Hi all,
>>> 
>>> I've prepped a new minor version (0.10.12.0) of the 0.10 branch of vector so that we can release https://github.com/haskell/vector/pull/31, which I cherry-picked from master. Could someone please review this and do the upload? I'm not sure I have the right bit set.
>>> 
>>> Also, in a related topic, an aside: I tried to merge 0.10 into master and got a horrorshow:
>>> 
>>> # Unmerged paths:
>>> #   (use "git add/rm <file>..." as appropriate to mark resolution)
>>> #
>>> #	both modified:      Data/Vector.hs
>>> #	deleted by them:    Data/Vector/Fusion/Bundle/Monadic.hs
>>> #	both modified:      Data/Vector/Fusion/Stream.hs
>>> #	both modified:      Data/Vector/Fusion/Stream/Monadic.hs
>>> #	both modified:      Data/Vector/Fusion/Stream/Size.hs
>>> #	both modified:      Data/Vector/Generic.hs
>>> #	both modified:      Data/Vector/Generic/Mutable.hs
>>> #	deleted by them:    Data/Vector/Generic/Mutable/Base.hs
>>> #	both modified:      Data/Vector/Generic/New.hs
>>> #	both modified:      Data/Vector/Mutable.hs
>>> #	both modified:      Data/Vector/Storable.hs
>>> #	both modified:      Data/Vector/Unboxed.hs
>>> #	both modified:      Data/Vector/Unboxed/Base.hs
>>> #	both added:         README.md
>>> #	both modified:      benchmarks/vector-benchmarks.cabal
>>> #	both added:         changelog
>>> #	both modified:      internal/unbox-tuple-instances
>>> #	both modified:      tests/vector-tests.cabal
>>> #	both modified:      vector.cabal
>>> 
>>> I'm curious why these branches have diverged like this, it doesn't smell good to me. Does anyone want to tackle doing this merge?
>>> 
>>> G
>>> -- 
>>> Gregory Collins <greg at gregorycollins.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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140626/4788bc22/attachment.html>

From greg at gregorycollins.net  Thu Jun 26 15:54:19 2014
From: greg at gregorycollins.net (Gregory Collins)
Date: Thu, 26 Jun 2014 17:54:19 +0200
Subject: New version of vector + discussion
In-Reply-To: <5ADEDAF4-6BF2-480B-B45A-E2A8166935E9@gmail.com>
References: <CAHZrzdrDSAn5kPSB1ryJ9J4ajk14GgZzE6iMphUsLMWWna=mkg@mail.gmail.com>
 <8572647A-32BE-45D7-A731-BE5921F470DB@gmail.com>
 <CAK-tuPZUe40LGGiEOKm8vZ84SufF-OKy-ESY2ibXptpJcBB3KA@mail.gmail.com>
 <5ADEDAF4-6BF2-480B-B45A-E2A8166935E9@gmail.com>
Message-ID: <CAHZrzdohDTcz80F27tydjX5OPd1F_ZALxbh7JRmT49uJ9Bw+Sg@mail.gmail.com>

On Thu, Jun 26, 2014 at 5:25 PM, Edward Kmett <ekmett at gmail.com> wrote:

> Given the way the last ad hoc release of vector went out and the problems
> that ensued I'd really appreciate it if he was the one to push any vector
> releases for now.
>
> He's done a ton of work cleaning it up, and we've already gone behind his
> back once.
>

Yes I should have not implied with my email that "anybody in particular"
should do the release, as that's not really what I meant -- instead that
whoever has been doing them lately or who had been granted the release bit
should do it. If Dan is going to coordinate or perform releases then we
should make a note of this in the readme so that people know in the future.

In relation to the patch, this particular change has turned out to be more
controversial than I expected so if we follow Johan's proposal by splitting
off a .Internal module then there is work to do still before the release
can be made anyways.

G
-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140626/abd746b9/attachment.html>

From ekmett at gmail.com  Thu Jun 26 17:46:46 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 26 Jun 2014 13:46:46 -0400
Subject: New version of vector + discussion
In-Reply-To: <CAHZrzdohDTcz80F27tydjX5OPd1F_ZALxbh7JRmT49uJ9Bw+Sg@mail.gmail.com>
References: <CAHZrzdrDSAn5kPSB1ryJ9J4ajk14GgZzE6iMphUsLMWWna=mkg@mail.gmail.com>
 <8572647A-32BE-45D7-A731-BE5921F470DB@gmail.com>
 <CAK-tuPZUe40LGGiEOKm8vZ84SufF-OKy-ESY2ibXptpJcBB3KA@mail.gmail.com>
 <5ADEDAF4-6BF2-480B-B45A-E2A8166935E9@gmail.com>
 <CAHZrzdohDTcz80F27tydjX5OPd1F_ZALxbh7JRmT49uJ9Bw+Sg@mail.gmail.com>
Message-ID: <CAJumaK-m3KcXVvAoWV3CRKObGqj6Bevj4iaANOPnnWpGU+xbFQ@mail.gmail.com>

By all means. We're all new to this process. =)

I just wanted to throw up a big red flag and make sure we actually did this
right, especially as the last quickee backport blew up.

The main thing we're trying to do with vector is move to actually following
the libraries@ process like other packages. Folks propose things,
preferably with patches. The maintainer maintains it and ultimately decides
on inclusion, like with everything else in the platform, etc.

Heretofore it has been more or less controlled chaos. That started when the
package slid into community hands when Roman washed his hands of it, but it
has led to the case where master and the stuff in wide use have been
getting farther and farther out of sync.

-Edward


On Thu, Jun 26, 2014 at 11:54 AM, Gregory Collins <greg at gregorycollins.net>
wrote:

>
> On Thu, Jun 26, 2014 at 5:25 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> Given the way the last ad hoc release of vector went out and the problems
>> that ensued I'd really appreciate it if he was the one to push any vector
>> releases for now.
>>
>> He's done a ton of work cleaning it up, and we've already gone behind his
>> back once.
>>
>
> Yes I should have not implied with my email that "anybody in particular"
> should do the release, as that's not really what I meant -- instead that
> whoever has been doing them lately or who had been granted the release bit
> should do it. If Dan is going to coordinate or perform releases then we
> should make a note of this in the readme so that people know in the future.
>
> In relation to the patch, this particular change has turned out to be more
> controversial than I expected so if we follow Johan's proposal by splitting
> off a .Internal module then there is work to do still before the release
> can be made anyways.
>
>
> G
> --
> Gregory Collins <greg at gregorycollins.net>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140626/95be0085/attachment-0001.html>

From greg at gregorycollins.net  Thu Jun 26 18:17:14 2014
From: greg at gregorycollins.net (Gregory Collins)
Date: Thu, 26 Jun 2014 20:17:14 +0200
Subject: New version of vector + discussion
In-Reply-To: <CAJumaK-m3KcXVvAoWV3CRKObGqj6Bevj4iaANOPnnWpGU+xbFQ@mail.gmail.com>
References: <CAHZrzdrDSAn5kPSB1ryJ9J4ajk14GgZzE6iMphUsLMWWna=mkg@mail.gmail.com>
 <8572647A-32BE-45D7-A731-BE5921F470DB@gmail.com>
 <CAK-tuPZUe40LGGiEOKm8vZ84SufF-OKy-ESY2ibXptpJcBB3KA@mail.gmail.com>
 <5ADEDAF4-6BF2-480B-B45A-E2A8166935E9@gmail.com>
 <CAHZrzdohDTcz80F27tydjX5OPd1F_ZALxbh7JRmT49uJ9Bw+Sg@mail.gmail.com>
 <CAJumaK-m3KcXVvAoWV3CRKObGqj6Bevj4iaANOPnnWpGU+xbFQ@mail.gmail.com>
Message-ID: <CAHZrzdpkY2pUxaRLkZ01SgdrepfJhuPasgJMPh4LKsN8gJ2UYw@mail.gmail.com>

On Thu, Jun 26, 2014 at 7:46 PM, Edward Kmett <ekmett at gmail.com> wrote:

> Heretofore it has been more or less controlled chaos. That started when
> the package slid into community hands when Roman washed his hands of it,
> but it has led to the case where master and the stuff in wide use have been
> getting farther and farther out of sync.


Some of the libraries packages are quite actively being looked at by
people, and others...not so much. A common scenario for pull requests to
libraries packages is that they languish, untouched, for ages. Is anyone
looking at the pull requests that have been coming in for X11, to give one
example?

My reaction to this scenario is that I subscribe to the notification stream
and if pull requests come across that look relatively uncontroversial, I
review and merge them, just to keep the peanuts rolling along. If,
sometimes, like in this instance, we might have to go back and do a little
bit of work to fix things up afterwards, because two steps forward and one
back is better than nothing happening at all.

Of course, sometimes when you go and do this, someone is actually actively
tending to the repository in question, in which case we need to get a
reminder of this put in the project's README. In general, as you noted,
releases have been a little bit of a free-for-all lately (that's what you
get with conscript labor) and maybe every repo libraries@ maintains should
either have a dedicated release person or release instructions for
community contributors in the readme.

I also don't think that the full review process is necessarily right for
every patch, although clearly this one should have stewed longer in
discussion before being merged. Mea culpa.

G
-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140626/32e4d614/attachment.html>

From ekmett at gmail.com  Thu Jun 26 18:31:03 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 26 Jun 2014 14:31:03 -0400
Subject: New version of vector + discussion
In-Reply-To: <CAHZrzdpkY2pUxaRLkZ01SgdrepfJhuPasgJMPh4LKsN8gJ2UYw@mail.gmail.com>
References: <CAHZrzdrDSAn5kPSB1ryJ9J4ajk14GgZzE6iMphUsLMWWna=mkg@mail.gmail.com>
 <8572647A-32BE-45D7-A731-BE5921F470DB@gmail.com>
 <CAK-tuPZUe40LGGiEOKm8vZ84SufF-OKy-ESY2ibXptpJcBB3KA@mail.gmail.com>
 <5ADEDAF4-6BF2-480B-B45A-E2A8166935E9@gmail.com>
 <CAHZrzdohDTcz80F27tydjX5OPd1F_ZALxbh7JRmT49uJ9Bw+Sg@mail.gmail.com>
 <CAJumaK-m3KcXVvAoWV3CRKObGqj6Bevj4iaANOPnnWpGU+xbFQ@mail.gmail.com>
 <CAHZrzdpkY2pUxaRLkZ01SgdrepfJhuPasgJMPh4LKsN8gJ2UYw@mail.gmail.com>
Message-ID: <CAJumaK-A8dqQhNie0oZRo4jcQ2rZAzYVP50zJTf2eG_q2weu6Q@mail.gmail.com>

Note, X11 isn't formally adopted by anyone under the
http://www.haskell.org/haskellwiki/Library_submissions process and just
lists Daniel Wagner as the maintainer.

I'm very much not trying to quell progress, just trying to make sure we
have some kind of arbiter of what is happening in the end.

-Edward


On Thu, Jun 26, 2014 at 2:17 PM, Gregory Collins <greg at gregorycollins.net>
wrote:

>
> On Thu, Jun 26, 2014 at 7:46 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> Heretofore it has been more or less controlled chaos. That started when
>> the package slid into community hands when Roman washed his hands of it,
>> but it has led to the case where master and the stuff in wide use have been
>> getting farther and farther out of sync.
>
>
> Some of the libraries packages are quite actively being looked at by
> people, and others...not so much. A common scenario for pull requests to
> libraries packages is that they languish, untouched, for ages. Is anyone
> looking at the pull requests that have been coming in for X11, to give one
> example?
>
> My reaction to this scenario is that I subscribe to the notification
> stream and if pull requests come across that look relatively
> uncontroversial, I review and merge them, just to keep the peanuts rolling
> along. If, sometimes, like in this instance, we might have to go back and
> do a little bit of work to fix things up afterwards, because two steps
> forward and one back is better than nothing happening at all.
>
> Of course, sometimes when you go and do this, someone is actually actively
> tending to the repository in question, in which case we need to get a
> reminder of this put in the project's README. In general, as you noted,
> releases have been a little bit of a free-for-all lately (that's what you
> get with conscript labor) and maybe every repo libraries@ maintains
> should either have a dedicated release person or release instructions for
> community contributors in the readme.
>
> I also don't think that the full review process is necessarily right for
> every patch, although clearly this one should have stewed longer in
> discussion before being merged. Mea culpa.
>
> G
> --
> Gregory Collins <greg at gregorycollins.net>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140626/eb04b49e/attachment.html>

From omari at smileystation.com  Sat Jun 28 15:30:21 2014
From: omari at smileystation.com (Omari Norman)
Date: Sat, 28 Jun 2014 11:30:21 -0400
Subject: Add instances for Functor, Monad, Applicative to Data.Monoid.First,
 Last
Message-ID: <CA+aFgYB6ZBH=OSQp6EKq1WAc7mUmO8k0XV==w3RJgwzNfp+Pgg@mail.gmail.com>

This was proposed in 2011:

http://www.haskell.org/pipermail/libraries/2011-January/015552.html

Any reason it did not go anywhere? Should I propose it again?

Thanks.
Omari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140628/fd38c530/attachment.html>

From ekmett at gmail.com  Sat Jun 28 17:17:01 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 28 Jun 2014 13:17:01 -0400
Subject: Add instances for Functor, Monad, Applicative to
 Data.Monoid.First, Last
In-Reply-To: <CA+aFgYB6ZBH=OSQp6EKq1WAc7mUmO8k0XV==w3RJgwzNfp+Pgg@mail.gmail.com>
References: <CA+aFgYB6ZBH=OSQp6EKq1WAc7mUmO8k0XV==w3RJgwzNfp+Pgg@mail.gmail.com>
Message-ID: <CAJumaK8sZgmRMECB7_P3Ec-pcA8X7t9HYcoE1bVYTwuxRvGnYw@mail.gmail.com>

This proposal made it through its discussion period without adverse
commentary; no real need to go through it all again.

I'd say we should just act upon it. At this point what it needs is a patch.

The core libraries committee has recently approved a similar raft of
missing instances for GHC.Generics.

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

The general guiding principle is that if there is only one canonical
instance for something that can exist then it should exist. The
alternatives forces people to write orphans that will collide across
projects.

-Edward


On Sat, Jun 28, 2014 at 11:30 AM, Omari Norman <omari at smileystation.com>
wrote:

> This was proposed in 2011:
>
> http://www.haskell.org/pipermail/libraries/2011-January/015552.html
>
> Any reason it did not go anywhere? Should I propose it again?
>
> Thanks.
> Omari
>
> _______________________________________________
> 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/20140628/1db23da5/attachment.html>

From bgamari.foss at gmail.com  Sat Jun 28 17:58:35 2014
From: bgamari.foss at gmail.com (Ben Gamari)
Date: Sat, 28 Jun 2014 13:58:35 -0400
Subject: Add instances for Functor, Monad, Applicative to Data.Monoid.First,
 Last
In-Reply-To: <id:CAJumaK8sZgmRMECB7_P3Ec-pcA8X7t9HYcoE1bVYTwuxRvGnYw@mail.gmail.com>
References: <id:CAJumaK8sZgmRMECB7_P3Ec-pcA8X7t9HYcoE1bVYTwuxRvGnYw@mail.gmail.com>
Message-ID: <1403978316-4056-1-git-send-email-bgamari.foss@gmail.com>


Edward Kmett wrote,
> I'd say we should just act upon it. At this point what it needs is a patch.
> 
You mean like this one against GHC master?

Cheers,

- Ben


From bgamari.foss at gmail.com  Sat Jun 28 17:58:36 2014
From: bgamari.foss at gmail.com (Ben Gamari)
Date: Sat, 28 Jun 2014 13:58:36 -0400
Subject: [PATCH] Add Functor, Applicative, Monad instances for First, Last
In-Reply-To: <1403978316-4056-1-git-send-email-bgamari.foss@gmail.com>
References: <id:CAJumaK8sZgmRMECB7_P3Ec-pcA8X7t9HYcoE1bVYTwuxRvGnYw@mail.gmail.com>
 <1403978316-4056-1-git-send-email-bgamari.foss@gmail.com>
Message-ID: <1403978316-4056-2-git-send-email-bgamari.foss@gmail.com>

This was proposed in 2011 [1] with no serious objections although wasn't
implemented until it was again mentioned in 2014 [2].

[1] http://www.haskell.org/pipermail/libraries/2011-January/015552.html
[2] http://www.haskell.org/pipermail/libraries/2014-June/023228.html
---
 libraries/base/Control/Applicative.hs | 11 ++++++++++-
 libraries/base/Data/Monoid.hs         | 14 ++++++++++++++
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/libraries/base/Control/Applicative.hs b/libraries/base/Control/Applicative.hs
index 4e77479..81ce513 100644
--- a/libraries/base/Control/Applicative.hs
+++ b/libraries/base/Control/Applicative.hs
@@ -54,7 +54,7 @@ import Control.Monad (liftM, ap, MonadPlus(..))
 import Control.Monad.ST.Safe (ST)
 import qualified Control.Monad.ST.Lazy.Safe as Lazy (ST)
 import Data.Functor ((<$>), (<$))
-import Data.Monoid (Monoid(..))
+import Data.Monoid (Monoid(..), First(..), Last(..))
 import Data.Proxy
 
 import Text.ParserCombinators.ReadP (ReadP)
@@ -281,6 +281,15 @@ instance (ArrowZero a, ArrowPlus a) => Alternative (WrappedArrow a b) where
     empty = WrapArrow zeroArrow
     WrapArrow u <|> WrapArrow v = WrapArrow (u <+> v)
 
+-- Added in base-4.8.0.0
+instance Applicative First where
+        pure x = First (Just x)
+        First x <*> First y = First (x <*> y)
+
+instance Applicative Last where
+        pure x = Last (Just x)
+        Last x <*> Last y = Last (x <*> y)
+
 -- | Lists, but with an 'Applicative' functor based on zipping, so that
 --
 -- @f '<$>' 'ZipList' xs1 '<*>' ... '<*>' 'ZipList' xsn = 'ZipList' (zipWithn f xs1 ... xsn)@
diff --git a/libraries/base/Data/Monoid.hs b/libraries/base/Data/Monoid.hs
index b71176b..bb87243 100644
--- a/libraries/base/Data/Monoid.hs
+++ b/libraries/base/Data/Monoid.hs
@@ -251,6 +251,13 @@ instance Monoid (First a) where
         r@(First (Just _)) `mappend` _ = r
         First Nothing `mappend` r = r
 
+instance Functor First where
+        fmap f (First x) = First (fmap f x)
+
+instance Monad First where
+        return x = First (Just x)
+        First x >>= m = First (x >>= getFirst . m)
+
 -- | Maybe monoid returning the rightmost non-Nothing value.
 newtype Last a = Last { getLast :: Maybe a }
         deriving (Eq, Ord, Read, Show, Generic, Generic1)
@@ -260,6 +267,13 @@ instance Monoid (Last a) where
         _ `mappend` r@(Last (Just _)) = r
         r `mappend` Last Nothing = r
 
+instance Functor Last where
+        fmap f (Last x) = Last (fmap f x)
+
+instance Monad Last where
+        return x = Last (Just x)
+        Last x >>= m = Last (x >>= getLast . m)
+
 {-
 {--------------------------------------------------------------------
   Testing
-- 
1.9.1


From ekmett at gmail.com  Sat Jun 28 18:00:50 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 28 Jun 2014 14:00:50 -0400
Subject: [PATCH] Add Functor, Applicative, Monad instances for First, Last
In-Reply-To: <1403978316-4056-2-git-send-email-bgamari.foss@gmail.com>
References: <1403978316-4056-1-git-send-email-bgamari.foss@gmail.com>
 <1403978316-4056-2-git-send-email-bgamari.foss@gmail.com>
Message-ID: <CAJumaK96V7rUNYbJHbyRf3TjDFVeOjkQLea5DX7494oVxX8LYQ@mail.gmail.com>

Looks good to me.

-Edward


On Sat, Jun 28, 2014 at 1:58 PM, Ben Gamari <bgamari.foss at gmail.com> wrote:

> This was proposed in 2011 [1] with no serious objections although wasn't
> implemented until it was again mentioned in 2014 [2].
>
> [1] http://www.haskell.org/pipermail/libraries/2011-January/015552.html
> [2] http://www.haskell.org/pipermail/libraries/2014-June/023228.html
> ---
>  libraries/base/Control/Applicative.hs | 11 ++++++++++-
>  libraries/base/Data/Monoid.hs         | 14 ++++++++++++++
>  2 files changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/libraries/base/Control/Applicative.hs
> b/libraries/base/Control/Applicative.hs
> index 4e77479..81ce513 100644
> --- a/libraries/base/Control/Applicative.hs
> +++ b/libraries/base/Control/Applicative.hs
> @@ -54,7 +54,7 @@ import Control.Monad (liftM, ap, MonadPlus(..))
>  import Control.Monad.ST.Safe (ST)
>  import qualified Control.Monad.ST.Lazy.Safe as Lazy (ST)
>  import Data.Functor ((<$>), (<$))
> -import Data.Monoid (Monoid(..))
> +import Data.Monoid (Monoid(..), First(..), Last(..))
>  import Data.Proxy
>
>  import Text.ParserCombinators.ReadP (ReadP)
> @@ -281,6 +281,15 @@ instance (ArrowZero a, ArrowPlus a) => Alternative
> (WrappedArrow a b) where
>      empty = WrapArrow zeroArrow
>      WrapArrow u <|> WrapArrow v = WrapArrow (u <+> v)
>
> +-- Added in base-4.8.0.0
> +instance Applicative First where
> +        pure x = First (Just x)
> +        First x <*> First y = First (x <*> y)
> +
> +instance Applicative Last where
> +        pure x = Last (Just x)
> +        Last x <*> Last y = Last (x <*> y)
> +
>  -- | Lists, but with an 'Applicative' functor based on zipping, so that
>  --
>  -- @f '<$>' 'ZipList' xs1 '<*>' ... '<*>' 'ZipList' xsn = 'ZipList'
> (zipWithn f xs1 ... xsn)@
> diff --git a/libraries/base/Data/Monoid.hs b/libraries/base/Data/Monoid.hs
> index b71176b..bb87243 100644
> --- a/libraries/base/Data/Monoid.hs
> +++ b/libraries/base/Data/Monoid.hs
> @@ -251,6 +251,13 @@ instance Monoid (First a) where
>          r@(First (Just _)) `mappend` _ = r
>          First Nothing `mappend` r = r
>
> +instance Functor First where
> +        fmap f (First x) = First (fmap f x)
> +
> +instance Monad First where
> +        return x = First (Just x)
> +        First x >>= m = First (x >>= getFirst . m)
> +
>  -- | Maybe monoid returning the rightmost non-Nothing value.
>  newtype Last a = Last { getLast :: Maybe a }
>          deriving (Eq, Ord, Read, Show, Generic, Generic1)
> @@ -260,6 +267,13 @@ instance Monoid (Last a) where
>          _ `mappend` r@(Last (Just _)) = r
>          r `mappend` Last Nothing = r
>
> +instance Functor Last where
> +        fmap f (Last x) = Last (fmap f x)
> +
> +instance Monad Last where
> +        return x = Last (Just x)
> +        Last x >>= m = Last (x >>= getLast . m)
> +
>  {-
>  {--------------------------------------------------------------------
>    Testing
> --
> 1.9.1
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140628/5701a6a6/attachment.html>

From michael at snoyman.com  Sun Jun 29 16:30:06 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Sun, 29 Jun 2014 19:30:06 +0300
Subject: [Haskell-cafe] Requesting maintainership: bzlib-conduit and
 process-conduit
In-Reply-To: <53B03AE4.8090906@fuuzetsu.co.uk>
References: <CAKA2JgJ7YhAk4K7fkMD5CvPy_Xg5eOWhLrdEfLxkJeP70nKcaA@mail.gmail.com>
 <53B03AE4.8090906@fuuzetsu.co.uk>
Message-ID: <CAKA2JgLuz5CAkvicG6HY-eeoCtfkHj2qN=f=fZ1Dug+YNi-qOw@mail.gmail.com>

Oops, you're right. I've added libraries@ to the CC list.


On Sun, Jun 29, 2014 at 7:12 PM, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk>
wrote:

> On 06/29/2014 06:02 PM, Michael Snoyman wrote:
> > I'd like to request to be granted maintainership of two conduit-related
> > packages: bzlib-conduit and process-conduit. Both packages are maintained
> > by the same author. I opened up a pull request[1] on bzlib-conduit back
> in
> > January, and haven't heard back yet. There's also an issue with
> > process-conduit[2] which I'd like to address, but given the lack of
> > response of bzlib-conduit, haven't sent a pull request yet.
> >
> > I also emailed the author directly five days ago regarding the
> > bzlib-conduit pull request, and have not received a response.
> >
> > [1] https://github.com/tanakh/bzlib-conduit/pull/7
> > [2] https://github.com/tanakh/process-conduit/issues/14
> >
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
> Two things:
>
> 1. Does this not need to go on libraries@ instead?
> 2. I happen to know the author is an active Twitter user under the
> ?tanakh?. I will tweet him your e-mail but perhaps it's worth trying
> that method of communication too.
>
> --
> Mateusz K.
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140629/5b7c994c/attachment.html>