From mark.lentczner at gmail.com  Mon Jun  1 04:06:19 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Sun, 31 May 2015 21:06:19 -0700
Subject: Time files... and here's another alpha HP for 7.10
Message-ID: <CAAOoiFaNBDCkS7TyZtv5WJ7m0AhnBHbLObyDnn7r8=8A3EkLHg@mail.gmail.com>

So - I hear from a bird that 7.10.2 might be just around the corner. I'm
getting ahead of the curve!

I just did a fully hermetic and clean build of head of GHC 7.10 branch
(what should become 7.10.2), and then brought HP up-to-date:

   - bootstrapped with 7.10.1 (so hptool needed fixes to build with that)
   - uses latest shake
   - built on a clean Debian Wheezy (7) install, (hence uses glibc 2.13 and
   should also run on Ubuntu 12.04 and later)

The package versions are updated as follows:

Cabal             1.22.2.0   --> 1.22.3.0
cabal-install     1.22.2.0   --> 1.22.4.0

attoparsec        0.12.1.4   --> 0.13.0.0
syb               0.4.4      --> 0.5.1
text              1.2.0.4    --> 1.2.1.1

cgi               3001.2.2.1 --> 3001.2.2.2
network           2.6.0.2    --> 2.6.2.0
network-uri       2.6.0.1    --> 2.6.0.3

QuickCheck        2.8        --> 2.8.1
hscolour          1.22       --> 1.23

GLUT              2.7.0.0    --> 2.7.0.1
GLURaw            1.5.0.0    --> 1.5.0.1
OpenGL            2.12.0.0   --> 2.12.0.1
OpenGLRaw         2.4.1.0    --> 2.5.0.0

Only package issue was:

zlib              0.5.4.2
   -- held back because cabal-install needs < 0.6


All the same caveats and notes from Alpha 2 still apply.
All these changes are in the pre-release-2 branch on github -- I'll merge
it all together later this week.
There is a hp-bindist-tarball on my server:

haskell-platform-7.10.1.20150528-x86_64-unknown-linux-deb7.tar.gz
<http://www.ozonehouse.com/mark/platform/haskell-platform-7.10.1.20150528-x86_64-unknown-linux-deb7.tar.gz>
SHA-256: b503c9e2c34c0865b5fee39444027667bb39b786fa7664029287e3bbf33379da


I'll build and put up OS X version in a day or two.

One last thing... I'm proposing that we name this release:  Haskell
Platform 7.10.2 !

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150531/f1adb7da/attachment.html>

From mail at joachim-breitner.de  Mon Jun  1 11:25:20 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 01 Jun 2015 13:25:20 +0200
Subject: Travis builds failing
In-Reply-To: <CANma=H9mi_g091LeUn0u4ZZb7Fn3Nj0fCmmwM6AREbS+WNEFkA@mail.gmail.com>
References: <1432860362-sup-2108@sabre>
 <1432932170.2126.5.camel@joachim-breitner.de>
 <CANma=H9PRG9Yn9j=X6MKMddrGaOB_hSQcEuEMOaP-EtXgTFbwg@mail.gmail.com>
 <CANma=H9mi_g091LeUn0u4ZZb7Fn3Nj0fCmmwM6AREbS+WNEFkA@mail.gmail.com>
Message-ID: <1433157920.1317.9.camel@joachim-breitner.de>

Hi,

yay, travis is green again. Thanks to Alan for fixing this.

Greetings,
Joachim
-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150601/3fb62f2d/attachment.sig>

From alan.zimm at gmail.com  Mon Jun  1 11:44:45 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Mon, 1 Jun 2015 13:44:45 +0200
Subject: Travis builds failing
In-Reply-To: <1433157920.1317.9.camel@joachim-breitner.de>
References: <1432860362-sup-2108@sabre>
 <1432932170.2126.5.camel@joachim-breitner.de>
 <CANma=H9PRG9Yn9j=X6MKMddrGaOB_hSQcEuEMOaP-EtXgTFbwg@mail.gmail.com>
 <CANma=H9mi_g091LeUn0u4ZZb7Fn3Nj0fCmmwM6AREbS+WNEFkA@mail.gmail.com>
 <1433157920.1317.9.camel@joachim-breitner.de>
Message-ID: <CANma=H9AZ012xDX0LeJ_cMeecU3L7pgBTkasg5H+0kd=KHyj_A@mail.gmail.com>

With a lot of help from @thomie ..

On Mon, Jun 1, 2015 at 1:25 PM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> yay, travis is green again. Thanks to Alan for fixing this.
>
> Greetings,
> Joachim
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150601/2f2acbcd/attachment.html>

From mail at joachim-breitner.de  Mon Jun  1 18:22:43 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 01 Jun 2015 20:22:43 +0200
Subject: Travis builds failing
In-Reply-To: <CANma=H9AZ012xDX0LeJ_cMeecU3L7pgBTkasg5H+0kd=KHyj_A@mail.gmail.com>
References: <1432860362-sup-2108@sabre>
 <1432932170.2126.5.camel@joachim-breitner.de>
 <CANma=H9PRG9Yn9j=X6MKMddrGaOB_hSQcEuEMOaP-EtXgTFbwg@mail.gmail.com>
 <CANma=H9mi_g091LeUn0u4ZZb7Fn3Nj0fCmmwM6AREbS+WNEFkA@mail.gmail.com>
 <1433157920.1317.9.camel@joachim-breitner.de>
 <CANma=H9AZ012xDX0LeJ_cMeecU3L7pgBTkasg5H+0kd=KHyj_A@mail.gmail.com>
Message-ID: <1433182963.19557.9.camel@joachim-breitner.de>

Hi,
        

Am Montag, den 01.06.2015, 13:44 +0200 schrieb Alan & Kim Zimmerman:
> On Mon, Jun 1, 2015 at 1:25 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> yay, travis is green again. Thanks to Alan for fixing this.

> With a lot of help from @thomie ..


hmm, looks like it is not fixed after all:

Unexpected failures:
   ghc-api                       T6145 [bad exit code] (normal)
   ghc-api                       T8628 [bad exit code] (normal)
   ghc-api                       T8639_api [bad exit code] (normal)
   ghc-api/annotations           T10278 [bad exit code] (normal)
   ghc-api/annotations           T10313 [bad exit code] (normal)
   ghc-api/annotations           T10354 [bad exit code] (normal)
   ghc-api/annotations           T10396 [bad exit code] (normal)
   ghc-api/annotations           T10399 [bad exit code] (normal)
   ghc-api/annotations           boolFormula [bad exit code] (normal)
   ghc-api/annotations-literals  parsed [bad exit code] (normal)


https://s3.amazonaws.com/archive.travis-ci.org/jobs/64945879/log.txt

Greetings,
Joachim
-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150601/d0c106ce/attachment.sig>

From alan.zimm at gmail.com  Mon Jun  1 18:30:42 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Mon, 1 Jun 2015 20:30:42 +0200
Subject: Travis builds failing
In-Reply-To: <1433182963.19557.9.camel@joachim-breitner.de>
References: <1432860362-sup-2108@sabre>
 <1432932170.2126.5.camel@joachim-breitner.de>
 <CANma=H9PRG9Yn9j=X6MKMddrGaOB_hSQcEuEMOaP-EtXgTFbwg@mail.gmail.com>
 <CANma=H9mi_g091LeUn0u4ZZb7Fn3Nj0fCmmwM6AREbS+WNEFkA@mail.gmail.com>
 <1433157920.1317.9.camel@joachim-breitner.de>
 <CANma=H9AZ012xDX0LeJ_cMeecU3L7pgBTkasg5H+0kd=KHyj_A@mail.gmail.com>
 <1433182963.19557.9.camel@joachim-breitner.de>
Message-ID: <CANma=H8dFRxSfTR-TiDai=Tdea5WLHJ+JnnAkeguOw1dHn_rHg@mail.gmail.com>

I suspect this is different, I am building a local master now, at current
HEAD a27fb46ff1ea46a45e0084c3db92a24475e3bab5 to see what I find.

Alan

On Mon, Jun 1, 2015 at 8:22 PM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
>
> Am Montag, den 01.06.2015, 13:44 +0200 schrieb Alan & Kim Zimmerman:
> > On Mon, Jun 1, 2015 at 1:25 PM, Joachim Breitner <
> mail at joachim-breitner.de> wrote:
> > yay, travis is green again. Thanks to Alan for fixing this.
>
> > With a lot of help from @thomie ..
>
>
> hmm, looks like it is not fixed after all:
>
> Unexpected failures:
>    ghc-api                       T6145 [bad exit code] (normal)
>    ghc-api                       T8628 [bad exit code] (normal)
>    ghc-api                       T8639_api [bad exit code] (normal)
>    ghc-api/annotations           T10278 [bad exit code] (normal)
>    ghc-api/annotations           T10313 [bad exit code] (normal)
>    ghc-api/annotations           T10354 [bad exit code] (normal)
>    ghc-api/annotations           T10396 [bad exit code] (normal)
>    ghc-api/annotations           T10399 [bad exit code] (normal)
>    ghc-api/annotations           boolFormula [bad exit code] (normal)
>    ghc-api/annotations-literals  parsed [bad exit code] (normal)
>
>
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/64945879/log.txt
>
> Greetings,
> Joachim
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150601/691f4195/attachment.html>

From austin at well-typed.com  Mon Jun  1 19:16:57 2015
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 1 Jun 2015 14:16:57 -0500
Subject: Travis builds failing
In-Reply-To: <CANma=H8dFRxSfTR-TiDai=Tdea5WLHJ+JnnAkeguOw1dHn_rHg@mail.gmail.com>
References: <1432860362-sup-2108@sabre>
 <1432932170.2126.5.camel@joachim-breitner.de>
 <CANma=H9PRG9Yn9j=X6MKMddrGaOB_hSQcEuEMOaP-EtXgTFbwg@mail.gmail.com>
 <CANma=H9mi_g091LeUn0u4ZZb7Fn3Nj0fCmmwM6AREbS+WNEFkA@mail.gmail.com>
 <1433157920.1317.9.camel@joachim-breitner.de>
 <CANma=H9AZ012xDX0LeJ_cMeecU3L7pgBTkasg5H+0kd=KHyj_A@mail.gmail.com>
 <1433182963.19557.9.camel@joachim-breitner.de>
 <CANma=H8dFRxSfTR-TiDai=Tdea5WLHJ+JnnAkeguOw1dHn_rHg@mail.gmail.com>
Message-ID: <CAEs96n3r4X6yiLNhLaxBjHqGYHOfBLU=x0vhmVVCYpt9NuvffQ@mail.gmail.com>

Looks like:

collect2: ld terminated with signal 9 [Killed]

which I'd say with fair certainty means that the jobs failed because
the linker ran out of memory on Travis, and the OOM killed it. So,
that's a thing now.

Perhaps for travis builds, we could disable SplitObjs by default to
relieve the memory pressure? I'm not sure if it's on during Travis's
builds, but it's a thought.

On Mon, Jun 1, 2015 at 1:30 PM, Alan & Kim Zimmerman
<alan.zimm at gmail.com> wrote:
> I suspect this is different, I am building a local master now, at current
> HEAD a27fb46ff1ea46a45e0084c3db92a24475e3bab5 to see what I find.
>
> Alan
>
> On Mon, Jun 1, 2015 at 8:22 PM, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>>
>> Hi,
>>
>>
>> Am Montag, den 01.06.2015, 13:44 +0200 schrieb Alan & Kim Zimmerman:
>> > On Mon, Jun 1, 2015 at 1:25 PM, Joachim Breitner
>> > <mail at joachim-breitner.de> wrote:
>> > yay, travis is green again. Thanks to Alan for fixing this.
>>
>> > With a lot of help from @thomie ..
>>
>>
>> hmm, looks like it is not fixed after all:
>>
>> Unexpected failures:
>>    ghc-api                       T6145 [bad exit code] (normal)
>>    ghc-api                       T8628 [bad exit code] (normal)
>>    ghc-api                       T8639_api [bad exit code] (normal)
>>    ghc-api/annotations           T10278 [bad exit code] (normal)
>>    ghc-api/annotations           T10313 [bad exit code] (normal)
>>    ghc-api/annotations           T10354 [bad exit code] (normal)
>>    ghc-api/annotations           T10396 [bad exit code] (normal)
>>    ghc-api/annotations           T10399 [bad exit code] (normal)
>>    ghc-api/annotations           boolFormula [bad exit code] (normal)
>>    ghc-api/annotations-literals  parsed [bad exit code] (normal)
>>
>>
>> https://s3.amazonaws.com/archive.travis-ci.org/jobs/64945879/log.txt
>>
>> Greetings,
>> Joachim
>> --
>> Joachim ?nomeata? Breitner
>>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>>   Debian Developer: nomeata at debian.org
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Regards,

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

From alan.zimm at gmail.com  Mon Jun  1 19:23:01 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Mon, 1 Jun 2015 21:23:01 +0200
Subject: Travis builds failing
In-Reply-To: <CAEs96n3r4X6yiLNhLaxBjHqGYHOfBLU=x0vhmVVCYpt9NuvffQ@mail.gmail.com>
References: <1432860362-sup-2108@sabre>
 <1432932170.2126.5.camel@joachim-breitner.de>
 <CANma=H9PRG9Yn9j=X6MKMddrGaOB_hSQcEuEMOaP-EtXgTFbwg@mail.gmail.com>
 <CANma=H9mi_g091LeUn0u4ZZb7Fn3Nj0fCmmwM6AREbS+WNEFkA@mail.gmail.com>
 <1433157920.1317.9.camel@joachim-breitner.de>
 <CANma=H9AZ012xDX0LeJ_cMeecU3L7pgBTkasg5H+0kd=KHyj_A@mail.gmail.com>
 <1433182963.19557.9.camel@joachim-breitner.de>
 <CANma=H8dFRxSfTR-TiDai=Tdea5WLHJ+JnnAkeguOw1dHn_rHg@mail.gmail.com>
 <CAEs96n3r4X6yiLNhLaxBjHqGYHOfBLU=x0vhmVVCYpt9NuvffQ@mail.gmail.com>
Message-ID: <CANma=H9euhQPQx-mVKJYcZ62wuW+92R8gsEv0Dxn0uD=jDVwDQ@mail.gmail.com>

Is is possible to limit the number of concurrent tests? Instead of running
on all available cores.

On Mon, Jun 1, 2015 at 9:16 PM, Austin Seipp <austin at well-typed.com> wrote:

> Looks like:
>
> collect2: ld terminated with signal 9 [Killed]
>
> which I'd say with fair certainty means that the jobs failed because
> the linker ran out of memory on Travis, and the OOM killed it. So,
> that's a thing now.
>
> Perhaps for travis builds, we could disable SplitObjs by default to
> relieve the memory pressure? I'm not sure if it's on during Travis's
> builds, but it's a thought.
>
> On Mon, Jun 1, 2015 at 1:30 PM, Alan & Kim Zimmerman
> <alan.zimm at gmail.com> wrote:
> > I suspect this is different, I am building a local master now, at current
> > HEAD a27fb46ff1ea46a45e0084c3db92a24475e3bab5 to see what I find.
> >
> > Alan
> >
> > On Mon, Jun 1, 2015 at 8:22 PM, Joachim Breitner <
> mail at joachim-breitner.de>
> > wrote:
> >>
> >> Hi,
> >>
> >>
> >> Am Montag, den 01.06.2015, 13:44 +0200 schrieb Alan & Kim Zimmerman:
> >> > On Mon, Jun 1, 2015 at 1:25 PM, Joachim Breitner
> >> > <mail at joachim-breitner.de> wrote:
> >> > yay, travis is green again. Thanks to Alan for fixing this.
> >>
> >> > With a lot of help from @thomie ..
> >>
> >>
> >> hmm, looks like it is not fixed after all:
> >>
> >> Unexpected failures:
> >>    ghc-api                       T6145 [bad exit code] (normal)
> >>    ghc-api                       T8628 [bad exit code] (normal)
> >>    ghc-api                       T8639_api [bad exit code] (normal)
> >>    ghc-api/annotations           T10278 [bad exit code] (normal)
> >>    ghc-api/annotations           T10313 [bad exit code] (normal)
> >>    ghc-api/annotations           T10354 [bad exit code] (normal)
> >>    ghc-api/annotations           T10396 [bad exit code] (normal)
> >>    ghc-api/annotations           T10399 [bad exit code] (normal)
> >>    ghc-api/annotations           boolFormula [bad exit code] (normal)
> >>    ghc-api/annotations-literals  parsed [bad exit code] (normal)
> >>
> >>
> >> https://s3.amazonaws.com/archive.travis-ci.org/jobs/64945879/log.txt
> >>
> >> Greetings,
> >> Joachim
> >> --
> >> Joachim ?nomeata? Breitner
> >>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
> >>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
> >>   Debian Developer: nomeata at debian.org
> >>
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150601/8d74aa2f/attachment.html>

From austin at well-typed.com  Mon Jun  1 19:26:38 2015
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 1 Jun 2015 14:26:38 -0500
Subject: Travis builds failing
In-Reply-To: <CANma=H9euhQPQx-mVKJYcZ62wuW+92R8gsEv0Dxn0uD=jDVwDQ@mail.gmail.com>
References: <1432860362-sup-2108@sabre>
 <1432932170.2126.5.camel@joachim-breitner.de>
 <CANma=H9PRG9Yn9j=X6MKMddrGaOB_hSQcEuEMOaP-EtXgTFbwg@mail.gmail.com>
 <CANma=H9mi_g091LeUn0u4ZZb7Fn3Nj0fCmmwM6AREbS+WNEFkA@mail.gmail.com>
 <1433157920.1317.9.camel@joachim-breitner.de>
 <CANma=H9AZ012xDX0LeJ_cMeecU3L7pgBTkasg5H+0kd=KHyj_A@mail.gmail.com>
 <1433182963.19557.9.camel@joachim-breitner.de>
 <CANma=H8dFRxSfTR-TiDai=Tdea5WLHJ+JnnAkeguOw1dHn_rHg@mail.gmail.com>
 <CAEs96n3r4X6yiLNhLaxBjHqGYHOfBLU=x0vhmVVCYpt9NuvffQ@mail.gmail.com>
 <CANma=H9euhQPQx-mVKJYcZ62wuW+92R8gsEv0Dxn0uD=jDVwDQ@mail.gmail.com>
Message-ID: <CAEs96n1bvdEK42eZCz_RWNbosq4UtQm_HBqsGb5Yf4JREnRYHw@mail.gmail.com>

I don't think there's any built-in way to do that in the current
testsuite infrastructure, other than setting THREADS=1, which, if it
isn't set already, would probably push us back over the Travis build
limit.

I wonder if we could just ask if they'd increase the limit for our project...

On Mon, Jun 1, 2015 at 2:23 PM, Alan & Kim Zimmerman
<alan.zimm at gmail.com> wrote:
> Is is possible to limit the number of concurrent tests? Instead of running
> on all available cores.
>
> On Mon, Jun 1, 2015 at 9:16 PM, Austin Seipp <austin at well-typed.com> wrote:
>>
>> Looks like:
>>
>> collect2: ld terminated with signal 9 [Killed]
>>
>> which I'd say with fair certainty means that the jobs failed because
>> the linker ran out of memory on Travis, and the OOM killed it. So,
>> that's a thing now.
>>
>> Perhaps for travis builds, we could disable SplitObjs by default to
>> relieve the memory pressure? I'm not sure if it's on during Travis's
>> builds, but it's a thought.
>>
>> On Mon, Jun 1, 2015 at 1:30 PM, Alan & Kim Zimmerman
>> <alan.zimm at gmail.com> wrote:
>> > I suspect this is different, I am building a local master now, at
>> > current
>> > HEAD a27fb46ff1ea46a45e0084c3db92a24475e3bab5 to see what I find.
>> >
>> > Alan
>> >
>> > On Mon, Jun 1, 2015 at 8:22 PM, Joachim Breitner
>> > <mail at joachim-breitner.de>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >>
>> >> Am Montag, den 01.06.2015, 13:44 +0200 schrieb Alan & Kim Zimmerman:
>> >> > On Mon, Jun 1, 2015 at 1:25 PM, Joachim Breitner
>> >> > <mail at joachim-breitner.de> wrote:
>> >> > yay, travis is green again. Thanks to Alan for fixing this.
>> >>
>> >> > With a lot of help from @thomie ..
>> >>
>> >>
>> >> hmm, looks like it is not fixed after all:
>> >>
>> >> Unexpected failures:
>> >>    ghc-api                       T6145 [bad exit code] (normal)
>> >>    ghc-api                       T8628 [bad exit code] (normal)
>> >>    ghc-api                       T8639_api [bad exit code] (normal)
>> >>    ghc-api/annotations           T10278 [bad exit code] (normal)
>> >>    ghc-api/annotations           T10313 [bad exit code] (normal)
>> >>    ghc-api/annotations           T10354 [bad exit code] (normal)
>> >>    ghc-api/annotations           T10396 [bad exit code] (normal)
>> >>    ghc-api/annotations           T10399 [bad exit code] (normal)
>> >>    ghc-api/annotations           boolFormula [bad exit code] (normal)
>> >>    ghc-api/annotations-literals  parsed [bad exit code] (normal)
>> >>
>> >>
>> >> https://s3.amazonaws.com/archive.travis-ci.org/jobs/64945879/log.txt
>> >>
>> >> Greetings,
>> >> Joachim
>> >> --
>> >> Joachim ?nomeata? Breitner
>> >>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>> >>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>> >>   Debian Developer: nomeata at debian.org
>> >>
>> >> _______________________________________________
>> >> ghc-devs mailing list
>> >> ghc-devs at haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >>
>> >
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >
>>
>>
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>
>



-- 
Regards,

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

From mail at joachim-breitner.de  Mon Jun  1 19:34:37 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 01 Jun 2015 21:34:37 +0200
Subject: Travis builds failing
In-Reply-To: <CAEs96n1bvdEK42eZCz_RWNbosq4UtQm_HBqsGb5Yf4JREnRYHw@mail.gmail.com>
References: <1432860362-sup-2108@sabre>
 <1432932170.2126.5.camel@joachim-breitner.de>
 <CANma=H9PRG9Yn9j=X6MKMddrGaOB_hSQcEuEMOaP-EtXgTFbwg@mail.gmail.com>
 <CANma=H9mi_g091LeUn0u4ZZb7Fn3Nj0fCmmwM6AREbS+WNEFkA@mail.gmail.com>
 <1433157920.1317.9.camel@joachim-breitner.de>
 <CANma=H9AZ012xDX0LeJ_cMeecU3L7pgBTkasg5H+0kd=KHyj_A@mail.gmail.com>
 <1433182963.19557.9.camel@joachim-breitner.de>
 <CANma=H8dFRxSfTR-TiDai=Tdea5WLHJ+JnnAkeguOw1dHn_rHg@mail.gmail.com>
 <CAEs96n3r4X6yiLNhLaxBjHqGYHOfBLU=x0vhmVVCYpt9NuvffQ@mail.gmail.com>
 <CANma=H9euhQPQx-mVKJYcZ62wuW+92R8gsEv0Dxn0uD=jDVwDQ@mail.gmail.com>
 <CAEs96n1bvdEK42eZCz_RWNbosq4UtQm_HBqsGb5Yf4JREnRYHw@mail.gmail.com>
Message-ID: <1433187277.11290.1.camel@joachim-breitner.de>

Hi,

Am Montag, den 01.06.2015, 14:26 -0500 schrieb Austin Seipp:
> I don't think there's any built-in way to do that in the current
> testsuite infrastructure, other than setting THREADS=1, which, if it
> isn't set already, would probably push us back over the Travis build
> limit.

we are running validate with CPU=2, which I believe translates to
THREADS=1.

But we never had memory problems before, and 3GB is still quite a bit.
Are we sure that there is no bug here? Or is our official requirement
now above 3GB?

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150601/ad6727c9/attachment.sig>

From austin at well-typed.com  Mon Jun  1 19:42:59 2015
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 1 Jun 2015 14:42:59 -0500
Subject: Travis builds failing
In-Reply-To: <1433187277.11290.1.camel@joachim-breitner.de>
References: <1432860362-sup-2108@sabre>
 <1432932170.2126.5.camel@joachim-breitner.de>
 <CANma=H9PRG9Yn9j=X6MKMddrGaOB_hSQcEuEMOaP-EtXgTFbwg@mail.gmail.com>
 <CANma=H9mi_g091LeUn0u4ZZb7Fn3Nj0fCmmwM6AREbS+WNEFkA@mail.gmail.com>
 <1433157920.1317.9.camel@joachim-breitner.de>
 <CANma=H9AZ012xDX0LeJ_cMeecU3L7pgBTkasg5H+0kd=KHyj_A@mail.gmail.com>
 <1433182963.19557.9.camel@joachim-breitner.de>
 <CANma=H8dFRxSfTR-TiDai=Tdea5WLHJ+JnnAkeguOw1dHn_rHg@mail.gmail.com>
 <CAEs96n3r4X6yiLNhLaxBjHqGYHOfBLU=x0vhmVVCYpt9NuvffQ@mail.gmail.com>
 <CANma=H9euhQPQx-mVKJYcZ62wuW+92R8gsEv0Dxn0uD=jDVwDQ@mail.gmail.com>
 <CAEs96n1bvdEK42eZCz_RWNbosq4UtQm_HBqsGb5Yf4JREnRYHw@mail.gmail.com>
 <1433187277.11290.1.camel@joachim-breitner.de>
Message-ID: <CAEs96n3b9cGbxnA_ErQkQ-udox8E+4PHuHVy5rg1e4j+LLZhgw@mail.gmail.com>

On Mon, Jun 1, 2015 at 2:34 PM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
> Am Montag, den 01.06.2015, 14:26 -0500 schrieb Austin Seipp:
>> I don't think there's any built-in way to do that in the current
>> testsuite infrastructure, other than setting THREADS=1, which, if it
>> isn't set already, would probably push us back over the Travis build
>> limit.
>
> we are running validate with CPU=2, which I believe translates to
> THREADS=1.

It's actually the opposite - if you check ./validate, CPU=2 translates
to THREAD=3! The reasoning is 'CPUS' is the number of physical cores
you have, and it adds 1 to saturate all your cores, while the extra
thread gets scheduled during I/O overlap on the underlying disk from
the other threads, overall improving throughput. Normally it's a win
on a completely un-contested machine, as some overlap exists.

> But we never had memory problems before, and 3GB is still quite a bit.
> Are we sure that there is no bug here? Or is our official requirement
> now above 3GB?

Well, it's possible there's something else lurking here. Maybe the
merge of D913 caused things to spike for some reason, during the
cleanup? Possible there was an error in the refactoring. But given
that the buildbot only has 3GB and executed (in essence) with
THREADS=3, I'm almost certain that it's just because they all ran at
once, and the OOM killed them. We may have just gotten lucky?

Also, Thomas has alerted me that the testsuite actually has an option
called `high_memory_usage` which will serialize the tests and run them
one at a time. So actually, that can work as a solution too!

> Greetings,
> Joachim
>
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

-- 
Regards,

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

From alan.zimm at gmail.com  Mon Jun  1 19:51:04 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Mon, 1 Jun 2015 21:51:04 +0200
Subject: Travis builds failing
In-Reply-To: <CAEs96n3b9cGbxnA_ErQkQ-udox8E+4PHuHVy5rg1e4j+LLZhgw@mail.gmail.com>
References: <1432860362-sup-2108@sabre>
 <1432932170.2126.5.camel@joachim-breitner.de>
 <CANma=H9PRG9Yn9j=X6MKMddrGaOB_hSQcEuEMOaP-EtXgTFbwg@mail.gmail.com>
 <CANma=H9mi_g091LeUn0u4ZZb7Fn3Nj0fCmmwM6AREbS+WNEFkA@mail.gmail.com>
 <1433157920.1317.9.camel@joachim-breitner.de>
 <CANma=H9AZ012xDX0LeJ_cMeecU3L7pgBTkasg5H+0kd=KHyj_A@mail.gmail.com>
 <1433182963.19557.9.camel@joachim-breitner.de>
 <CANma=H8dFRxSfTR-TiDai=Tdea5WLHJ+JnnAkeguOw1dHn_rHg@mail.gmail.com>
 <CAEs96n3r4X6yiLNhLaxBjHqGYHOfBLU=x0vhmVVCYpt9NuvffQ@mail.gmail.com>
 <CANma=H9euhQPQx-mVKJYcZ62wuW+92R8gsEv0Dxn0uD=jDVwDQ@mail.gmail.com>
 <CAEs96n1bvdEK42eZCz_RWNbosq4UtQm_HBqsGb5Yf4JREnRYHw@mail.gmail.com>
 <1433187277.11290.1.camel@joachim-breitner.de>
 <CAEs96n3b9cGbxnA_ErQkQ-udox8E+4PHuHVy5rg1e4j+LLZhgw@mail.gmail.com>
Message-ID: <CANma=H8W6akR3_EAEGuHJ5XLM4-BjobHT3Xeey3FNvk411644A@mail.gmail.com>

And I am preparing a test branch on ghc-api/annotations to use this flag,
will push it once I have checked its sanity locally

On Mon, Jun 1, 2015 at 9:42 PM, Austin Seipp <austin at well-typed.com> wrote:

> On Mon, Jun 1, 2015 at 2:34 PM, Joachim Breitner
> <mail at joachim-breitner.de> wrote:
> > Hi,
> >
> > Am Montag, den 01.06.2015, 14:26 -0500 schrieb Austin Seipp:
> >> I don't think there's any built-in way to do that in the current
> >> testsuite infrastructure, other than setting THREADS=1, which, if it
> >> isn't set already, would probably push us back over the Travis build
> >> limit.
> >
> > we are running validate with CPU=2, which I believe translates to
> > THREADS=1.
>
> It's actually the opposite - if you check ./validate, CPU=2 translates
> to THREAD=3! The reasoning is 'CPUS' is the number of physical cores
> you have, and it adds 1 to saturate all your cores, while the extra
> thread gets scheduled during I/O overlap on the underlying disk from
> the other threads, overall improving throughput. Normally it's a win
> on a completely un-contested machine, as some overlap exists.
>
> > But we never had memory problems before, and 3GB is still quite a bit.
> > Are we sure that there is no bug here? Or is our official requirement
> > now above 3GB?
>
> Well, it's possible there's something else lurking here. Maybe the
> merge of D913 caused things to spike for some reason, during the
> cleanup? Possible there was an error in the refactoring. But given
> that the buildbot only has 3GB and executed (in essence) with
> THREADS=3, I'm almost certain that it's just because they all ran at
> once, and the OOM killed them. We may have just gotten lucky?
>
> Also, Thomas has alerted me that the testsuite actually has an option
> called `high_memory_usage` which will serialize the tests and run them
> one at a time. So actually, that can work as a solution too!
>
> > Greetings,
> > Joachim
> >
> > --
> > Joachim ?nomeata? Breitner
> >   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
> >   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
> >   Debian Developer: nomeata at debian.org
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150601/3a712d59/attachment.html>

From mail at joachim-breitner.de  Mon Jun  1 19:54:28 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 01 Jun 2015 21:54:28 +0200
Subject: Travis builds failing
In-Reply-To: <CAEs96n3b9cGbxnA_ErQkQ-udox8E+4PHuHVy5rg1e4j+LLZhgw@mail.gmail.com>
References: <1432860362-sup-2108@sabre>
 <1432932170.2126.5.camel@joachim-breitner.de>
 <CANma=H9PRG9Yn9j=X6MKMddrGaOB_hSQcEuEMOaP-EtXgTFbwg@mail.gmail.com>
 <CANma=H9mi_g091LeUn0u4ZZb7Fn3Nj0fCmmwM6AREbS+WNEFkA@mail.gmail.com>
 <1433157920.1317.9.camel@joachim-breitner.de>
 <CANma=H9AZ012xDX0LeJ_cMeecU3L7pgBTkasg5H+0kd=KHyj_A@mail.gmail.com>
 <1433182963.19557.9.camel@joachim-breitner.de>
 <CANma=H8dFRxSfTR-TiDai=Tdea5WLHJ+JnnAkeguOw1dHn_rHg@mail.gmail.com>
 <CAEs96n3r4X6yiLNhLaxBjHqGYHOfBLU=x0vhmVVCYpt9NuvffQ@mail.gmail.com>
 <CANma=H9euhQPQx-mVKJYcZ62wuW+92R8gsEv0Dxn0uD=jDVwDQ@mail.gmail.com>
 <CAEs96n1bvdEK42eZCz_RWNbosq4UtQm_HBqsGb5Yf4JREnRYHw@mail.gmail.com>
 <1433187277.11290.1.camel@joachim-breitner.de>
 <CAEs96n3b9cGbxnA_ErQkQ-udox8E+4PHuHVy5rg1e4j+LLZhgw@mail.gmail.com>
Message-ID: <1433188468.11290.3.camel@joachim-breitner.de>

HI,

Am Montag, den 01.06.2015, 14:42 -0500 schrieb Austin Seipp:
> On Mon, Jun 1, 2015 at 2:34 PM, Joachim Breitner
> > we are running validate with CPU=2, which I believe translates to
> > THREADS=1.
> 
> It's actually the opposite - if you check ./validate, CPU=2 translates
> to THREAD=3!

Eh, sorry, that?s what I meant.

> Also, Thomas has alerted me that the testsuite actually has an option
> called `high_memory_usage` which will serialize the tests and run them
> one at a time. So actually, that can work as a solution too!

Good idea. I just pushed a wip/ branch to test that.

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150601/b3fb0569/attachment.sig>

From alan.zimm at gmail.com  Mon Jun  1 21:22:34 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Mon, 1 Jun 2015 23:22:34 +0200
Subject: Travis builds failing
In-Reply-To: <1433188468.11290.3.camel@joachim-breitner.de>
References: <1432860362-sup-2108@sabre>
 <1432932170.2126.5.camel@joachim-breitner.de>
 <CANma=H9PRG9Yn9j=X6MKMddrGaOB_hSQcEuEMOaP-EtXgTFbwg@mail.gmail.com>
 <CANma=H9mi_g091LeUn0u4ZZb7Fn3Nj0fCmmwM6AREbS+WNEFkA@mail.gmail.com>
 <1433157920.1317.9.camel@joachim-breitner.de>
 <CANma=H9AZ012xDX0LeJ_cMeecU3L7pgBTkasg5H+0kd=KHyj_A@mail.gmail.com>
 <1433182963.19557.9.camel@joachim-breitner.de>
 <CANma=H8dFRxSfTR-TiDai=Tdea5WLHJ+JnnAkeguOw1dHn_rHg@mail.gmail.com>
 <CAEs96n3r4X6yiLNhLaxBjHqGYHOfBLU=x0vhmVVCYpt9NuvffQ@mail.gmail.com>
 <CANma=H9euhQPQx-mVKJYcZ62wuW+92R8gsEv0Dxn0uD=jDVwDQ@mail.gmail.com>
 <CAEs96n1bvdEK42eZCz_RWNbosq4UtQm_HBqsGb5Yf4JREnRYHw@mail.gmail.com>
 <1433187277.11290.1.camel@joachim-breitner.de>
 <CAEs96n3b9cGbxnA_ErQkQ-udox8E+4PHuHVy5rg1e4j+LLZhgw@mail.gmail.com>
 <1433188468.11290.3.camel@joachim-breitner.de>
Message-ID: <CANma=H-3P6VNrf1t8JUq+ouvejhUrniZhOi9WCq=MKPGVhbPTw@mail.gmail.com>

Looks like https://github.com/ghc/ghc/tree/wip/high_memory_usage has passed.

Interestingly it gathered all the tests marked that way for the end, and
ran them one at a time.
See https://api.travis-ci.org/jobs/64977719/log.txt?deansi=true

On Mon, Jun 1, 2015 at 9:54 PM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> HI,
>
> Am Montag, den 01.06.2015, 14:42 -0500 schrieb Austin Seipp:
> > On Mon, Jun 1, 2015 at 2:34 PM, Joachim Breitner
> > > we are running validate with CPU=2, which I believe translates to
> > > THREADS=1.
> >
> > It's actually the opposite - if you check ./validate, CPU=2 translates
> > to THREAD=3!
>
> Eh, sorry, that?s what I meant.
>
> > Also, Thomas has alerted me that the testsuite actually has an option
> > called `high_memory_usage` which will serialize the tests and run them
> > one at a time. So actually, that can work as a solution too!
>
> Good idea. I just pushed a wip/ branch to test that.
>
> Greetings,
> Joachim
>
>
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150601/4e4bf28a/attachment-0001.html>

From alan.zimm at gmail.com  Mon Jun  1 21:28:19 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Mon, 1 Jun 2015 23:28:19 +0200
Subject: Travis builds failing
In-Reply-To: <CANma=H-3P6VNrf1t8JUq+ouvejhUrniZhOi9WCq=MKPGVhbPTw@mail.gmail.com>
References: <1432860362-sup-2108@sabre>
 <1432932170.2126.5.camel@joachim-breitner.de>
 <CANma=H9PRG9Yn9j=X6MKMddrGaOB_hSQcEuEMOaP-EtXgTFbwg@mail.gmail.com>
 <CANma=H9mi_g091LeUn0u4ZZb7Fn3Nj0fCmmwM6AREbS+WNEFkA@mail.gmail.com>
 <1433157920.1317.9.camel@joachim-breitner.de>
 <CANma=H9AZ012xDX0LeJ_cMeecU3L7pgBTkasg5H+0kd=KHyj_A@mail.gmail.com>
 <1433182963.19557.9.camel@joachim-breitner.de>
 <CANma=H8dFRxSfTR-TiDai=Tdea5WLHJ+JnnAkeguOw1dHn_rHg@mail.gmail.com>
 <CAEs96n3r4X6yiLNhLaxBjHqGYHOfBLU=x0vhmVVCYpt9NuvffQ@mail.gmail.com>
 <CANma=H9euhQPQx-mVKJYcZ62wuW+92R8gsEv0Dxn0uD=jDVwDQ@mail.gmail.com>
 <CAEs96n1bvdEK42eZCz_RWNbosq4UtQm_HBqsGb5Yf4JREnRYHw@mail.gmail.com>
 <1433187277.11290.1.camel@joachim-breitner.de>
 <CAEs96n3b9cGbxnA_ErQkQ-udox8E+4PHuHVy5rg1e4j+LLZhgw@mail.gmail.com>
 <1433188468.11290.3.camel@joachim-breitner.de>
 <CANma=H-3P6VNrf1t8JUq+ouvejhUrniZhOi9WCq=MKPGVhbPTw@mail.gmail.com>
Message-ID: <CANma=H_frsu1J8u6vKR+GO0htVuDsSNn-PbXjwGtt0nBBwhJCQ@mail.gmail.com>

And the tests are just too long for the 50 minute limit.

But if I can guarantee the single thread case then I can speed up the api
annotations tests, by building a single exe to use for most of the tests.

On Mon, Jun 1, 2015 at 11:22 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com>
wrote:

> Looks like https://github.com/ghc/ghc/tree/wip/high_memory_usage has
> passed.
>
> Interestingly it gathered all the tests marked that way for the end, and
> ran them one at a time.
> See https://api.travis-ci.org/jobs/64977719/log.txt?deansi=true
>
> On Mon, Jun 1, 2015 at 9:54 PM, Joachim Breitner <mail at joachim-breitner.de
> > wrote:
>
>> HI,
>>
>> Am Montag, den 01.06.2015, 14:42 -0500 schrieb Austin Seipp:
>> > On Mon, Jun 1, 2015 at 2:34 PM, Joachim Breitner
>> > > we are running validate with CPU=2, which I believe translates to
>> > > THREADS=1.
>> >
>> > It's actually the opposite - if you check ./validate, CPU=2 translates
>> > to THREAD=3!
>>
>> Eh, sorry, that?s what I meant.
>>
>> > Also, Thomas has alerted me that the testsuite actually has an option
>> > called `high_memory_usage` which will serialize the tests and run them
>> > one at a time. So actually, that can work as a solution too!
>>
>> Good idea. I just pushed a wip/ branch to test that.
>>
>> Greetings,
>> Joachim
>>
>>
>> --
>> Joachim ?nomeata? Breitner
>>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>>   Debian Developer: nomeata at debian.org
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150601/67373050/attachment.html>

From mark.lentczner at gmail.com  Tue Jun  2 07:03:24 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Tue, 2 Jun 2015 00:03:24 -0700
Subject: Time files... and here's another alpha HP for 7.10
In-Reply-To: <CAAOoiFaNBDCkS7TyZtv5WJ7m0AhnBHbLObyDnn7r8=8A3EkLHg@mail.gmail.com>
References: <CAAOoiFaNBDCkS7TyZtv5WJ7m0AhnBHbLObyDnn7r8=8A3EkLHg@mail.gmail.com>
Message-ID: <CAAOoiFagwoGHOmCh6m2BbG4_qNU=qFuuyqjGcq57neE-3_P5+A@mail.gmail.com>

There is now an OS X installer of this* "pre 7.10.2 - we'll just call it
alpha 3" *Platform, again, built with head of GHC 7.10 branch this morning:

Haskell Platform 7.10.1.20150601 alpha 3 64bit.pkg
<http://www.ozonehouse.com/mark/platform/Haskell%20Platform%207.10.1.20150601%20alpha%203%2064bit.pkg>
SHA-256: 65adae24b0a75e23c77632e7375198b4f3158e49984e3a1afec452d7ae5832ce

Watch out... it weighs 230MiB!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150602/3084b1fa/attachment.html>

From george.colpitts at gmail.com  Tue Jun  2 11:03:13 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Tue, 2 Jun 2015 08:03:13 -0300
Subject: Time files... and here's another alpha HP for 7.10
In-Reply-To: <CAAOoiFagwoGHOmCh6m2BbG4_qNU=qFuuyqjGcq57neE-3_P5+A@mail.gmail.com>
References: <CAAOoiFaNBDCkS7TyZtv5WJ7m0AhnBHbLObyDnn7r8=8A3EkLHg@mail.gmail.com>
 <CAAOoiFagwoGHOmCh6m2BbG4_qNU=qFuuyqjGcq57neE-3_P5+A@mail.gmail.com>
Message-ID: <CAB-d4A7CW5ZLND0LpLuG4V7jEyo874wo1kDQ15T-R1=QGaF_eA@mail.gmail.com>

Installed fine, ghc-pkg check shows no problems.
However cabal install ghc-core finished with:

/Users/gcolpitts/Library/Haskell/share/doc/x86_64-osx-ghc-7.10.1.20150601/index.html
haddock: internal error:
/Library/Frameworks/GHC.framework/Versions/7.10.1-x86_64/usr/lib/ghc-7.10.1/settings:
openFile: does not exist (No such file or directory)

Should I file a haddock or a ghc-core bug? cabal install criterion did not
have a problem

Thanks
George



On Tue, Jun 2, 2015 at 4:03 AM, Mark Lentczner <mark.lentczner at gmail.com>
wrote:

> There is now an OS X installer of this* "pre 7.10.2 - we'll just call it
> alpha 3" *Platform, again, built with head of GHC 7.10 branch this
> morning:
>
> Haskell Platform 7.10.1.20150601 alpha 3 64bit.pkg
> <http://www.ozonehouse.com/mark/platform/Haskell%20Platform%207.10.1.20150601%20alpha%203%2064bit.pkg>
> SHA-256: 65adae24b0a75e23c77632e7375198b4f3158e49984e3a1afec452d7ae5832ce
>
> Watch out... it weighs 230MiB!
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150602/23756411/attachment.html>

From george.colpitts at gmail.com  Tue Jun  2 11:40:53 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Tue, 2 Jun 2015 08:40:53 -0300
Subject: Time files... and here's another alpha HP for 7.10
In-Reply-To: <CAB-d4A7CW5ZLND0LpLuG4V7jEyo874wo1kDQ15T-R1=QGaF_eA@mail.gmail.com>
References: <CAAOoiFaNBDCkS7TyZtv5WJ7m0AhnBHbLObyDnn7r8=8A3EkLHg@mail.gmail.com>
 <CAAOoiFagwoGHOmCh6m2BbG4_qNU=qFuuyqjGcq57neE-3_P5+A@mail.gmail.com>
 <CAB-d4A7CW5ZLND0LpLuG4V7jEyo874wo1kDQ15T-R1=QGaF_eA@mail.gmail.com>
Message-ID: <CAB-d4A6pVU4nmWSmXz7Lr=bGNmLw+Z3ejZ5QE84BYtiDHFWxWQ@mail.gmail.com>

I guess I should file a haddock bug as I got the same error installing
threadscope

On Tue, Jun 2, 2015 at 8:03 AM, George Colpitts <george.colpitts at gmail.com>
wrote:

> Installed fine, ghc-pkg check shows no problems.
> However cabal install ghc-core finished with:
>
>
> /Users/gcolpitts/Library/Haskell/share/doc/x86_64-osx-ghc-7.10.1.20150601/index.html
> haddock: internal error:
> /Library/Frameworks/GHC.framework/Versions/7.10.1-x86_64/usr/lib/ghc-7.10.1/settings:
> openFile: does not exist (No such file or directory)
>
> Should I file a haddock or a ghc-core bug? cabal install criterion did not
> have a problem
>
> Thanks
> George
>
>
>
> On Tue, Jun 2, 2015 at 4:03 AM, Mark Lentczner <mark.lentczner at gmail.com>
> wrote:
>
>> There is now an OS X installer of this* "pre 7.10.2 - we'll just call it
>> alpha 3" *Platform, again, built with head of GHC 7.10 branch this
>> morning:
>>
>> Haskell Platform 7.10.1.20150601 alpha 3 64bit.pkg
>> <http://www.ozonehouse.com/mark/platform/Haskell%20Platform%207.10.1.20150601%20alpha%203%2064bit.pkg>
>> SHA-256: 65adae24b0a75e23c77632e7375198b4f3158e49984e3a1afec452d7ae5832ce
>>
>> Watch out... it weighs 230MiB!
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150602/4b4fb903/attachment.html>

From simonpj at microsoft.com  Tue Jun  2 12:57:13 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 2 Jun 2015 12:57:13 +0000
Subject: [Diffusion] [Build Failed] rGHCd6c01faed26f: Remove redundant
 import
In-Reply-To: <20150602124713.27640.86251@phabricator.haskell.org>
References: <diffusion-audit-PHID-CMIT-ziiozmj4ttvhig7lhzos@phabricator.haskell.org>
 <20150602124713.27640.86251@phabricator.haskell.org>
Message-ID: <a7e6c0cf51574d37b30b41bf54841ab4@DB4PR30MB030.064d.mgd.msft.net>

Well I validated all right, but now I'm getting this unexpected pass, both on my machine and Phabricator:

Unexpected passes:
  driver T9938 (normal)

The ticket seems to oscillate about whether it's supposed to pass or not, and I don't understand the comment stream, so I'm unsure what to do.

Also on Phab, but NOT on my machine, I see 

Unexpected stat failures:
  perf/haddock haddock.compiler [stat not good enough] (normal)

But I can't see the log so I have no idea what is going on.

Sorry about this.

Simon

|  -----Original Message-----
|  From: noreply at phabricator.haskell.org
|  [mailto:noreply at phabricator.haskell.org]
|  Sent: 02 June 2015 13:47
|  To: Simon Peyton Jones
|  Subject: [Diffusion] [Build Failed] rGHCd6c01faed26f: Remove redundant
|  import
|  
|  Harbormaster failed to build B4222: rGHCd6c01faed26f: Remove redundant
|  import!
|  
|  BRANCHES
|    master
|  
|  USERS
|    simonpj (Author)
|    GHC - GHCi (Auditor)
|  
|  COMMIT
|    https://phabricator.haskell.org/rGHCd6c01faed26f
|  
|  EMAIL PREFERENCES
|    https://phabricator.haskell.org/settings/panel/emailpreferences/
|  
|  To: simonpj, GHC - GHCi

From mark.lentczner at gmail.com  Tue Jun  2 13:22:04 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Tue, 2 Jun 2015 06:22:04 -0700
Subject: Time files... and here's another alpha HP for 7.10
In-Reply-To: <CAB-d4A6pVU4nmWSmXz7Lr=bGNmLw+Z3ejZ5QE84BYtiDHFWxWQ@mail.gmail.com>
References: <CAAOoiFaNBDCkS7TyZtv5WJ7m0AhnBHbLObyDnn7r8=8A3EkLHg@mail.gmail.com>
 <CAAOoiFagwoGHOmCh6m2BbG4_qNU=qFuuyqjGcq57neE-3_P5+A@mail.gmail.com>
 <CAB-d4A7CW5ZLND0LpLuG4V7jEyo874wo1kDQ15T-R1=QGaF_eA@mail.gmail.com>
 <CAB-d4A6pVU4nmWSmXz7Lr=bGNmLw+Z3ejZ5QE84BYtiDHFWxWQ@mail.gmail.com>
Message-ID: <CAAOoiFYqhUeCeHhDF3M+BvOkfO-S0n50tOaU7r3D++RFVAW5zw@mail.gmail.com>

On Tue, Jun 2, 2015 at 4:40 AM, George Colpitts <george.colpitts at gmail.com>
wrote:

> I guess I should file a haddock bug as I got the same error installing
> threadscope



Does ghc --print-libdir display the correct path? (That is, with the full
version number.)

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150602/fd9ff9b4/attachment.html>

From dct25-561bs at mythic-beasts.com  Tue Jun  2 13:26:06 2015
From: dct25-561bs at mythic-beasts.com (David Turner)
Date: Tue, 2 Jun 2015 14:26:06 +0100
Subject: [Haskell-cafe] Consecutive FFI calls
In-Reply-To: <CAPB_Nvx4_2UxeY9qha8P8QMow7OzLtujncXgaV9ci_VPoLxiNw@mail.gmail.com>
References: <CAErCyQ_VdkCaqSs8469W95CnAGpkpg=xk2TjWgrJTiW4Ks1niw@mail.gmail.com>
 <CAPB_Nvx4_2UxeY9qha8P8QMow7OzLtujncXgaV9ci_VPoLxiNw@mail.gmail.com>
Message-ID: <CAErCyQ-O67Cpg_ntOgdthU4HXm1tNG+cw2cvh=1_cvjDyWvpfg@mail.gmail.com>

Hi Takenobu,

My question is more about consecutive FFI calls on the same Haskell
thread, of which there are I suppose 8 cases in your model: the thread
is {unbound,bound}, the first call is {safe,unsafe} and the second is
{safe,unsafe}. If the thread is bound, there's no problem as the two
calls happen on the same OS thread. No memory barriers are needed. If
the thread is unbound, the two calls may occur on distinct OS threads.
Although the first call must have returned before the second is made,
it doesn't immediately follow that there has been a memory barrier in
between. I'm not sure it matters whether either call is safe or
unsafe. As a Haskell thread can migrate to a different OS thread at
any point, I don't think it's possible to put appropriate memory
barriers in the source.

I've been looking at the GHC source and commentary and believe the
answer is 'yes', but can anyone from ghc-dev comment on the following?

If a Haskell thread moves to a different OS thread then
yieldCapability() will at some point be called. This function normally
calls ACQUIRE_LOCK, which is either pthread_mutex_lock() or
EnterCriticalSection() in the threaded runtime (on Linux and Win32
respectively). It looks like both of these count as full memory
barriers. I think in the (rare) case where yieldCapability() only does
a GC and then exits, the fact that it's always called in a loop means
that eventually *some* Task or other emits a memory barrier.

Thanks in advance,

David








On 30 May 2015 at 04:10, Takenobu Tani <takenobu.hs at gmail.com> wrote:
> Hi David,
>
> I'm not 100% sure, especially semantics,  and I'm studying too.
> I don't have an answer, but I describe the related matters in order to
> organize my head.
>
> At first:
>   "memory barrier" ... is order control mechanism between memory accesses.
>   "bound thread"   ... is association mechanism between ffi calls and a
> specified thread.
>
> And:
>   "memory barrier"  ... is depend on cpu hardware architecture(x86, ARM,
> ...).
>   "OS level thread" ... is depend on OS(Linux, Windows, ...).
>
> Last:
> There are four cases about ffi call [1]:
>   (1) safe ffi call   on unbound thread(forkIO)
>   (2) unsafe ffi call on unbound thread(forkIO)
>   (3) safe ffi call   on bound thread(main, forkOS)
>   (4) unsafe ffi call on bound thread(main, forkOS)
>
> I think, maybe (2) and (4) have not guarantee with memory ordering.
> Because they might be inlined and optimized.
>
> If (1) and (3) always use pthread api (or memory barrier api) for thread/HEC
> context switch,
> they are guarantee.
> But I think that it would not guarantee the full case.
>
>
> I feel that order issues are very difficult.
> I think order issues can be safely solved by explicit notation,
> like explicit memory barrier notation, STM,...
>
>
> If I have misunderstood, please teach me :-)
>
>
> [1]:
> http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf#page=98
>
> Cheers,
> Takenobu
>
>
>
> 2015-05-29 1:24 GMT+09:00 David Turner <dct25-561bs at mythic-beasts.com>:
>>
>> Hi,
>>
>> If I make a sequence of FFI calls (on a single Haskell thread) but
>> which end up being called from different OS threads, is there any kind
>> of ordering guarantee given? More specifically, is there a full memory
>> barrier at the point where a Haskell thread migrates to a new OS
>> thread?
>>
>> Many thanks,
>>
>> David
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>

From george.colpitts at gmail.com  Tue Jun  2 16:01:02 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Tue, 2 Jun 2015 13:01:02 -0300
Subject: Time files... and here's another alpha HP for 7.10
In-Reply-To: <CAAOoiFYqhUeCeHhDF3M+BvOkfO-S0n50tOaU7r3D++RFVAW5zw@mail.gmail.com>
References: <CAAOoiFaNBDCkS7TyZtv5WJ7m0AhnBHbLObyDnn7r8=8A3EkLHg@mail.gmail.com>
 <CAAOoiFagwoGHOmCh6m2BbG4_qNU=qFuuyqjGcq57neE-3_P5+A@mail.gmail.com>
 <CAB-d4A7CW5ZLND0LpLuG4V7jEyo874wo1kDQ15T-R1=QGaF_eA@mail.gmail.com>
 <CAB-d4A6pVU4nmWSmXz7Lr=bGNmLw+Z3ejZ5QE84BYtiDHFWxWQ@mail.gmail.com>
 <CAAOoiFYqhUeCeHhDF3M+BvOkfO-S0n50tOaU7r3D++RFVAW5zw@mail.gmail.com>
Message-ID: <CAB-d4A5ta64nYJv4F3AW+d2kEgweO6oNN-2P2hazVm8BTkMb0g@mail.gmail.com>

Yes


ghc --print-libdir
/Library/Frameworks/GHC.framework/Versions/7.10.1.20150601-x86_64/usr/lib/ghc-7.10.1.20150601
bash-3.2$

On Tue, Jun 2, 2015 at 10:22 AM, Mark Lentczner <mark.lentczner at gmail.com>
wrote:

> On Tue, Jun 2, 2015 at 4:40 AM, George Colpitts <george.colpitts at gmail.com>
> wrote:
>
>> I guess I should file a haddock bug as I got the same error installing
>> threadscope
>
>
>
> Does ghc --print-libdir display the correct path? (That is, with the full
> version number.)
>
> - Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150602/ee404f81/attachment.html>

From simonpj at microsoft.com  Tue Jun  2 16:23:21 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 2 Jun 2015 16:23:21 +0000
Subject: [Diffusion] [Commented On] rGHC1189196ce7f0: Re-do superclass
 solving (again); fixes #10423
In-Reply-To: <20150602160923.25429.51774@phabricator.haskell.org>
References: <diffusion-audit-PHID-CMIT-r2g6ugvta2dw4pytchjr@phabricator.haskell.org>
 <20150602160923.25429.51774@phabricator.haskell.org>
Message-ID: <06dda53cc44d4c01aa3a26c28e330b68@DB4PR30MB030.064d.mgd.msft.net>

That's quite a surprise. I didn't expect performance improvements.  But hey, I'll take it!

Thanks

Simon

|  -----Original Message-----
|  From: noreply at phabricator.haskell.org
|  [mailto:noreply at phabricator.haskell.org]
|  Sent: 02 June 2015 17:09
|  To: Simon Peyton Jones
|  Subject: [Diffusion] [Commented On] rGHC1189196ce7f0: Re-do superclass
|  solving (again); fixes #10423
|  
|  nomeata added a subscriber: nomeata.
|  nomeata added a comment.
|  
|  Yay! There is a 7.5% percent improvement in cryptarithm2?s allocation
|  count:
|  https://perf.haskell.org/ghc/#revision/1189196ce7f064af408c9d16874a4c0
|  b78f3a006
|  
|  
|  BRANCHES
|    master
|  
|  USERS
|    simonpj (Author)
|    GHC - Type checker/inferencer (Auditor)
|  
|  COMMIT
|    https://phabricator.haskell.org/rGHC1189196ce7f0
|  
|  EMAIL PREFERENCES
|    https://phabricator.haskell.org/settings/panel/emailpreferences/
|  
|  To: simonpj, GHC - Type checker/inferencer
|  Cc: nomeata

From austin at well-typed.com  Tue Jun  2 21:31:04 2015
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 2 Jun 2015 16:31:04 -0500
Subject: HEADS UP: Final call for 7.10.2 is soon
Message-ID: <CAEs96n08kNWS0gOS1CtC1zkHz_Ay8WgwpE1ncRZCfinxcaVrrw@mail.gmail.com>

Hi *,

I've just finished merging all the latest patches for GHC 7.10.2 into
the STABLE branch. All in all, we've fixed a lot of bugs (over 80
tickets closed)!

So, we'll probably be doing a 7.10.2 release here in a few weeks. The
tentative plan was around the 14th, although it's not set in stone.
(At worst, it would be pushed from the 14th to the 21st).

With that in mind, if I could quickly direct your attention to the GHC
bug tracker and the status page[1] - it would be really helpful if you
check if the things you want are fixed!

Specifically, if you want something fixed for the 7.10.2 release:

  - Make sure there is a ticket. It really needs to exist or we'll just forget!

  - If your bug is critical, please explain why! We really want to
kill showstoppers ASAP, because bugs are much cheaper to fix early. If
that's the case we can bump the priority if it's necessary to make
things clear.

  - Set the milestone to 7.10.2. It'll automatically appear on the status page.

That should be it - we'll be monitoring the status page regularly to
keep track of new things. The current bug list is pretty small - we
may move some of them out, or fix several more. So just try to let us
know.

As a sidenote, I'm quite happy with this release - it's fixed dozens
of tricky bugs, improved some nasty corner cases in compiler
performance, and overall seems like it will be high quality. Thanks to
everyone who submitted patches!

I'll send out another email next week as another reminder.

[1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2

-- 
Regards,

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

From austin at well-typed.com  Wed Jun  3 06:58:54 2015
From: austin at well-typed.com (Austin Seipp)
Date: Wed, 3 Jun 2015 01:58:54 -0500
Subject: =?UTF-8?Q?Re=3A_API_to_=E2=80=9Craise_concern=E2=80=9D_in_Phabricator?=
In-Reply-To: <1432110884.2048.7.camel@joachim-breitner.de>
References: <1432110884.2048.7.camel@joachim-breitner.de>
Message-ID: <CAEs96n3fWWULPofqQPOyx9iNXZ+nXF6aKG574HpJLiJyp2+okA@mail.gmail.com>

Hi Joachim,

(Sorry for the late reply).

There may not be an API directly for this, but we can probably write
one pretty easily - Phabricator's API endpoints can also be customized
by library extensions, so we can extend libphutil-haskell (the
repository with our extensions) to contain some outward facing Conduit
API calls.

I'll talk to upstream about this as well, in case they have any ideas
or other approaches.

On Wed, May 20, 2015 at 3:34 AM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
> with https://perf.haskell.org/ghc/ up and running I?m wondering about
> the best way to notify us about regressions. A mail to ghc-commits is
> one possibility, but maybe it?s neater to integrate that into
> Phabricator.
>
> How hard would it be comment and optionally ?raise concern? with a
> commit automatically?
>
> Or, put differently, I want a script that takes a git commit, a comment,
> and a flag that indicated whether a concern should be raised, and then
> does that on Phabricator.
>
> It seems that https://phabricator.haskell.org/conduit/ is an entry
> point, but I only see methods for attaching comments to DRs.
>
> Greetings,
> Joachim
>
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Regards,

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

From austin at well-typed.com  Wed Jun  3 07:04:35 2015
From: austin at well-typed.com (Austin Seipp)
Date: Wed, 3 Jun 2015 02:04:35 -0500
Subject: GHC Weekly News - 2015/06/03
Message-ID: <CAEs96n0QHHhVQcnazr=BpNTK4MsA06GkvrtQObzKcc+sUL9Daw@mail.gmail.com>

(This post is available online at
https://ghc.haskell.org/trac/ghc/blog/weekly20150603)

Hi *,

It's that time once again - to get some info on what's happening in
the world of GHC! It's been a quiet few weeks as a UK Holiday punted
one of GHC HQ's meetings off, and this week we were only partially
there.

The main point of discussion was 7.10.2, and continuing work on
compiler performance. The good news is, the past few weeks have seen
good work on both these fronts!

== 7.10.2 status ==

7.10.2 is swimming along very nicely - the
[https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 status page]
shows the current set of tickets we've fixed and plan on fixing.

Not much has changed from last time, except we've fixed even more
bugs! We're currently sitting at about 85 bugs fixed, some of them
pretty important - code generation bugs, compiler performance fixes,
some RTS and event manager work. Your author is actually quite happy
with what GHC 7.10.2 looks like, at this rate.

== List chatter ==

  - Austin Seipp announced that GHC 7.10.2 will be release soon, and
developers/users should get bugs they want fixed reported to us ASAP
so we can do something.
https://mail.haskell.org/pipermail/ghc-devs/2015-June/009150.html

  - Mark Lentczner announced a Haskell Platform alpha featuring GHC
7.10.2 https://mail.haskell.org/pipermail/ghc-devs/2015-June/009128.html

  - Facundo Dominguez asks: sometimes we want to create a `static`
pointer in a function with a local definition, how can we do that? The
current problem is the desugarer gets in the way and current
approaches are currently rejected, but Facundo has some
ideas/questions about a fix.
https://mail.haskell.org/pipermail/ghc-devs/2015-May/009110.html

  - David Macek has made great progress on getting native MSYS2
packages for windows working - which should be a great boon to all our
Windows users! https://mail.haskell.org/pipermail/ghc-devs/2015-May/009089.html

  - Joachim Breitner announced the new GHC performance dashboard,
which can be used to track all of GHC's performance-based tests over
time. Whoohoo! https://mail.haskell.org/pipermail/ghc-devs/2015-May/009032.html

  - Joachim Breitner asked: is there a way to programmatically 'Raise
a Concern' on a Phabricator commit? With the new
https://perf.haskell.org/ghc/ work, it'd be nice if regressions could
be automatically flagged. The current problem is there is no API
endpoint, but one can be built.
https://mail.haskell.org/pipermail/ghc-devs/2015-June/009128.html

  - Adam Gundry asked ghc-devs about some input on changes to the new
typechecker plugins API. After some discussion and elbow grease, the
new changes have already landed in HEAD and will be in 7.12.1.
https://mail.haskell.org/pipermail/ghc-devs/2015-May/009097.html

== Noteworthy commits ==

  - Commit 45d9a15c4b85a2ed89579106bdafd84accf2cb39 - Fix a huge space
leak in the mighty simplifier

  - Commit c89bd681d34d3339771ebdde8aa468b1d9ab042b - Fix quadratic
behavior in `tidyOccName`

  - Commit b03f074fd51adfb9bc4f5275294712ee62741aed - ghci: Allow
`:back` and `:forward` to take counts

  - Commit 8e4dc8fb63b8d3bfee485c1c830776f3ed704f4d - Greatly speed up
`nativeCodeGen/seqBlocks`

  - Commit c256357242ee2dd282fd0516260edccbb7617244 - Speed up
`elimCommonBlocks` by grouping blocks also by outgoing labels

  - Commit f5188f3acd73a07b648924a58b9882c2d0a3dbcb - Fix weird
behavior of `-ignore-dot-ghci` and `-ghci-script`

  - Commit 4fffbc34c024231c3c9fac7a2134896cc09c7fb7 - New handling of
overlapping instances in Safe Haskell

  - Commit f16ddcee0c64a92ab911a7841a8cf64e3ac671fd - Support stage 1
Template Haskell (non-quasi) quotes, fixes #10382

  - Commit cf7573b8207bbb17c58612f3345e0b17d74cfb58 - More accurate
allocation stats for `:set -s`

== Closed tickets ==

#10407, #10408, #10177, #10359, #10403, #10248, #9579, #10415, #10419,
#10427, #10429, #10397, #10422, #10335, #10366, #10110, #10397,
#10349, #10244, #8555, #8799, #9131, #10396, #10354, #10278, #9899,
#3533, #9950, #10092, #9950, #10430, #9682, #9584, #10446, #10410,
#10298, #10449, #10399, #7695, #10261, #8292, #10360, #10126, #10317,
#10101, #10322, #10313, #10471, #10473, #7170, #10473, #10423, #10466,
#8695, #10461, #10052, #10370, #10425, #10452, #10474,

-- 
Regards,

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

From fuuzetsu at fuuzetsu.co.uk  Wed Jun  3 08:10:43 2015
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Wed, 03 Jun 2015 09:10:43 +0100
Subject: [commit: ghc] master: build: make haddock a bit less chatty
 (e796026)
In-Reply-To: <20150602143144.298873A300@ghc.haskell.org>
References: <20150602143144.298873A300@ghc.haskell.org>
Message-ID: <556EB683.70107@fuuzetsu.co.uk>

On 06/02/2015 03:31 PM, git at git.haskell.org wrote:
> Repository : ssh://git at git.haskell.org/ghc
> 
> On branch  : master
> Link       : http://ghc.haskell.org/trac/ghc/changeset/e796026b45974d71233eef7ffb6feee482c6dd7e/ghc
> 
>> ---------------------------------------------------------------
> 
> commit e796026b45974d71233eef7ffb6feee482c6dd7e
> Author: Austin Seipp <austin at well-typed.com>
> Date:   Tue Jun 2 09:31:52 2015 -0500
> 
>     build: make haddock a bit less chatty
>     
>     Summary:
>     Haddock outputs well over a thousand lines of file output just to give
>     its executive summary about coverage. Kill this by default, since we
>     really don't need it in any setting.
>     
>     Signed-off-by: Austin Seipp <austin at well-typed.com>
>     
>     Test Plan: Crossed my fingers.
>     
>     Reviewers: nomeata, thomie
>     
>     Reviewed By: thomie
>     
>     Subscribers: bgamari, thomie
>     
>     Differential Revision: https://phabricator.haskell.org/D933
> 
> 
>> ---------------------------------------------------------------
> 
> e796026b45974d71233eef7ffb6feee482c6dd7e
>  ghc.mk           | 2 +-
>  rules/haddock.mk | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/ghc.mk b/ghc.mk
> index 5a1845c..3b38372 100644
> --- a/ghc.mk
> +++ b/ghc.mk
> @@ -1375,7 +1375,7 @@ validate_build_xhtml:
>  	cd libraries/xhtml && ./Setup configure --with-ghc="$(BINDIST_PREFIX)/bin/ghc" $(BINDIST_HADDOCK_FLAG) $(BINDIST_LIBRARY_FLAGS) --global --builddir=dist-bindist --prefix="$(BINDIST_PREFIX)"
>  	cd libraries/xhtml && ./Setup build   --builddir=dist-bindist
>  ifeq "$(HADDOCK_DOCS)" "YES"
> -	cd libraries/xhtml && ./Setup haddock --ghc-options=-optP-P --builddir=dist-bindist
> +	cd libraries/xhtml && ./Setup haddock -v0 --ghc-options=-optP-P --builddir=dist-bindist
>  endif
>  	cd libraries/xhtml && ./Setup install --builddir=dist-bindist
>  	cd libraries/xhtml && ./Setup clean   --builddir=dist-bindist
> diff --git a/rules/haddock.mk b/rules/haddock.mk
> index a43df95..5604a50 100644
> --- a/rules/haddock.mk
> +++ b/rules/haddock.mk
> @@ -48,6 +48,7 @@ ifeq "$$(HSCOLOUR_SRCS)" "YES"
>  	"$$(ghc-cabal_INPLACE)" hscolour $1 $2
>  endif
>  	"$$(TOP)/$$(INPLACE_BIN)/haddock" \
> +	  --verbosity=0 \
>  	  --odir="$1/$2/doc/html/$$($1_PACKAGE)" \
>  	  --no-tmp-comp-dir \
>  	  --dump-interface=$$($$($1_PACKAGE)-$$($1_$2_VERSION)_HADDOCK_FILE) \
> 
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits
> 

You could have just used --no-print-missing-docs to go to the old amount
of output. Or start filling out the stuff Haddock is complaining about,
I made it a default to nag people :)

-- 
Mateusz K.

From simonpj at microsoft.com  Wed Jun  3 11:53:19 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 3 Jun 2015 11:53:19 +0000
Subject: [Diffusion] [Build Failed] rGHC7ea156ae3e1c: Refactor
 RdrName.Provenance, to fix #7672
In-Reply-To: <20150603112645.867.88002@phabricator.haskell.org>
References: <diffusion-audit-PHID-CMIT-2wu2a4cfegvirlign4nr@phabricator.haskell.org>
 <20150603112645.867.88002@phabricator.haskell.org>
Message-ID: <094b0a7abe5845bf8c2e32f467e054d6@DB4PR30MB030.064d.mgd.msft.net>

I'm still seeing 

Unexpected stat failures:
perf/haddock haddock.compiler [stat not good enough] (normal)

but only on Phab not on my own machine.  I don't know how to fix this.

Simon
|  -----Original Message-----
|  From: noreply at phabricator.haskell.org
|  [mailto:noreply at phabricator.haskell.org]
|  Sent: 03 June 2015 12:27
|  To: Simon Peyton Jones
|  Subject: [Diffusion] [Build Failed] rGHC7ea156ae3e1c: Refactor
|  RdrName.Provenance, to fix #7672
|  
|  Harbormaster failed to build B4245: rGHC7ea156ae3e1c: Refactor
|  RdrName.Provenance, to fix #7672!
|  
|  BRANCHES
|    master
|  
|  USERS
|    simonpj (Author)
|    GHC - Testsuite (Auditor)
|    GHC - Core/System FC (Auditor)
|    GHC - Driver (Auditor)
|    GHC - Renamer (Auditor)
|    GHC - Type checker/inferencer (Auditor)
|  
|  COMMIT
|    https://phabricator.haskell.org/rGHC7ea156ae3e1c
|  
|  EMAIL PREFERENCES
|    https://phabricator.haskell.org/settings/panel/emailpreferences/
|  
|  To: simonpj, GHC - Testsuite, GHC - Core/System FC, GHC - Driver, GHC
|  - Renamer, GHC - Type checker/inferencer

From takenobu.hs at gmail.com  Wed Jun  3 13:07:08 2015
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Wed, 3 Jun 2015 22:07:08 +0900
Subject: [Haskell-cafe] Consecutive FFI calls
In-Reply-To: <CAErCyQ-O67Cpg_ntOgdthU4HXm1tNG+cw2cvh=1_cvjDyWvpfg@mail.gmail.com>
References: <CAErCyQ_VdkCaqSs8469W95CnAGpkpg=xk2TjWgrJTiW4Ks1niw@mail.gmail.com>
 <CAPB_Nvx4_2UxeY9qha8P8QMow7OzLtujncXgaV9ci_VPoLxiNw@mail.gmail.com>
 <CAErCyQ-O67Cpg_ntOgdthU4HXm1tNG+cw2cvh=1_cvjDyWvpfg@mail.gmail.com>
Message-ID: <CAPB_Nvzc0nzsKb=bwDGpuLdoLzvg-xSuKh147Qgy9zHRjCPHNA@mail.gmail.com>

Hi David,

Interesting.
I don't have an answer, but I write few things.

Your case is:
  * consecutive FFI calls
  * on the same Haskell Thread

Consecutive FFI call cases are:
  (1) do { safe_ffiCall1;   safe_ffiCall2 }
  (2) do { safe_ffiCall1;   unsafe_ffiCall2 }
  (3) do { unsafe_ffiCall1; safe_ffiCall2 }
  (4) do { unsafe_ffiCall1; unsafe_ffiCall2 }

I think at least answer is 'no' with case (4).
There are no memory barrier between unsafe_ffiCall1 and 2.


And apologies if I'm missing context.
Although a haskell thread can migrate to a different OS thread at any point,
you can put a memory barrier primitive (like "mfence" instruction [1][2][3])
at each target points before or after each ffi calls.

Of course, it's expensive if you put for each ffi calls.
And you should abstract from cpu hardware.
(I found useful explicit memory barrier api[4].)


I feel that the _exact_ memory barrier on out-of-order cpu,
multi core, memory mapped IO, ... is very expensive.
It's only satisfy by explicit "hardware memory barrier mechanism".

And it's difficult that exact memory barrier satisfy all case
by the combination of some implicit mechanism.


BTW, does it truly need memory barrier?
Also C language, exact memory barrier is expensive.


And, Maybe, ghc-devs are very busy to ship ghc7.10.2 :-)


[1]: Chapter 8.2,
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf
[2]: MFENCE,
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf
[3]: Chapter 7.5.5,
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf
[4]: https://hackage.haskell.org/package/atomic-primops


Cheers,
Takenobu


2015-06-02 22:26 GMT+09:00 David Turner <dct25-561bs at mythic-beasts.com>:

> Hi Takenobu,
>
> My question is more about consecutive FFI calls on the same Haskell
> thread, of which there are I suppose 8 cases in your model: the thread
> is {unbound,bound}, the first call is {safe,unsafe} and the second is
> {safe,unsafe}. If the thread is bound, there's no problem as the two
> calls happen on the same OS thread. No memory barriers are needed. If
> the thread is unbound, the two calls may occur on distinct OS threads.
> Although the first call must have returned before the second is made,
> it doesn't immediately follow that there has been a memory barrier in
> between. I'm not sure it matters whether either call is safe or
> unsafe. As a Haskell thread can migrate to a different OS thread at
> any point, I don't think it's possible to put appropriate memory
> barriers in the source.
>
> I've been looking at the GHC source and commentary and believe the
> answer is 'yes', but can anyone from ghc-dev comment on the following?
>
> If a Haskell thread moves to a different OS thread then
> yieldCapability() will at some point be called. This function normally
> calls ACQUIRE_LOCK, which is either pthread_mutex_lock() or
> EnterCriticalSection() in the threaded runtime (on Linux and Win32
> respectively). It looks like both of these count as full memory
> barriers. I think in the (rare) case where yieldCapability() only does
> a GC and then exits, the fact that it's always called in a loop means
> that eventually *some* Task or other emits a memory barrier.
>
> Thanks in advance,
>
> David
>
>
>
>
>
>
>
>
> On 30 May 2015 at 04:10, Takenobu Tani <takenobu.hs at gmail.com> wrote:
> > Hi David,
> >
> > I'm not 100% sure, especially semantics,  and I'm studying too.
> > I don't have an answer, but I describe the related matters in order to
> > organize my head.
> >
> > At first:
> >   "memory barrier" ... is order control mechanism between memory
> accesses.
> >   "bound thread"   ... is association mechanism between ffi calls and a
> > specified thread.
> >
> > And:
> >   "memory barrier"  ... is depend on cpu hardware architecture(x86, ARM,
> > ...).
> >   "OS level thread" ... is depend on OS(Linux, Windows, ...).
> >
> > Last:
> > There are four cases about ffi call [1]:
> >   (1) safe ffi call   on unbound thread(forkIO)
> >   (2) unsafe ffi call on unbound thread(forkIO)
> >   (3) safe ffi call   on bound thread(main, forkOS)
> >   (4) unsafe ffi call on bound thread(main, forkOS)
> >
> > I think, maybe (2) and (4) have not guarantee with memory ordering.
> > Because they might be inlined and optimized.
> >
> > If (1) and (3) always use pthread api (or memory barrier api) for
> thread/HEC
> > context switch,
> > they are guarantee.
> > But I think that it would not guarantee the full case.
> >
> >
> > I feel that order issues are very difficult.
> > I think order issues can be safely solved by explicit notation,
> > like explicit memory barrier notation, STM,...
> >
> >
> > If I have misunderstood, please teach me :-)
> >
> >
> > [1]:
> >
> http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf#page=98
> >
> > Cheers,
> > Takenobu
> >
> >
> >
> > 2015-05-29 1:24 GMT+09:00 David Turner <dct25-561bs at mythic-beasts.com>:
> >>
> >> Hi,
> >>
> >> If I make a sequence of FFI calls (on a single Haskell thread) but
> >> which end up being called from different OS threads, is there any kind
> >> of ordering guarantee given? More specifically, is there a full memory
> >> barrier at the point where a Haskell thread migrates to a new OS
> >> thread?
> >>
> >> Many thanks,
> >>
> >> David
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150603/56809298/attachment.html>

From ezyang at mit.edu  Wed Jun  3 18:58:28 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Wed, 03 Jun 2015 11:58:28 -0700
Subject: [Haskell-cafe] Consecutive FFI calls
In-Reply-To: <CAErCyQ_VdkCaqSs8469W95CnAGpkpg=xk2TjWgrJTiW4Ks1niw@mail.gmail.com>
References: <CAErCyQ_VdkCaqSs8469W95CnAGpkpg=xk2TjWgrJTiW4Ks1niw@mail.gmail.com>
Message-ID: <1433357750-sup-1872@sabre>

The ordering is guaranteed, because full synchronization is used
when threads migrate.  (It goes something like, a capability with
a full run queue grabs all idle capabilities, distributes its
threads to those capabilities, and then releases them.  The act
of acquiring and releasing a capability is a synchronization point.)

Cheers,
Edward

Excerpts from David Turner's message of 2015-05-28 09:24:50 -0700:
> Hi,
> 
> If I make a sequence of FFI calls (on a single Haskell thread) but
> which end up being called from different OS threads, is there any kind
> of ordering guarantee given? More specifically, is there a full memory
> barrier at the point where a Haskell thread migrates to a new OS
> thread?
> 
> Many thanks,
> 
> David

From dct25-561bs at mythic-beasts.com  Wed Jun  3 20:05:35 2015
From: dct25-561bs at mythic-beasts.com (David Turner)
Date: Wed, 3 Jun 2015 21:05:35 +0100
Subject: [Haskell-cafe] Consecutive FFI calls
In-Reply-To: <1433357750-sup-1872@sabre>
References: <CAErCyQ_VdkCaqSs8469W95CnAGpkpg=xk2TjWgrJTiW4Ks1niw@mail.gmail.com>
 <1433357750-sup-1872@sabre>
Message-ID: <CAErCyQ9TEFZfdg65XKSZmFx6rBJ4wMy67jOc8KvKDfLGTnV_Cg@mail.gmail.com>

Excellent, thanks!
On 3 Jun 2015 7:58 pm, "Edward Z. Yang" <ezyang at mit.edu> wrote:

> The ordering is guaranteed, because full synchronization is used
> when threads migrate.  (It goes something like, a capability with
> a full run queue grabs all idle capabilities, distributes its
> threads to those capabilities, and then releases them.  The act
> of acquiring and releasing a capability is a synchronization point.)
>
> Cheers,
> Edward
>
> Excerpts from David Turner's message of 2015-05-28 09:24:50 -0700:
> > Hi,
> >
> > If I make a sequence of FFI calls (on a single Haskell thread) but
> > which end up being called from different OS threads, is there any kind
> > of ordering guarantee given? More specifically, is there a full memory
> > barrier at the point where a Haskell thread migrates to a new OS
> > thread?
> >
> > Many thanks,
> >
> > David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150603/5ca80c2d/attachment.html>

From malcolm.wallace at me.com  Thu Jun  4 12:06:42 2015
From: malcolm.wallace at me.com (malcolm.wallace)
Date: Thu, 04 Jun 2015 12:06:42 +0000 (GMT)
Subject: archive of old ghc nightly builds?
Message-ID: <8aab727c-b2b6-416a-b236-29203b2f5a2e@me.com>

I'm looking for an archive of ghc nightly builds, so I can bisect a suspected bug at least to a small date range. ?Does such an archive exist? ?I have colleagues who say they used such an archive, and fairly recently, but we can't seem to find it from the ghc dev wiki today. ?The date range I am hoping for is roughly Sept 2012 to April 2014.
Regards,
    Malcolm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150604/3fd9bc6a/attachment.html>

From adam at sandbergericsson.se  Thu Jun  4 19:52:02 2015
From: adam at sandbergericsson.se (Adam Sandberg Eriksson)
Date: Thu, 04 Jun 2015 21:52:02 +0200
Subject: StrictData and the parser
Message-ID: <1433447522.784285.287081417.2F46277B@webmail.messagingengine.com>

Hello *,

I'm working on the -XStrict language extension[1] for this years Google
summer of code. I've started with the smaller -XStrictData (as
documented at the wiki) and have the internals mostly figured out.

However after adding relevant rules for '~' in the parser[2] I get an
explosion of shift/reduce conflicts as well as 4 extra reduce/reduce
conflicts, see [3] for the happy info (the states with 36 shift/reduce
conflicts seem to be the problematic ones), I also fail to parse the
test file [4] with the error

DsStrictData.hs:15:1: error:
    parse error (possibly incorrect indentation or mismatched brackets)

Can anyone offer some guidance on what the appropriate changes to the
parser are to make these "lazyness" marks work?

Thanks,
Adam

[1]: https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
[2]:
https://github.com/adamse/ghc/blob/strict-pragma/compiler/parser/Parser.y#L1547-L1563
[3]:
https://gist.githubusercontent.com/adamse/8d6c54b6ae660fca8b97/raw/detailed-info
[4]:
https://github.com/adamse/ghc/blob/strict-pragma/testsuite/tests/deSugar/should_run/DsStrictData.hs#L13
-- 
Adam Sandberg Eriksson

From ezyang at mit.edu  Thu Jun  4 20:05:21 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Thu, 04 Jun 2015 13:05:21 -0700
Subject: StrictData and the parser
In-Reply-To: <1433447522.784285.287081417.2F46277B@webmail.messagingengine.com>
References: <1433447522.784285.287081417.2F46277B@webmail.messagingengine.com>
Message-ID: <1433448133-sup-9225@sabre>

Hello Adam,

At a guess, ~ is ambiguous with the type equality syntax a ~ b.
You'll probably have to add a new production for types (similar
to atype) which are at the top level of a data constructor definition.

I recently wrote some documentation on how to interpret Happy
info files.  There hasn't been a release yet but the docs
are here:
https://github.com/ezyang/happy/commit/daf84f5aa6f6453a118944f77393537f323d1adb

Cheers,
Edward

Excerpts from Adam Sandberg Eriksson's message of 2015-06-04 12:52:02 -0700:
> Hello *,
> 
> I'm working on the -XStrict language extension[1] for this years Google
> summer of code. I've started with the smaller -XStrictData (as
> documented at the wiki) and have the internals mostly figured out.
> 
> However after adding relevant rules for '~' in the parser[2] I get an
> explosion of shift/reduce conflicts as well as 4 extra reduce/reduce
> conflicts, see [3] for the happy info (the states with 36 shift/reduce
> conflicts seem to be the problematic ones), I also fail to parse the
> test file [4] with the error
> 
> DsStrictData.hs:15:1: error:
>     parse error (possibly incorrect indentation or mismatched brackets)
> 
> Can anyone offer some guidance on what the appropriate changes to the
> parser are to make these "lazyness" marks work?
> 
> Thanks,
> Adam
> 
> [1]: https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
> [2]:
> https://github.com/adamse/ghc/blob/strict-pragma/compiler/parser/Parser.y#L1547-L1563
> [3]:
> https://gist.githubusercontent.com/adamse/8d6c54b6ae660fca8b97/raw/detailed-info
> [4]:
> https://github.com/adamse/ghc/blob/strict-pragma/testsuite/tests/deSugar/should_run/DsStrictData.hs#L13

From allbery.b at gmail.com  Thu Jun  4 20:06:52 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 4 Jun 2015 16:06:52 -0400
Subject: StrictData and the parser
In-Reply-To: <1433447522.784285.287081417.2F46277B@webmail.messagingengine.com>
References: <1433447522.784285.287081417.2F46277B@webmail.messagingengine.com>
Message-ID: <CAKFCL4Wb_r9C-BGA5CjbyNfQGKKVE+-+w4rwbobZB2tu5PgnGA@mail.gmail.com>

On Thu, Jun 4, 2015 at 3:52 PM, Adam Sandberg Eriksson <
adam at sandbergericsson.se> wrote:

> However after adding relevant rules for '~' in the parser[2] I get an
> explosion of shift/reduce conflicts as well as 4 extra reduce/reduce
> conflicts, see [3] for the happy info (the states with 36 shift/reduce
> conflicts seem to be the problematic ones)
>

Looks to me like it's confused about whether a ~ is part of an equality
constraint or is a laziness annotation. The former would be illegal at that
point, though, I'd think? Somewhere it believes a constraint might be
possible there, via btype.

As ezyang says in the message I see just came in, you'll need extra
production rules to distinguish that top level. Although I'd wonder why it
believes an equality constraint is acceptable there in the first place; is
that a lurking bug in the parser?

-- 
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://mail.haskell.org/pipermail/ghc-devs/attachments/20150604/d85233f0/attachment.html>

From ezyang at mit.edu  Thu Jun  4 20:30:19 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Thu, 04 Jun 2015 13:30:19 -0700
Subject: StrictData and the parser
In-Reply-To: <CAKFCL4Wb_r9C-BGA5CjbyNfQGKKVE+-+w4rwbobZB2tu5PgnGA@mail.gmail.com>
References: <1433447522.784285.287081417.2F46277B@webmail.messagingengine.com>
 <CAKFCL4Wb_r9C-BGA5CjbyNfQGKKVE+-+w4rwbobZB2tu5PgnGA@mail.gmail.com>
Message-ID: <1433449686-sup-9195@sabre>

Excerpts from Brandon Allbery's message of 2015-06-04 13:06:52 -0700:
> Looks to me like it's confused about whether a ~ is part of an equality
> constraint or is a laziness annotation. The former would be illegal at that
> point, though, I'd think? Somewhere it believes a constraint might be
> possible there, via btype.
> 
> As ezyang says in the message I see just came in, you'll need extra
> production rules to distinguish that top level. Although I'd wonder why it
> believes an equality constraint is acceptable there in the first place; is
> that a lurking bug in the parser?

In general, the parser is more liberal than is actually required; we
can give better error messages this way.

Second, here is where it's ambiguous:

    T a ~b

where T is a TyCon.  Does this parse as

    T a (~b)

or

    T a ~ b

Parser doesn't currently distinguish these cases. 

Edward

From simonpj at microsoft.com  Thu Jun  4 20:58:29 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 4 Jun 2015 20:58:29 +0000
Subject: StrictData and the parser
In-Reply-To: <1433447522.784285.287081417.2F46277B@webmail.messagingengine.com>
References: <1433447522.784285.287081417.2F46277B@webmail.messagingengine.com>
Message-ID: <54ec3e2332544de5a6e0d91c4769bd90@DB4PR30MB030.064d.mgd.msft.net>

You need to understand why the shift/reduce conflicts are happening.  Happy has a flag that makes it dump out the state transition tables, and you have to look at them.  there probably is some genuine ambiguity.

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Adam
| Sandberg Eriksson
| Sent: 04 June 2015 20:52
| To: ghc-devs at haskell.org; johan.tibell at gmail.com
| Subject: StrictData and the parser
| 
| Hello *,
| 
| I'm working on the -XStrict language extension[1] for this years Google
| summer of code. I've started with the smaller -XStrictData (as
| documented at the wiki) and have the internals mostly figured out.
| 
| However after adding relevant rules for '~' in the parser[2] I get an
| explosion of shift/reduce conflicts as well as 4 extra reduce/reduce
| conflicts, see [3] for the happy info (the states with 36 shift/reduce
| conflicts seem to be the problematic ones), I also fail to parse the
| test file [4] with the error
| 
| DsStrictData.hs:15:1: error:
|     parse error (possibly incorrect indentation or mismatched brackets)
| 
| Can anyone offer some guidance on what the appropriate changes to the
| parser are to make these "lazyness" marks work?
| 
| Thanks,
| Adam
| 
| [1]: https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
| [2]:
| https://github.com/adamse/ghc/blob/strict-
| pragma/compiler/parser/Parser.y#L1547-L1563
| [3]:
| https://gist.githubusercontent.com/adamse/8d6c54b6ae660fca8b97/raw/detail
| ed-info
| [4]:
| https://github.com/adamse/ghc/blob/strict-
| pragma/testsuite/tests/deSugar/should_run/DsStrictData.hs#L13
| --
| Adam Sandberg Eriksson
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From david.macek.0 at gmail.com  Thu Jun  4 21:39:16 2015
From: david.macek.0 at gmail.com (David Macek)
Date: Thu, 04 Jun 2015 23:39:16 +0200
Subject: MSYS2 package for GHC 7.10.1
In-Reply-To: <555E45A8.1070203@gmail.com>
References: <CAARHtnTfwC-rHJQ7Ea7ZeaLSJ0HEXUxCcK3UhF1iFtmUqAtgog@mail.gmail.com>
 <555E45A8.1070203@gmail.com>
Message-ID: <5570C584.7030208@gmail.com>

On 24. 5. 2015 8:43, someone wrote:
> Hi,

Hi. First off, let me note that I proposed multiple things and each affects this in a different way (and some not at all).

> I saw your email at ghc-devs (I couldnt reply to your email because I wasnt subscribed at the time, hence this email) regarding msys2, and was wondering how it would affect the msys instructions at : 
> 
> https://wiki.haskell.org/Windows#Quickstart_on_Windows_7

Note that these steps results in a setup roughly equivalent to the one MinGHC provides.

> Currently I use these instructions to setup ghc in msys2, but I suspect these would change following your modifications.

If the mingw-unbundling proposal goes through and the MSYS2 package gets sanctioned, the new steps would be:

1. Install MSYS2 and update using pacman
2. Install ghc and cabal-install packages using pacman

For usage inside a POSIX shell, launch mingw64_shell.bat. For usage outside of MSYS2, add `$msysroot/mingw64/bin` to PATH.

-- 
David Macek


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4234 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150604/d3ba7f72/attachment.bin>

From johan.tibell at gmail.com  Thu Jun  4 23:52:30 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Fri, 5 Jun 2015 01:52:30 +0200
Subject: StrictData and the parser
In-Reply-To: <1433449686-sup-9195@sabre>
References: <1433447522.784285.287081417.2F46277B@webmail.messagingengine.com>
 <CAKFCL4Wb_r9C-BGA5CjbyNfQGKKVE+-+w4rwbobZB2tu5PgnGA@mail.gmail.com>
 <1433449686-sup-9195@sabre>
Message-ID: <CAK-tuPYdtZdnmFd_YzGyRStcNs+YZpKvKwQHcTEXqvS2-uEpVg@mail.gmail.com>

On Thu, Jun 4, 2015 at 10:30 PM, Edward Z. Yang <ezyang at mit.edu> wrote:

> Excerpts from Brandon Allbery's message of 2015-06-04 13:06:52 -0700:
> > Looks to me like it's confused about whether a ~ is part of an equality
> > constraint or is a laziness annotation. The former would be illegal at
> that
> > point, though, I'd think? Somewhere it believes a constraint might be
> > possible there, via btype.
> >
> > As ezyang says in the message I see just came in, you'll need extra
> > production rules to distinguish that top level. Although I'd wonder why
> it
> > believes an equality constraint is acceptable there in the first place;
> is
> > that a lurking bug in the parser?
>
> In general, the parser is more liberal than is actually required; we
> can give better error messages this way.
>
> Second, here is where it's ambiguous:
>
>     T a ~b
>
> where T is a TyCon.  Does this parse as
>
>     T a (~b)
>
> or
>
>     T a ~ b
>
> Parser doesn't currently distinguish these cases.
>

I guess we should parse it as T a (~b), just as we have unary minus bind
"tighter" with the following token.


>
> Edward
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150605/e2cf4e88/attachment.html>

From ezyang at mit.edu  Fri Jun  5 00:07:47 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Thu, 04 Jun 2015 17:07:47 -0700
Subject: StrictData and the parser
In-Reply-To: <CAK-tuPYdtZdnmFd_YzGyRStcNs+YZpKvKwQHcTEXqvS2-uEpVg@mail.gmail.com>
References: <1433447522.784285.287081417.2F46277B@webmail.messagingengine.com>
 <CAKFCL4Wb_r9C-BGA5CjbyNfQGKKVE+-+w4rwbobZB2tu5PgnGA@mail.gmail.com>
 <1433449686-sup-9195@sabre>
 <CAK-tuPYdtZdnmFd_YzGyRStcNs+YZpKvKwQHcTEXqvS2-uEpVg@mail.gmail.com>
Message-ID: <1433462457-sup-124@sabre>

Excerpts from Johan Tibell's message of 2015-06-04 16:52:30 -0700:
> I guess we should parse it as T a (~b), just as we have unary minus bind
> "tighter" with the following token.

Not in all contexts.

It is true that if you have 'data SLPair a b = SLP a ~ b' you want to
parse 'SLP a (~b)'

But if you have 'Maybe a ~ b' you want to parse '(Maybe a) ~ b'.

But in GADTs, if you have

    data SLPair a b where
        SLP :: a -> ~ b -> SLPair a b

you want a -> (~ b) -> SLPair a b

If the twiddle is not immediately after an arrow you don't want
that, e.g.

    data T a b where
        T :: a -> a ~ b -> SLPair a b

you want T :: a -> (a ~ b) -> SLPair a b

Edward

From simonpj at microsoft.com  Fri Jun  5 08:41:25 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 5 Jun 2015 08:41:25 +0000
Subject: StrictData and the parser
In-Reply-To: <1433462457-sup-124@sabre>
References: <1433447522.784285.287081417.2F46277B@webmail.messagingengine.com>
 <CAKFCL4Wb_r9C-BGA5CjbyNfQGKKVE+-+w4rwbobZB2tu5PgnGA@mail.gmail.com>
 <1433449686-sup-9195@sabre>
 <CAK-tuPYdtZdnmFd_YzGyRStcNs+YZpKvKwQHcTEXqvS2-uEpVg@mail.gmail.com>
 <1433462457-sup-124@sabre>
Message-ID: <66d5a2c774c1451e84b1be55ba56c7ab@DB4PR30MB030.064d.mgd.msft.net>

There is some similar stuff in GHC already, to do with "!".  It is both an infix operator and (in some contexts) a unary prefix to a function argument 
	f !x y = ...rhs...
See RdrHsSyn.splitBang.

Just possibly the same kind of stuff will help with "~"?

S

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Edward Z. Yang
|  Sent: 05 June 2015 01:08
|  To: Johan Tibell
|  Cc: "ghc-devs at haskell.org"
|  Subject: Re: StrictData and the parser
|  
|  Excerpts from Johan Tibell's message of 2015-06-04 16:52:30 -0700:
|  > I guess we should parse it as T a (~b), just as we have unary minus
|  > bind "tighter" with the following token.
|  
|  Not in all contexts.
|  
|  It is true that if you have 'data SLPair a b = SLP a ~ b' you want to
|  parse 'SLP a (~b)'
|  
|  But if you have 'Maybe a ~ b' you want to parse '(Maybe a) ~ b'.
|  
|  But in GADTs, if you have
|  
|      data SLPair a b where
|          SLP :: a -> ~ b -> SLPair a b
|  
|  you want a -> (~ b) -> SLPair a b
|  
|  If the twiddle is not immediately after an arrow you don't want that,
|  e.g.
|  
|      data T a b where
|          T :: a -> a ~ b -> SLPair a b
|  
|  you want T :: a -> (a ~ b) -> SLPair a b
|  
|  Edward
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From simonpj at microsoft.com  Fri Jun  5 10:44:42 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 5 Jun 2015 10:44:42 +0000
Subject: HEADS UP: Final call for 7.10.2 is soon
In-Reply-To: <1433438917.7963.101.camel@idefix>
References: <CAEs96n08kNWS0gOS1CtC1zkHz_Ay8WgwpE1ncRZCfinxcaVrrw@mail.gmail.com>
 <1433282583.7963.29.camel@idefix>
 <167097b7f7d94e529625a0a6bd8aa57e@DB4PR30MB030.064d.mgd.msft.net>
 <1433330440.7963.32.camel@idefix> <1433438917.7963.101.camel@idefix>
Message-ID: <ad8ab61fb3714a86950654198eae1d13@DB4PR30MB030.064d.mgd.msft.net>

| Now that I have a working GHC development environment (which was easier
| than thought thanks to the good documentation on the wiki), I am looking
| forward to work on ticket #7081 during the summer. When is the
| (approximate) deadline for feature patches for GHC 7.12?

Great!  We don't have a deadline for 7.12 yet.

Everyone: when would you *like* 7.12?
See https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.12.1
for what might be in it.

Simon

| -----Original Message-----
| From: Wolfgang Jeltsch [mailto:wolfgang at cs.ioc.ee]
| Sent: 04 June 2015 18:29
| To: Simon Peyton Jones
| Subject: Re: HEADS UP: Final call for 7.10.2 is soon
| 
| Hi again,
| 
| I have successfully set up my GHC development environment and have tried
| building incremental-computing with GHC HEAD. And yes,
| incremental-computing does go through. :-) Thank you for the good work.
| 
| Now that I have a working GHC development environment (which was easier
| than thought thanks to the good documentation on the wiki), I am looking
| forward to work on ticket #7081 during the summer. When is the
| (approximate) deadline for feature patches for GHC 7.12?
| 
| All the best,
| Wolfgang
| 
| Am Mittwoch, den 03.06.2015, 14:20 +0300 schrieb Wolfgang Jeltsch:
| > Hi,
| >
| > I did not try, since I do not have HEAD on my machine and thought that
| > it was too difficult and time consuming to install it. I can give it a
| > try, hoping that the GHC HEAD installation will be painless.
| >
| > All the best,
| > Wolfgang
| >
| > Am Mittwoch, den 03.06.2015, 08:57 +0000 schrieb Simon Peyton Jones:
| > > Wolfgang: did incremental-computing go through with HEAD?
| > >
| > >
| > >
| > > |  -----Original Message-----
| > > |  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| > > |  bounces at haskell.org] On Behalf Of Wolfgang Jeltsch
| > > |  Sent: 02 June 2015 23:03
| > > |  To: glasgow-haskell-users at haskell.org
| > > |  Subject: Re: HEADS UP: Final call for 7.10.2 is soon
| > > |
| > > |  Hi,
| > > |
| > > |  bug #10009 appears on the status page with status ?new?, although
| the
| > > |  bug should have been fixed in HEAD. Can this fix *please* be a
| part of
| > > |  GHC 7.10.2? At the moment, this bug breaks the incremental-
| computing
| > > |  package in a nontrivial way (and I think it breaks HList too).
| > > |
| > > |  All the best,
| > > |  Wolfgang
| > > |
| > > |  Am Dienstag, den 02.06.2015, 16:31 -0500 schrieb Austin Seipp:
| > > |  > Hi *,
| > > |  >
| > > |  > I've just finished merging all the latest patches for GHC 7.10.2
| > > |  into
| > > |  > the STABLE branch. All in all, we've fixed a lot of bugs (over
| 80
| > > |  > tickets closed)!
| > > |  >
| > > |  > So, we'll probably be doing a 7.10.2 release here in a few
| weeks.
| > > |  The
| > > |  > tentative plan was around the 14th, although it's not set in
| stone.
| > > |  > (At worst, it would be pushed from the 14th to the 21st).
| > > |  >
| > > |  > With that in mind, if I could quickly direct your attention to
| the
| > > |  GHC
| > > |  > bug tracker and the status page[1] - it would be really helpful
| if
| > > |  you
| > > |  > check if the things you want are fixed!
| > > |  >
| > > |  > Specifically, if you want something fixed for the 7.10.2
| release:
| > > |  >
| > > |  >   - Make sure there is a ticket. It really needs to exist or
| we'll
| > > |  just forget!
| > > |  >
| > > |  >   - If your bug is critical, please explain why! We really want
| to
| > > |  > kill showstoppers ASAP, because bugs are much cheaper to fix
| early.
| > > |  If
| > > |  > that's the case we can bump the priority if it's necessary to
| make
| > > |  > things clear.
| > > |  >
| > > |  >   - Set the milestone to 7.10.2. It'll automatically appear on
| the
| > > |  status page.
| > > |  >
| > > |  > That should be it - we'll be monitoring the status page
| regularly to
| > > |  > keep track of new things. The current bug list is pretty small -
| we
| > > |  > may move some of them out, or fix several more. So just try to
| let
| > > |  us
| > > |  > know.
| > > |  >
| > > |  > As a sidenote, I'm quite happy with this release - it's fixed
| dozens
| > > |  > of tricky bugs, improved some nasty corner cases in compiler
| > > |  > performance, and overall seems like it will be high quality.
| Thanks
| > > |  to
| > > |  > everyone who submitted patches!
| > > |  >
| > > |  > I'll send out another email next week as another reminder.
| > > |  >
| > > |  > [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2
| > > |  >
| > > |
| > > |
| > > |  _______________________________________________
| > > |  Glasgow-haskell-users mailing list
| > > |  Glasgow-haskell-users at haskell.org
| > > |  http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-
| users
| >
| 


From mle+hs at mega-nerd.com  Fri Jun  5 10:58:18 2015
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Fri, 5 Jun 2015 20:58:18 +1000
Subject: HEADS UP: Final call for 7.10.2 is soon
In-Reply-To: <CAEs96n08kNWS0gOS1CtC1zkHz_Ay8WgwpE1ncRZCfinxcaVrrw@mail.gmail.com>
References: <CAEs96n08kNWS0gOS1CtC1zkHz_Ay8WgwpE1ncRZCfinxcaVrrw@mail.gmail.com>
Message-ID: <20150605205818.0d9bc5bbc3837fa7a660a540@mega-nerd.com>

Austin Seipp wrote:

>   - If your bug is critical, please explain why! We really want to
> kill showstoppers ASAP, because bugs are much cheaper to fix early. If
> that's the case we can bump the priority if it's necessary to make
> things clear.

I know Arm is not a tier 1 platform, but I think #10375 is rather 
important.

The problem is that in ghci the following two statements:

     data X = Y deriving Eq
     Y == Y

will cause ghci to segfault. I've done some work debugging this, but
it has proved rather elusive.

This is a major regression with respect to ghc 7.8.

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

From alan.zimm at gmail.com  Fri Jun  5 11:09:35 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Fri, 5 Jun 2015 13:09:35 +0200
Subject: HEADS UP: Final call for 7.10.2 is soon
In-Reply-To: <CAEs96n08kNWS0gOS1CtC1zkHz_Ay8WgwpE1ncRZCfinxcaVrrw@mail.gmail.com>
References: <CAEs96n08kNWS0gOS1CtC1zkHz_Ay8WgwpE1ncRZCfinxcaVrrw@mail.gmail.com>
Message-ID: <CANma=H9mTEKg=O4LjmBkHbC54B425cqx00azY9A9jcz566pThA@mail.gmail.com>

>   - If your bug is critical, please explain why! We really want to
> kill showstoppers ASAP, because bugs are much cheaper to fix early. If
> that's the case we can bump the priority if it's necessary to make
> things clear.
>

#10443 is critical to me, it prevents the installation of ghc-mod, which is
widely used, and is a regression.

Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150605/1ce61cb1/attachment.html>

From g9ks157k at acme.softbase.org  Fri Jun  5 14:04:42 2015
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Fri, 05 Jun 2015 17:04:42 +0300
Subject: HEADS UP: Final call for 7.10.2 is soon
In-Reply-To: <ad8ab61fb3714a86950654198eae1d13@DB4PR30MB030.064d.mgd.msft.net>
References: <CAEs96n08kNWS0gOS1CtC1zkHz_Ay8WgwpE1ncRZCfinxcaVrrw@mail.gmail.com>
 <1433282583.7963.29.camel@idefix>
 <167097b7f7d94e529625a0a6bd8aa57e@DB4PR30MB030.064d.mgd.msft.net>
 <1433330440.7963.32.camel@idefix> <1433438917.7963.101.camel@idefix>
 <ad8ab61fb3714a86950654198eae1d13@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <1433513082.7963.115.camel@idefix>

Am Freitag, den 05.06.2015, 10:44 +0000 schrieb Simon Peyton Jones:
> > Now that I have a working GHC development environment (which was easier
> > than thought thanks to the good documentation on the wiki), I am looking
> > forward to work on ticket #7081 during the summer. When is the
> > (approximate) deadline for feature patches for GHC 7.12?
> 
> Great!  We don't have a deadline for 7.12 yet.

Should I assign the ticket to myself once I start working on it? What
else do I need to take care of regarding Trac?

All the best,
Wolfgang



From ezyang at mit.edu  Fri Jun  5 21:31:27 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Fri, 05 Jun 2015 14:31:27 -0700
Subject: Cabal and simultaneous installations of the same package
In-Reply-To: <20150511110452.GA17991@machine>
References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>
 <c635e60512f043a09c20a1a9c096d969@DB4PR30MB030.064d.mgd.msft.net>
 <500eca8d0bb845cea05a03a19a3dffa2@DB4PR30MB030.064d.mgd.msft.net>
 <CA+tcxkBcU8ZhY7YCf4qB8vb+y6UQmRq8jqV_kp2UOHozrzGS3g@mail.gmail.com>
 <CAM8RHpHhR9f+ZB081Uoepie=eSixiYR0qegG4vkNUC8HQgPtzw@mail.gmail.com>
 <32ac93f9ffb44faaa2a3771bbd9e3033@DB4PR30MB030.064d.mgd.msft.net>
 <20150511110452.GA17991@machine>
Message-ID: <1433539664-sup-2733@sabre>

> But if multiple versions of the same library can be linked into one
> binary, then the binary sizes will increase and therefore the memory
> usage might increase and even performance might decrease a bit if
> the number of cache misses increase.

This is not in the current proposal.  GHC knows how to deal with this,
but extending Cabal to do this is out of scope for the GSOC.

Edward

From ezyang at mit.edu  Fri Jun  5 23:46:36 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Fri, 05 Jun 2015 16:46:36 -0700
Subject: Clearing up confusion about package keys, package ids, et al
Message-ID: <1433547985-sup-4456@sabre>

I have written a new wiki page which tries to explicate these concepts:

https://ghc.haskell.org/trac/ghc/wiki/Commentary/Packages/Concepts

I haven't finished writing my proposal but one thing that I am going
to argue is that we are going to need *MORE* package identification
concepts (sorry Simon!); e.g. reusing package keys as Nix keys just
isn't going to work.

Edward

From mark.lentczner at gmail.com  Sun Jun  7 16:33:26 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Sun, 7 Jun 2015 09:33:26 -0700
Subject: the platform has outgrown Travis-CI
Message-ID: <CAAOoiFbeM07GriYxjZYXDNy4gumOE+OhWhDwv_OWqkuvUuqwBg@mail.gmail.com>

I finally figured out what was wrong with the Travis CI build for Haskell
Platform, and got it all working w/hvr's .debs of GHC (for the boot
compiler)... and ran smack into this:

Your test run exceeded 50 minutes.


SO... I'd like to find another CI solution. Is phabricator.haskell.org an
option? Can we / should we create a project there?

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150607/42771464/attachment.html>

From cma at bitemyapp.com  Sun Jun  7 18:31:29 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Sun, 7 Jun 2015 13:31:29 -0500
Subject: the platform has outgrown Travis-CI
In-Reply-To: <CAAOoiFbeM07GriYxjZYXDNy4gumOE+OhWhDwv_OWqkuvUuqwBg@mail.gmail.com>
References: <CAAOoiFbeM07GriYxjZYXDNy4gumOE+OhWhDwv_OWqkuvUuqwBg@mail.gmail.com>
Message-ID: <CADnndOqZX2rbg=tGaWna+rd-LZ42RzhtPKvkkbYD6y=wrPgV=Q@mail.gmail.com>

I rang the gong of the TravisCI people about this. I'll let y'all know if
they come back with an answer, but the GH issue timeouts were being
discussed in didn't look promising. They were suggesting to the reporter
that they break the build up into smaller components. Old ticket though ?
something might've changed.


On Sun, Jun 7, 2015 at 11:33 AM, Mark Lentczner <mark.lentczner at gmail.com>
wrote:

> I finally figured out what was wrong with the Travis CI build for Haskell
> Platform, and got it all working w/hvr's .debs of GHC (for the boot
> compiler)... and ran smack into this:
>
> Your test run exceeded 50 minutes.
>
>
> SO... I'd like to find another CI solution. Is phabricator.haskell.org an
> option? Can we / should we create a project there?
>
> - Mark
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150607/fe860470/attachment.html>

From mle+hs at mega-nerd.com  Sun Jun  7 18:39:55 2015
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Mon, 8 Jun 2015 04:39:55 +1000
Subject: the platform has outgrown Travis-CI
In-Reply-To: <CAAOoiFbeM07GriYxjZYXDNy4gumOE+OhWhDwv_OWqkuvUuqwBg@mail.gmail.com>
References: <CAAOoiFbeM07GriYxjZYXDNy4gumOE+OhWhDwv_OWqkuvUuqwBg@mail.gmail.com>
Message-ID: <20150608043955.3d212878bb7d5182503da0b9@mega-nerd.com>

Mark Lentczner wrote:

> I finally figured out what was wrong with the Travis CI build for Haskell
> Platform, and got it all working w/hvr's .debs of GHC (for the boot
> compiler)... and ran smack into this:

Another option you or others may want to pursue is setting up a self
manager Jenkins instance. I have a personal Jenkins instance that 
includes Arm and PowerPC slave build nodes. Setup is and maintenance
is relatively easy, but slightly less convienient than Travis.

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

From dan.doel at gmail.com  Sun Jun  7 19:34:16 2015
From: dan.doel at gmail.com (Dan Doel)
Date: Sun, 7 Jun 2015 15:34:16 -0400
Subject: the platform has outgrown Travis-CI
In-Reply-To: <CAAOoiFbeM07GriYxjZYXDNy4gumOE+OhWhDwv_OWqkuvUuqwBg@mail.gmail.com>
References: <CAAOoiFbeM07GriYxjZYXDNy4gumOE+OhWhDwv_OWqkuvUuqwBg@mail.gmail.com>
Message-ID: <CAHEA9tN1oBmxfg9votmzP0pqUX=U7FkYF40AFj0kk6jUF3GnYw@mail.gmail.com>

I don't know what tests you're running, but if it includes building all the
test suites of everything in the platform, you might want to turn that off
for vector if possible. Just building vector's tests on 7.10.1 is enough to
kill Travis right now. Turning them off might buy you some leeway.

-- Dan

On Sun, Jun 7, 2015 at 12:33 PM, Mark Lentczner <mark.lentczner at gmail.com>
wrote:

> I finally figured out what was wrong with the Travis CI build for Haskell
> Platform, and got it all working w/hvr's .debs of GHC (for the boot
> compiler)... and ran smack into this:
>
> Your test run exceeded 50 minutes.
>
>
> SO... I'd like to find another CI solution. Is phabricator.haskell.org an
> option? Can we / should we create a project there?
>
> - Mark
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150607/37fff7e6/attachment.html>

From pali.gabor at gmail.com  Mon Jun  8 19:07:37 2015
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Mon, 8 Jun 2015 21:07:37 +0200
Subject: Broken build: Documentation mistake
Message-ID: <CAHnG2CwBGTf7jho4LQ42_0OEa__oQ-FqQUqCSV3eeuZqDfpqRQ@mail.gmail.com>

Hello there,

Looks like there is some problem with one of the recent changes to The
User's Guide source code as it cannot be built any more [1] (since
about June 4).  Here is the error message, hopefully it helps with
fixing the cause:

[..]
Build users_guide.ps
latex failed
users_guide.tex:15584: Cannot determine size of graphic in
docs/users_guide//prof_scc.png (no BoundingBox).
users_guide.tex:15584: leading text: ...width=645pt,height=428pt]{prof_scc.png}
Unexpected error occured
[ -f docs/users_guide/users_guide.ps ]
docs/users_guide/ghc.mk:26: recipe for target
'docs/users_guide/users_guide.ps' failed
gmake[1]: *** [docs/users_guide/users_guide.ps] Error 1
Makefile:102: recipe for target 'all' failed
gmake: *** [all] Error 2

Thanks,
G?bor

[1] http://haskell.inf.elte.hu/builders/freebsd-amd64-head/652/10.html

From austin at well-typed.com  Mon Jun  8 21:19:55 2015
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 8 Jun 2015 16:19:55 -0500
Subject: Broken build: Documentation mistake
In-Reply-To: <CAHnG2CwBGTf7jho4LQ42_0OEa__oQ-FqQUqCSV3eeuZqDfpqRQ@mail.gmail.com>
References: <CAHnG2CwBGTf7jho4LQ42_0OEa__oQ-FqQUqCSV3eeuZqDfpqRQ@mail.gmail.com>
Message-ID: <CAEs96n13=tXJt3aoG2DUZs7XGz7iddmvo_LxHNm5rbCBRLLMGQ@mail.gmail.com>

Sigh. I'll revert this. I couldn't reproduce this on my two machines,
but I should have figured it would have broken something. I took a
chance. :)

I'll try it on FreeBSD before pushing.

On Mon, Jun 8, 2015 at 2:07 PM, P?li G?bor J?nos <pali.gabor at gmail.com> wrote:
> Hello there,
>
> Looks like there is some problem with one of the recent changes to The
> User's Guide source code as it cannot be built any more [1] (since
> about June 4).  Here is the error message, hopefully it helps with
> fixing the cause:
>
> [..]
> Build users_guide.ps
> latex failed
> users_guide.tex:15584: Cannot determine size of graphic in
> docs/users_guide//prof_scc.png (no BoundingBox).
> users_guide.tex:15584: leading text: ...width=645pt,height=428pt]{prof_scc.png}
> Unexpected error occured
> [ -f docs/users_guide/users_guide.ps ]
> docs/users_guide/ghc.mk:26: recipe for target
> 'docs/users_guide/users_guide.ps' failed
> gmake[1]: *** [docs/users_guide/users_guide.ps] Error 1
> Makefile:102: recipe for target 'all' failed
> gmake: *** [all] Error 2
>
> Thanks,
> G?bor
>
> [1] http://haskell.inf.elte.hu/builders/freebsd-amd64-head/652/10.html
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



-- 
Regards,

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

From simonpj at microsoft.com  Mon Jun  8 21:52:42 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 8 Jun 2015 21:52:42 +0000
Subject: windows failure in testsuite
Message-ID: <827780cfc2d244e0a20ca65f8f6d2c1a@DB4PR30MB030.064d.mgd.msft.net>

Windows and testsuite folk: The testsuite framework is crashing on my 32-bit Windows machine, with the error below.  Happens when the stderr output differs from expected.
I know that there have been recent changes in the testsuite stuff.  Could you fix please?
Thanks
Simon
=====> T4254(normal) 1587 of 4522 [2, 15, 0]
cd ./indexed-types/should_fail &&  "C:/code/HEAD/inplace/bin/ghc-stage2.exe" -c T4254.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history   > T4254.comp.stderr 2>&1
Actual stderr output differs from expected:
'diff' is not recognized as an internal or external command,
operable program or batch file.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150608/12b7105d/attachment.html>

From pali.gabor at gmail.com  Tue Jun  9 07:10:49 2015
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Tue, 9 Jun 2015 09:10:49 +0200
Subject: Broken build: Documentation mistake
In-Reply-To: <CAEs96n13=tXJt3aoG2DUZs7XGz7iddmvo_LxHNm5rbCBRLLMGQ@mail.gmail.com>
References: <CAHnG2CwBGTf7jho4LQ42_0OEa__oQ-FqQUqCSV3eeuZqDfpqRQ@mail.gmail.com>
 <CAEs96n13=tXJt3aoG2DUZs7XGz7iddmvo_LxHNm5rbCBRLLMGQ@mail.gmail.com>
Message-ID: <CAHnG2Cw31JOJmouBifwShgPEtfwsckNQ_q7YPFidjEdX97EsbQ@mail.gmail.com>

2015-06-08 23:19 GMT+02:00 Austin Seipp <austin at well-typed.com>:
> Sigh. I'll revert this. I couldn't reproduce this on my two machines,
> but I should have figured it would have broken something. I took a
> chance. :)

So the documentation builds fine for you?  I believed the FreeBSD
builders failed only because the they always try to build the
documentation as well, while that might not be the part of the
standard validation pass.

> I'll try it on FreeBSD before pushing.

I can help with this, you do not have to struggle with FreeBSD just
because of this -- just send me the patch to try.  However, I think
this may not be fully an operating system-related issue, perhaps the
documentation toolchain is not up-to-date enough.  For example, I have
this version of the latex command installed currently:

pdfTeX 3.14159265-2.6-1.40.15 (Web2C 2014)
kpathsea version 6.2.0
[..]
Compiled with libpng 1.6.16; using libpng 1.6.16
Compiled with zlib 1.2.3; using zlib 1.2.3
Compiled with xpdf version 3.03

From thomasmiedema at gmail.com  Tue Jun  9 11:51:21 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Tue, 9 Jun 2015 13:51:21 +0200
Subject: windows failure in testsuite
In-Reply-To: <827780cfc2d244e0a20ca65f8f6d2c1a@DB4PR30MB030.064d.mgd.msft.net>
References: <827780cfc2d244e0a20ca65f8f6d2c1a@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAD3WKgjKOPVTq_B_+hHmihSX7jXKxWtcCEZV3is0KCNjwid-HA@mail.gmail.com>

Hi Simon,

this doesn't look like a problem with the testsuite driver. The testsuite
driver indeed calls 'diff', but has been doing so for years. Nothing
changed there. I just ran the testsuite on Windows with msys2 to double
check, and didn't get any framework errors either.

Something changed in your Windows setup maybe?

Cheers,
Thomas


On Mon, Jun 8, 2015 at 11:52 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>  Windows and testsuite folk: The testsuite framework is crashing on my
> 32-bit Windows machine, with the error below.  Happens when the stderr
> output differs from expected.
>
> I know that there have been recent changes in the testsuite stuff.  Could
> you fix please?
>
> Thanks
>
> Simon
>
> =====> T4254(normal) 1587 of 4522 [2, 15, 0]
>
> cd ./indexed-types/should_fail &&
> "C:/code/HEAD/inplace/bin/ghc-stage2.exe" -c T4254.hs -fforce-recomp
> -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts
> -fno-warn-tabs -fno-ghci-history   > T4254.comp.stderr 2>&1
>
> Actual stderr output differs from expected:
>
> *'diff' is not recognized as an internal or external command,*
>
> *operable program or batch file.*
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150609/83d9c864/attachment.html>

From austin at well-typed.com  Tue Jun  9 12:34:08 2015
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 9 Jun 2015 07:34:08 -0500
Subject: Broken build: Documentation mistake
In-Reply-To: <CAHnG2Cw31JOJmouBifwShgPEtfwsckNQ_q7YPFidjEdX97EsbQ@mail.gmail.com>
References: <CAHnG2CwBGTf7jho4LQ42_0OEa__oQ-FqQUqCSV3eeuZqDfpqRQ@mail.gmail.com>
 <CAEs96n13=tXJt3aoG2DUZs7XGz7iddmvo_LxHNm5rbCBRLLMGQ@mail.gmail.com>
 <CAHnG2Cw31JOJmouBifwShgPEtfwsckNQ_q7YPFidjEdX97EsbQ@mail.gmail.com>
Message-ID: <CAEs96n3P3pexrBpg5r75+4c562LeMfkototeaH_ZjP+VMfvpQA@mail.gmail.com>

Yes, please try the patch here - I think it should fix it (it carries
an explanation too): https://phabricator.haskell.org/D970

On Tue, Jun 9, 2015 at 2:10 AM, P?li G?bor J?nos <pali.gabor at gmail.com> wrote:
> 2015-06-08 23:19 GMT+02:00 Austin Seipp <austin at well-typed.com>:
>> Sigh. I'll revert this. I couldn't reproduce this on my two machines,
>> but I should have figured it would have broken something. I took a
>> chance. :)
>
> So the documentation builds fine for you?  I believed the FreeBSD
> builders failed only because the they always try to build the
> documentation as well, while that might not be the part of the
> standard validation pass.
>
>> I'll try it on FreeBSD before pushing.
>
> I can help with this, you do not have to struggle with FreeBSD just
> because of this -- just send me the patch to try.  However, I think
> this may not be fully an operating system-related issue, perhaps the
> documentation toolchain is not up-to-date enough.  For example, I have
> this version of the latex command installed currently:
>
> pdfTeX 3.14159265-2.6-1.40.15 (Web2C 2014)
> kpathsea version 6.2.0
> [..]
> Compiled with libpng 1.6.16; using libpng 1.6.16
> Compiled with zlib 1.2.3; using zlib 1.2.3
> Compiled with xpdf version 3.03
>



-- 
Regards,

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

From george.colpitts at gmail.com  Tue Jun  9 12:39:47 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Tue, 9 Jun 2015 09:39:47 -0300
Subject: Time files... and here's another alpha HP for 7.10
In-Reply-To: <CAB-d4A5ta64nYJv4F3AW+d2kEgweO6oNN-2P2hazVm8BTkMb0g@mail.gmail.com>
References: <CAAOoiFaNBDCkS7TyZtv5WJ7m0AhnBHbLObyDnn7r8=8A3EkLHg@mail.gmail.com>
 <CAAOoiFagwoGHOmCh6m2BbG4_qNU=qFuuyqjGcq57neE-3_P5+A@mail.gmail.com>
 <CAB-d4A7CW5ZLND0LpLuG4V7jEyo874wo1kDQ15T-R1=QGaF_eA@mail.gmail.com>
 <CAB-d4A6pVU4nmWSmXz7Lr=bGNmLw+Z3ejZ5QE84BYtiDHFWxWQ@mail.gmail.com>
 <CAAOoiFYqhUeCeHhDF3M+BvOkfO-S0n50tOaU7r3D++RFVAW5zw@mail.gmail.com>
 <CAB-d4A5ta64nYJv4F3AW+d2kEgweO6oNN-2P2hazVm8BTkMb0g@mail.gmail.com>
Message-ID: <CAB-d4A5_aLS6wpJzW=biinRK_48c93bV6Go8pzVjObN_AF-zOg@mail.gmail.com>

I uninstalled, reinstalled , did a cabal install of haddock then ghc-core
and threadscope and saw no errors so I guess we are fine as long as the
next version includes the latest haddock. I notice on the 7.10.2 active
tickets page there is a ticket saying that 7.10.2 needs the latest haddock.

On Tue, Jun 2, 2015 at 1:01 PM, George Colpitts <george.colpitts at gmail.com>
wrote:

> Yes
>
>
> ghc --print-libdir
>
> /Library/Frameworks/GHC.framework/Versions/7.10.1.20150601-x86_64/usr/lib/ghc-7.10.1.20150601
> bash-3.2$
>
> On Tue, Jun 2, 2015 at 10:22 AM, Mark Lentczner <mark.lentczner at gmail.com>
> wrote:
>
>> On Tue, Jun 2, 2015 at 4:40 AM, George Colpitts <
>> george.colpitts at gmail.com> wrote:
>>
>>> I guess I should file a haddock bug as I got the same error installing
>>> threadscope
>>
>>
>>
>> Does ghc --print-libdir display the correct path? (That is, with the
>> full version number.)
>>
>> - Mark
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150609/19975961/attachment.html>

From mark.lentczner at gmail.com  Tue Jun  9 14:02:24 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Tue, 9 Jun 2015 07:02:24 -0700
Subject: Time files... and here's another alpha HP for 7.10
In-Reply-To: <CAB-d4A5_aLS6wpJzW=biinRK_48c93bV6Go8pzVjObN_AF-zOg@mail.gmail.com>
References: <CAAOoiFaNBDCkS7TyZtv5WJ7m0AhnBHbLObyDnn7r8=8A3EkLHg@mail.gmail.com>
 <CAAOoiFagwoGHOmCh6m2BbG4_qNU=qFuuyqjGcq57neE-3_P5+A@mail.gmail.com>
 <CAB-d4A7CW5ZLND0LpLuG4V7jEyo874wo1kDQ15T-R1=QGaF_eA@mail.gmail.com>
 <CAB-d4A6pVU4nmWSmXz7Lr=bGNmLw+Z3ejZ5QE84BYtiDHFWxWQ@mail.gmail.com>
 <CAAOoiFYqhUeCeHhDF3M+BvOkfO-S0n50tOaU7r3D++RFVAW5zw@mail.gmail.com>
 <CAB-d4A5ta64nYJv4F3AW+d2kEgweO6oNN-2P2hazVm8BTkMb0g@mail.gmail.com>
 <CAB-d4A5_aLS6wpJzW=biinRK_48c93bV6Go8pzVjObN_AF-zOg@mail.gmail.com>
Message-ID: <CAAOoiFYyh2T=qjCNgyamm-TzG5U4JnZthjWPtzCLwhyKiWAUQw@mail.gmail.com>

When you did the cabal install of haddock, which haddock did you get? Isn't
2.16.0 the latest? And that should be what is in the Platform.

I guess I should check that the haddock in GHC is actually 2.16.0!
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150609/3f0745f0/attachment.html>

From dluposchainsky at googlemail.com  Tue Jun  9 20:43:30 2015
From: dluposchainsky at googlemail.com (David Luposchainsky)
Date: Tue, 09 Jun 2015 22:43:30 +0200
Subject: MonadFail proposal (MFP): Moving fail out of Monad
Message-ID: <55774FF2.8020505@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello *,

the subject says it all. After we successfully put `=>`
into Monad, it is time to remove something in return: `fail`.

Like with the AMP, I wrote up the proposal in Markdown
format on Github, which you can find below as a URL, and in
verbatim copy at the end of this email. It provides an
overview over the intended outcome, which design decisions
we had to take, and how our initial plan for the transition
looks like. There are also some issues left open to
discussion.

https://github.com/quchen/articles/blob/master/monad_fail.md

Here's a short abstract:

- - Move `fail` from `Monad` into a new class `MonadFail`.
- - Code using failable patterns will receive a more
  restrictive `MonadFail` constraint. Code without this
  constraint will be safe to use for all Monads.
- - Transition will take at least two GHC releases.
  GHC 7.12 will include the new class, and generate
  warnings asking users to make their failable patterns
  compliant.
- - Stackage showed an upper bound of less than 500 breaking
  code fragments when compiled with the new desugaring.

For more details, refer to the link or the paste at the end.


Let's get going!

David aka quchen





===============================================================
===============================================================
===============================================================





`MonadFail` proposal (MFP)
==========================

A couple of years ago, we proposed to make `Applicative` a superclass of
`Monad`, which successfully killed the single most ugly thing in Haskell
as of GHC 7.10.

Now, it's time to tackle the other major issue with `Monad`: `fail` being a
part of it.

You can contact me as usual via IRC/Freenode as *quchen*, or by email to
*dluposchainsky at the email service of Google*. This file will also be posted
on the ghc-devs@ and libraries@ mailing lists, as well as on Reddit.



Overview
- --------

- - **The problem** - reason for the proposal
- - **MonadFail class** - the solution
- - **Discussion** - explaining our design choices
- - **Adapting old code** - how to prepare current code to transition smoothly
- - **Esimating the breakage** - how much stuff we will break (spoiler: not much)
- - **Transitional strategy** - how to break as little as possible while
transitioning
- - **Current status**




The problem
- -----------

Currently, the `<-` symbol is unconditionally desugared as follows:

```haskell
do pat <- computation     >>>     let f pat = more
   more                   >>>         f _ = fail "..."
                          >>>     in  computation >>= f
```

The problem with this is that `fail` cannot (!) be sensibly implemented for
many monads, for example `State`, `IO`, `Reader`. In those cases it defaults to
`error`. As a consequence, in current Haskell, you can not use
`Monad`-polymorphic code safely, because although it claims to work for all
`Monad`s, it might just crash on you. This kind of implicit non-totality baked
into the class is *terrible*.

The goal of this proposal is adding the `fail` only when necessary and
reflecting that in the type signature of the `do` block, so that it can be used
safely, and more importantly, is guaranteed not to be used if the type
signature does not say so.



`MonadFail` class
- -----------------

To fix this, introduce a new typeclass:

```haskell
class Monad m => MonadFail m where
    fail :: String -> m a
```

Desugaring can now be changed to produce this constraint when necessary. For
this, we have to decide when a pattern match can not fail; if this is the case,
we can omit inserting the `fail` call.

The most trivial examples of unfailable patterns are of course those that match
anywhere unconditionally,

```haskell
do x <- action     >>>     let f x = more
   more            >>>     in  action >>= f
```

In particular, the programmer can assert any pattern be unfailable by making it
irrefutable using a prefix tilde:

```haskell
do ~pat <- action     >>>     let f ~pat = more
   more               >>>     in  action >>= f
```

A class of patterns that are conditionally failable are `newtype`s, and single
constructor `data` types, which are unfailable by themselves, but may fail
if matching on their fields is done with failable paterns.

```haskell
data Newtype a = Newtype a

- -- "x" cannot fail
do Newtype x <- action            >>>     let f (Newtype x) = more
   more                           >>>     in  action >>= f

- -- "Just x" can fail
do Newtype (Just x) <- action     >>>     let f (Newtype (Just x)) = more
   more                           >>>         f _ = fail "..."
                                  >>>     in  action >>= f
```

`ViewPatterns` are as failable as the pattern the view is matched against.
Patterns like `(Just -> Just x)` should generate a `MonadFail` constraint even
when it's "obvious" from the view's implementation that the pattern will always
match. From an implementor's perspective, this means that only types (and their
constructors) have to be looked at, not arbitrary values (like functions),
which is impossible to do statically in general.

```haskell
do (view ->  pat) <- action     >>>     let f (view ->  pat) = more
   more                         >>>         f _ = fail "..."
                                >>>     in  action >>= f

do (view -> ~pat) <- action     >>>     let f (view -> ~pat) = more
   more                         >>>     in  action >>= f
```

A similar issue arises for `PatternSynonyms`, which we cannot inspect during
compilation sufficiently. A pattern synonym will therefore always be considered
failable.

```haskell
do PatternSynonym x <- action     >>>     let f PatternSynonym x = more
   more                           >>>     in f _ = fail "..."
                                  >>>     in  action >>= f
```



Discussion
- ----------

- - Although for many `MonadPlus` `fail _ = mzero`, a separate `MonadFail` class
  should be created instead of just using that.

    - A parser might fail with an error message involving positional
      information. Some libraries, like `Binary`, provide `fail` as their
      only interface to fail a decoding step.

    - Although `STM` is `MonadPlus`, it uses the default `fail = error`. It
      will therefore not get a `MonadFail` instance.

- - What laws should `fail` follow? **Left zero**,

  ```haskell
  ? s f.  fail s >>= f  ?  fail s
  ```

  A call to `fail` should abort the computation. In this sense, `fail` would
  become a close relative of `mzero`. It would work well with the common
  definition `fail _ = mzero`, and give a simple guideline to the intended
  usage and effect of the `MonadFail` class.

- - Rename `fail`? **No.** Old code might use `fail` explicitly and we might
  avoid breaking it, the Report talks about `fail`, and we have a solid
  migration strategy that does not require a renaming.

- - Remove the `String` argument? **No.** The `String` might help error reporting
  and debugging. `String` may be ugly, but it's the de facto standard for
  simple text in GHC. No high performance string operations are to be
  expected with `fail`, so this breaking change would in no way be justified.
  Also note that explicit `fail` calls would break if we removed the argument.

- - How sensitive would existing code be to subtle changes in the strictness
  behaviour of `do` notation pattern matching? **It doesn't.** The
  implementation does not affect strictness at all, only the desugaring step.
  Care must be taken when fixing warnings by making patterns irrefutable using
  `~`, as that *does* affect strictness. (Cf. difference between lazy/strict
  State)

- - The `Monad` constraint for `MonadFail` seems unnecessary. Should we drop or
  relax it? What other things should be considered?

  - Applicative `do` notation is coming sooner or later, `fail` might be useful
    in this more general scenario. Due to the AMP, it is trivial to change
    the `MonadFail` superclass to `Applicative` later. (The name will be a bit
    misleading, but it's a very small price to pay.)
  - The class might be misused for a strange pointed type if left without
    any constraint. This is not the intended use at all.

  I think we should keep the `Monad` superclass for three main reasons:

  - We don't want to see `(Monad m, MonadFail m) =>` all over the place.
  - The primary intended use of `fail` is for desugaring do-notation anyway.
  - Retroactively removing superclasses is easy, but adding them is hard
    (see AMP).




Adapting old code
- -----------------

- - Help! My code is broken because of a missing `MonadFail` instance!

  *Here are your options:*

    1. Write a `MonadFail` instance (and bring it into scope)

       ```haskell
       #if !MIN_VERSION_base(4,11,0)
       -- Control.Monad.Fail import will become redundant in GHC 7.16+
       import qualified Control.Monad.Fail as Fail
       #endif
       import Control.Monad

       instance Monad Foo where
         (>>=) = <...bind impl...>
         -- NB: `return` defaults to `pure`

       #if !MIN_VERSION_base(4,11,0)
         -- Monad(fail) will be removed in GHC 7.16+
         fail = Fail.fail
       #endif

       instance MonadFail Foo where
         fail = <...fail implementation...>
       ```

    2. Change your pattern to be irrefutable

    3. Emulate the old behaviour by desugaring the pattern match by hand:

       ```haskell
       do Left e <- foobar
          stuff
       ```

       becomes

       ```haskell
       do x <- foobar
          e <- case foobar of
              Left e' -> e'
              Right r -> error "Pattern match failed" -- Boooo
          stuff
       ```

       The point is you'll have to do your dirty laundry yourself now if you
       have a value that *you* know will always match, and if you don't handle
       the other patterns you'll get incompleteness warnings, and the compiler
       won't silently eat those for you.

- - Help! My code is broken because you removed `fail` from `Monad`, but my class
  defines it!

  *Delete that part of the instance definition.*



Esimating the breakage
- ----------------------

Using our initial implementation, I compiled stackage-nightly, and grepped the
logs for found "invalid use of fail desugaring". Assuming my implementation
is correct, the number of "missing `MonadFail`" warnings generated is 487.
Note that I filtered out `[]`, `Maybe` and `ReadPrec`, since those can be given
a `MonadFail` instance from within GHC, and no breakage is expected from them.

The build logs can be found [here][stackage-logs]. Search for "failable
pattern" to find your way to the still pretty raw warnings.




Transitional strategy
- ---------------------

The roadmap is similar to the [AMP][amp], the main difference being that since
`MonadFail` does not exist yet, we have to introduce new functionality and then
switch to it.

* **GHC 7.12 / base-4.9**

    - Add module `Control.Monad.Fail` with new class `MonadFail(fail)` so
      people can start writing instances for it.

      `Control.Monad` only re-exports the class `MonadFail`, but not its
      `fail` method.

      NB: At this point, `Control.Monad.Fail.fail` clashes with
      `Prelude.fail` and `Control.Monad.fail`.

    - *(non-essential)* Add a language extension `-XMonadFail` that
      changes desugaring to use `MonadFail(fail)` instead of `Monad(fail)`.

      This has the effect that typechecking will infer a `MonadFail` constraint
      for `do` blocks with failable patterns, just as it is planned to do when
      the entire thing is done.

    - Warn when a `do`-block that contains a failable pattern is
      desugared, but there is no `MonadFail`-instance in scope: "Please add the
      instance or change your pattern matching." Add a flag to control whether
      this warning appears.

    - Warn when an instance implements the `fail` function (or when `fail`
      is imported as a method of `Monad`), as it will be removed from the
      `Monad` class in the future. (See also [GHC #10071][trac-10071])

3. GHC 7.14

    - Switch `-XMonadFail` on by default.
    - Remove the desugaring warnings.

3. GHC 7.16

    - Remove `-XMonadFail`, leaving its effects on at all times.
    - Remove `fail` from `Monad`.
    - Instead, re-export `Control.Monad.Fail.fail` as `Prelude.fail` and
      `Control.Monad.fail`.
    - `Control.Monad.Fail` is now a redundant module that can be considered
      deprecated.



Current status
- --------------

- - [ZuriHac 2015 (29.5. - 31.5.)][zurihac]: Franz Thoma (@fmthoma) and me
  (David Luposchainsky aka @quchen) started implementing the MFP in GHC.

    - Desugaring to the new `fail` can be controlled via a new langauge
      extension, `MonadFailDesugaring`.
    - If the language extension is turned off, a warning will be emitted for
      code that would break if it was enabled.
    - Warnings are emitted for types that *have* a *MonadFail* instance. This
      still needs to be fixed.
    - The error message are readable, but should be more so. We're still
      on this.
- - 2015-06-09: Estimated breakage by compiling Stackage. Smaller than expected.



[amp]: https://github.com/quchen/articles/blob/master/applicative_monad.md
[stackage-logs]: https://www.dropbox.com/s/knz0i979skam4zs/stackage-build.tar.xz?dl=0
[trac-10071]: https://ghc.haskell.org/trac/ghc/ticket/10071
[zurihac]: https://wiki.haskell.org/ZuriHac2015

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVd0/yAAoJELrQsaT5WQUshbUH/A3W0itVAk7ao8rtxId5unCJ
7StriKVkTyLAkkrbRJngM4MHEKiCsoyIgr8kBIwSHgk194GxeP2NCF4ijuBZoDBt
+Uci+6BCBinV8+OzfrfTcJb4+8iw1j+eLWJ/Nz/JDMDNCiyzyC0SMsqGa+ssOz7H
/2mqPkQjQgpHuP5PTRLHKPPIsayCQvTbZR1f14KhuMN2SPDE+WY4rqugu//XuIkN
u1YssIf5l8mEez/1ljaqGL55cTI0UNg2z0iA0bFl/ajHaeQ6mc5BAevWfSohAMW7
7PIt13p9NIaMHnikmI+YJszm2IEaXuv47mGgbyDV//nHq3fwWN+naB+1mPX2eSU=
=vPAL
-----END PGP SIGNATURE-----

From hvr at gnu.org  Tue Jun  9 21:09:35 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Tue, 09 Jun 2015 23:09:35 +0200
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <55774FF2.8020505@gmail.com> (David Luposchainsky's message of
 "Tue, 09 Jun 2015 22:43:30 +0200")
References: <55774FF2.8020505@gmail.com>
Message-ID: <87twugbncg.fsf@gnu.org>

On 2015-06-09 at 22:43:30 +0200, David Luposchainsky wrote:

[...]

> https://github.com/quchen/articles/blob/master/monad_fail.md
>
> Here's a short abstract:
>
> - Move `fail` from `Monad` into a new class `MonadFail`.

[...]

+1 obviously :-)

From ekmett at gmail.com  Tue Jun  9 22:19:00 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 10 Jun 2015 00:19:00 +0200
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <55774FF2.8020505@gmail.com>
References: <55774FF2.8020505@gmail.com>
Message-ID: <CAJumaK-r-q5DTk_WKGGYZ8idfvMx__LQOAwMJcUGkB0jCSeWug@mail.gmail.com>

+1 from me for both the spirit and the substance of this proposal. We've
been talking about this in the abstract for a while now (since ICFP 2013 or
so) and as concrete plans go, this strikes me as straightforward and
implementable.

-Edward

On Tue, Jun 9, 2015 at 10:43 PM, David Luposchainsky <
dluposchainsky at googlemail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello *,
>
> the subject says it all. After we successfully put `=>`
> into Monad, it is time to remove something in return: `fail`.
>
> Like with the AMP, I wrote up the proposal in Markdown
> format on Github, which you can find below as a URL, and in
> verbatim copy at the end of this email. It provides an
> overview over the intended outcome, which design decisions
> we had to take, and how our initial plan for the transition
> looks like. There are also some issues left open to
> discussion.
>
> https://github.com/quchen/articles/blob/master/monad_fail.md
>
> Here's a short abstract:
>
> - - Move `fail` from `Monad` into a new class `MonadFail`.
> - - Code using failable patterns will receive a more
>   restrictive `MonadFail` constraint. Code without this
>   constraint will be safe to use for all Monads.
> - - Transition will take at least two GHC releases.
>   GHC 7.12 will include the new class, and generate
>   warnings asking users to make their failable patterns
>   compliant.
> - - Stackage showed an upper bound of less than 500 breaking
>   code fragments when compiled with the new desugaring.
>
> For more details, refer to the link or the paste at the end.
>
>
> Let's get going!
>
> David aka quchen
>
>
>
>
>
> ===============================================================
> ===============================================================
> ===============================================================
>
>
>
>
>
> `MonadFail` proposal (MFP)
> ==========================
>
> A couple of years ago, we proposed to make `Applicative` a superclass of
> `Monad`, which successfully killed the single most ugly thing in Haskell
> as of GHC 7.10.
>
> Now, it's time to tackle the other major issue with `Monad`: `fail` being a
> part of it.
>
> You can contact me as usual via IRC/Freenode as *quchen*, or by email to
> *dluposchainsky at the email service of Google*. This file will also be
> posted
> on the ghc-devs@ and libraries@ mailing lists, as well as on Reddit.
>
>
>
> Overview
> - --------
>
> - - **The problem** - reason for the proposal
> - - **MonadFail class** - the solution
> - - **Discussion** - explaining our design choices
> - - **Adapting old code** - how to prepare current code to transition
> smoothly
> - - **Esimating the breakage** - how much stuff we will break (spoiler:
> not much)
> - - **Transitional strategy** - how to break as little as possible while
> transitioning
> - - **Current status**
>
>
>
>
> The problem
> - -----------
>
> Currently, the `<-` symbol is unconditionally desugared as follows:
>
> ```haskell
> do pat <- computation     >>>     let f pat = more
>    more                   >>>         f _ = fail "..."
>                           >>>     in  computation >>= f
> ```
>
> The problem with this is that `fail` cannot (!) be sensibly implemented for
> many monads, for example `State`, `IO`, `Reader`. In those cases it
> defaults to
> `error`. As a consequence, in current Haskell, you can not use
> `Monad`-polymorphic code safely, because although it claims to work for all
> `Monad`s, it might just crash on you. This kind of implicit non-totality
> baked
> into the class is *terrible*.
>
> The goal of this proposal is adding the `fail` only when necessary and
> reflecting that in the type signature of the `do` block, so that it can be
> used
> safely, and more importantly, is guaranteed not to be used if the type
> signature does not say so.
>
>
>
> `MonadFail` class
> - -----------------
>
> To fix this, introduce a new typeclass:
>
> ```haskell
> class Monad m => MonadFail m where
>     fail :: String -> m a
> ```
>
> Desugaring can now be changed to produce this constraint when necessary.
> For
> this, we have to decide when a pattern match can not fail; if this is the
> case,
> we can omit inserting the `fail` call.
>
> The most trivial examples of unfailable patterns are of course those that
> match
> anywhere unconditionally,
>
> ```haskell
> do x <- action     >>>     let f x = more
>    more            >>>     in  action >>= f
> ```
>
> In particular, the programmer can assert any pattern be unfailable by
> making it
> irrefutable using a prefix tilde:
>
> ```haskell
> do ~pat <- action     >>>     let f ~pat = more
>    more               >>>     in  action >>= f
> ```
>
> A class of patterns that are conditionally failable are `newtype`s, and
> single
> constructor `data` types, which are unfailable by themselves, but may fail
> if matching on their fields is done with failable paterns.
>
> ```haskell
> data Newtype a = Newtype a
>
> - -- "x" cannot fail
> do Newtype x <- action            >>>     let f (Newtype x) = more
>    more                           >>>     in  action >>= f
>
> - -- "Just x" can fail
> do Newtype (Just x) <- action     >>>     let f (Newtype (Just x)) = more
>    more                           >>>         f _ = fail "..."
>                                   >>>     in  action >>= f
> ```
>
> `ViewPatterns` are as failable as the pattern the view is matched against.
> Patterns like `(Just -> Just x)` should generate a `MonadFail` constraint
> even
> when it's "obvious" from the view's implementation that the pattern will
> always
> match. From an implementor's perspective, this means that only types (and
> their
> constructors) have to be looked at, not arbitrary values (like functions),
> which is impossible to do statically in general.
>
> ```haskell
> do (view ->  pat) <- action     >>>     let f (view ->  pat) = more
>    more                         >>>         f _ = fail "..."
>                                 >>>     in  action >>= f
>
> do (view -> ~pat) <- action     >>>     let f (view -> ~pat) = more
>    more                         >>>     in  action >>= f
> ```
>
> A similar issue arises for `PatternSynonyms`, which we cannot inspect
> during
> compilation sufficiently. A pattern synonym will therefore always be
> considered
> failable.
>
> ```haskell
> do PatternSynonym x <- action     >>>     let f PatternSynonym x = more
>    more                           >>>     in f _ = fail "..."
>                                   >>>     in  action >>= f
> ```
>
>
>
> Discussion
> - ----------
>
> - - Although for many `MonadPlus` `fail _ = mzero`, a separate `MonadFail`
> class
>   should be created instead of just using that.
>
>     - A parser might fail with an error message involving positional
>       information. Some libraries, like `Binary`, provide `fail` as their
>       only interface to fail a decoding step.
>
>     - Although `STM` is `MonadPlus`, it uses the default `fail = error`. It
>       will therefore not get a `MonadFail` instance.
>
> - - What laws should `fail` follow? **Left zero**,
>
>   ```haskell
>   ? s f.  fail s >>= f  ?  fail s
>   ```
>
>   A call to `fail` should abort the computation. In this sense, `fail`
> would
>   become a close relative of `mzero`. It would work well with the common
>   definition `fail _ = mzero`, and give a simple guideline to the intended
>   usage and effect of the `MonadFail` class.
>
> - - Rename `fail`? **No.** Old code might use `fail` explicitly and we
> might
>   avoid breaking it, the Report talks about `fail`, and we have a solid
>   migration strategy that does not require a renaming.
>
> - - Remove the `String` argument? **No.** The `String` might help error
> reporting
>   and debugging. `String` may be ugly, but it's the de facto standard for
>   simple text in GHC. No high performance string operations are to be
>   expected with `fail`, so this breaking change would in no way be
> justified.
>   Also note that explicit `fail` calls would break if we removed the
> argument.
>
> - - How sensitive would existing code be to subtle changes in the
> strictness
>   behaviour of `do` notation pattern matching? **It doesn't.** The
>   implementation does not affect strictness at all, only the desugaring
> step.
>   Care must be taken when fixing warnings by making patterns irrefutable
> using
>   `~`, as that *does* affect strictness. (Cf. difference between
> lazy/strict
>   State)
>
> - - The `Monad` constraint for `MonadFail` seems unnecessary. Should we
> drop or
>   relax it? What other things should be considered?
>
>   - Applicative `do` notation is coming sooner or later, `fail` might be
> useful
>     in this more general scenario. Due to the AMP, it is trivial to change
>     the `MonadFail` superclass to `Applicative` later. (The name will be a
> bit
>     misleading, but it's a very small price to pay.)
>   - The class might be misused for a strange pointed type if left without
>     any constraint. This is not the intended use at all.
>
>   I think we should keep the `Monad` superclass for three main reasons:
>
>   - We don't want to see `(Monad m, MonadFail m) =>` all over the place.
>   - The primary intended use of `fail` is for desugaring do-notation
> anyway.
>   - Retroactively removing superclasses is easy, but adding them is hard
>     (see AMP).
>
>
>
>
> Adapting old code
> - -----------------
>
> - - Help! My code is broken because of a missing `MonadFail` instance!
>
>   *Here are your options:*
>
>     1. Write a `MonadFail` instance (and bring it into scope)
>
>        ```haskell
>        #if !MIN_VERSION_base(4,11,0)
>        -- Control.Monad.Fail import will become redundant in GHC 7.16+
>        import qualified Control.Monad.Fail as Fail
>        #endif
>        import Control.Monad
>
>        instance Monad Foo where
>          (>>=) = <...bind impl...>
>          -- NB: `return` defaults to `pure`
>
>        #if !MIN_VERSION_base(4,11,0)
>          -- Monad(fail) will be removed in GHC 7.16+
>          fail = Fail.fail
>        #endif
>
>        instance MonadFail Foo where
>          fail = <...fail implementation...>
>        ```
>
>     2. Change your pattern to be irrefutable
>
>     3. Emulate the old behaviour by desugaring the pattern match by hand:
>
>        ```haskell
>        do Left e <- foobar
>           stuff
>        ```
>
>        becomes
>
>        ```haskell
>        do x <- foobar
>           e <- case foobar of
>               Left e' -> e'
>               Right r -> error "Pattern match failed" -- Boooo
>           stuff
>        ```
>
>        The point is you'll have to do your dirty laundry yourself now if
> you
>        have a value that *you* know will always match, and if you don't
> handle
>        the other patterns you'll get incompleteness warnings, and the
> compiler
>        won't silently eat those for you.
>
> - - Help! My code is broken because you removed `fail` from `Monad`, but
> my class
>   defines it!
>
>   *Delete that part of the instance definition.*
>
>
>
> Esimating the breakage
> - ----------------------
>
> Using our initial implementation, I compiled stackage-nightly, and grepped
> the
> logs for found "invalid use of fail desugaring". Assuming my implementation
> is correct, the number of "missing `MonadFail`" warnings generated is 487.
> Note that I filtered out `[]`, `Maybe` and `ReadPrec`, since those can be
> given
> a `MonadFail` instance from within GHC, and no breakage is expected from
> them.
>
> The build logs can be found [here][stackage-logs]. Search for "failable
> pattern" to find your way to the still pretty raw warnings.
>
>
>
>
> Transitional strategy
> - ---------------------
>
> The roadmap is similar to the [AMP][amp], the main difference being that
> since
> `MonadFail` does not exist yet, we have to introduce new functionality and
> then
> switch to it.
>
> * **GHC 7.12 / base-4.9**
>
>     - Add module `Control.Monad.Fail` with new class `MonadFail(fail)` so
>       people can start writing instances for it.
>
>       `Control.Monad` only re-exports the class `MonadFail`, but not its
>       `fail` method.
>
>       NB: At this point, `Control.Monad.Fail.fail` clashes with
>       `Prelude.fail` and `Control.Monad.fail`.
>
>     - *(non-essential)* Add a language extension `-XMonadFail` that
>       changes desugaring to use `MonadFail(fail)` instead of `Monad(fail)`.
>
>       This has the effect that typechecking will infer a `MonadFail`
> constraint
>       for `do` blocks with failable patterns, just as it is planned to do
> when
>       the entire thing is done.
>
>     - Warn when a `do`-block that contains a failable pattern is
>       desugared, but there is no `MonadFail`-instance in scope: "Please
> add the
>       instance or change your pattern matching." Add a flag to control
> whether
>       this warning appears.
>
>     - Warn when an instance implements the `fail` function (or when `fail`
>       is imported as a method of `Monad`), as it will be removed from the
>       `Monad` class in the future. (See also [GHC #10071][trac-10071])
>
> 3. GHC 7.14
>
>     - Switch `-XMonadFail` on by default.
>     - Remove the desugaring warnings.
>
> 3. GHC 7.16
>
>     - Remove `-XMonadFail`, leaving its effects on at all times.
>     - Remove `fail` from `Monad`.
>     - Instead, re-export `Control.Monad.Fail.fail` as `Prelude.fail` and
>       `Control.Monad.fail`.
>     - `Control.Monad.Fail` is now a redundant module that can be considered
>       deprecated.
>
>
>
> Current status
> - --------------
>
> - - [ZuriHac 2015 (29.5. - 31.5.)][zurihac]: Franz Thoma (@fmthoma) and me
>   (David Luposchainsky aka @quchen) started implementing the MFP in GHC.
>
>     - Desugaring to the new `fail` can be controlled via a new langauge
>       extension, `MonadFailDesugaring`.
>     - If the language extension is turned off, a warning will be emitted
> for
>       code that would break if it was enabled.
>     - Warnings are emitted for types that *have* a *MonadFail* instance.
> This
>       still needs to be fixed.
>     - The error message are readable, but should be more so. We're still
>       on this.
> - - 2015-06-09: Estimated breakage by compiling Stackage. Smaller than
> expected.
>
>
>
> [amp]: https://github.com/quchen/articles/blob/master/applicative_monad.md
> [stackage-logs]:
> https://www.dropbox.com/s/knz0i979skam4zs/stackage-build.tar.xz?dl=0
> [trac-10071]: https://ghc.haskell.org/trac/ghc/ticket/10071
> [zurihac]: https://wiki.haskell.org/ZuriHac2015
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVd0/yAAoJELrQsaT5WQUshbUH/A3W0itVAk7ao8rtxId5unCJ
> 7StriKVkTyLAkkrbRJngM4MHEKiCsoyIgr8kBIwSHgk194GxeP2NCF4ijuBZoDBt
> +Uci+6BCBinV8+OzfrfTcJb4+8iw1j+eLWJ/Nz/JDMDNCiyzyC0SMsqGa+ssOz7H
> /2mqPkQjQgpHuP5PTRLHKPPIsayCQvTbZR1f14KhuMN2SPDE+WY4rqugu//XuIkN
> u1YssIf5l8mEez/1ljaqGL55cTI0UNg2z0iA0bFl/ajHaeQ6mc5BAevWfSohAMW7
> 7PIt13p9NIaMHnikmI+YJszm2IEaXuv47mGgbyDV//nHq3fwWN+naB+1mPX2eSU=
> =vPAL
> -----END PGP SIGNATURE-----
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150610/992c58c0/attachment-0001.html>

From johan.tibell at gmail.com  Tue Jun  9 22:26:25 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 10 Jun 2015 00:26:25 +0200
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <55774FF2.8020505@gmail.com>
References: <55774FF2.8020505@gmail.com>
Message-ID: <CAK-tuPazUnoOjGKDMcwhcj30SMBuSzq1boHL9WYEWFLO1EKtPg@mail.gmail.com>

Thanks for putting this together.

The proposal says:

"As a consequence, in current Haskell, you can not use Monad-polymorphic
code safely, because although it claims to work for all Monads, it might
just crash on you. This kind of implicit non-totality baked into the class
is terrible."

Is this actually a problem in practice? Is there any code we can point to
that suffers because of the current state of affairs? Could it be included
in the proposal?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150610/c738ea8e/attachment.html>

From johnw at newartisans.com  Tue Jun  9 22:32:14 2015
From: johnw at newartisans.com (John Wiegley)
Date: Tue, 09 Jun 2015 17:32:14 -0500
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <55774FF2.8020505@gmail.com> (David Luposchainsky's message of
 "Tue, 09 Jun 2015 22:43:30 +0200")
References: <55774FF2.8020505@gmail.com>
Message-ID: <m2bngoh5sh.fsf@newartisans.com>

>>>>> David Luposchainsky <dluposchainsky at googlemail.com> writes:

> the subject says it all. After we successfully put `=>`
> into Monad, it is time to remove something in return: `fail`.

+1

John

From dluposchainsky at googlemail.com  Tue Jun  9 22:42:12 2015
From: dluposchainsky at googlemail.com (David Luposchainsky)
Date: Wed, 10 Jun 2015 00:42:12 +0200
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <CAK-tuPazUnoOjGKDMcwhcj30SMBuSzq1boHL9WYEWFLO1EKtPg@mail.gmail.com>
References: <55774FF2.8020505@gmail.com>
 <CAK-tuPazUnoOjGKDMcwhcj30SMBuSzq1boHL9WYEWFLO1EKtPg@mail.gmail.com>
Message-ID: <55776BC4.3050400@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10.06.2015 00:26, Johan Tibell wrote:
> "As a consequence, in current Haskell, you can not use Monad-polymorphic code 
> safely, because although it claims to work for all Monads, it might just crash
> on you. This kind of implicit non-totality baked into the class is terrible."
> 
> Is this actually a problem in practice? Is there any code we can point to
> that suffers because of the current state of affairs? Could it be included in
> the proposal?

I don't have hard evidence, but the Monad class being partial strikes me as
pretty backwards in a language where totality and no implicit failures are
important to the programmers. We try our best to advocate not using certain
functions like "head" carelessly, but do-notation comes with similar partiality.

One concrete example that I know is bimap, but that's something I stumbled upon
months ago by accident. Another is that Binary does not have a monomorphic "fail"
function and it hurts me a bit to use the Monad-"fail" and write a comment on how
that is safe to do in the current context.

I think there are two important consequences of MonadFail. First of all, we can
all safely write failable patterns if we so desire. Second, the compiler can
ensure other people's codebases do not lie to us (knowingly or unknowingly).

David/quchen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVd2vEAAoJELrQsaT5WQUs+m8IAOWA9Hd52MG1wZ6g6FoOcXd6
x64dRDlilmkVu2IRxHADzip75Oji254yKQ5VY9yMGjYpFajtgf0Q8LrmA0ePTzhg
E/oxdm1vyRoJab1C5TfdrzPM/voP+wHi7y2ak1j0hTNky+wETj4MKtJ/Jef225nd
APUq05t6nPwzEDCz37RitfbA6/nwwYShaVjNe0tRluPrJuxdBu0+aobFc2lzVL+s
J7egnV1kqEOhc7INOhWYsvAJPAJSiY950y/Nmxb2/r5orTfN3tsr98d1zwRxhCmq
UNXhUaj5xD7BK2Rn1Zy7VwUv1T8IRLZuOQrlZh3HWz4t1SI0tTu3tdS468s/B1g=
=4mEU
-----END PGP SIGNATURE-----

From ekmett at gmail.com  Wed Jun 10 01:44:40 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 10 Jun 2015 03:44:40 +0200
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <CAK-tuPazUnoOjGKDMcwhcj30SMBuSzq1boHL9WYEWFLO1EKtPg@mail.gmail.com>
References: <55774FF2.8020505@gmail.com>
 <CAK-tuPazUnoOjGKDMcwhcj30SMBuSzq1boHL9WYEWFLO1EKtPg@mail.gmail.com>
Message-ID: <CAJumaK8e_Yb8vB-LCK83MJqp2AV5d9pB-51TiOvMo-Ux+Ef_bA@mail.gmail.com>

I can give a couple of "rather academic" issues that the status quo causes:

An example of where this has bit us in the hindquarters in the past is that
the old Error class based instance for Monad (Either a) from the mtl
incurred a constraint on the entire Monad instance in order to support
'fail'.

This ruled out many applications for the Either monad, e.g. apo/gapo are
based on the real (Either e) monad, just as para/zygo are based on the
"real" ((,) e) comonad. This rather complicated the use of recursion
schemes and in fact was what drove me to write what turned into the
"either" package in the first place.

Now we don't try to support 'fail' at all for that Monad. Under this
proposal though, one _could_ add a MonadFail instance that incurred a
rather ad hoc constraint on the left hand side of the sum without
encumbering the Monad itself.

In general you have no way of knowing that you stick to the product-like
structure of the Monad in the current ecosystem, because 'fail' is always
there, you can get to values in the Monad you couldn't reach with just
return and (>>=).

Ideally you'd have (forall m. Monad m => m a) being isomorphic to a, this
can be useful for ensuring we can plumb user-defined effects through code:

http://comonad.com/reader/2011/searching-infinity/

but in Haskell as it exists today you always have to worry about it
invoking a call to fail, and having a special form of _distinguishable_
bottom available from that computation so it is really more like `Either
String a`.

Can you just say "don't do that?"

Sure, but it is the moral equivalent of programming with nulls all over
your code.

-Edward

On Wed, Jun 10, 2015 at 12:26 AM, Johan Tibell <johan.tibell at gmail.com>
wrote:

> Thanks for putting this together.
>
> The proposal says:
>
> "As a consequence, in current Haskell, you can not use Monad-polymorphic
> code safely, because although it claims to work for all Monads, it might
> just crash on you. This kind of implicit non-totality baked into the class
> is terrible."
>
> Is this actually a problem in practice? Is there any code we can point to
> that suffers because of the current state of affairs? Could it be included
> in the proposal?
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150610/6ec7fef7/attachment.html>

From carter.schonwald at gmail.com  Wed Jun 10 04:27:12 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 10 Jun 2015 00:27:12 -0400
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <ml8acq$tmj$1@ger.gmane.org>
References: <55774FF2.8020505@gmail.com> <ml8acq$tmj$1@ger.gmane.org>
Message-ID: <CAHYVw0wWWSuBEoGR0pd=6sxhdG-6yBRFvK+_jGH4jWKCunK+DQ@mail.gmail.com>

i'll add my token +1 to the land slide

On Tue, Jun 9, 2015 at 11:19 PM, Bardur Arantsson <spam at scientician.net>
wrote:

> On 06/09/2015 10:43 PM, David Luposchainsky wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
>
> +1
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150610/3d4d6683/attachment.html>

From malcolm.wallace at me.com  Wed Jun 10 07:27:54 2015
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Wed, 10 Jun 2015 08:27:54 +0100
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <CAJumaK-r-q5DTk_WKGGYZ8idfvMx__LQOAwMJcUGkB0jCSeWug@mail.gmail.com>
References: <55774FF2.8020505@gmail.com>
 <CAJumaK-r-q5DTk_WKGGYZ8idfvMx__LQOAwMJcUGkB0jCSeWug@mail.gmail.com>
Message-ID: <5EABF3D5-7923-4C37-8AC8-FDCCD0FF8C3D@me.com>

I'm a +1 on this proposal as well. In our private Haskell compiler at work, we have had separate Monad and MonadFail classes since 2010, and it is clearly the more principled way to handle partiality: make it visible in the inferred types.  I found that there were very few instances when porting Hackage libraries to our compiler that we came across a need to change type signatures because of MonadFail, and making the change was in all cases easy anyway.

Regards,
    Malcolm

On 9 Jun 2015, at 23:19, Edward Kmett wrote:

> +1 from me for both the spirit and the substance of this proposal. We've been talking about this in the abstract for a while now (since ICFP 2013 or so) and as concrete plans go, this strikes me as straightforward and implementable.
> 
> -Edward
> 
> On Tue, Jun 9, 2015 at 10:43 PM, David Luposchainsky <dluposchainsky at googlemail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello *,
> 
> the subject says it all. After we successfully put `=>`
> into Monad, it is time to remove something in return: `fail`.
> 
> Like with the AMP, I wrote up the proposal in Markdown
> format on Github, which you can find below as a URL, and in
> verbatim copy at the end of this email. It provides an
> overview over the intended outcome, which design decisions
> we had to take, and how our initial plan for the transition
> looks like. There are also some issues left open to
> discussion.
> 
> https://github.com/quchen/articles/blob/master/monad_fail.md
> 
> Here's a short abstract:
> 
> - - Move `fail` from `Monad` into a new class `MonadFail`.
> - - Code using failable patterns will receive a more
>   restrictive `MonadFail` constraint. Code without this
>   constraint will be safe to use for all Monads.
> - - Transition will take at least two GHC releases.
>   GHC 7.12 will include the new class, and generate
>   warnings asking users to make their failable patterns
>   compliant.
> - - Stackage showed an upper bound of less than 500 breaking
>   code fragments when compiled with the new desugaring.
> 
> For more details, refer to the link or the paste at the end.
> 
> 
> Let's get going!
> 
> David aka quchen
> 
> 
> 
> 
> 
> ===============================================================
> ===============================================================
> ===============================================================
> 
> 
> 
> 
> 
> `MonadFail` proposal (MFP)
> ==========================
> 
> A couple of years ago, we proposed to make `Applicative` a superclass of
> `Monad`, which successfully killed the single most ugly thing in Haskell
> as of GHC 7.10.
> 
> Now, it's time to tackle the other major issue with `Monad`: `fail` being a
> part of it.
> 
> You can contact me as usual via IRC/Freenode as *quchen*, or by email to
> *dluposchainsky at the email service of Google*. This file will also be posted
> on the ghc-devs@ and libraries@ mailing lists, as well as on Reddit.
> 
> 
> 
> Overview
> - --------
> 
> - - **The problem** - reason for the proposal
> - - **MonadFail class** - the solution
> - - **Discussion** - explaining our design choices
> - - **Adapting old code** - how to prepare current code to transition smoothly
> - - **Esimating the breakage** - how much stuff we will break (spoiler: not much)
> - - **Transitional strategy** - how to break as little as possible while
> transitioning
> - - **Current status**
> 
> 
> 
> 
> The problem
> - -----------
> 
> Currently, the `<-` symbol is unconditionally desugared as follows:
> 
> ```haskell
> do pat <- computation     >>>     let f pat = more
>    more                   >>>         f _ = fail "..."
>                           >>>     in  computation >>= f
> ```
> 
> The problem with this is that `fail` cannot (!) be sensibly implemented for
> many monads, for example `State`, `IO`, `Reader`. In those cases it defaults to
> `error`. As a consequence, in current Haskell, you can not use
> `Monad`-polymorphic code safely, because although it claims to work for all
> `Monad`s, it might just crash on you. This kind of implicit non-totality baked
> into the class is *terrible*.
> 
> The goal of this proposal is adding the `fail` only when necessary and
> reflecting that in the type signature of the `do` block, so that it can be used
> safely, and more importantly, is guaranteed not to be used if the type
> signature does not say so.
> 
> 
> 
> `MonadFail` class
> - -----------------
> 
> To fix this, introduce a new typeclass:
> 
> ```haskell
> class Monad m => MonadFail m where
>     fail :: String -> m a
> ```
> 
> Desugaring can now be changed to produce this constraint when necessary. For
> this, we have to decide when a pattern match can not fail; if this is the case,
> we can omit inserting the `fail` call.
> 
> The most trivial examples of unfailable patterns are of course those that match
> anywhere unconditionally,
> 
> ```haskell
> do x <- action     >>>     let f x = more
>    more            >>>     in  action >>= f
> ```
> 
> In particular, the programmer can assert any pattern be unfailable by making it
> irrefutable using a prefix tilde:
> 
> ```haskell
> do ~pat <- action     >>>     let f ~pat = more
>    more               >>>     in  action >>= f
> ```
> 
> A class of patterns that are conditionally failable are `newtype`s, and single
> constructor `data` types, which are unfailable by themselves, but may fail
> if matching on their fields is done with failable paterns.
> 
> ```haskell
> data Newtype a = Newtype a
> 
> - -- "x" cannot fail
> do Newtype x <- action            >>>     let f (Newtype x) = more
>    more                           >>>     in  action >>= f
> 
> - -- "Just x" can fail
> do Newtype (Just x) <- action     >>>     let f (Newtype (Just x)) = more
>    more                           >>>         f _ = fail "..."
>                                   >>>     in  action >>= f
> ```
> 
> `ViewPatterns` are as failable as the pattern the view is matched against.
> Patterns like `(Just -> Just x)` should generate a `MonadFail` constraint even
> when it's "obvious" from the view's implementation that the pattern will always
> match. From an implementor's perspective, this means that only types (and their
> constructors) have to be looked at, not arbitrary values (like functions),
> which is impossible to do statically in general.
> 
> ```haskell
> do (view ->  pat) <- action     >>>     let f (view ->  pat) = more
>    more                         >>>         f _ = fail "..."
>                                 >>>     in  action >>= f
> 
> do (view -> ~pat) <- action     >>>     let f (view -> ~pat) = more
>    more                         >>>     in  action >>= f
> ```
> 
> A similar issue arises for `PatternSynonyms`, which we cannot inspect during
> compilation sufficiently. A pattern synonym will therefore always be considered
> failable.
> 
> ```haskell
> do PatternSynonym x <- action     >>>     let f PatternSynonym x = more
>    more                           >>>     in f _ = fail "..."
>                                   >>>     in  action >>= f
> ```
> 
> 
> 
> Discussion
> - ----------
> 
> - - Although for many `MonadPlus` `fail _ = mzero`, a separate `MonadFail` class
>   should be created instead of just using that.
> 
>     - A parser might fail with an error message involving positional
>       information. Some libraries, like `Binary`, provide `fail` as their
>       only interface to fail a decoding step.
> 
>     - Although `STM` is `MonadPlus`, it uses the default `fail = error`. It
>       will therefore not get a `MonadFail` instance.
> 
> - - What laws should `fail` follow? **Left zero**,
> 
>   ```haskell
>   ? s f.  fail s >>= f  ?  fail s
>   ```
> 
>   A call to `fail` should abort the computation. In this sense, `fail` would
>   become a close relative of `mzero`. It would work well with the common
>   definition `fail _ = mzero`, and give a simple guideline to the intended
>   usage and effect of the `MonadFail` class.
> 
> - - Rename `fail`? **No.** Old code might use `fail` explicitly and we might
>   avoid breaking it, the Report talks about `fail`, and we have a solid
>   migration strategy that does not require a renaming.
> 
> - - Remove the `String` argument? **No.** The `String` might help error reporting
>   and debugging. `String` may be ugly, but it's the de facto standard for
>   simple text in GHC. No high performance string operations are to be
>   expected with `fail`, so this breaking change would in no way be justified.
>   Also note that explicit `fail` calls would break if we removed the argument.
> 
> - - How sensitive would existing code be to subtle changes in the strictness
>   behaviour of `do` notation pattern matching? **It doesn't.** The
>   implementation does not affect strictness at all, only the desugaring step.
>   Care must be taken when fixing warnings by making patterns irrefutable using
>   `~`, as that *does* affect strictness. (Cf. difference between lazy/strict
>   State)
> 
> - - The `Monad` constraint for `MonadFail` seems unnecessary. Should we drop or
>   relax it? What other things should be considered?
> 
>   - Applicative `do` notation is coming sooner or later, `fail` might be useful
>     in this more general scenario. Due to the AMP, it is trivial to change
>     the `MonadFail` superclass to `Applicative` later. (The name will be a bit
>     misleading, but it's a very small price to pay.)
>   - The class might be misused for a strange pointed type if left without
>     any constraint. This is not the intended use at all.
> 
>   I think we should keep the `Monad` superclass for three main reasons:
> 
>   - We don't want to see `(Monad m, MonadFail m) =>` all over the place.
>   - The primary intended use of `fail` is for desugaring do-notation anyway.
>   - Retroactively removing superclasses is easy, but adding them is hard
>     (see AMP).
> 
> 
> 
> 
> Adapting old code
> - -----------------
> 
> - - Help! My code is broken because of a missing `MonadFail` instance!
> 
>   *Here are your options:*
> 
>     1. Write a `MonadFail` instance (and bring it into scope)
> 
>        ```haskell
>        #if !MIN_VERSION_base(4,11,0)
>        -- Control.Monad.Fail import will become redundant in GHC 7.16+
>        import qualified Control.Monad.Fail as Fail
>        #endif
>        import Control.Monad
> 
>        instance Monad Foo where
>          (>>=) = <...bind impl...>
>          -- NB: `return` defaults to `pure`
> 
>        #if !MIN_VERSION_base(4,11,0)
>          -- Monad(fail) will be removed in GHC 7.16+
>          fail = Fail.fail
>        #endif
> 
>        instance MonadFail Foo where
>          fail = <...fail implementation...>
>        ```
> 
>     2. Change your pattern to be irrefutable
> 
>     3. Emulate the old behaviour by desugaring the pattern match by hand:
> 
>        ```haskell
>        do Left e <- foobar
>           stuff
>        ```
> 
>        becomes
> 
>        ```haskell
>        do x <- foobar
>           e <- case foobar of
>               Left e' -> e'
>               Right r -> error "Pattern match failed" -- Boooo
>           stuff
>        ```
> 
>        The point is you'll have to do your dirty laundry yourself now if you
>        have a value that *you* know will always match, and if you don't handle
>        the other patterns you'll get incompleteness warnings, and the compiler
>        won't silently eat those for you.
> 
> - - Help! My code is broken because you removed `fail` from `Monad`, but my class
>   defines it!
> 
>   *Delete that part of the instance definition.*
> 
> 
> 
> Esimating the breakage
> - ----------------------
> 
> Using our initial implementation, I compiled stackage-nightly, and grepped the
> logs for found "invalid use of fail desugaring". Assuming my implementation
> is correct, the number of "missing `MonadFail`" warnings generated is 487.
> Note that I filtered out `[]`, `Maybe` and `ReadPrec`, since those can be given
> a `MonadFail` instance from within GHC, and no breakage is expected from them.
> 
> The build logs can be found [here][stackage-logs]. Search for "failable
> pattern" to find your way to the still pretty raw warnings.
> 
> 
> 
> 
> Transitional strategy
> - ---------------------
> 
> The roadmap is similar to the [AMP][amp], the main difference being that since
> `MonadFail` does not exist yet, we have to introduce new functionality and then
> switch to it.
> 
> * **GHC 7.12 / base-4.9**
> 
>     - Add module `Control.Monad.Fail` with new class `MonadFail(fail)` so
>       people can start writing instances for it.
> 
>       `Control.Monad` only re-exports the class `MonadFail`, but not its
>       `fail` method.
> 
>       NB: At this point, `Control.Monad.Fail.fail` clashes with
>       `Prelude.fail` and `Control.Monad.fail`.
> 
>     - *(non-essential)* Add a language extension `-XMonadFail` that
>       changes desugaring to use `MonadFail(fail)` instead of `Monad(fail)`.
> 
>       This has the effect that typechecking will infer a `MonadFail` constraint
>       for `do` blocks with failable patterns, just as it is planned to do when
>       the entire thing is done.
> 
>     - Warn when a `do`-block that contains a failable pattern is
>       desugared, but there is no `MonadFail`-instance in scope: "Please add the
>       instance or change your pattern matching." Add a flag to control whether
>       this warning appears.
> 
>     - Warn when an instance implements the `fail` function (or when `fail`
>       is imported as a method of `Monad`), as it will be removed from the
>       `Monad` class in the future. (See also [GHC #10071][trac-10071])
> 
> 3. GHC 7.14
> 
>     - Switch `-XMonadFail` on by default.
>     - Remove the desugaring warnings.
> 
> 3. GHC 7.16
> 
>     - Remove `-XMonadFail`, leaving its effects on at all times.
>     - Remove `fail` from `Monad`.
>     - Instead, re-export `Control.Monad.Fail.fail` as `Prelude.fail` and
>       `Control.Monad.fail`.
>     - `Control.Monad.Fail` is now a redundant module that can be considered
>       deprecated.
> 
> 
> 
> Current status
> - --------------
> 
> - - [ZuriHac 2015 (29.5. - 31.5.)][zurihac]: Franz Thoma (@fmthoma) and me
>   (David Luposchainsky aka @quchen) started implementing the MFP in GHC.
> 
>     - Desugaring to the new `fail` can be controlled via a new langauge
>       extension, `MonadFailDesugaring`.
>     - If the language extension is turned off, a warning will be emitted for
>       code that would break if it was enabled.
>     - Warnings are emitted for types that *have* a *MonadFail* instance. This
>       still needs to be fixed.
>     - The error message are readable, but should be more so. We're still
>       on this.
> - - 2015-06-09: Estimated breakage by compiling Stackage. Smaller than expected.
> 
> 
> 
> [amp]: https://github.com/quchen/articles/blob/master/applicative_monad.md
> [stackage-logs]: https://www.dropbox.com/s/knz0i979skam4zs/stackage-build.tar.xz?dl=0
> [trac-10071]: https://ghc.haskell.org/trac/ghc/ticket/10071
> [zurihac]: https://wiki.haskell.org/ZuriHac2015
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJVd0/yAAoJELrQsaT5WQUshbUH/A3W0itVAk7ao8rtxId5unCJ
> 7StriKVkTyLAkkrbRJngM4MHEKiCsoyIgr8kBIwSHgk194GxeP2NCF4ijuBZoDBt
> +Uci+6BCBinV8+OzfrfTcJb4+8iw1j+eLWJ/Nz/JDMDNCiyzyC0SMsqGa+ssOz7H
> /2mqPkQjQgpHuP5PTRLHKPPIsayCQvTbZR1f14KhuMN2SPDE+WY4rqugu//XuIkN
> u1YssIf5l8mEez/1ljaqGL55cTI0UNg2z0iA0bFl/ajHaeQ6mc5BAevWfSohAMW7
> 7PIt13p9NIaMHnikmI+YJszm2IEaXuv47mGgbyDV//nHq3fwWN+naB+1mPX2eSU=
> =vPAL
> -----END PGP SIGNATURE-----
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


From hvr at gnu.org  Wed Jun 10 10:34:50 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 10 Jun 2015 12:34:50 +0200
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <55776BC4.3050400@gmail.com> (David Luposchainsky's message of
 "Wed, 10 Jun 2015 00:42:12 +0200")
References: <55774FF2.8020505@gmail.com>
 <CAK-tuPazUnoOjGKDMcwhcj30SMBuSzq1boHL9WYEWFLO1EKtPg@mail.gmail.com>
 <55776BC4.3050400@gmail.com>
Message-ID: <874mmf26np.fsf@gnu.org>

On 2015-06-10 at 00:42:12 +0200, David Luposchainsky wrote:

[...]

> I think there are two important consequences of MonadFail. First of all, we can
> all safely write failable patterns if we so desire. Second, the compiler can
> ensure other people's codebases do not lie to us (knowingly or unknowingly).

...as a data-point, when turning on MonadFail during testing, I've seen
at least one place in GHC's own code-base that directly calls 'fail' for
a Monad instance which did *not* have its 'fail' method
overridden. Moreover, I've seen at least one (other) case, where
failable pattern matches occurred (intentionally or not[1]), but the
respective Monad instance didn't have the 'fail' method overridden
either.

 [1]: Failable patterns can in theory snuck in non-intentionally,
      e.g. they can be introduced during refactoring if e.g. a
      single-constructor type gets added new constructors. If the
      context was previously constraint to a 'Monad', after the
      refactoring the typechecker would point out that now there's a
      failable pattern not accounted for.

From johan.tibell at gmail.com  Wed Jun 10 11:22:43 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 10 Jun 2015 13:22:43 +0200
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <55776BC4.3050400@gmail.com>
References: <55774FF2.8020505@gmail.com>
 <CAK-tuPazUnoOjGKDMcwhcj30SMBuSzq1boHL9WYEWFLO1EKtPg@mail.gmail.com>
 <55776BC4.3050400@gmail.com>
Message-ID: <CAK-tuPY1KaA-i8xo=538YQjY7B2-tNZ1G6ngn=zkCOZCJ-L0HA@mail.gmail.com>

On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky <
dluposchainsky at googlemail.com> wrote:

> I think there are two important consequences of MonadFail. First of all,
> we can
> all safely write failable patterns if we so desire. Second, the compiler
> can
> ensure other people's codebases do not lie to us (knowingly or
> unknowingly).
>

The second is a bit overstated I think. Any function you call can still
have partial pattern matches in all the other places Haskell allows them
and you wouldn't know from the type.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150610/3d43a8bb/attachment.html>

From roma at ro-che.info  Wed Jun 10 11:46:34 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Wed, 10 Jun 2015 14:46:34 +0300
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <CAK-tuPY1KaA-i8xo=538YQjY7B2-tNZ1G6ngn=zkCOZCJ-L0HA@mail.gmail.com>
References: <55774FF2.8020505@gmail.com>
 <CAK-tuPazUnoOjGKDMcwhcj30SMBuSzq1boHL9WYEWFLO1EKtPg@mail.gmail.com>
 <55776BC4.3050400@gmail.com>
 <CAK-tuPY1KaA-i8xo=538YQjY7B2-tNZ1G6ngn=zkCOZCJ-L0HA@mail.gmail.com>
Message-ID: <5578239A.7080409@ro-che.info>

On 10/06/15 14:22, Johan Tibell wrote:
> On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky
> <dluposchainsky at googlemail.com <mailto:dluposchainsky at googlemail.com>>
> wrote:
> 
>     I think there are two important consequences of MonadFail. First of
>     all, we can
>     all safely write failable patterns if we so desire. Second, the
>     compiler can
>     ensure other people's codebases do not lie to us (knowingly or
>     unknowingly).
> 
> 
> The second is a bit overstated I think. Any function you call can still
> have partial pattern matches in all the other places Haskell allows them
> and you wouldn't know from the type.

For most of them, at least you get a warning from GHC (not for patterns
inside lambda, sadly, although that should be fixable). But for

do
  Just x <- a
  ...

it's not possible in principle to give a warning, because it's not clear
whether the implicit call to fail is intended.

Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150610/1859e75c/attachment.sig>

From ganesh at earth.li  Wed Jun 10 11:58:09 2015
From: ganesh at earth.li (Ganesh Sittampalam)
Date: Wed, 10 Jun 2015 12:58:09 +0100
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <CAK-tuPazUnoOjGKDMcwhcj30SMBuSzq1boHL9WYEWFLO1EKtPg@mail.gmail.com>
References: <55774FF2.8020505@gmail.com>
 <CAK-tuPazUnoOjGKDMcwhcj30SMBuSzq1boHL9WYEWFLO1EKtPg@mail.gmail.com>
Message-ID: <55782651.9010105@earth.li>

On 09/06/2015 23:26, Johan Tibell wrote:
> Thanks for putting this together.
> 
> The proposal says:
> 
> "As a consequence, in current Haskell, you can not use Monad-polymorphic
> code safely, because although it claims to work for all Monads, it might
> just crash on you. This kind of implicit non-totality baked into the
> class is terrible."
> 
> Is this actually a problem in practice? Is there any code we can point
> to that suffers because of the current state of affairs? Could it be
> included in the proposal?

Here's a concrete example:

https://mail.haskell.org/pipermail/libraries/2015-March/025166.html

I needed to change some code that used a monad with an explicit fail to
use one without, and I couldn't get the compiler to tell me if it was
using partial pattern matches or not. If it had been then the
refactoring would have caused a nasty behaviour change.

Ganesh


From tomberek at gmail.com  Wed Jun 10 12:04:08 2015
From: tomberek at gmail.com (Thomas Bereknyei)
Date: Wed, 10 Jun 2015 08:04:08 -0400
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <5578239A.7080409@ro-che.info>
References: <55774FF2.8020505@gmail.com>
 <CAK-tuPazUnoOjGKDMcwhcj30SMBuSzq1boHL9WYEWFLO1EKtPg@mail.gmail.com>
 <55776BC4.3050400@gmail.com>
 <CAK-tuPY1KaA-i8xo=538YQjY7B2-tNZ1G6ngn=zkCOZCJ-L0HA@mail.gmail.com>
 <5578239A.7080409@ro-che.info>
Message-ID: <CA+CkF20ehaxf+6KX6KQpgDmE1yPEhdh0ZZwQtruc_bFcP+hhmw@mail.gmail.com>

+1 also improves the correctness of the monad laws
On Jun 10, 2015 7:46 AM, "Roman Cheplyaka" <roma at ro-che.info> wrote:

> On 10/06/15 14:22, Johan Tibell wrote:
> > On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky
> > <dluposchainsky at googlemail.com <mailto:dluposchainsky at googlemail.com>>
> > wrote:
> >
> >     I think there are two important consequences of MonadFail. First of
> >     all, we can
> >     all safely write failable patterns if we so desire. Second, the
> >     compiler can
> >     ensure other people's codebases do not lie to us (knowingly or
> >     unknowingly).
> >
> >
> > The second is a bit overstated I think. Any function you call can still
> > have partial pattern matches in all the other places Haskell allows them
> > and you wouldn't know from the type.
>
> For most of them, at least you get a warning from GHC (not for patterns
> inside lambda, sadly, although that should be fixable). But for
>
> do
>   Just x <- a
>   ...
>
> it's not possible in principle to give a warning, because it's not clear
> whether the implicit call to fail is intended.
>
> Roman
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150610/7c8a69f6/attachment.html>

From johan.tibell at gmail.com  Wed Jun 10 12:14:15 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Wed, 10 Jun 2015 14:14:15 +0200
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <5578239A.7080409@ro-che.info>
References: <55774FF2.8020505@gmail.com>
 <CAK-tuPazUnoOjGKDMcwhcj30SMBuSzq1boHL9WYEWFLO1EKtPg@mail.gmail.com>
 <55776BC4.3050400@gmail.com>
 <CAK-tuPY1KaA-i8xo=538YQjY7B2-tNZ1G6ngn=zkCOZCJ-L0HA@mail.gmail.com>
 <5578239A.7080409@ro-che.info>
Message-ID: <CAK-tuPYyh28B+ubdC2QQbsF-kYQhG=Ye9n5RPGCwRxZgPg-7cQ@mail.gmail.com>

On Wed, Jun 10, 2015 at 1:46 PM, Roman Cheplyaka <roma at ro-che.info> wrote:

> On 10/06/15 14:22, Johan Tibell wrote:
> > On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky
> > <dluposchainsky at googlemail.com <mailto:dluposchainsky at googlemail.com>>
> > wrote:
> >
> >     I think there are two important consequences of MonadFail. First of
> >     all, we can
> >     all safely write failable patterns if we so desire. Second, the
> >     compiler can
> >     ensure other people's codebases do not lie to us (knowingly or
> >     unknowingly).
> >
> >
> > The second is a bit overstated I think. Any function you call can still
> > have partial pattern matches in all the other places Haskell allows them
> > and you wouldn't know from the type.
>
> For most of them, at least you get a warning from GHC (not for patterns
> inside lambda, sadly, although that should be fixable). But for
>
> do
>   Just x <- a
>   ...
>
> it's not possible in principle to give a warning, because it's not clear
> whether the implicit call to fail is intended.
>

That's a good point. An alternative to changing fail would to add a warning
for partial matches even in do-notation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150610/04904476/attachment.html>

From hesselink at gmail.com  Wed Jun 10 12:21:12 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Wed, 10 Jun 2015 14:21:12 +0200
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <CAK-tuPYyh28B+ubdC2QQbsF-kYQhG=Ye9n5RPGCwRxZgPg-7cQ@mail.gmail.com>
References: <55774FF2.8020505@gmail.com>
 <CAK-tuPazUnoOjGKDMcwhcj30SMBuSzq1boHL9WYEWFLO1EKtPg@mail.gmail.com>
 <55776BC4.3050400@gmail.com>
 <CAK-tuPY1KaA-i8xo=538YQjY7B2-tNZ1G6ngn=zkCOZCJ-L0HA@mail.gmail.com>
 <5578239A.7080409@ro-che.info>
 <CAK-tuPYyh28B+ubdC2QQbsF-kYQhG=Ye9n5RPGCwRxZgPg-7cQ@mail.gmail.com>
Message-ID: <CAPeieQGZSG3Exb3By9V9aGCd2yD1Ea0Bw3-8gJnVWe=i5fzu0g@mail.gmail.com>

On Wed, Jun 10, 2015 at 2:14 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
> On Wed, Jun 10, 2015 at 1:46 PM, Roman Cheplyaka <roma at ro-che.info> wrote:
>>
>> On 10/06/15 14:22, Johan Tibell wrote:
>> > On Wed, Jun 10, 2015 at 12:42 AM, David Luposchainsky
>> > <dluposchainsky at googlemail.com <mailto:dluposchainsky at googlemail.com>>
>> > wrote:
>> >
>> >     I think there are two important consequences of MonadFail. First of
>> >     all, we can
>> >     all safely write failable patterns if we so desire. Second, the
>> >     compiler can
>> >     ensure other people's codebases do not lie to us (knowingly or
>> >     unknowingly).
>> >
>> >
>> > The second is a bit overstated I think. Any function you call can still
>> > have partial pattern matches in all the other places Haskell allows them
>> > and you wouldn't know from the type.
>>
>> For most of them, at least you get a warning from GHC (not for patterns
>> inside lambda, sadly, although that should be fixable). But for
>>
>> do
>>   Just x <- a
>>   ...
>>
>> it's not possible in principle to give a warning, because it's not clear
>> whether the implicit call to fail is intended.
>
>
> That's a good point. An alternative to changing fail would to add a warning
> for partial matches even in do-notation.

That would be an improvement, but only a small one. You'd have to turn
off the warning if you really meant to use fail, and then if you
changed the monad you're using, or you're writing a polymorphic
function, nothing will warn you.

I'm +1 on this change. The plan looks thorough, minimizing breakage.
It'll bring many advantages. For example, I'll feel much safer when I
use functions like time's parseTimeM, to give a concrete example.

Regards,

Erik

From jan.stolarek at p.lodz.pl  Wed Jun 10 13:12:19 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Wed, 10 Jun 2015 15:12:19 +0200
Subject: Adding location information to derived code
Message-ID: <201506101512.19915.jan.stolarek@p.lodz.pl>

Hi devs,

say I have:

  class C a where
    type F a
    type F a = a

  instance C Int

During compilation of "instance C Int" GHC will derive a default associated type instance "F Int = 
Int". That instance has no location information and so any errors that it might cause will have a 
very uninformative source code location 1:1. I want to fix this but I'm not sure whether it is a 
good idea to add location information to automatically generated code. Do we make any assumptions 
that derived code should have no location information?

Janek

---
Politechnika ??dzka
Lodz University of Technology

Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k?
prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.

This email contains information intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient or if you have received this message in error,
please notify the sender and delete it from your system.

From pali.gabor at gmail.com  Wed Jun 10 21:09:39 2015
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Wed, 10 Jun 2015 23:09:39 +0200
Subject: Broken build: Documentation mistake
In-Reply-To: <CAEs96n3P3pexrBpg5r75+4c562LeMfkototeaH_ZjP+VMfvpQA@mail.gmail.com>
References: <CAHnG2CwBGTf7jho4LQ42_0OEa__oQ-FqQUqCSV3eeuZqDfpqRQ@mail.gmail.com>
 <CAEs96n13=tXJt3aoG2DUZs7XGz7iddmvo_LxHNm5rbCBRLLMGQ@mail.gmail.com>
 <CAHnG2Cw31JOJmouBifwShgPEtfwsckNQ_q7YPFidjEdX97EsbQ@mail.gmail.com>
 <CAEs96n3P3pexrBpg5r75+4c562LeMfkototeaH_ZjP+VMfvpQA@mail.gmail.com>
Message-ID: <CAHnG2Czggx+ypE1hGH=XYughYL5guqYCuXBKLvyr26DfqWq1yw@mail.gmail.com>

2015-06-09 14:34 GMT+02:00 Austin Seipp <austin at well-typed.com>:
> Yes, please try the patch here - I think it should fix it (it carries
> an explanation too): https://phabricator.haskell.org/D970

Yeah, thanks, this appears to be working.

From simonpj at microsoft.com  Wed Jun 10 21:36:30 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 10 Jun 2015 21:36:30 +0000
Subject: Adding location information to derived code
In-Reply-To: <201506101512.19915.jan.stolarek@p.lodz.pl>
References: <201506101512.19915.jan.stolarek@p.lodz.pl>
Message-ID: <d590506e5689486e9a1ca948278dcc54@DB4PR30MB030.064d.mgd.msft.net>

| not sure whether it is a
| good idea to add location information to automatically generated code.

I think it would be an excellent idea.

| Do we make any assumptions
| that derived code should have no location information?

I don't think so.

Please open a ticket for your test case, and (if you can) fix it.  The location for the implicit instance should jolly well be the instance declaration for 'instance C Int'!

Thanks for spotting this.

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Jan
| Stolarek
| Sent: 10 June 2015 14:12
| To: ghc-devs at haskell.org
| Subject: Adding location information to derived code
| 
| Hi devs,
| 
| say I have:
| 
|   class C a where
|     type F a
|     type F a = a
| 
|   instance C Int
| 
| During compilation of "instance C Int" GHC will derive a default
| associated type instance "F Int =
| Int". That instance has no location information and so any errors that it
| might cause will have a
| very uninformative source code location 1:1. I want to fix this but I'm
| not sure whether it is a
| good idea to add location information to automatically generated code. Do
| we make any assumptions
| that derived code should have no location information?
| 
| Janek
| 
| ---
| Politechnika ??dzka
| Lodz University of Technology
| 
| Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
| Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez
| pomy?k?
| prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.
| 
| This email contains information intended solely for the use of the
| individual to whom it is addressed.
| If you are not the intended recipient or if you have received this
| message in error,
| please notify the sender and delete it from your system.
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From austin at well-typed.com  Wed Jun 10 21:36:51 2015
From: austin at well-typed.com (Austin Seipp)
Date: Wed, 10 Jun 2015 16:36:51 -0500
Subject: GHC Weekly News - 2015/06/10
Message-ID: <CAEs96n1mytrN9zv_6DaNpWVYGryCiyh5uqWDQQxcpn_hqPVc4Q@mail.gmail.com>

(This post is available online at
https://ghc.haskell.org/trac/ghc/blog/weekly20150610)

Hi *,

Welcome for the latest entry in the GHC Weekly News. The past week,
GHC HQ met up for a quick catch up on 7.10.2 (which you'll want to
read up on, see below), and some other technical nonsense about some
work we've been doing. As a result the current weekly notes have been
slow - the current priority is the next release though, which leads us
to...

== 7.10.2 status ==

7.10.2 is '''going to be out soon''' - our current plan is to have a
release candidate on '''the weekend of Saturday the 13th''', and the
final release '''the next week'''. That means if you want something
fixed, you'd better hollar ''very'' soon, or we're just not going to
get to it!

If you're wondering what's currently been fixed/scheduled,  the
[https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.2 status page]
shows the current set of tickets we've fixed and plan on fixing.

== List chatter ==

  - Edward Z. Yang has written up a new wiki page to clearly explain
and document all the various confusion around package keys, package
ids, etc as a result of all the new Backpack work. If you're
interested in this, it's definitely worth a read.
https://mail.haskell.org/pipermail/ghc-devs/2015-June/009173.html

  - Mark Lentczner sez: The Haskell Platform has finally outgrown
Travis-CI, now going beyond the 50 minute build limit. Mark asks what
alternatives we can use going forward.
https://mail.haskell.org/pipermail/ghc-devs/2015-June/009174.html

  - Jan Stolarek asks: in some cases, GHC will generate default
instances or values, but that source code has no textual information
location (for example, consider an `instance` clause without the
`where`) - what do people think about fixing this, and are there
anythings to look out for?
https://mail.haskell.org/pipermail/ghc-devs/2015-June/009202.html

  - David Luposchainsky has opened a new thread - about moving `fail`
out of `Monad` and into its own typeclass, `MonadFail`. This change is
a request that's very long in the tooth (older than the AMP or FTP
changes by a landslide), but David's proposal has a clearly set out
goal to tackle compatibility, warnings, and implementation.
https://mail.haskell.org/pipermail/ghc-devs/2015-June/009186.html

== Noteworthy commits ==

  - Commit 19ec6a84d6344c2808d0d41da11956689a0e4ae9 - Fix for CAF
retention when dynamically loading & unloading code

  - Commit 4a0b7a10442eec3747d5f95ef186a79bb0648754 - Build: run
autoreconf jobs in parallel

== Closed tickets ==

#10460, #7672, #9252, #9506, #10294, #5316, #10408, #10386, #9960,
#10145, #9259, #10386, #9507, #8723, #10442, #5014, #4215, #10443,
#8244, #10499, #10500, #10428, #10488, #10489, #10406, #10501, #10441,
#10406, #10502, #9101, #9663, and #9945.

-- 
Regards,

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

From simonpj at microsoft.com  Wed Jun 10 22:27:36 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 10 Jun 2015 22:27:36 +0000
Subject: windows failure in testsuite
In-Reply-To: <CAD3WKgjKOPVTq_B_+hHmihSX7jXKxWtcCEZV3is0KCNjwid-HA@mail.gmail.com>
References: <827780cfc2d244e0a20ca65f8f6d2c1a@DB4PR30MB030.064d.mgd.msft.net>
 <CAD3WKgjKOPVTq_B_+hHmihSX7jXKxWtcCEZV3is0KCNjwid-HA@mail.gmail.com>
Message-ID: <a282f4fc19ab43a1a358c37cef1f677c@DB4PR30MB030.064d.mgd.msft.net>

Thomas

Thanks.  Happily, it has started working again now. I changed nothing!  Mysterious.

Simon

From: Thomas Miedema [mailto:thomasmiedema at gmail.com]
Sent: 09 June 2015 12:51
To: Simon Peyton Jones
Cc: ghc-devs at haskell.org
Subject: Re: windows failure in testsuite

Hi Simon,

this doesn't look like a problem with the testsuite driver. The testsuite driver indeed calls 'diff', but has been doing so for years. Nothing changed there. I just ran the testsuite on Windows with msys2 to double check, and didn't get any framework errors either.

Something changed in your Windows setup maybe?

Cheers,
Thomas


On Mon, Jun 8, 2015 at 11:52 PM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Windows and testsuite folk: The testsuite framework is crashing on my 32-bit Windows machine, with the error below.  Happens when the stderr output differs from expected.
I know that there have been recent changes in the testsuite stuff.  Could you fix please?
Thanks
Simon
=====> T4254(normal) 1587 of 4522 [2, 15, 0]
cd ./indexed-types/should_fail &&  "C:/code/HEAD/inplace/bin/ghc-stage2.exe" -c T4254.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history   > T4254.comp.stderr 2>&1
Actual stderr output differs from expected:
'diff' is not recognized as an internal or external command,
operable program or batch file.

_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150610/91c4dba1/attachment.html>

From george.colpitts at gmail.com  Wed Jun 10 23:31:13 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Wed, 10 Jun 2015 20:31:13 -0300
Subject: Time files... and here's another alpha HP for 7.10
In-Reply-To: <CAAOoiFYyh2T=qjCNgyamm-TzG5U4JnZthjWPtzCLwhyKiWAUQw@mail.gmail.com>
References: <CAAOoiFaNBDCkS7TyZtv5WJ7m0AhnBHbLObyDnn7r8=8A3EkLHg@mail.gmail.com>
 <CAAOoiFagwoGHOmCh6m2BbG4_qNU=qFuuyqjGcq57neE-3_P5+A@mail.gmail.com>
 <CAB-d4A7CW5ZLND0LpLuG4V7jEyo874wo1kDQ15T-R1=QGaF_eA@mail.gmail.com>
 <CAB-d4A6pVU4nmWSmXz7Lr=bGNmLw+Z3ejZ5QE84BYtiDHFWxWQ@mail.gmail.com>
 <CAAOoiFYqhUeCeHhDF3M+BvOkfO-S0n50tOaU7r3D++RFVAW5zw@mail.gmail.com>
 <CAB-d4A5ta64nYJv4F3AW+d2kEgweO6oNN-2P2hazVm8BTkMb0g@mail.gmail.com>
 <CAB-d4A5_aLS6wpJzW=biinRK_48c93bV6Go8pzVjObN_AF-zOg@mail.gmail.com>
 <CAAOoiFYyh2T=qjCNgyamm-TzG5U4JnZthjWPtzCLwhyKiWAUQw@mail.gmail.com>
Message-ID: <CAB-d4A7+dGesBzkmiM0drfzp=pZ1789XqhEAxsuoOfRYoLh+aw@mail.gmail.com>

Not sure what is in the platform as I just did the following:

cabal install -j3 haddock
Resolving dependencies...
Configuring ghc-paths-0.1.0.9...
Configuring haddock-library-1.2.0...
Building haddock-library-1.2.0...
Building ghc-paths-0.1.0.9...
Installed ghc-paths-0.1.0.9
Installed haddock-library-1.2.0
Configuring haddock-api-2.16.0...
Building haddock-api-2.16.0...
Installed haddock-api-2.16.0
Configuring haddock-2.16.0...
Building haddock-2.16.0...
Installed haddock-2.16.0
Updating documentation index
/Users/gcolpitts/Library/Haskell/share/doc/x86_64-osx-ghc-7.10.1.20150601/index.html

If nobody else is seeing the problem I did, I don't think we should worry
about it.

For reference, here is the link for the ghc 7.10.2 Haddock ticket
<https://ghc.haskell.org/trac/ghc/ticket/10496> I mentioned, "Update
Haddock for 7.10.2"

Regards
George

On Tue, Jun 9, 2015 at 11:02 AM, Mark Lentczner <mark.lentczner at gmail.com>
wrote:

> When you did the cabal install of haddock, which haddock did you get?
> Isn't 2.16.0 the latest? And that should be what is in the Platform.
>
> I guess I should check that the haddock in GHC is actually 2.16.0!
> ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150610/944d6d1a/attachment-0001.html>

From g9ks157k at acme.softbase.org  Thu Jun 11 14:37:47 2015
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Thu, 11 Jun 2015 17:37:47 +0300
Subject: GHC build failure
Message-ID: <1434033467.2205.5.camel@idefix>

Hi,

I just updated my GHC HEAD copy via git pull and tried to rebuild GHC
with BuildFlavour set to devel2. I got the following error message:

    ghc/InteractiveUI.hs:68:8: error:
        Could not find module ?Control.DeepSeq?
        It is a member of the hidden package
        ?deepseq-1.4.1.1 at deeps_6vMKxt5sPFR0XsbRWvvq59?.
        Use -v to see a list of the files searched for.

Any ideas what to do?

All the best,
Wolfgang


From thomasmiedema at gmail.com  Thu Jun 11 14:49:07 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Thu, 11 Jun 2015 16:49:07 +0200
Subject: GHC build failure
In-Reply-To: <1434033467.2205.5.camel@idefix>
References: <1434033467.2205.5.camel@idefix>
Message-ID: <CAD3WKgjy8pPZdcZ64iwjj0F+Qi04SvHQs5J8F2+BfXXE==kr8w@mail.gmail.com>

Maybe you forgot `git submodule init` or `git submodule update`? See this
page for a simple trick to never forget again:
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#UsingaGitalias

If that didn't work, do a `make maintainer-clean` and try again.


On Thu, Jun 11, 2015 at 4:37 PM, Wolfgang Jeltsch <
g9ks157k at acme.softbase.org> wrote:

> Hi,
>
> I just updated my GHC HEAD copy via git pull and tried to rebuild GHC
> with BuildFlavour set to devel2. I got the following error message:
>
>     ghc/InteractiveUI.hs:68:8: error:
>         Could not find module ?Control.DeepSeq?
>         It is a member of the hidden package
>         ?deepseq-1.4.1.1 at deeps_6vMKxt5sPFR0XsbRWvvq59?.
>         Use -v to see a list of the files searched for.
>
> Any ideas what to do?
>
> All the best,
> Wolfgang
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150611/e2d2558c/attachment.html>

From hvriedel at gmail.com  Thu Jun 11 14:50:45 2015
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Thu, 11 Jun 2015 16:50:45 +0200
Subject: GHC build failure
In-Reply-To: <1434033467.2205.5.camel@idefix> (Wolfgang Jeltsch's message of
 "Thu, 11 Jun 2015 17:37:47 +0300")
References: <1434033467.2205.5.camel@idefix>
Message-ID: <87pp52xpru.fsf@gmail.com>

On 2015-06-11 at 16:37:47 +0200, Wolfgang Jeltsch wrote:
> I just updated my GHC HEAD copy via git pull and tried to rebuild GHC
> with BuildFlavour set to devel2. I got the following error message:
>
>     ghc/InteractiveUI.hs:68:8: error:
>         Could not find module ?Control.DeepSeq?
>         It is a member of the hidden package
>         ?deepseq-1.4.1.1 at deeps_6vMKxt5sPFR0XsbRWvvq59?.
>         Use -v to see a list of the files searched for.
>
> Any ideas what to do?

...have you ./boot'ed and ./configure'd again (and to be on the safe
side, also 'make distclean')? This sounds as if your ghc/ghc-bin.cabal
wasn't regenerated from the .in file...

From jan.stolarek at p.lodz.pl  Thu Jun 11 15:04:55 2015
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 11 Jun 2015 17:04:55 +0200
Subject: Adding location information to derived code
In-Reply-To: <d590506e5689486e9a1ca948278dcc54@DB4PR30MB030.064d.mgd.msft.net>
References: <201506101512.19915.jan.stolarek@p.lodz.pl>
 <d590506e5689486e9a1ca948278dcc54@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <201506111704.55297.jan.stolarek@p.lodz.pl>

> Please open a ticket for your test case, and (if you can) fix it.  The
> location for the implicit instance should jolly well be the instance
> declaration for 'instance C Int'!
The fix is trivial and I have it on my injectivity branch. I'm really not sure if that problem 
manifests itself without injectivity.

Janek

>
> Thanks for spotting this.
>
> Simon
>
> | -----Original Message-----
> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Jan
> | Stolarek
> | Sent: 10 June 2015 14:12
> | To: ghc-devs at haskell.org
> | Subject: Adding location information to derived code
> |
> | Hi devs,
> |
> | say I have:
> |
> |   class C a where
> |     type F a
> |     type F a = a
> |
> |   instance C Int
> |
> | During compilation of "instance C Int" GHC will derive a default
> | associated type instance "F Int =
> | Int". That instance has no location information and so any errors that it
> | might cause will have a
> | very uninformative source code location 1:1. I want to fix this but I'm
> | not sure whether it is a
> | good idea to add location information to automatically generated code. Do
> | we make any assumptions
> | that derived code should have no location information?
> |
> | Janek
> |
> | ---
> | Politechnika ??dzka
> | Lodz University of Technology
> |
> | Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
> | Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez
> | pomy?k?
> | prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.
> |
> | This email contains information intended solely for the use of the
> | individual to whom it is addressed.
> | If you are not the intended recipient or if you have received this
> | message in error,
> | please notify the sender and delete it from your system.
> | _______________________________________________
> | ghc-devs mailing list
> | ghc-devs at haskell.org
> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



---
Politechnika ??dzka
Lodz University of Technology

Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata.
Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k?
prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie.

This email contains information intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient or if you have received this message in error,
please notify the sender and delete it from your system.

From g9ks157k at acme.softbase.org  Thu Jun 11 15:08:58 2015
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Thu, 11 Jun 2015 18:08:58 +0300
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <55774FF2.8020505@gmail.com>
References: <55774FF2.8020505@gmail.com>
Message-ID: <1434035338.2205.17.camel@idefix>

Hi David,

thank you very much for this proposal. I think having fail in Monad is
just plain wrong, and I am therefore very happy to see it being moved
out.

I have some remarks, though:

> A class of patterns that are conditionally failable are `newtype`s,
> and single constructor `data` types, which are unfailable by
> themselves, but may fail if matching on their fields is done with
> failable paterns.

The part about single-constructor data types is not true. A
single-constructor data type has a value ? that is different from
applying the data constructor to ??s. For example, ? and (?, ?) are two
different values. Matching ? against the pattern (_, _) fails, matching
(?, ?) against (_, _) succeeds. So single-constructor data types are not
different from all other data types in this respect. The dividing line
really runs between data types and newtypes. So only matches against
patterns C p where C is a newtype constructor and p is unfailable should
be considered unfailable.

>   - Applicative `do` notation is coming sooner or later, `fail` might
>     be useful in this more general scenario. Due to the AMP, it is
>     trivial to change the `MonadFail` superclass to `Applicative`
>     later. (The name will be a bit misleading, but it's a very small
>     price to pay.)

I think it would be very misleading having a MonadFail class that might
have instances that are not monads, and that this is a price we should
not pay. So we should not name the class MonadFail. Maybe, Fail would be
a good name.

> I think we should keep the `Monad` superclass for three main reasons:
> 
>   - We don't want to see `(Monad m, MonadFail m) =>` all over the place.

But exactly this will happen if we change the superclass of (Monad)Fail
from Monad to Applicative. So it might be better to impose a more
light-weight constraint in the first place. Functor m might be a good
choice.

All the best,
Wolfgang


From g9ks157k at acme.softbase.org  Thu Jun 11 15:12:12 2015
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Thu, 11 Jun 2015 18:12:12 +0300
Subject: GHC build failure
In-Reply-To: <87pp52xpru.fsf@gmail.com>
References: <1434033467.2205.5.camel@idefix> <87pp52xpru.fsf@gmail.com>
Message-ID: <1434035532.2205.19.camel@idefix>

Am Donnerstag, den 11.06.2015, 16:50 +0200 schrieb Herbert Valerio
Riedel:
> On 2015-06-11 at 16:37:47 +0200, Wolfgang Jeltsch wrote:
> > I just updated my GHC HEAD copy via git pull and tried to rebuild GHC
> > with BuildFlavour set to devel2. I got the following error message:
> >
> >     ghc/InteractiveUI.hs:68:8: error:
> >         Could not find module ?Control.DeepSeq?
> >         It is a member of the hidden package
> >         ?deepseq-1.4.1.1 at deeps_6vMKxt5sPFR0XsbRWvvq59?.
> >         Use -v to see a list of the files searched for.
> >
> > Any ideas what to do?
> 
> ...have you ./boot'ed and ./configure'd again (and to be on the safe
> side, also 'make distclean')? This sounds as if your ghc/ghc-bin.cabal
> wasn't regenerated from the .in file...

The page at <https://ghc.haskell.org/trac/ghc/wiki/Building/Hacking>
says that just running make again is enough.

Also, I do not want to run make distclean, of course, since I want the
rebuild to be fast.

All the best,
Wolfgang


From g9ks157k at acme.softbase.org  Thu Jun 11 15:17:48 2015
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Thu, 11 Jun 2015 18:17:48 +0300
Subject: GHC build failure
In-Reply-To: <CAD3WKgjy8pPZdcZ64iwjj0F+Qi04SvHQs5J8F2+BfXXE==kr8w@mail.gmail.com>
References: <1434033467.2205.5.camel@idefix>
 <CAD3WKgjy8pPZdcZ64iwjj0F+Qi04SvHQs5J8F2+BfXXE==kr8w@mail.gmail.com>
Message-ID: <1434035868.2205.22.camel@idefix>

Hi,

I did not care about the submodules; so this could be the reason of the
failure. That said, running

    git submodule update --init

now only showed a message regarding utils/haddock, which causes me some
doubts that it will really fix the issue with deepseq. Let?s see.

All the best,
Wolfgang

Am Donnerstag, den 11.06.2015, 16:49 +0200 schrieb Thomas Miedema:
> Maybe you forgot `git submodule init` or `git submodule update`? See
> this page for a simple trick to never forget again:
> https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#UsingaGitalias
> 
> 
> If that didn't work, do a `make maintainer-clean` and try again.
> 
> 
> 
> On Thu, Jun 11, 2015 at 4:37 PM, Wolfgang Jeltsch
> <g9ks157k at acme.softbase.org> wrote:
>         Hi,
>         
>         I just updated my GHC HEAD copy via git pull and tried to
>         rebuild GHC
>         with BuildFlavour set to devel2. I got the following error
>         message:
>         
>             ghc/InteractiveUI.hs:68:8: error:
>                 Could not find module ?Control.DeepSeq?
>                 It is a member of the hidden package
>                 ?deepseq-1.4.1.1 at deeps_6vMKxt5sPFR0XsbRWvvq59?.
>                 Use -v to see a list of the files searched for.
>         
>         Any ideas what to do?
>         
>         All the best,
>         Wolfgang



From g9ks157k at acme.softbase.org  Thu Jun 11 15:20:09 2015
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Thu, 11 Jun 2015 18:20:09 +0300
Subject: GHC build failure
In-Reply-To: <1434035868.2205.22.camel@idefix>
References: <1434033467.2205.5.camel@idefix>
 <CAD3WKgjy8pPZdcZ64iwjj0F+Qi04SvHQs5J8F2+BfXXE==kr8w@mail.gmail.com>
 <1434035868.2205.22.camel@idefix>
Message-ID: <1434036009.2205.23.camel@idefix>

Hi again,

it still fails with the same error message.

All the best,
Wolfgang

Am Donnerstag, den 11.06.2015, 18:17 +0300 schrieb Wolfgang Jeltsch:
> Hi,
> 
> I did not care about the submodules; so this could be the reason of the
> failure. That said, running
> 
>     git submodule update --init
> 
> now only showed a message regarding utils/haddock, which causes me some
> doubts that it will really fix the issue with deepseq. Let?s see.
> 
> All the best,
> Wolfgang
> 
> Am Donnerstag, den 11.06.2015, 16:49 +0200 schrieb Thomas Miedema:
> > Maybe you forgot `git submodule init` or `git submodule update`? See
> > this page for a simple trick to never forget again:
> > https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#UsingaGitalias
> > 
> > 
> > If that didn't work, do a `make maintainer-clean` and try again.
> > 
> > 
> > 
> > On Thu, Jun 11, 2015 at 4:37 PM, Wolfgang Jeltsch
> > <g9ks157k at acme.softbase.org> wrote:
> >         Hi,
> >         
> >         I just updated my GHC HEAD copy via git pull and tried to
> >         rebuild GHC
> >         with BuildFlavour set to devel2. I got the following error
> >         message:
> >         
> >             ghc/InteractiveUI.hs:68:8: error:
> >                 Could not find module ?Control.DeepSeq?
> >                 It is a member of the hidden package
> >                 ?deepseq-1.4.1.1 at deeps_6vMKxt5sPFR0XsbRWvvq59?.
> >                 Use -v to see a list of the files searched for.
> >         
> >         Any ideas what to do?
> >         
> >         All the best,
> >         Wolfgang
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



From dct25-561bs at mythic-beasts.com  Thu Jun 11 15:23:28 2015
From: dct25-561bs at mythic-beasts.com (David Turner)
Date: Thu, 11 Jun 2015 16:23:28 +0100
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <1434035338.2205.17.camel@idefix>
References: <55774FF2.8020505@gmail.com>
	<1434035338.2205.17.camel@idefix>
Message-ID: <CAErCyQ-SQYHkagt7929g=oa+jjf+8MsZ50cyGjFNM98zOWYiVA@mail.gmail.com>

AIUI the point about ? and (?, ?) being different doesn't matter here:
a bind for a single-constructor datatype never desugars in a way that
uses fail (which isn't to say that it can't be undefined)

For instance:

runErrorT (do { (_,_) <- return undefined; return () } :: ErrorT String IO ())

throws an exception, even though the bind is in ErrorT where fail just
returns left:

runErrorT (do { fail "oops"; return () } :: ErrorT String IO ())

=> Left "oops"

Hope that helps, and hope I understand correctly!

David


On 11 June 2015 at 16:08, Wolfgang Jeltsch <g9ks157k at acme.softbase.org> wrote:
> Hi David,
>
> thank you very much for this proposal. I think having fail in Monad is
> just plain wrong, and I am therefore very happy to see it being moved
> out.
>
> I have some remarks, though:
>
>> A class of patterns that are conditionally failable are `newtype`s,
>> and single constructor `data` types, which are unfailable by
>> themselves, but may fail if matching on their fields is done with
>> failable paterns.
>
> The part about single-constructor data types is not true. A
> single-constructor data type has a value ? that is different from
> applying the data constructor to ??s. For example, ? and (?, ?) are two
> different values. Matching ? against the pattern (_, _) fails, matching
> (?, ?) against (_, _) succeeds. So single-constructor data types are not
> different from all other data types in this respect. The dividing line
> really runs between data types and newtypes. So only matches against
> patterns C p where C is a newtype constructor and p is unfailable should
> be considered unfailable.
>
>>   - Applicative `do` notation is coming sooner or later, `fail` might
>>     be useful in this more general scenario. Due to the AMP, it is
>>     trivial to change the `MonadFail` superclass to `Applicative`
>>     later. (The name will be a bit misleading, but it's a very small
>>     price to pay.)
>
> I think it would be very misleading having a MonadFail class that might
> have instances that are not monads, and that this is a price we should
> not pay. So we should not name the class MonadFail. Maybe, Fail would be
> a good name.
>
>> I think we should keep the `Monad` superclass for three main reasons:
>>
>>   - We don't want to see `(Monad m, MonadFail m) =>` all over the place.
>
> But exactly this will happen if we change the superclass of (Monad)Fail
> from Monad to Applicative. So it might be better to impose a more
> light-weight constraint in the first place. Functor m might be a good
> choice.
>
> All the best,
> Wolfgang
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From g9ks157k at acme.softbase.org  Thu Jun 11 15:28:20 2015
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Thu, 11 Jun 2015 18:28:20 +0300
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <CAErCyQ-SQYHkagt7929g=oa+jjf+8MsZ50cyGjFNM98zOWYiVA@mail.gmail.com>
References: <55774FF2.8020505@gmail.com> <1434035338.2205.17.camel@idefix>
 <CAErCyQ-SQYHkagt7929g=oa+jjf+8MsZ50cyGjFNM98zOWYiVA@mail.gmail.com>
Message-ID: <1434036500.2205.25.camel@idefix>

Are you sure that desugaring works this way? If yes, this should be
considered a bug and be fixed, I would say. It is very illogical.

All the best,
Wolfgang

Am Donnerstag, den 11.06.2015, 16:23 +0100 schrieb David Turner:
> AIUI the point about ? and (?, ?) being different doesn't matter here:
> a bind for a single-constructor datatype never desugars in a way that
> uses fail (which isn't to say that it can't be undefined)
> 
> For instance:
> 
> runErrorT (do { (_,_) <- return undefined; return () } :: ErrorT String IO ())
> 
> throws an exception, even though the bind is in ErrorT where fail just
> returns left:
> 
> runErrorT (do { fail "oops"; return () } :: ErrorT String IO ())
> 
> => Left "oops"
> 
> Hope that helps, and hope I understand correctly!
> 
> David
> 
> 
> On 11 June 2015 at 16:08, Wolfgang Jeltsch <g9ks157k at acme.softbase.org> wrote:
> > Hi David,
> >
> > thank you very much for this proposal. I think having fail in Monad is
> > just plain wrong, and I am therefore very happy to see it being moved
> > out.
> >
> > I have some remarks, though:
> >
> >> A class of patterns that are conditionally failable are `newtype`s,
> >> and single constructor `data` types, which are unfailable by
> >> themselves, but may fail if matching on their fields is done with
> >> failable paterns.
> >
> > The part about single-constructor data types is not true. A
> > single-constructor data type has a value ? that is different from
> > applying the data constructor to ??s. For example, ? and (?, ?) are two
> > different values. Matching ? against the pattern (_, _) fails, matching
> > (?, ?) against (_, _) succeeds. So single-constructor data types are not
> > different from all other data types in this respect. The dividing line
> > really runs between data types and newtypes. So only matches against
> > patterns C p where C is a newtype constructor and p is unfailable should
> > be considered unfailable.
> >
> >>   - Applicative `do` notation is coming sooner or later, `fail` might
> >>     be useful in this more general scenario. Due to the AMP, it is
> >>     trivial to change the `MonadFail` superclass to `Applicative`
> >>     later. (The name will be a bit misleading, but it's a very small
> >>     price to pay.)
> >
> > I think it would be very misleading having a MonadFail class that might
> > have instances that are not monads, and that this is a price we should
> > not pay. So we should not name the class MonadFail. Maybe, Fail would be
> > a good name.
> >
> >> I think we should keep the `Monad` superclass for three main reasons:
> >>
> >>   - We don't want to see `(Monad m, MonadFail m) =>` all over the place.
> >
> > But exactly this will happen if we change the superclass of (Monad)Fail
> > from Monad to Applicative. So it might be better to impose a more
> > light-weight constraint in the first place. Functor m might be a good
> > choice.
> >
> > All the best,
> > Wolfgang
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



From david.feuer at gmail.com  Thu Jun 11 15:36:23 2015
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 11 Jun 2015 11:36:23 -0400
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <1434036500.2205.25.camel@idefix>
References: <55774FF2.8020505@gmail.com> <1434035338.2205.17.camel@idefix>
 <CAErCyQ-SQYHkagt7929g=oa+jjf+8MsZ50cyGjFNM98zOWYiVA@mail.gmail.com>
 <1434036500.2205.25.camel@idefix>
Message-ID: <CAMgWh9um_qYVYK69G-fcPas_hBXvsZaxijpKjSiR57hE1Pzkdg@mail.gmail.com>

Pattern matching on `undefined` is not like pattern match failure.
Single-constructor types are only special if they're unlifted:
`newtype` and GHC's unboxed tuples are the only examples I know of,
and you can't use unboxed tuples in this context.

On Thu, Jun 11, 2015 at 11:28 AM, Wolfgang Jeltsch
<g9ks157k at acme.softbase.org> wrote:
> Are you sure that desugaring works this way? If yes, this should be
> considered a bug and be fixed, I would say. It is very illogical.
>
> All the best,
> Wolfgang
>
> Am Donnerstag, den 11.06.2015, 16:23 +0100 schrieb David Turner:
>> AIUI the point about ? and (?, ?) being different doesn't matter here:
>> a bind for a single-constructor datatype never desugars in a way that
>> uses fail (which isn't to say that it can't be undefined)
>>
>> For instance:
>>
>> runErrorT (do { (_,_) <- return undefined; return () } :: ErrorT String IO ())
>>
>> throws an exception, even though the bind is in ErrorT where fail just
>> returns left:
>>
>> runErrorT (do { fail "oops"; return () } :: ErrorT String IO ())
>>
>> => Left "oops"
>>
>> Hope that helps, and hope I understand correctly!
>>
>> David
>>
>>
>> On 11 June 2015 at 16:08, Wolfgang Jeltsch <g9ks157k at acme.softbase.org> wrote:
>> > Hi David,
>> >
>> > thank you very much for this proposal. I think having fail in Monad is
>> > just plain wrong, and I am therefore very happy to see it being moved
>> > out.
>> >
>> > I have some remarks, though:
>> >
>> >> A class of patterns that are conditionally failable are `newtype`s,
>> >> and single constructor `data` types, which are unfailable by
>> >> themselves, but may fail if matching on their fields is done with
>> >> failable paterns.
>> >
>> > The part about single-constructor data types is not true. A
>> > single-constructor data type has a value ? that is different from
>> > applying the data constructor to ??s. For example, ? and (?, ?) are two
>> > different values. Matching ? against the pattern (_, _) fails, matching
>> > (?, ?) against (_, _) succeeds. So single-constructor data types are not
>> > different from all other data types in this respect. The dividing line
>> > really runs between data types and newtypes. So only matches against
>> > patterns C p where C is a newtype constructor and p is unfailable should
>> > be considered unfailable.
>> >
>> >>   - Applicative `do` notation is coming sooner or later, `fail` might
>> >>     be useful in this more general scenario. Due to the AMP, it is
>> >>     trivial to change the `MonadFail` superclass to `Applicative`
>> >>     later. (The name will be a bit misleading, but it's a very small
>> >>     price to pay.)
>> >
>> > I think it would be very misleading having a MonadFail class that might
>> > have instances that are not monads, and that this is a price we should
>> > not pay. So we should not name the class MonadFail. Maybe, Fail would be
>> > a good name.
>> >
>> >> I think we should keep the `Monad` superclass for three main reasons:
>> >>
>> >>   - We don't want to see `(Monad m, MonadFail m) =>` all over the place.
>> >
>> > But exactly this will happen if we change the superclass of (Monad)Fail
>> > from Monad to Applicative. So it might be better to impose a more
>> > light-weight constraint in the first place. Functor m might be a good
>> > choice.
>> >
>> > All the best,
>> > Wolfgang
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From g9ks157k at acme.softbase.org  Thu Jun 11 15:58:19 2015
From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch)
Date: Thu, 11 Jun 2015 18:58:19 +0300
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <CAMgWh9um_qYVYK69G-fcPas_hBXvsZaxijpKjSiR57hE1Pzkdg@mail.gmail.com>
References: <55774FF2.8020505@gmail.com> <1434035338.2205.17.camel@idefix>
 <CAErCyQ-SQYHkagt7929g=oa+jjf+8MsZ50cyGjFNM98zOWYiVA@mail.gmail.com>
 <1434036500.2205.25.camel@idefix>
 <CAMgWh9um_qYVYK69G-fcPas_hBXvsZaxijpKjSiR57hE1Pzkdg@mail.gmail.com>
Message-ID: <1434038299.2205.32.camel@idefix>

Ah, I see. Even if you desugar pattern matching against (_, _) in a do
block like you do for multi-constructor data types, ? still does not
result in an invocation of fail, since matching ? against (_, _) leads
to divergence. To illustrate this, let f be defined as follows:

    f (_, _) = True
    f _      = False

Applying f to an expression of the form (x, y) results in True, applying
it to ? results in ?. False can never be the result.

That said, it would seem more logical to me if all data types would be
treated equal in monadic pattern matching.

All the best,
Wolfgang

Am Donnerstag, den 11.06.2015, 11:36 -0400 schrieb David Feuer:
> Pattern matching on `undefined` is not like pattern match failure.
> Single-constructor types are only special if they're unlifted:
> `newtype` and GHC's unboxed tuples are the only examples I know of,
> and you can't use unboxed tuples in this context.
> 
> On Thu, Jun 11, 2015 at 11:28 AM, Wolfgang Jeltsch
> <g9ks157k at acme.softbase.org> wrote:
> > Are you sure that desugaring works this way? If yes, this should be
> > considered a bug and be fixed, I would say. It is very illogical.
> >
> > All the best,
> > Wolfgang
> >
> > Am Donnerstag, den 11.06.2015, 16:23 +0100 schrieb David Turner:
> >> AIUI the point about ? and (?, ?) being different doesn't matter here:
> >> a bind for a single-constructor datatype never desugars in a way that
> >> uses fail (which isn't to say that it can't be undefined)
> >>
> >> For instance:
> >>
> >> runErrorT (do { (_,_) <- return undefined; return () } :: ErrorT String IO ())
> >>
> >> throws an exception, even though the bind is in ErrorT where fail just
> >> returns left:
> >>
> >> runErrorT (do { fail "oops"; return () } :: ErrorT String IO ())
> >>
> >> => Left "oops"
> >>
> >> Hope that helps, and hope I understand correctly!
> >>
> >> David
> >>
> >>
> >> On 11 June 2015 at 16:08, Wolfgang Jeltsch <g9ks157k at acme.softbase.org> wrote:
> >> > Hi David,
> >> >
> >> > thank you very much for this proposal. I think having fail in Monad is
> >> > just plain wrong, and I am therefore very happy to see it being moved
> >> > out.
> >> >
> >> > I have some remarks, though:
> >> >
> >> >> A class of patterns that are conditionally failable are `newtype`s,
> >> >> and single constructor `data` types, which are unfailable by
> >> >> themselves, but may fail if matching on their fields is done with
> >> >> failable paterns.
> >> >
> >> > The part about single-constructor data types is not true. A
> >> > single-constructor data type has a value ? that is different from
> >> > applying the data constructor to ??s. For example, ? and (?, ?) are two
> >> > different values. Matching ? against the pattern (_, _) fails, matching
> >> > (?, ?) against (_, _) succeeds. So single-constructor data types are not
> >> > different from all other data types in this respect. The dividing line
> >> > really runs between data types and newtypes. So only matches against
> >> > patterns C p where C is a newtype constructor and p is unfailable should
> >> > be considered unfailable.
> >> >
> >> >>   - Applicative `do` notation is coming sooner or later, `fail` might
> >> >>     be useful in this more general scenario. Due to the AMP, it is
> >> >>     trivial to change the `MonadFail` superclass to `Applicative`
> >> >>     later. (The name will be a bit misleading, but it's a very small
> >> >>     price to pay.)
> >> >
> >> > I think it would be very misleading having a MonadFail class that might
> >> > have instances that are not monads, and that this is a price we should
> >> > not pay. So we should not name the class MonadFail. Maybe, Fail would be
> >> > a good name.
> >> >
> >> >> I think we should keep the `Monad` superclass for three main reasons:
> >> >>
> >> >>   - We don't want to see `(Monad m, MonadFail m) =>` all over the place.
> >> >
> >> > But exactly this will happen if we change the superclass of (Monad)Fail
> >> > from Monad to Applicative. So it might be better to impose a more
> >> > light-weight constraint in the first place. Functor m might be a good
> >> > choice.
> >> >
> >> > All the best,
> >> > Wolfgang
> >> >
> >> > _______________________________________________
> >> > ghc-devs mailing list
> >> > ghc-devs at haskell.org
> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



From dct25-561bs at mythic-beasts.com  Thu Jun 11 16:11:40 2015
From: dct25-561bs at mythic-beasts.com (David Turner)
Date: Thu, 11 Jun 2015 17:11:40 +0100
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <1434036500.2205.25.camel@idefix>
References: <55774FF2.8020505@gmail.com> <1434035338.2205.17.camel@idefix>
 <CAErCyQ-SQYHkagt7929g=oa+jjf+8MsZ50cyGjFNM98zOWYiVA@mail.gmail.com>
 <1434036500.2205.25.camel@idefix>
Message-ID: <CAErCyQ-aXZUj6dhzQ6Ui2ZF7ugpC87TY58Gi7_E1AMZ8oysxxg@mail.gmail.com>

Quoting the Haskell 2010 Report section 3.17.2: Attempting to match a
pattern can have one of three results: it may fail; it may succeed
...; or it may diverge. Then in paragraph 5:

Matching the pattern con pat1 ... patn against a value, where con is a
constructor defined by data, depends on the value:
- If the value is of the form con v1 ... vn, sub-patterns are matched
left-to-right against the components of the data value; if all matches
succeed, the overall match succeeds; the first to fail or diverge
causes the overall match to fail or diverge, respectively.
- If the value is of the form con' v1 ... vm, where con is a different
constructor to con', the match fails.
- If the value is ?, the match diverges.

In particular, matching (_,_) can only succeed or diverge: failure is
not an option! Desugaring 'do' handles match failure with a catch-all
case that calls 'fail' but doesn't handle ?.



On 11 June 2015 at 16:28, Wolfgang Jeltsch <g9ks157k at acme.softbase.org> wrote:
> Are you sure that desugaring works this way? If yes, this should be
> considered a bug and be fixed, I would say. It is very illogical.
>
> All the best,
> Wolfgang
>
> Am Donnerstag, den 11.06.2015, 16:23 +0100 schrieb David Turner:
>> AIUI the point about ? and (?, ?) being different doesn't matter here:
>> a bind for a single-constructor datatype never desugars in a way that
>> uses fail (which isn't to say that it can't be undefined)
>>
>> For instance:
>>
>> runErrorT (do { (_,_) <- return undefined; return () } :: ErrorT String IO ())
>>
>> throws an exception, even though the bind is in ErrorT where fail just
>> returns left:
>>
>> runErrorT (do { fail "oops"; return () } :: ErrorT String IO ())
>>
>> => Left "oops"
>>
>> Hope that helps, and hope I understand correctly!
>>
>> David
>>
>>
>> On 11 June 2015 at 16:08, Wolfgang Jeltsch <g9ks157k at acme.softbase.org> wrote:
>> > Hi David,
>> >
>> > thank you very much for this proposal. I think having fail in Monad is
>> > just plain wrong, and I am therefore very happy to see it being moved
>> > out.
>> >
>> > I have some remarks, though:
>> >
>> >> A class of patterns that are conditionally failable are `newtype`s,
>> >> and single constructor `data` types, which are unfailable by
>> >> themselves, but may fail if matching on their fields is done with
>> >> failable paterns.
>> >
>> > The part about single-constructor data types is not true. A
>> > single-constructor data type has a value ? that is different from
>> > applying the data constructor to ??s. For example, ? and (?, ?) are two
>> > different values. Matching ? against the pattern (_, _) fails, matching
>> > (?, ?) against (_, _) succeeds. So single-constructor data types are not
>> > different from all other data types in this respect. The dividing line
>> > really runs between data types and newtypes. So only matches against
>> > patterns C p where C is a newtype constructor and p is unfailable should
>> > be considered unfailable.
>> >
>> >>   - Applicative `do` notation is coming sooner or later, `fail` might
>> >>     be useful in this more general scenario. Due to the AMP, it is
>> >>     trivial to change the `MonadFail` superclass to `Applicative`
>> >>     later. (The name will be a bit misleading, but it's a very small
>> >>     price to pay.)
>> >
>> > I think it would be very misleading having a MonadFail class that might
>> > have instances that are not monads, and that this is a price we should
>> > not pay. So we should not name the class MonadFail. Maybe, Fail would be
>> > a good name.
>> >
>> >> I think we should keep the `Monad` superclass for three main reasons:
>> >>
>> >>   - We don't want to see `(Monad m, MonadFail m) =>` all over the place.
>> >
>> > But exactly this will happen if we change the superclass of (Monad)Fail
>> > from Monad to Applicative. So it might be better to impose a more
>> > light-weight constraint in the first place. Functor m might be a good
>> > choice.
>> >
>> > All the best,
>> > Wolfgang
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From dan.doel at gmail.com  Thu Jun 11 16:20:02 2015
From: dan.doel at gmail.com (Dan Doel)
Date: Thu, 11 Jun 2015 12:20:02 -0400
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <CAErCyQ-aXZUj6dhzQ6Ui2ZF7ugpC87TY58Gi7_E1AMZ8oysxxg@mail.gmail.com>
References: <55774FF2.8020505@gmail.com> <1434035338.2205.17.camel@idefix>
 <CAErCyQ-SQYHkagt7929g=oa+jjf+8MsZ50cyGjFNM98zOWYiVA@mail.gmail.com>
 <1434036500.2205.25.camel@idefix>
 <CAErCyQ-aXZUj6dhzQ6Ui2ZF7ugpC87TY58Gi7_E1AMZ8oysxxg@mail.gmail.com>
Message-ID: <CAHEA9tP3X4=P9fAwPO=7rSWfCPxPtZOV40A1BYaqeZ487iXJnA@mail.gmail.com>

This is all well defined in the Haskell 1.4 report. Back then Haskell had
"unfailable" patterns for desugaring do notation, because there was no fail
(it was introduced in H98).

I believe a pattern is classified as unfailable there if it is irrefutable
or refutable only by bottom. Which of course is the distinction here, (x,y)
is unfailable, but not irrefutable.

And of course, it seems that GHC never actually stopped implementing
unfailable patterns, even though they were removed from the report (or
someone added it back at some point). You just have to know how to observe
this fact.

-- Dan

On Thu, Jun 11, 2015 at 12:11 PM, David Turner <
dct25-561bs at mythic-beasts.com> wrote:

> Quoting the Haskell 2010 Report section 3.17.2: Attempting to match a
> pattern can have one of three results: it may fail; it may succeed
> ...; or it may diverge. Then in paragraph 5:
>
> Matching the pattern con pat1 ... patn against a value, where con is a
> constructor defined by data, depends on the value:
> - If the value is of the form con v1 ... vn, sub-patterns are matched
> left-to-right against the components of the data value; if all matches
> succeed, the overall match succeeds; the first to fail or diverge
> causes the overall match to fail or diverge, respectively.
> - If the value is of the form con' v1 ... vm, where con is a different
> constructor to con', the match fails.
> - If the value is ?, the match diverges.
>
> In particular, matching (_,_) can only succeed or diverge: failure is
> not an option! Desugaring 'do' handles match failure with a catch-all
> case that calls 'fail' but doesn't handle ?.
>
>
>
> On 11 June 2015 at 16:28, Wolfgang Jeltsch <g9ks157k at acme.softbase.org>
> wrote:
> > Are you sure that desugaring works this way? If yes, this should be
> > considered a bug and be fixed, I would say. It is very illogical.
> >
> > All the best,
> > Wolfgang
> >
> > Am Donnerstag, den 11.06.2015, 16:23 +0100 schrieb David Turner:
> >> AIUI the point about ? and (?, ?) being different doesn't matter here:
> >> a bind for a single-constructor datatype never desugars in a way that
> >> uses fail (which isn't to say that it can't be undefined)
> >>
> >> For instance:
> >>
> >> runErrorT (do { (_,_) <- return undefined; return () } :: ErrorT String
> IO ())
> >>
> >> throws an exception, even though the bind is in ErrorT where fail just
> >> returns left:
> >>
> >> runErrorT (do { fail "oops"; return () } :: ErrorT String IO ())
> >>
> >> => Left "oops"
> >>
> >> Hope that helps, and hope I understand correctly!
> >>
> >> David
> >>
> >>
> >> On 11 June 2015 at 16:08, Wolfgang Jeltsch <g9ks157k at acme.softbase.org>
> wrote:
> >> > Hi David,
> >> >
> >> > thank you very much for this proposal. I think having fail in Monad is
> >> > just plain wrong, and I am therefore very happy to see it being moved
> >> > out.
> >> >
> >> > I have some remarks, though:
> >> >
> >> >> A class of patterns that are conditionally failable are `newtype`s,
> >> >> and single constructor `data` types, which are unfailable by
> >> >> themselves, but may fail if matching on their fields is done with
> >> >> failable paterns.
> >> >
> >> > The part about single-constructor data types is not true. A
> >> > single-constructor data type has a value ? that is different from
> >> > applying the data constructor to ??s. For example, ? and (?, ?) are
> two
> >> > different values. Matching ? against the pattern (_, _) fails,
> matching
> >> > (?, ?) against (_, _) succeeds. So single-constructor data types are
> not
> >> > different from all other data types in this respect. The dividing line
> >> > really runs between data types and newtypes. So only matches against
> >> > patterns C p where C is a newtype constructor and p is unfailable
> should
> >> > be considered unfailable.
> >> >
> >> >>   - Applicative `do` notation is coming sooner or later, `fail` might
> >> >>     be useful in this more general scenario. Due to the AMP, it is
> >> >>     trivial to change the `MonadFail` superclass to `Applicative`
> >> >>     later. (The name will be a bit misleading, but it's a very small
> >> >>     price to pay.)
> >> >
> >> > I think it would be very misleading having a MonadFail class that
> might
> >> > have instances that are not monads, and that this is a price we should
> >> > not pay. So we should not name the class MonadFail. Maybe, Fail would
> be
> >> > a good name.
> >> >
> >> >> I think we should keep the `Monad` superclass for three main reasons:
> >> >>
> >> >>   - We don't want to see `(Monad m, MonadFail m) =>` all over the
> place.
> >> >
> >> > But exactly this will happen if we change the superclass of
> (Monad)Fail
> >> > from Monad to Applicative. So it might be better to impose a more
> >> > light-weight constraint in the first place. Functor m might be a good
> >> > choice.
> >> >
> >> > All the best,
> >> > Wolfgang
> >> >
> >> > _______________________________________________
> >> > ghc-devs mailing list
> >> > ghc-devs at haskell.org
> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150611/1313db8c/attachment-0001.html>

From simonpj at microsoft.com  Thu Jun 11 16:23:22 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 11 Jun 2015 16:23:22 +0000
Subject: GHC build failure
In-Reply-To: <1434036009.2205.23.camel@idefix>
References: <1434033467.2205.5.camel@idefix>
 <CAD3WKgjy8pPZdcZ64iwjj0F+Qi04SvHQs5J8F2+BfXXE==kr8w@mail.gmail.com>
 <1434035868.2205.22.camel@idefix> <1434036009.2205.23.camel@idefix>
Message-ID: <92c63c05c932461788180154ece4d894@DB4PR30MB030.064d.mgd.msft.net>

I got the same thing on my 7.10 branch.  But when I said "sh validate" (which starts with make distclean etc) all was well.

S

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Wolfgang Jeltsch
|  Sent: 11 June 2015 16:20
|  To: ghc-devs at haskell.org
|  Subject: Re: GHC build failure
|  
|  Hi again,
|  
|  it still fails with the same error message.
|  
|  All the best,
|  Wolfgang
|  
|  Am Donnerstag, den 11.06.2015, 18:17 +0300 schrieb Wolfgang Jeltsch:
|  > Hi,
|  >
|  > I did not care about the submodules; so this could be the reason of
|  > the failure. That said, running
|  >
|  >     git submodule update --init
|  >
|  > now only showed a message regarding utils/haddock, which causes me
|  > some doubts that it will really fix the issue with deepseq. Let?s
|  see.
|  >
|  > All the best,
|  > Wolfgang
|  >
|  > Am Donnerstag, den 11.06.2015, 16:49 +0200 schrieb Thomas Miedema:
|  > > Maybe you forgot `git submodule init` or `git submodule update`?
|  See
|  > > this page for a simple trick to never forget again:
|  > >
|  https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodu
|  > > les#UsingaGitalias
|  > >
|  > >
|  > > If that didn't work, do a `make maintainer-clean` and try again.
|  > >
|  > >
|  > >
|  > > On Thu, Jun 11, 2015 at 4:37 PM, Wolfgang Jeltsch
|  > > <g9ks157k at acme.softbase.org> wrote:
|  > >         Hi,
|  > >
|  > >         I just updated my GHC HEAD copy via git pull and tried to
|  > >         rebuild GHC
|  > >         with BuildFlavour set to devel2. I got the following error
|  > >         message:
|  > >
|  > >             ghc/InteractiveUI.hs:68:8: error:
|  > >                 Could not find module ?Control.DeepSeq?
|  > >                 It is a member of the hidden package
|  > >                 ?deepseq-1.4.1.1 at deeps_6vMKxt5sPFR0XsbRWvvq59?.
|  > >                 Use -v to see a list of the files searched for.
|  > >
|  > >         Any ideas what to do?
|  > >
|  > >         All the best,
|  > >         Wolfgang
|  >
|  >
|  > _______________________________________________
|  > ghc-devs mailing list
|  > ghc-devs at haskell.org
|  > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
|  
|  
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From austin at well-typed.com  Thu Jun 11 16:28:58 2015
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 11 Jun 2015 11:28:58 -0500
Subject: GHC build failure
In-Reply-To: <92c63c05c932461788180154ece4d894@DB4PR30MB030.064d.mgd.msft.net>
References: <1434033467.2205.5.camel@idefix>
 <CAD3WKgjy8pPZdcZ64iwjj0F+Qi04SvHQs5J8F2+BfXXE==kr8w@mail.gmail.com>
 <1434035868.2205.22.camel@idefix> <1434036009.2205.23.camel@idefix>
 <92c63c05c932461788180154ece4d894@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAEs96n12NZHkwTuOBNAyKTY7fumPcE7pB61Q0M6cEW+AqMY3_g@mail.gmail.com>

OK, so I think the reason is because this commit:

https://phabricator.haskell.org/rGHC3b55659d4f54e503f4e550d762bc55a2650ed13d

actually changed the ghc-bin.cabal.in file under ghc/. Which we use to
generate ghc-bin.cabal, which is actually fed to Cabal to build the
'ghc' executable. The build system generates these files from .in
files (from autoconf) very early so 'make' doesn't track the
dependencies here, and it can't rebuild the files from the .in files.
That means you need to regenerate the .cabal file from the .in file to
pick up 'deepseq', which was added to Build-Depends.

The reason this gets 'fixed' with ./validate is precisely because
validate cleans the entire tree and re-boots it before continuing. So
it happens automatically.

TL;DR you should re-./boot and re-./configure again, as Herbert said.
In practice this shouldn't cost you much time, because even though GHC
will re-run the build steps, most of the results of those steps will
be cached compilations, which it can skip. If that doesn't work, then
distclean and start over - which sucks, but you won't have to do it
again ('make' will work fine to rebuilt).

On Thu, Jun 11, 2015 at 11:23 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> I got the same thing on my 7.10 branch.  But when I said "sh validate" (which starts with make distclean etc) all was well.
>
> S
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> |  Wolfgang Jeltsch
> |  Sent: 11 June 2015 16:20
> |  To: ghc-devs at haskell.org
> |  Subject: Re: GHC build failure
> |
> |  Hi again,
> |
> |  it still fails with the same error message.
> |
> |  All the best,
> |  Wolfgang
> |
> |  Am Donnerstag, den 11.06.2015, 18:17 +0300 schrieb Wolfgang Jeltsch:
> |  > Hi,
> |  >
> |  > I did not care about the submodules; so this could be the reason of
> |  > the failure. That said, running
> |  >
> |  >     git submodule update --init
> |  >
> |  > now only showed a message regarding utils/haddock, which causes me
> |  > some doubts that it will really fix the issue with deepseq. Let?s
> |  see.
> |  >
> |  > All the best,
> |  > Wolfgang
> |  >
> |  > Am Donnerstag, den 11.06.2015, 16:49 +0200 schrieb Thomas Miedema:
> |  > > Maybe you forgot `git submodule init` or `git submodule update`?
> |  See
> |  > > this page for a simple trick to never forget again:
> |  > >
> |  https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodu
> |  > > les#UsingaGitalias
> |  > >
> |  > >
> |  > > If that didn't work, do a `make maintainer-clean` and try again.
> |  > >
> |  > >
> |  > >
> |  > > On Thu, Jun 11, 2015 at 4:37 PM, Wolfgang Jeltsch
> |  > > <g9ks157k at acme.softbase.org> wrote:
> |  > >         Hi,
> |  > >
> |  > >         I just updated my GHC HEAD copy via git pull and tried to
> |  > >         rebuild GHC
> |  > >         with BuildFlavour set to devel2. I got the following error
> |  > >         message:
> |  > >
> |  > >             ghc/InteractiveUI.hs:68:8: error:
> |  > >                 Could not find module ?Control.DeepSeq?
> |  > >                 It is a member of the hidden package
> |  > >                 ?deepseq-1.4.1.1 at deeps_6vMKxt5sPFR0XsbRWvvq59?.
> |  > >                 Use -v to see a list of the files searched for.
> |  > >
> |  > >         Any ideas what to do?
> |  > >
> |  > >         All the best,
> |  > >         Wolfgang
> |  >
> |  >
> |  > _______________________________________________
> |  > ghc-devs mailing list
> |  > ghc-devs at haskell.org
> |  > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> |
> |
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



-- 
Regards,

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

From simonpj at microsoft.com  Sat Jun 13 23:07:30 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Sat, 13 Jun 2015 23:07:30 +0000
Subject: overlapping instances in 7.10.1
In-Reply-To: <1432415282.2467.15.camel@one.mechvel.pereslavl.ru>
References: <1432415282.2467.15.camel@one.mechvel.pereslavl.ru>
Message-ID: <3b6fd5fd8dbc4414af8d8e1f3aaae67c@DB4PR30MB030.064d.mgd.msft.net>

Sergei



I finally found time to look into what is happening here.  It's a good illustration of the dangers of overlapping instances.  Here is the setup:



* Module ResEuc_

  * Contains

        instance (...)                    => Ring  (ResidueE a)  <---- (A)

        instance (..., Ring (ResidueE a)) => Field (ResidueE a)  <---- (B)



* Module PFact__

  * Imports Pgcd_, which imports ResEuc_

  * Contains code that needs

       (Field (ResidueE (UPol (ResidueE Integer))))      <------ (X)

  * To solve (X) we use instance (B) from ResEuc_

  * And hence we need to solve (Ring (ResidueE (UPol (ResidueE Integer))))

    which we do using (A) but not (C)





* Module RsePol_

  * Imports PFact__

  * Contains the specialised instance

      instance (...) => Ring (ResidueE (UPol a))     <------ (C)

    which overlaps instance (A)



* Module Main

  * Needs an instance for

       Field (ResidueE (UPol (Residue Integer)))      <------ (Y)



  * Although GHC *could* generate this by instance declarations,

    which it would do using (B) and then using (C),



    instead GHC cleverly sees that it has generated it before,

    in module PFact__, and so uses the one from PFact__. And

    that is what gives rise to your error



So the real problem is that in PFact__, we make an instance (X) that does not see the specialised instance (C).  It *cannot* see that instance because RsePol_ imports PFact__.  So whatever code uses (X) is not going to see the specialised instance.  I bet that this is not what you intend. This may be a latent bug in DoCon.



I solved the problem by combining PFact__ and RsePol_ into a single module.  Then everything works fine.



What are the general lessons here?



*        GHC generally assumes that if it generates (C T) in one place, then it can use that anywhere in the program that (C T) is needed.  That is, there is only one (C T) dictionary.



*        But suppose you have overlapping instance in different modules; say

module A where instance C [a]

module B where import A; instance C [Maybe a]

If you use (C [Maybe Int]) in A, then of course we won't see the instance in B.  So you'll get a different dictionary than if you compute C [Maybe Int] in module B.



In short, overlapping instances are OK, but it's best to put them in the same module as the instances they overlap.



Could GHC behave as if all instances were calculated afresh in the module being compiled.  Yes, of course it could, but at the cost of losing the benefit of cross-module specialisation.  An overloaded function specialised at, say, [Int] in one module could not be re-used in another in case the instances changed.



Simon



| -----Original Message-----

| From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf Of

| Sergei Meshveliani

| Sent: 23 May 2015 22:08

| To: glasgow-haskell-users at haskell.org

| Cc: glasgow-haskell-bugs at haskell.org

| Subject: overlapping instances in 7.10.1

|

| Dear GHC developers,

|

| This request overrides my previous one of  "7.10.1-err..."

| (it is simpler and more precise).

| The archive

|

| http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-<http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-may23-2015.zip>

| may23-2015.zip<http://www.botik.ru/pub/local/Mechveliani/ghcQuest/7.10.1-errReport-may23-2015.zip>

|

| presents a question about  ghc-7.10.1.

|

| Make it, please, with  ghc-7.10.1  by

|

|          ghc $doconCpOpt -O --make Main

| ,

| $doconCpOpt =

|  -fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports

|  -fno-warn-overlapping-patterns -XRecordWildCards -XNamedFieldPuns

|  -XFlexibleContexts -XMultiParamTypeClasses -XUndecidableInstances

|  -XTypeSynonymInstances -XFlexibleInstances -fcontext-stack=30

|

|

| as it is written there in  README.txt.

|

| README.txt  explains which two instances are wrongly resolved

| -- as I expect.

|

| In  ghc-7.8.2  they are resolved in a correct way

| (and there is a different pragma syntax).

| I conclude this from running the test in  docon-2.12.

|

| Am I missing something?

|

| Please, advise,

|

| ------

| Sergei

|

|

|

|

| _______________________________________________

| ghc-tickets mailing list

| ghc-tickets at haskell.org<mailto:ghc-tickets at haskell.org>

| http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150613/0811789f/attachment.html>

From pali.gabor at gmail.com  Sun Jun 14 15:08:33 2015
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Sun, 14 Jun 2015 17:08:33 +0200
Subject: Broken build: Documentation mistake
In-Reply-To: <CAHnG2Czggx+ypE1hGH=XYughYL5guqYCuXBKLvyr26DfqWq1yw@mail.gmail.com>
References: <CAHnG2CwBGTf7jho4LQ42_0OEa__oQ-FqQUqCSV3eeuZqDfpqRQ@mail.gmail.com>
 <CAEs96n13=tXJt3aoG2DUZs7XGz7iddmvo_LxHNm5rbCBRLLMGQ@mail.gmail.com>
 <CAHnG2Cw31JOJmouBifwShgPEtfwsckNQ_q7YPFidjEdX97EsbQ@mail.gmail.com>
 <CAEs96n3P3pexrBpg5r75+4c562LeMfkototeaH_ZjP+VMfvpQA@mail.gmail.com>
 <CAHnG2Czggx+ypE1hGH=XYughYL5guqYCuXBKLvyr26DfqWq1yw@mail.gmail.com>
Message-ID: <CAHnG2Czj4pGXkBYQ2XcDy-MWyFj4Qn2WKLADapgc+OyjO599Pw@mail.gmail.com>

Hi Austin,

Looks like the build is failing again, with another error message from
LaTeX [1]:

<snip>
Build users_guide.ps
latex failed
users_guide.tex:17168: Undefined control sequence \Colon.
users_guide.tex:17168: leading text: }
Unexpected error occured
Missing character &#x2919;
Missing character &#x291a;
Missing character &#x291b;
Missing character &#x291c;
[ -f docs/users_guide/users_guide.ps ]
docs/users_guide/ghc.mk:26: recipe for target
'docs/users_guide/users_guide.ps' failed
gmake[1]: *** [docs/users_guide/users_guide.ps] Error 1
Makefile:102: recipe for target 'all' failed
gmake: *** [all] Error 2

Do you have any ideas why this is happening?

Thanks,
G?bor

[1] http://haskell.inf.elte.hu/builders/freebsd-i386-head/650/10.html

From thomasmiedema at gmail.com  Sun Jun 14 17:07:44 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Sun, 14 Jun 2015 19:07:44 +0200
Subject: Broken build: Documentation mistake
In-Reply-To: <CAHnG2Czj4pGXkBYQ2XcDy-MWyFj4Qn2WKLADapgc+OyjO599Pw@mail.gmail.com>
References: <CAHnG2CwBGTf7jho4LQ42_0OEa__oQ-FqQUqCSV3eeuZqDfpqRQ@mail.gmail.com>
 <CAEs96n13=tXJt3aoG2DUZs7XGz7iddmvo_LxHNm5rbCBRLLMGQ@mail.gmail.com>
 <CAHnG2Cw31JOJmouBifwShgPEtfwsckNQ_q7YPFidjEdX97EsbQ@mail.gmail.com>
 <CAEs96n3P3pexrBpg5r75+4c562LeMfkototeaH_ZjP+VMfvpQA@mail.gmail.com>
 <CAHnG2Czggx+ypE1hGH=XYughYL5guqYCuXBKLvyr26DfqWq1yw@mail.gmail.com>
 <CAHnG2Czj4pGXkBYQ2XcDy-MWyFj4Qn2WKLADapgc+OyjO599Pw@mail.gmail.com>
Message-ID: <CAD3WKgjyA94PvSw8QmiOpWTgx+UQ9jHtCxd-6CPfdRmOPui9wQ@mail.gmail.com>

>
> Missing character &#x2919;
> Missing character &#x291a;
> Missing character &#x291b;
> Missing character &#x291c;
>

That is from the patch in https://ghc.haskell.org/trac/ghc/ticket/10509.

The user's guide builds and looks fine for me, and Phabricator validates it
as well. These are some related packages I have installed:
ii  dblatex                                        0.3.4-3build1
ii  docbook-dsssl                                  1.79-7ubuntu1
ii  docbook-utils                                  0.6.14-3ubuntu1
ii  docbook-xml                                    4.5-7.2
ii  docbook-xsl                                    1.78.1+dfsg-1
ii  texlive-latex-base                             2013.20140215-1
ii  texlive-latex-extra                            2013.20140215-2
ii  texlive-latex-recommended                      2013.20140215-1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150614/47731b35/attachment.html>

From austin at well-typed.com  Mon Jun 15 00:16:09 2015
From: austin at well-typed.com (Austin Seipp)
Date: Sun, 14 Jun 2015 19:16:09 -0500
Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 1
Message-ID: <CAEs96n1+k2O1fEBSfuhSkTQ2irV-rWLKhXHy7oNRG9c=BMR6Ow@mail.gmail.com>

We are pleased to announce the first release candidate for GHC 7.10.2:

    https://downloads.haskell.org/~ghc/7.10.2-rc1
    https://downloads.haskell.org/~ghc/7.10.2-rc1/docs/html/

This includes the source tarball and bindists for Windows, Mac OS X,
and Debian Linux. FreeBSD and Solaris binaries will follow soon. These
binaries and tarballs have an accompanying SHA256SUMS file signed by
my GPG key id (0x3B58D86F).

We plan to make the 7.10.2 final release at the end of this coming
week - so please test as much as possible; bugs are much cheaper if we
find them before the release!

-- 
Regards,

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

From austin at well-typed.com  Mon Jun 15 00:08:47 2015
From: austin at well-typed.com (Austin Seipp)
Date: Sun, 14 Jun 2015 19:08:47 -0500
Subject: Test message, please ignore
Message-ID: <CAEs96n2YL0zmwvGYyNgj7mNZH9pYMd5yAFRhVNgR=JXy5S5KvQ@mail.gmail.com>

If you can see this, it probably works.

-- 
Regards,

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

From austin at well-typed.com  Sun Jun 14 23:34:14 2015
From: austin at well-typed.com (Austin Seipp)
Date: Sun, 14 Jun 2015 18:34:14 -0500
Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 1
Message-ID: <CAEs96n208K4pbLOJH5s0K9fQ_3tbA5628oHaCZHTauSBpTV2DA@mail.gmail.com>

We are pleased to announce the first release candidate for GHC 7.10.2:

    https://downloads.haskell.org/~ghc/7.10.2-rc1
    https://downloads.haskell.org/~ghc/7.10.2-rc1/docs/html/

This includes the source tarball and bindists for Windows, Mac OS X,
and Debian Linux. FreeBSD and Solaris binaries will follow soon. These
binaries and tarballs have an accompanying SHA256SUMS file signed by
my GPG key id (0x3B58D86F).

We plan to make the 7.10.2 final release at the end of this coming
week - so please test as much as possible; bugs are much cheaper if we
find them before the release!

-- 
Regards,

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

From austin at well-typed.com  Mon Jun 15 00:07:10 2015
From: austin at well-typed.com (Austin Seipp)
Date: Sun, 14 Jun 2015 19:07:10 -0500
Subject: Test message, please ignore
Message-ID: <CAEs96n17PesfZB9XmhwYmuB74iutrqo8p_HogG3K4bEhxAw4Uw@mail.gmail.com>

If you can see this, it probably works.

-- 
Regards,

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

From austin at well-typed.com  Sun Jun 14 16:15:21 2015
From: austin at well-typed.com (Austin Seipp)
Date: Sun, 14 Jun 2015 11:15:21 -0500
Subject: Broken build: Documentation mistake
In-Reply-To: <CAHnG2Czj4pGXkBYQ2XcDy-MWyFj4Qn2WKLADapgc+OyjO599Pw@mail.gmail.com>
References: <CAHnG2CwBGTf7jho4LQ42_0OEa__oQ-FqQUqCSV3eeuZqDfpqRQ@mail.gmail.com>
 <CAEs96n13=tXJt3aoG2DUZs7XGz7iddmvo_LxHNm5rbCBRLLMGQ@mail.gmail.com>
 <CAHnG2Cw31JOJmouBifwShgPEtfwsckNQ_q7YPFidjEdX97EsbQ@mail.gmail.com>
 <CAEs96n3P3pexrBpg5r75+4c562LeMfkototeaH_ZjP+VMfvpQA@mail.gmail.com>
 <CAHnG2Czggx+ypE1hGH=XYughYL5guqYCuXBKLvyr26DfqWq1yw@mail.gmail.com>
 <CAHnG2Czj4pGXkBYQ2XcDy-MWyFj4Qn2WKLADapgc+OyjO599Pw@mail.gmail.com>
Message-ID: <CAEs96n18i56iBwRJMCG_TGsUJZGJNABak24K1npow4SX5bsWnA@mail.gmail.com>

I'm afraid I have no idea... I pushed several documentation patches to
the ghc-7.10 branch:

https://phabricator.haskell.org/diffusion/GHC/history/ghc-7.10/

Can you try reverting some of those 'More 7.10.2 release notes
commits'? That's the only thing I can think that might be the
culprit...

On Sun, Jun 14, 2015 at 10:08 AM, P?li G?bor J?nos <pali.gabor at gmail.com> wrote:
> Hi Austin,
>
> Looks like the build is failing again, with another error message from
> LaTeX [1]:
>
> <snip>
> Build users_guide.ps
> latex failed
> users_guide.tex:17168: Undefined control sequence \Colon.
> users_guide.tex:17168: leading text: }
> Unexpected error occured
> Missing character &#x2919;
> Missing character &#x291a;
> Missing character &#x291b;
> Missing character &#x291c;
> [ -f docs/users_guide/users_guide.ps ]
> docs/users_guide/ghc.mk:26: recipe for target
> 'docs/users_guide/users_guide.ps' failed
> gmake[1]: *** [docs/users_guide/users_guide.ps] Error 1
> Makefile:102: recipe for target 'all' failed
> gmake: *** [all] Error 2
>
> Do you have any ideas why this is happening?
>
> Thanks,
> G?bor
>
> [1] http://haskell.inf.elte.hu/builders/freebsd-i386-head/650/10.html
>



-- 
Regards,

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

From izgzhen at gmail.com  Sat Jun 13 13:44:29 2015
From: izgzhen at gmail.com (Zhen Zhang)
Date: Sat, 13 Jun 2015 21:44:29 +0800
Subject: Problem about `DerivedConstants.h` and `tmp.c` in
 `includes/dist-derivedconstants/header`, GHC 7.8.3
Message-ID: <CAPdu10j2+Mb_8gDYqXUZNgGTODCqoeBNBD71EkAJPLjuVdTW1A@mail.gmail.com>

Hi everyone,

I am having trouble porting some 6.8.2 GHC code to 7.8.3 GHC. The main
trouble I met is that, in 6.8.2, there is a includes/mkDerivedConstants.c and
some constants about RTS are declared here.

While in 7.8.3, there is only a
similar  `includes/dist-derivedconstants/header` directory containing a
bunch of code. Some seems generated like `DerivedConstants.h`, and it seems
like `tmp.c` generated this.

However, when I added some entries in `tmp.c` and compiled it, then it
became the original version ... So I doubted that if there is another file
which is equivalent to the includes/mkDerivedConstants.c in 6.8.2?

Thank a lot!


Zhen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150613/72d3d2d4/attachment.html>

From mark.lentczner at gmail.com  Mon Jun 15 02:41:16 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Sun, 14 Jun 2015 19:41:16 -0700
Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 1
In-Reply-To: <CAEs96n208K4pbLOJH5s0K9fQ_3tbA5628oHaCZHTauSBpTV2DA@mail.gmail.com>
References: <CAEs96n208K4pbLOJH5s0K9fQ_3tbA5628oHaCZHTauSBpTV2DA@mail.gmail.com>
Message-ID: <CAAOoiFauGq-6Mpd18P0DRs8xuN9H2K-zXuN-ay6uncpWC23ztg@mail.gmail.com>

Right on the heels of Austin's 7.10.2 RC1 announcement we have...

*Haskell Platform 7.10.2 RC1 as well!* This is the same release of GHC
7.10.2 plus a 35+ common packages and tools for Haskell, pre-built and
easily installable:

generic linux:
haskell-platform-7.10.1.20150612-x86_64-unknown-linux-deb7.tar.gz
<http://www.ozonehouse.com/mark/platform/haskell-platform-7.10.1.20150612-x86_64-unknown-linux-deb7.tar.gz>
OS X: Haskell Platform 7.10.1.20150612 64bit-signed.pkg
<http://www.ozonehouse.com/mark/platform/Haskell%20Platform%207.10.1.20150612%2064bit-signed.pkg>


Generic linux is built on a clean debian wheezy (7) system and has been
tested on Ubuntu 12.02, CentOS 7, Fedora 20, and openSUSE 13.1. It should
work on those and later versions of same distros, as well as similar modern
distros. Note that you may need zlib-dev, ncurses-dev, and gmp-dev
packaages (or equivalent on your distro).  It now unpacks as an install
script and inner-tarball for ease of installation.

Package list here: Releases2015.hs#L111
<https://github.com/haskell/haskell-platform/blob/master/hptool/src/Releases2015.hs#L111>

Notably, includes latest attoparsec with security fixes that were long
missing from HP, newest QuickCheck (pulling in tf-random as well), and very
up to date OpenGL packages.

- Mark

hashes:
7e76493728f29ec5a64c8bfe48a7242fbf96f39dba08249c425eaee26eda88fb
 haskell-platform-7.10.1.20150612-x86_64-unknown-linux-deb7.tar.gz
4ecc0a180786fd6780a31531fe816f2b0cd5c8f1d123cd2eef441e2ca0b81f4b  Haskell
Platform 7.10.1.20150612 64bit-signed.pkg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150614/1112f54e/attachment-0001.html>

From cma at bitemyapp.com  Mon Jun 15 02:45:21 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Sun, 14 Jun 2015 21:45:21 -0500
Subject: the platform has outgrown Travis-CI
In-Reply-To: <CAHS+xEm72gUVENB3Vx=_OUSriTyhPscbaJ=iZPzSkav-Sh_UXw@mail.gmail.com>
References: <CAAOoiFbeM07GriYxjZYXDNy4gumOE+OhWhDwv_OWqkuvUuqwBg@mail.gmail.com>
 <CADnndOpO_nSN7j9cW9AQVQetBsSOQBE-CWg=MpMiuMZpChkGzA@mail.gmail.com>
 <CAHS+xEm72gUVENB3Vx=_OUSriTyhPscbaJ=iZPzSkav-Sh_UXw@mail.gmail.com>
Message-ID: <CADnndOoGOjQiM+KgdnHMUnWTKSSODbQ+6_sm3OV1H_rCkr+8Yg@mail.gmail.com>

Have the build timeout issues been resolved? Mathias Meyer (CEO at
TravisCI) said you didn't get in touch with him with the info he needed to
bump the timeout for Haskell Platform. Did you not get the email?

On Tue, Jun 9, 2015 at 9:04 AM, Mathias Meyer <mathias at travis-ci.com> wrote:

> Hey Christopher and Mark,
>
> Great to meet you.
>
> Could you let me know what the name of the project on GitHub and the
> owner's account name is?
>
> I'll have a look if I can adjust the timeout upwards for this project.
>
> Cheers, Mathias
>
> On Tue, Jun 9, 2015 at 3:50 PM, Christopher Allen <cma at bitemyapp.com>
> wrote:
>
>> Mark Lentczner has been the main (and hard-working) Haskell Platform
>> mensch for at least a couple years now. I forwarded the initial email for
>> context.
>>
>> What can be done?
>>
>> Thanks for your time.
>>
>> ---------- Forwarded message ----------
>> From: Mark Lentczner <mark.lentczner at gmail.com>
>> Date: Sun, Jun 7, 2015 at 11:33 AM
>> Subject: the platform has outgrown Travis-CI
>> To: "haskell-platform at projects.haskell.org" <
>> haskell-platform at projects.haskell.org>, "ghc-devs at haskell.org" <
>> ghc-devs at haskell.org>, "haskell-infrastructure at community.galois.com" <
>> haskell-infrastructure at community.galois.com>
>>
>>
>> I finally figured out what was wrong with the Travis CI build for Haskell
>> Platform, and got it all working w/hvr's .debs of GHC (for the boot
>> compiler)... and ran smack into this:
>>
>> Your test run exceeded 50 minutes.
>>
>>
>> SO... I'd like to find another CI solution. Is phabricator.haskell.org
>> an option? Can we / should we create a project there?
>>
>> - Mark
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>>
>>
>> --
>> Chris Allen
>> Currently working on http://haskellbook.com
>>
>
>


-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150614/40c9f0a7/attachment.html>

From asr at eafit.edu.co  Mon Jun 15 03:25:57 2015
From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Sun, 14 Jun 2015 22:25:57 -0500
Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 1
In-Reply-To: <CAEs96n1+k2O1fEBSfuhSkTQ2irV-rWLKhXHy7oNRG9c=BMR6Ow@mail.gmail.com>
References: <CAEs96n1+k2O1fEBSfuhSkTQ2irV-rWLKhXHy7oNRG9c=BMR6Ow@mail.gmail.com>
Message-ID: <CAOUWSGDkzOxJK=mvT=bO=8mFv3WZEafSPe+Mm7YSimEFArRgGA@mail.gmail.com>

On 14 June 2015 at 19:16, Austin Seipp <austin at well-typed.com> wrote:
> We are pleased to announce the first release candidate for GHC 7.10.2:

Since transformers is a GHC-include library, is there any particular
reason why GHC 7.10.2 RC1 didn't include the latest version of the
transformers library, i.e. transformers-0.4.3.0?

-- 
Andr?s

From juhpetersen at gmail.com  Mon Jun 15 11:11:22 2015
From: juhpetersen at gmail.com (Jens Petersen)
Date: Mon, 15 Jun 2015 20:11:22 +0900
Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 1
In-Reply-To: <CAEs96n1+k2O1fEBSfuhSkTQ2irV-rWLKhXHy7oNRG9c=BMR6Ow@mail.gmail.com>
References: <CAEs96n1+k2O1fEBSfuhSkTQ2irV-rWLKhXHy7oNRG9c=BMR6Ow@mail.gmail.com>
Message-ID: <CAEDGBqKh0YwdekAKfk=Sohn=5HJ8_2pLFE0rEoG+GJjUNSM6fw@mail.gmail.com>

> We are pleased to announce the first release candidate for GHC 7.10.2:

Thanks!

>     https://downloads.haskell.org/~ghc/7.10.2-rc1

The testsuite src tarball still (like in 7.10.1) includes this large
binary executable file:

 -rwxrwxr-x       a/a       7873779 Mar 16 17:34 2015
ghc-7.10.0.20150316/testsuite/mk/ghc-config

Can it be removed it for 7.10.2?

Jens

ps It might be good to have some tarball size sanity check
to avoid these kind of problems recurring.

From austin at well-typed.com  Mon Jun 15 14:15:23 2015
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 15 Jun 2015 09:15:23 -0500
Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 1
In-Reply-To: <CA+8-LikjVU=OFwoYAqYdj85-Wi0Yu8f0NQ0Ox--ZigHGaphFNQ@mail.gmail.com>
References: <CAEs96n1+k2O1fEBSfuhSkTQ2irV-rWLKhXHy7oNRG9c=BMR6Ow@mail.gmail.com>
 <CAOUWSGDkzOxJK=mvT=bO=8mFv3WZEafSPe+Mm7YSimEFArRgGA@mail.gmail.com>
 <CA+8-LikjVU=OFwoYAqYdj85-Wi0Yu8f0NQ0Ox--ZigHGaphFNQ@mail.gmail.com>
Message-ID: <CAEs96n0LpF+wwOt7jY140FyE2OGUH8cAYYdHY2xM3kfn-1Zoqg@mail.gmail.com>

Yes, as noted on the ticket, I've bumped the priority and we'll be
looking into this - and hopefully have a fix in time for 7.10.2. There
are some similar tickets where we get large explosions of terms, so it
may be in the same ballpark.

On Sun, Jun 14, 2015 at 11:18 PM, Rob Everest <robertce at cse.unsw.edu.au> wrote:
>>  We plan to make the 7.10.2 final release at the end of this coming week -
>> so please test as much as possible; bugs are much cheaper if we find them
>> before the release!
>
>
> Could I possibly draw attention to #10491? It's a regression in the
> simplifier that is causing considerable pain for Accelerate, namely a
> compile time of many hours for a 300 line module. It would be unfortunate if
> this couldn't be resolved for the 7.10.2 release.



-- 
Regards,

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

From austin at well-typed.com  Mon Jun 15 14:19:36 2015
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 15 Jun 2015 09:19:36 -0500
Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 1
In-Reply-To: <CAOUWSGDkzOxJK=mvT=bO=8mFv3WZEafSPe+Mm7YSimEFArRgGA@mail.gmail.com>
References: <CAEs96n1+k2O1fEBSfuhSkTQ2irV-rWLKhXHy7oNRG9c=BMR6Ow@mail.gmail.com>
 <CAOUWSGDkzOxJK=mvT=bO=8mFv3WZEafSPe+Mm7YSimEFArRgGA@mail.gmail.com>
Message-ID: <CAEs96n0piHG1QTdc22abFpfV=4+qink675==FWVJ2SDu+HF8aw@mail.gmail.com>

Not in particular - I guess we didn't get everything we precisely
needed for the RC.

I've filed a ticket: #10530

On Sun, Jun 14, 2015 at 10:25 PM, Andr?s Sicard-Ram?rez
<asr at eafit.edu.co> wrote:
> On 14 June 2015 at 19:16, Austin Seipp <austin at well-typed.com> wrote:
>> We are pleased to announce the first release candidate for GHC 7.10.2:
>
> Since transformers is a GHC-include library, is there any particular
> reason why GHC 7.10.2 RC1 didn't include the latest version of the
> transformers library, i.e. transformers-0.4.3.0?
>
> --
> Andr?s
>



-- 
Regards,

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

From austin at well-typed.com  Mon Jun 15 14:20:27 2015
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 15 Jun 2015 09:20:27 -0500
Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 1
In-Reply-To: <CAEDGBqKh0YwdekAKfk=Sohn=5HJ8_2pLFE0rEoG+GJjUNSM6fw@mail.gmail.com>
References: <CAEs96n1+k2O1fEBSfuhSkTQ2irV-rWLKhXHy7oNRG9c=BMR6Ow@mail.gmail.com>
 <CAEDGBqKh0YwdekAKfk=Sohn=5HJ8_2pLFE0rEoG+GJjUNSM6fw@mail.gmail.com>
Message-ID: <CAEs96n2DhLDhAH+7u9M_NjoO890WZgU2VbrF+N8DbwfRo7=i9A@mail.gmail.com>

Grrr... I could have *swore* I fixed it this time, and even to be
double-sure I did a `git clean` and everything..

Yes, we should have a sanity check somewhere, and also double check
the testsuite is clean. I'll noodle on it for the release (since
apparently the last version didn't work).

On Mon, Jun 15, 2015 at 6:11 AM, Jens Petersen <juhpetersen at gmail.com> wrote:
>> We are pleased to announce the first release candidate for GHC 7.10.2:
>
> Thanks!
>
>>     https://downloads.haskell.org/~ghc/7.10.2-rc1
>
> The testsuite src tarball still (like in 7.10.1) includes this large
> binary executable file:
>
>  -rwxrwxr-x       a/a       7873779 Mar 16 17:34 2015
> ghc-7.10.0.20150316/testsuite/mk/ghc-config
>
> Can it be removed it for 7.10.2?
>
> Jens
>
> ps It might be good to have some tarball size sanity check
> to avoid these kind of problems recurring.
>



-- 
Regards,

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

From juhpetersen at gmail.com  Mon Jun 15 14:35:51 2015
From: juhpetersen at gmail.com (Jens Petersen)
Date: Mon, 15 Jun 2015 23:35:51 +0900
Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 1
In-Reply-To: <CAEs96n1+k2O1fEBSfuhSkTQ2irV-rWLKhXHy7oNRG9c=BMR6Ow@mail.gmail.com>
References: <CAEs96n1+k2O1fEBSfuhSkTQ2irV-rWLKhXHy7oNRG9c=BMR6Ow@mail.gmail.com>
Message-ID: <CAEDGBqK17UQ5fz5sMvOvzEJEH8MQs2byijrLBGdhQs=KQhNztg@mail.gmail.com>

On 15 June 2015 at 09:16, Austin Seipp <austin at well-typed.com> wrote:
> We are pleased to announce the first release candidate for GHC 7.10.2:

Thank you

I did a 'quick' build of it for Fedora 22 in my Copr repo:

https://copr.fedoraproject.org/coprs/petersen/ghc-7.10.2

I will try to update it to a 'perf' build soon.

Cheers, Jens

From mietek at bak.io  Mon Jun 15 17:05:15 2015
From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=)
Date: Mon, 15 Jun 2015 18:05:15 +0100
Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 1
In-Reply-To: <CAEs96n1+k2O1fEBSfuhSkTQ2irV-rWLKhXHy7oNRG9c=BMR6Ow@mail.gmail.com>
References: <CAEs96n1+k2O1fEBSfuhSkTQ2irV-rWLKhXHy7oNRG9c=BMR6Ow@mail.gmail.com>
Message-ID: <BE3A549E-AF31-4848-BE7F-C1951CBDDF12@bak.io>

Thanks.  GHC 7.10.2-rc1 can now be installed with Halcyon:

        halcyon install --ghc-version=7.10.2-rc1 --cabal-version=1.22.4.0

Supported platforms include:

- Amazon Linux 2014.09
- Arch Linux
- CentOS 6, 7
- Debian 6, 7, 8
- Gentoo Linux
- openSUSE 13.2
- OS X 10.8, 10.9, 10.10
- Red Hat Enterprise Linux 6, 7
- Slackware 14.1
- SUSE Linux Enterprise Server 12
- Ubuntu 12.04 LTS, 14.04 LTS, 14.10, 15.04
- Fedora 20, 21


-- 
Mi?tek
https://mietek.io




On 2015-06-15, at 01:16, Austin Seipp <austin at well-typed.com> wrote:

> We are pleased to announce the first release candidate for GHC 7.10.2:
> 
>    https://downloads.haskell.org/~ghc/7.10.2-rc1
>    https://downloads.haskell.org/~ghc/7.10.2-rc1/docs/html/
> 
> This includes the source tarball and bindists for Windows, Mac OS X,
> and Debian Linux. FreeBSD and Solaris binaries will follow soon. These
> binaries and tarballs have an accompanying SHA256SUMS file signed by
> my GPG key id (0x3B58D86F).
> 
> We plan to make the 7.10.2 final release at the end of this coming
> week - so please test as much as possible; bugs are much cheaper if we
> find them before the release!
> 
> -- 
> Regards,
> 
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150615/dbd792a7/attachment.bin>

From dluposchainsky at googlemail.com  Mon Jun 15 18:18:33 2015
From: dluposchainsky at googlemail.com (David Luposchainsky)
Date: Mon, 15 Jun 2015 20:18:33 +0200
Subject: MonadFail proposal (MFP): Moving fail out of Monad
In-Reply-To: <CAHEA9tP3X4=P9fAwPO=7rSWfCPxPtZOV40A1BYaqeZ487iXJnA@mail.gmail.com>
References: <55774FF2.8020505@gmail.com> <1434035338.2205.17.camel@idefix>
 <CAErCyQ-SQYHkagt7929g=oa+jjf+8MsZ50cyGjFNM98zOWYiVA@mail.gmail.com>
 <1434036500.2205.25.camel@idefix>
 <CAErCyQ-aXZUj6dhzQ6Ui2ZF7ugpC87TY58Gi7_E1AMZ8oysxxg@mail.gmail.com>
 <CAHEA9tP3X4=P9fAwPO=7rSWfCPxPtZOV40A1BYaqeZ487iXJnA@mail.gmail.com>
Message-ID: <557F16F9.40306@gmail.com>

On 11.06.2015 18:20, Dan Doel wrote:
> I believe a pattern is classified as unfailable there if it is irrefutable or 
> refutable only by bottom. Which of course is the distinction here, (x,y) is 
> unfailable, but not irrefutable.

Some of the confusion may be because GHC has a function "isIrrefutableHsPat" that
seems to check whether a pattern is irrefutable by your definition. The source
comment talks about naming a bit:

> (isIrrefutableHsPat p) is true if matching against p cannot fail,
> in the sense of falling through to the next pattern.
>      (NB: this is not quite the same as the (silly) defn
>      in 3.17.2 of the Haskell 98 report.)

Source:
https://github.com/ghc/ghc/blob/c5911479f295242e16e396eb5d1369f2e4ce8de0/compiler/hsSyn/HsPat.hs#L443

(Time for a PatternUnfallthroughableProposal?)

Greetings,
David

From pali.gabor at gmail.com  Mon Jun 15 21:39:04 2015
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Mon, 15 Jun 2015 23:39:04 +0200
Subject: Broken build: Documentation mistake
In-Reply-To: <CAD3WKgjyA94PvSw8QmiOpWTgx+UQ9jHtCxd-6CPfdRmOPui9wQ@mail.gmail.com>
References: <CAHnG2CwBGTf7jho4LQ42_0OEa__oQ-FqQUqCSV3eeuZqDfpqRQ@mail.gmail.com>
 <CAEs96n13=tXJt3aoG2DUZs7XGz7iddmvo_LxHNm5rbCBRLLMGQ@mail.gmail.com>
 <CAHnG2Cw31JOJmouBifwShgPEtfwsckNQ_q7YPFidjEdX97EsbQ@mail.gmail.com>
 <CAEs96n3P3pexrBpg5r75+4c562LeMfkototeaH_ZjP+VMfvpQA@mail.gmail.com>
 <CAHnG2Czggx+ypE1hGH=XYughYL5guqYCuXBKLvyr26DfqWq1yw@mail.gmail.com>
 <CAHnG2Czj4pGXkBYQ2XcDy-MWyFj4Qn2WKLADapgc+OyjO599Pw@mail.gmail.com>
 <CAD3WKgjyA94PvSw8QmiOpWTgx+UQ9jHtCxd-6CPfdRmOPui9wQ@mail.gmail.com>
Message-ID: <CAHnG2Cyvj1SVqYZvSuJzTJpCMVx9YD3bLDN1HoddWew2NYQ5zA@mail.gmail.com>

Hi Thomas,

2015-06-14 19:07 GMT+02:00 Thomas Miedema <thomasmiedema at gmail.com>:
> The user's guide builds and looks fine for me, and Phabricator validates it
> as well.

I tried to make this work with a recent set of those related packages
(dblatex, docbook, LaTeX etc.) but it still does not fully work for
me.  The best result I was able to achive is that I passed the -P
'latex.unicode.use=1' flag to dblatex so it could build the PS file.
It still says that, though:

Missing character &#x2919;
Missing character &#x291a;
Missing character &#x291b;
Missing character &#x291c;

Note that this way the PS file is generated, but when I checked the
table in 7.3.1, it had the entity codes in place of the Unicode
symbols.  May I see the build logs of yours somewhere?

Thanks,
G?bor

From mark.lentczner at gmail.com  Tue Jun 16 01:01:48 2015
From: mark.lentczner at gmail.com (Mark Lentczner)
Date: Mon, 15 Jun 2015 18:01:48 -0700
Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 1
In-Reply-To: <CAAOoiFauGq-6Mpd18P0DRs8xuN9H2K-zXuN-ay6uncpWC23ztg@mail.gmail.com>
References: <CAEs96n208K4pbLOJH5s0K9fQ_3tbA5628oHaCZHTauSBpTV2DA@mail.gmail.com>
 <CAAOoiFauGq-6Mpd18P0DRs8xuN9H2K-zXuN-ay6uncpWC23ztg@mail.gmail.com>
Message-ID: <CAAOoiFaYKpxNFGJ-mzzazkfzG=+AYNp55N6N+WjOs6RfccNBfg@mail.gmail.com>

And the Windows install for HP 7.10.2 RC1 is out too:
HaskellPlatform-7.10.1.20150612-x86_64-setup.exe
<http://www.ozonehouse.com/mark/platform/HaskellPlatform-7.10.1.20150612-x86_64-setup.exe>

08c5f2168bdf9147b548263d2b45e1db6b602830002f27bbbbf92bf066b761f0
HaskellPlatform-7.10.1.20150612-x86_64-setup.exe
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150615/6d5e5e22/attachment-0001.html>

From rwbarton at gmail.com  Tue Jun 16 13:09:43 2015
From: rwbarton at gmail.com (Reid Barton)
Date: Tue, 16 Jun 2015 09:09:43 -0400
Subject: Problem about `DerivedConstants.h` and `tmp.c` in
 `includes/dist-derivedconstants/header`, GHC 7.8.3
In-Reply-To: <CAPdu10j2+Mb_8gDYqXUZNgGTODCqoeBNBD71EkAJPLjuVdTW1A@mail.gmail.com>
References: <CAPdu10j2+Mb_8gDYqXUZNgGTODCqoeBNBD71EkAJPLjuVdTW1A@mail.gmail.com>
Message-ID: <CADmwj47s66dP=a3vrU7X6ajMFTVhmOivR=HVgD5W0+kbQBd_ag@mail.gmail.com>

On Sat, Jun 13, 2015 at 9:44 AM, Zhen Zhang <izgzhen at gmail.com> wrote:

> Hi everyone,
>
> I am having trouble porting some 6.8.2 GHC code to 7.8.3 GHC. The main
> trouble I met is that, in 6.8.2, there is a includes/mkDerivedConstants.c and
> some constants about RTS are declared here.
>
> While in 7.8.3, there is only a
> similar  `includes/dist-derivedconstants/header` directory containing a
> bunch of code. Some seems generated like `DerivedConstants.h`, and it seems
> like `tmp.c` generated this.
>
> However, when I added some entries in `tmp.c` and compiled it, then it
> became the original version ... So I doubted that if there is another file
> which is equivalent to the includes/mkDerivedConstants.c in 6.8.2?
>

Hi Zhen,

Take a look at utils/deriveConstants/DeriveConstants.hs. That program
generates tmp.c, then compiles it with the C compiler and inspects the
sizes of symbols in the resulting object file and writes the information it
gathered to DerivedConstants.h. We do it this way now to support
cross-compilation (in that case, the C compiler generates object files for
the target platform so we can't simply run them on the system that is
building GHC).

Regards,
Reid Barton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150616/3a81f1c0/attachment.html>

From dluposchainsky at googlemail.com  Tue Jun 16 15:07:50 2015
From: dluposchainsky at googlemail.com (David Luposchainsky)
Date: Tue, 16 Jun 2015 17:07:50 +0200
Subject: MFP updates: ideas worth discussing
In-Reply-To: <55774FF2.8020505@gmail.com>
References: <55774FF2.8020505@gmail.com>
Message-ID: <55803BC6.7040706@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

MonadFail proposal update 1
===========================


Rendered version of this text:
https://github.com/quchen/articles/blob/master/monad_fail_update1.md

Original MFP:
https://github.com/quchen/articles/blob/master/monad_fail.md


Short summary
- -------------

A week has passed since I posted the MFP, and the initial discussion is mostly
over. Here are my observations:

- - Everyone agrees that `fail` should not be in `Monad`.
- - Almost everyone agrees that it should be thrown out of it.
- - Some would prefer to see the special desugaring be gone entirely.
- - The name `MonadFail` is controversial, because of a potential `Applicative`
  constraint.
- - We're still unsure about whether `IO` should get a `MonadFail` instance, but
  the bias seems to be towards "yes".



New ideas worth thinking about
- ------------------------------

### Special desugaring or not

Johann suggested an optional warning whenever something desugars to use `fail`.
I think that's an idea we should think about. It is easily implemented in the
compiler, and would probably behave similar to -fwarn-unused-do-binds in
practice: notation that is not wrong, but might not be what the programmer
intended.


### Errors vs. Exceptions

Henning is concerned about the confusion between exceptions and programming
errors. In his words,

> We should clearly decide what "fail" is intended for - for programming
> errors or for exceptions.

What I see clashing with his point is backwards compatibility. Removing the
`String` argument breaks all explicit invocations of `fail`. Unfortunately,
we're not in a position to break very much. If someone has a better idea I'd
love to hear about it though.


### ApplicativeDo

ApplicativeDo is somewhere out there on the horizon, and we're not sure yet how
much `fail` makes sense in the context of `Applicative`. An Applicative
computation is statically determined in its shape, so it either always or never
fails. Depending on previous results would introduce the `Monad` constraint
anyway.



Probing status
- --------------

Henning has started to look at the impact of the proposal when explicit
invocations of `fail` are considered as well, something I have not done in my
original survey. Luckily, things don't look too bad, Lens and its forest of
dependencies can be fixed in around ten trivial changes, for example.


Greetings,
David/quchen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVgDvGAAoJELrQsaT5WQUspmIIAJi9UVYIitHv2CKvWSmk1fg0
hYaPRXDJMnyFS21v57+JeTPhM/dnI4k0guUUrlIB9k5WPaySQ6MKIAnB51o5O9Gv
zt87FII5/oYsJtVPruKgBtLPbJVhg6zGUXmNco1S2wvB5m5HdBooQsiBRY+qiFfZ
MJOdzXpRCrYJk/0PeF7sglBOElSwsSmGq/klvJUo4VeVAdi8bU+lKRfET/AmAAM5
oqckAI0SEaFo+w6EXBLPiL/F5SoFBmKR50Nu4NKWRBcoNGq7AwvWEKDZeU0PvC3a
dykqSnFTRtL5LeWZnByuZTVVqlDG3afjX6ZYkrUbMKQeE9rVf24Gx9jlRusxSds=
=zUDu
-----END PGP SIGNATURE-----

From omeragacan at gmail.com  Tue Jun 16 15:20:51 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Tue, 16 Jun 2015 11:20:51 -0400
Subject: expanding type synonyms in error messages
Message-ID: <CAMQQO3=i2-38x5hDAUyww_x=08GJ7c2Yi3HJLFAQvfqO=qEc9g@mail.gmail.com>

Hi all,

While working with complex types with lots of arguments etc. errors are
becoming annoying very fast. For example, GHC prints errors in this way:

    Expected type: <type without any synonyms>
      Actual type: <type with synonyms>

Now I have to expand that synonym in my head to understand the error.

I was wondering if implementing something like this is possible:

In type error messages, GHC also prints types that are cleaned from type
synonyms. Maybe something like this:

         Expected type: <type1>
    (without synonyms): <type1, synonyms are expanded>
           Actual type: <type2>
    (without synonyms): <type2, synonyms are expanded>

If this is not always desirable for some reason, we can hide this behavior
behind a flag.

What do GHC devs think about this? Is this, in theory, possible to do? How hard
would it be to implement this?

Thanks.

From ggreif at gmail.com  Tue Jun 16 17:53:44 2015
From: ggreif at gmail.com (Gabor Greif)
Date: Tue, 16 Jun 2015 19:53:44 +0200
Subject: expanding type synonyms in error messages
In-Reply-To: <CAMQQO3=i2-38x5hDAUyww_x=08GJ7c2Yi3HJLFAQvfqO=qEc9g@mail.gmail.com>
References: <CAMQQO3=i2-38x5hDAUyww_x=08GJ7c2Yi3HJLFAQvfqO=qEc9g@mail.gmail.com>
Message-ID: <CAK-hX0m31w5O23aE4jWvqg23-6ZzaJonDvEFDC5CL1uQ-62XJA@mail.gmail.com>

Clang (and recent GCC versions) do something like this in error
messages. They say

   MyString (aka std::string<...lots of junk...>) is uncool

maybe a similar system would help you?

Cheers,

    Gabor

On 6/16/15, ?mer Sinan A?acan <omeragacan at gmail.com> wrote:
> Hi all,
>
> While working with complex types with lots of arguments etc. errors are
> becoming annoying very fast. For example, GHC prints errors in this way:
>
>     Expected type: <type without any synonyms>
>       Actual type: <type with synonyms>
>
> Now I have to expand that synonym in my head to understand the error.
>
> I was wondering if implementing something like this is possible:
>
> In type error messages, GHC also prints types that are cleaned from type
> synonyms. Maybe something like this:
>
>          Expected type: <type1>
>     (without synonyms): <type1, synonyms are expanded>
>            Actual type: <type2>
>     (without synonyms): <type2, synonyms are expanded>
>
> If this is not always desirable for some reason, we can hide this behavior
> behind a flag.
>
> What do GHC devs think about this? Is this, in theory, possible to do? How
> hard
> would it be to implement this?
>
> Thanks.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From eir at cis.upenn.edu  Tue Jun 16 19:44:43 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 16 Jun 2015 15:44:43 -0400
Subject: expanding type synonyms in error messages
In-Reply-To: <CAMQQO3=i2-38x5hDAUyww_x=08GJ7c2Yi3HJLFAQvfqO=qEc9g@mail.gmail.com>
References: <CAMQQO3=i2-38x5hDAUyww_x=08GJ7c2Yi3HJLFAQvfqO=qEc9g@mail.gmail.com>
Message-ID: <DA74706D-FA4C-4AEA-B3CC-61718109F15D@cis.upenn.edu>

GHC tries hard to preserve type synonyms where possible, but of course, it can't preserve all of them. The general rule it tries to follow is: preserve vanilla type synonyms; expand type families. This is true both in expected types and actual types. 
If you have a case where you believe that GHC could preserve a type synonym in an expected type, submit a bug report. (Note that constraint synonyms are particularly hard to preserve!)

It would be very easy to report both the synonym-preserving form and the expanded form in an error report, at the cost of making error reports even more verbose. You're welcome to submit a feature request, and this would likely make a good first patch to GHC if you want to get your hands dirty. I'd personally prefer the feature to be protected behind a flag (to avoid seeing that `String` expands to `[Char]` everywhere, for example), but others may feel differently here.

Richard

On Jun 16, 2015, at 11:20 AM, ?mer Sinan A?acan <omeragacan at gmail.com> wrote:

> Hi all,
> 
> While working with complex types with lots of arguments etc. errors are
> becoming annoying very fast. For example, GHC prints errors in this way:
> 
>    Expected type: <type without any synonyms>
>      Actual type: <type with synonyms>
> 
> Now I have to expand that synonym in my head to understand the error.
> 
> I was wondering if implementing something like this is possible:
> 
> In type error messages, GHC also prints types that are cleaned from type
> synonyms. Maybe something like this:
> 
>         Expected type: <type1>
>    (without synonyms): <type1, synonyms are expanded>
>           Actual type: <type2>
>    (without synonyms): <type2, synonyms are expanded>
> 
> If this is not always desirable for some reason, we can hide this behavior
> behind a flag.
> 
> What do GHC devs think about this? Is this, in theory, possible to do? How hard
> would it be to implement this?
> 
> Thanks.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From pali.gabor at gmail.com  Wed Jun 17 11:43:53 2015
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Wed, 17 Jun 2015 13:43:53 +0200
Subject: Broken build: Documentation mistake
In-Reply-To: <CAHnG2Cyvj1SVqYZvSuJzTJpCMVx9YD3bLDN1HoddWew2NYQ5zA@mail.gmail.com>
References: <CAHnG2CwBGTf7jho4LQ42_0OEa__oQ-FqQUqCSV3eeuZqDfpqRQ@mail.gmail.com>
 <CAEs96n13=tXJt3aoG2DUZs7XGz7iddmvo_LxHNm5rbCBRLLMGQ@mail.gmail.com>
 <CAHnG2Cw31JOJmouBifwShgPEtfwsckNQ_q7YPFidjEdX97EsbQ@mail.gmail.com>
 <CAEs96n3P3pexrBpg5r75+4c562LeMfkototeaH_ZjP+VMfvpQA@mail.gmail.com>
 <CAHnG2Czggx+ypE1hGH=XYughYL5guqYCuXBKLvyr26DfqWq1yw@mail.gmail.com>
 <CAHnG2Czj4pGXkBYQ2XcDy-MWyFj4Qn2WKLADapgc+OyjO599Pw@mail.gmail.com>
 <CAD3WKgjyA94PvSw8QmiOpWTgx+UQ9jHtCxd-6CPfdRmOPui9wQ@mail.gmail.com>
 <CAHnG2Cyvj1SVqYZvSuJzTJpCMVx9YD3bLDN1HoddWew2NYQ5zA@mail.gmail.com>
Message-ID: <CAHnG2CxouVSwuRX3Mp4LOvwb3bGaAHJPoBabPE3KY9FvKJR2aA@mail.gmail.com>

2015-06-15 23:39 GMT+02:00 P?li G?bor J?nos <pali.gabor at gmail.com>:
> The best result I was able to achive is that I passed the -P
> 'latex.unicode.use=1' flag to dblatex so it could build the PS file.

So, would you mind if I added this flag for dblatex, so it would at
least unbreak the build for me?  That is, consider the following
patch:

--- a/mk/config.mk.in
+++ b/mk/config.mk.in
@@ -731,7 +731,7 @@ BUILD_DOCBOOK_PS         = @BUILD_DOCBOOK_PS@
 BUILD_DOCBOOK_PDF        = @BUILD_DOCBOOK_PDF@
 DBLATEX                  = @DblatexCmd@
 # filename.as.url=0 is needed with dblatex 0.3.4 (#7486)
-DBLATEX_OPTS             = -P 'filename.as.url=0'
+DBLATEX_OPTS             = -P 'filename.as.url=0' -P 'latex.unicode.use=1'
 XSLTPROC                 = @XsltprocCmd@
 XMLLINT                  = @XmllintCmd@
 HAVE_DOCBOOK_XSL        = @HAVE_DOCBOOK_XSL@

I have not yet given up the hope to understand the exact causes, but
this could serve as an interim solution for me until I can solve it --
unless if it breaks something on Ubuntu.

> Note that this way the PS file is generated, but when I checked the
> table in 7.3.1, it had the entity codes in place of the Unicode
> symbols.  May I see the build logs of yours somewhere?

In the meantime, I tried to look up some logs for the referenced
Phabricator builds, but unfortunately they are not run in verbose
mode, so I cannot exactly tell if the PS/PDF versions of the User's
Guide are built or not at all.  (Though, the configure output
indicates that they are.)

Note that the HTML version builds just fine for me as well, as dblatex
simply puts the corresponding Unicode codes right into the generated
files.  The problem is with LaTeX because it cannot handle those codes
-- after studying the sources of both dblatex, passivetex, the latex
ucs package, and the DocBook XML 4.5 entities, I could not yet get how
it is able to work on your system.  That is why it would be good to
see a detailed build log as a reference.

From simonpj at microsoft.com  Wed Jun 17 12:00:28 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 17 Jun 2015 12:00:28 +0000
Subject: Validate failures on 7.10 branch
Message-ID: <ff72f7a413d845f0b05ace8807657264@DB4PR30MB030.064d.mgd.msft.net>

On a fresh build of the 7.10 branch, I get five validate failures on Linux. They are below.  Is this only me?
Simon
Unexpected failures:
   driver                 T8959a [bad stderr] (normal)
   th                     T10279 [stderr mismatch] (normal)
   typecheck/should_fail  T10534 [stderr mismatch] (normal)

Unexpected stat failures:
   perf/should_run  T4830 [stat not good enough] (normal)
   perf/should_run  T7436 [stat not good enough] (normal)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150617/ed04d889/attachment-0001.html>

From ekmett at gmail.com  Wed Jun 17 13:33:31 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 17 Jun 2015 09:33:31 -0400
Subject: MFP updates: ideas worth discussing
In-Reply-To: <55803BC6.7040706@gmail.com>
References: <55774FF2.8020505@gmail.com>
	<55803BC6.7040706@gmail.com>
Message-ID: <CAJumaK_33EfBx+xmCkaUU+PS-uufhWaYKeT1ie6FE5vEMgtgdw@mail.gmail.com>

There is a bit of a knee-jerk reaction that we should go to something
simpler than Monad as a superclass constraint for MonadFail, but I think
most of those reasons fall apart or at least lose much of their weight upon
deeper inspection.

Ultimately, I'm a not concerned about interactions between ApplicativeDo
notation and fail.

Any automatic desugaring into 'fail' will be in a context which is
necessarily incurring a monad constraint.

E.g.

do
   Just x <- m
   ...

has to pick up the Monad constraint anyways to deal with the binding!

This leaves only code that does something like.

foo = x <*> fail y

which is hand written to invoke fail.

Given that the entire "tree" of the Applicative" is available for
inspection and that that fail can't depend on any context internal to the
Applicative and remain 'just Applicative' I have a hard time foreseeing any
real applications lost by continuing to assume a context of:

class Monad m => MonadFail m

and there is a lot of value in the simple context.

Most of the value in ApplicativeDo notation comes from the opportunities
for increased parallelism, not so much from the reduced constraints on the
resulting code, and as we can see above, it'll never arise during the
desguaring in a place that wouldn't incur a Monad constraint anyways.

Even getting rid of the Monad constraint w/ ApplicativeDo is going to
require gymnastics around `return`.

-Edward

P.S. On an unrelated note, for the record, I'm very strongly +1 on a
MonadFail instance for IO. There we use throwIO explicitly, so it is even
able to be handled and caught locally. The set of things you can do in IO
is large enough to support and reason about explicit failure.

P.P.S. I think if we extend the proposal to include an explicit member of
the class for pattern match failure with the code we currently have lurking
in the compiler for producing the string from the context, then most of the
concerns raised by folks who would prefer to use a heavier weight -- but
vastly harder to standardize -- exception mechanism would also be addressed
in practice.

On Tue, Jun 16, 2015 at 11:07 AM, David Luposchainsky <
dluposchainsky at googlemail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> MonadFail proposal update 1
> ===========================
>
>
> Rendered version of this text:
> https://github.com/quchen/articles/blob/master/monad_fail_update1.md
>
> Original MFP:
> https://github.com/quchen/articles/blob/master/monad_fail.md
>
>
> Short summary
> - -------------
>
> A week has passed since I posted the MFP, and the initial discussion is
> mostly
> over. Here are my observations:
>
> - - Everyone agrees that `fail` should not be in `Monad`.
> - - Almost everyone agrees that it should be thrown out of it.
> - - Some would prefer to see the special desugaring be gone entirely.
> - - The name `MonadFail` is controversial, because of a potential
> `Applicative`
>   constraint.
> - - We're still unsure about whether `IO` should get a `MonadFail`
> instance, but
>   the bias seems to be towards "yes".
>
>
>
> New ideas worth thinking about
> - ------------------------------
>
> ### Special desugaring or not
>
> Johann suggested an optional warning whenever something desugars to use
> `fail`.
> I think that's an idea we should think about. It is easily implemented in
> the
> compiler, and would probably behave similar to -fwarn-unused-do-binds in
> practice: notation that is not wrong, but might not be what the programmer
> intended.
>
>
> ### Errors vs. Exceptions
>
> Henning is concerned about the confusion between exceptions and programming
> errors. In his words,
>
> > We should clearly decide what "fail" is intended for - for programming
> > errors or for exceptions.
>
> What I see clashing with his point is backwards compatibility. Removing the
> `String` argument breaks all explicit invocations of `fail`. Unfortunately,
> we're not in a position to break very much. If someone has a better idea
> I'd
> love to hear about it though.
>
>
> ### ApplicativeDo
>
> ApplicativeDo is somewhere out there on the horizon, and we're not sure
> yet how
> much `fail` makes sense in the context of `Applicative`. An Applicative
> computation is statically determined in its shape, so it either always or
> never
> fails. Depending on previous results would introduce the `Monad` constraint
> anyway.
>
>
>
> Probing status
> - --------------
>
> Henning has started to look at the impact of the proposal when explicit
> invocations of `fail` are considered as well, something I have not done in
> my
> original survey. Luckily, things don't look too bad, Lens and its forest of
> dependencies can be fixed in around ten trivial changes, for example.
>
>
> Greetings,
> David/quchen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVgDvGAAoJELrQsaT5WQUspmIIAJi9UVYIitHv2CKvWSmk1fg0
> hYaPRXDJMnyFS21v57+JeTPhM/dnI4k0guUUrlIB9k5WPaySQ6MKIAnB51o5O9Gv
> zt87FII5/oYsJtVPruKgBtLPbJVhg6zGUXmNco1S2wvB5m5HdBooQsiBRY+qiFfZ
> MJOdzXpRCrYJk/0PeF7sglBOElSwsSmGq/klvJUo4VeVAdi8bU+lKRfET/AmAAM5
> oqckAI0SEaFo+w6EXBLPiL/F5SoFBmKR50Nu4NKWRBcoNGq7AwvWEKDZeU0PvC3a
> dykqSnFTRtL5LeWZnByuZTVVqlDG3afjX6ZYkrUbMKQeE9rVf24Gx9jlRusxSds=
> =zUDu
> -----END PGP SIGNATURE-----
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150617/fc60691e/attachment.html>

From eir at cis.upenn.edu  Wed Jun 17 13:42:14 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 17 Jun 2015 09:42:14 -0400
Subject: Validate failures on 7.10 branch
In-Reply-To: <ff72f7a413d845f0b05ace8807657264@DB4PR30MB030.064d.mgd.msft.net>
References: <ff72f7a413d845f0b05ace8807657264@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <813075CD-3688-47F8-83E4-EB70CB641B9C@cis.upenn.edu>


On Jun 17, 2015, at 8:00 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> On a fresh build of the 7.10 branch, I get five validate failures on Linux. They are below.  Is this only me?
> 
>    typecheck/should_fail  T10534 [stderr mismatch] (normal)
> 
> 

That's probably my fault. As long as the file doesn't compile and the error message is something along the lines of "can't match a with b", it's fine. I validated on master, not 7.10, and it's quite possible the error message changed between them.

I don't know about the others.

Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150617/0f0523d1/attachment.html>

From simonpj at microsoft.com  Wed Jun 17 14:42:42 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 17 Jun 2015 14:42:42 +0000
Subject: Validate failures on 7.10 branch
In-Reply-To: <813075CD-3688-47F8-83E4-EB70CB641B9C@cis.upenn.edu>
References: <ff72f7a413d845f0b05ace8807657264@DB4PR30MB030.064d.mgd.msft.net>
 <813075CD-3688-47F8-83E4-EB70CB641B9C@cis.upenn.edu>
Message-ID: <c34be33560734d95922fcec772bbe0b5@DB4PR30MB030.064d.mgd.msft.net>

OK I've pushed that change.

S

From: Richard Eisenberg [mailto:eir at cis.upenn.edu]
Sent: 17 June 2015 14:42
To: Simon Peyton Jones
Cc: ghc-devs at haskell.org
Subject: Re: Validate failures on 7.10 branch


On Jun 17, 2015, at 8:00 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:


On a fresh build of the 7.10 branch, I get five validate failures on Linux. They are below.  Is this only me?
   typecheck/should_fail  T10534 [stderr mismatch] (normal)


That's probably my fault. As long as the file doesn't compile and the error message is something along the lines of "can't match a with b", it's fine. I validated on master, not 7.10, and it's quite possible the error message changed between them.

I don't know about the others.

Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150617/168d698c/attachment-0001.html>

From alan.zimm at gmail.com  Wed Jun 17 15:21:53 2015
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Wed, 17 Jun 2015 17:21:53 +0200
Subject: [GHC] #10537: Parser: commas_tup_tail returns spurious "Missing"
 value
In-Reply-To: <059.12600e7b810f52907141c17a650847a2@haskell.org>
References: <044.8f8ff9122e016e5ffbb6178f93fcf42d@haskell.org>
 <059.12600e7b810f52907141c17a650847a2@haskell.org>
Message-ID: <CANma=H9nFd2eUaSO6guGuG9q5eUCewfveTDvLuyDjgSTxWoiWg@mail.gmail.com>

So it appears the `Missing` item is correct, but it has been given the
wrong SrcSpan. Originally it was a `noLoc`.

I think I will just advance the column by one, then it is actually correct,
and the annotation lookup will only succeed for the first one, so it will
all just work.

On Wed, Jun 17, 2015 at 5:14 PM, GHC <ghc-devs at haskell.org> wrote:

> #10537: Parser: commas_tup_tail returns spurious "Missing" value
> -------------------------------------+-------------------------------------
>         Reporter:  alanz             |                   Owner:  alanz
>             Type:  bug               |                  Status:  new
>         Priority:  normal            |               Milestone:  7.10.2
>        Component:  Compiler          |                 Version:  7.10.1
>   (Parser)                           |                Keywords:
>       Resolution:                    |            Architecture:
> Operating System:  Unknown/Multiple  |  Unknown/Multiple
>  Type of failure:  None/Unknown      |               Test Case:
>       Blocked By:                    |                Blocking:
>  Related Tickets:                    |  Differential Revisions:
> -------------------------------------+-------------------------------------
>
> Comment (by mpickering):
>
>  I think you're right Simon. There is something wrong with the annotations
>  though, firstly both the Missing elements have the same SrcSpan `L
>  tests/examples/Tuple.hs:3:24`.
>
>  {{{
>   ((tests/examples/Tuple.hs:3:8, AnnComma),
>     [tests/examples/Tuple.hs:3:9]),
>    ((tests/examples/Tuple.hs:3:11-17, AnnComma),
>     [tests/examples/Tuple.hs:3:18]),
>    ((tests/examples/Tuple.hs:3:20-22, AnnComma),
>     [tests/examples/Tuple.hs:3:23]),
>    ((tests/examples/Tuple.hs:3:24, AnnComma),
>     [tests/examples/Tuple.hs:3:24]),
>  }}}
>
>  Here are the relevant annotations. Notice how the first three commas are
>  associated with the preceding item (much like they are for lists) but the
>  last one is associated directly with the `Missing`. As both `Missing`s
>  have the same SrcSpan then this is causing duplicated output in `ghc-
>  exactprint`.
>
> --
> Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10537#comment:2>
> GHC <http://www.haskell.org/ghc/>
> The Glasgow Haskell Compiler
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150617/b4a6bda8/attachment.html>

From simonpj at microsoft.com  Wed Jun 17 20:28:34 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 17 Jun 2015 20:28:34 +0000
Subject: [commit: ghc] master: Update submodule process to master (c1dc421)
In-Reply-To: <20150611172952.3223C3A300@ghc.haskell.org>
References: <20150611172952.3223C3A300@ghc.haskell.org>
Message-ID: <4a1c3bc6c6324df2b45f99649ff74b77@DB4PR30MB030.064d.mgd.msft.net>

Thomas

|     Update submodule process to master
| 
|     This allows a warning free build on Windows, and thus an error free
|     validate.

I was excited about this, because GHC has not validated on Windows for ages and ages.

But I get the following failures, with HEAD, on 32-bit Windows.

I can get more details if you like. I'd LOVE someone to fix these failures.

thanks

Simon


Unexpected passes:
   driver  T2507 (normal)
   driver  T8959a (normal)
   rts     T5250 (normal)
   rts     rdynamic (normal)

Unexpected failures:
   ../../libraries/base/tests/System  Timeout001 [bad exit code] (normal)
   codeGen/should_compile             T10518 [exit code non-0] (normal)
   codeGen/should_fail                T8131 [stderr mismatch] (normal)
   ghci/scripts                       T5975a [bad stderr] (ghci)
   perf/haddock                       haddock.Cabal [[Errno 2] No such file or directory: './perf/haddock/../../../../libraries/Cabal/Cabal/dist-install/haddock.t'] (normal)
   perf/haddock                       haddock.base [[Errno 2] No such file or directory: './perf/haddock/../../../../libraries/base/dist-install/haddock.t'] (normal)
   perf/haddock                       haddock.compiler [[Errno 2] No such file or directory: './perf/haddock/../../../../compiler/stage2/haddock.t'] (normal)
   rts                                outofmem [bad stderr] (normal)

Unexpected stat failures:
   perf/compiler    T3294 [stat too good] (normal)
   perf/compiler    T5030 [stat too good] (normal)
   perf/compiler    T5837 [stat too good] (normal)
   perf/compiler    T9961 [stat too good] (normal)
   perf/should_run  T9203 [stat not good enough] (normal)

   perf/compiler    T5321Fun [stat not good enough] (normal)
   perf/compiler    T783 [stat not good enough] (normal)
   perf/compiler    T9675 [stat not good enough] (optasm)
   perf/compiler    T9872d [stat not good enough] (normal)

| -----Original Message-----
| From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
| git at git.haskell.org
| Sent: 11 June 2015 18:30
| To: ghc-commits at haskell.org
| Subject: [commit: ghc] master: Update submodule process to master
| (c1dc421)
| 
| Repository : ssh://git at git.haskell.org/ghc
| 
| On branch  : master
| Link       :
| http://ghc.haskell.org/trac/ghc/changeset/c1dc4216efc3db1a8fbd56a658981b5
| 3b7e42eda/ghc
| 
| >---------------------------------------------------------------
| 
| commit c1dc4216efc3db1a8fbd56a658981b53b7e42eda
| Author: Thomas Miedema <thomasmiedema at gmail.com>
| Date:   Thu Jun 11 19:24:25 2015 +0200
| 
|     Update submodule process to master
| 
|     This allows a warning free build on Windows, and thus an error free
|     validate.
| 
| 
| >---------------------------------------------------------------
| 
| c1dc4216efc3db1a8fbd56a658981b53b7e42eda
|  libraries/process | 2 +-
|  1 file changed, 1 insertion(+), 1 deletion(-)
| 
| diff --git a/libraries/process b/libraries/process
| index 67efaf5..e0983fb 160000
| --- a/libraries/process
| +++ b/libraries/process
| @@ -1 +1 @@
| -Subproject commit 67efaf599a03f454a98a3905820ce40aa80825c7
| +Subproject commit e0983fbbfa8a3d81c7b99e83a3169fc686caab62
| 
| _______________________________________________
| ghc-commits mailing list
| ghc-commits at haskell.org
| http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits

From hvr at gnu.org  Thu Jun 18 08:32:05 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Thu, 18 Jun 2015 10:32:05 +0200
Subject: Native -XCPP Conclusion (was: RFC: "Native -XCPP" Proposal)
In-Reply-To: <87zj5i55gs.fsf@gmail.com> (Herbert Valerio Riedel's message of
 "Wed, 06 May 2015 13:08:03 +0200")
References: <87zj5i55gs.fsf@gmail.com>
Message-ID: <87oakdo1ru.fsf@gmail.com>

Hello *,

Following up on the "Native -XCPP" Proposal discussion, it appears that
cpphs' current LGPL+SLE licensing doesn't pose an *objective*
showstopper problem but is rather more of an inconvenience as it causes
argumentation/discussion overhead (which then /may/ actually result in
Haskell being turned down eventually over alternatives that do without
LGPL components).

In order to acknowledge this discomfort, for GHC 7.12 we propose to follow
"plan 4" according to [1] (i.e. calling out to a cpphs-executable as a
separate process), thereby avoiding pulling any LGPL-subjected cpphs
code into produced executables when linking against the 'ghc' package.

"Plan 2" (i.e. embedding/linking cpphs' code directly into ghc) would
reduce fork/exec overhead, which can be substantial on Windows [2],
but plan 4 is no worse than what we have now.

Last Call: Are there any objections with GHC adopting "plan 4"[1]?

 [1]: <https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp>

 [2]: <http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/8869>

Thanks,
  HVR

On 2015-05-06 at 13:08:03 +0200, Herbert Valerio Riedel wrote:
> Hello *,
>
> As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
> currently relies on the system's C-compiler bundled `cpp` program to
> provide a "traditional mode" c-preprocessor.
>
> This has caused several problems in the past, since parsing Haskell code
> with a preprocessor mode designed for use with C's tokenizer has caused
> already quite some problems[1] in the past. I'd like to see GHC 7.12
> adopt an implemntation of `-XCPP` that does not rely on the shaky
> system-`cpp` foundation. To this end I've created a wiki page
>
>   https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp
>
> to describe the actual problems in more detail, and a couple of possible
> ways forward. Ideally, we'd simply integrate `cpphs` into GHC
> (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be
> discussed and debated since affects the overall-license of the GHC
> code-base, which may or may not be a problem to GHC's user-base (and
> that's what I hope this discussion will help to find out).
>
> So please go ahead and read the Wiki page... and then speak your mind!
>
>
> Thanks,
>   HVR
>
>
> [1]: ...does anybody remember the issues Haskell packages (& GHC)
>      encountered when Apple switched to the Clang tool-chain, thereby
>      causing code using `-XCPP` to suddenly break due to subtly
>      different `cpp`-semantics?

-- 
"Elegance is not optional" -- Richard O'Keefe

From k-bx at k-bx.com  Thu Jun 18 08:41:11 2015
From: k-bx at k-bx.com (Kostiantyn Rybnikov)
Date: Thu, 18 Jun 2015 11:41:11 +0300
Subject: expanding type synonyms in error messages
In-Reply-To: <DA74706D-FA4C-4AEA-B3CC-61718109F15D@cis.upenn.edu>
References: <CAMQQO3=i2-38x5hDAUyww_x=08GJ7c2Yi3HJLFAQvfqO=qEc9g@mail.gmail.com>
 <DA74706D-FA4C-4AEA-B3CC-61718109F15D@cis.upenn.edu>
Message-ID: <CAAbahfTuSx6EXN2=PCq=S7a2_4XbKvqhEh2oeHoYGJgS8T9s=w@mail.gmail.com>

I wanted to add that synonym expansion would be especially helpful in
error-messages like:

Expected type: <non-expanded, small type, like "Producer a m ()">
Actual type: <your type, like "Proxy a a' b b' m v">

I would be glad if we could have an expansions enabling flag in GHC, and
could consider turning it on by default if it will look good for that.
16 ????. 2015 22:44 "Richard Eisenberg" <eir at cis.upenn.edu> ????:

> GHC tries hard to preserve type synonyms where possible, but of course, it
> can't preserve all of them. The general rule it tries to follow is:
> preserve vanilla type synonyms; expand type families. This is true both in
> expected types and actual types.
> If you have a case where you believe that GHC could preserve a type
> synonym in an expected type, submit a bug report. (Note that constraint
> synonyms are particularly hard to preserve!)
>
> It would be very easy to report both the synonym-preserving form and the
> expanded form in an error report, at the cost of making error reports even
> more verbose. You're welcome to submit a feature request, and this would
> likely make a good first patch to GHC if you want to get your hands dirty.
> I'd personally prefer the feature to be protected behind a flag (to avoid
> seeing that `String` expands to `[Char]` everywhere, for example), but
> others may feel differently here.
>
> Richard
>
> On Jun 16, 2015, at 11:20 AM, ?mer Sinan A?acan <omeragacan at gmail.com>
> wrote:
>
> > Hi all,
> >
> > While working with complex types with lots of arguments etc. errors are
> > becoming annoying very fast. For example, GHC prints errors in this way:
> >
> >    Expected type: <type without any synonyms>
> >      Actual type: <type with synonyms>
> >
> > Now I have to expand that synonym in my head to understand the error.
> >
> > I was wondering if implementing something like this is possible:
> >
> > In type error messages, GHC also prints types that are cleaned from type
> > synonyms. Maybe something like this:
> >
> >         Expected type: <type1>
> >    (without synonyms): <type1, synonyms are expanded>
> >           Actual type: <type2>
> >    (without synonyms): <type2, synonyms are expanded>
> >
> > If this is not always desirable for some reason, we can hide this
> behavior
> > behind a flag.
> >
> > What do GHC devs think about this? Is this, in theory, possible to do?
> How hard
> > would it be to implement this?
> >
> > Thanks.
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150618/724c4ca8/attachment-0001.html>

From simonpj at microsoft.com  Thu Jun 18 14:30:56 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 18 Jun 2015 14:30:56 +0000
Subject: missing file
Message-ID: <e1461efae8624559b5127b7ac6061cc8@DB4PR30MB030.064d.mgd.msft.net>

I'm getting validate failures on HEAD.  Missing file perhaps?
Simon
Unexpected failures:
   llvm/should_compile  T8131b [exit code non-0] (optllvm)
<command line>: does not exist: T8131b.cmm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150618/7320a8ef/attachment.html>

From omeragacan at gmail.com  Fri Jun 19 02:42:28 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Thu, 18 Jun 2015 22:42:28 -0400
Subject: expanding type synonyms in error messages
In-Reply-To: <CAAbahfTuSx6EXN2=PCq=S7a2_4XbKvqhEh2oeHoYGJgS8T9s=w@mail.gmail.com>
References: <CAMQQO3=i2-38x5hDAUyww_x=08GJ7c2Yi3HJLFAQvfqO=qEc9g@mail.gmail.com>
 <DA74706D-FA4C-4AEA-B3CC-61718109F15D@cis.upenn.edu>
 <CAAbahfTuSx6EXN2=PCq=S7a2_4XbKvqhEh2oeHoYGJgS8T9s=w@mail.gmail.com>
Message-ID: <CAMQQO3kOosf1NJVQs8pctjKB2_cGoC2G2PWDUz6nwODmq6MfVw@mail.gmail.com>

It's good to see that I'm not the only one who wants this. I'm doing
some GHC hacking nowadays and I'll give it a try.

2015-06-18 4:41 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
> I wanted to add that synonym expansion would be especially helpful in
> error-messages like:
>
> Expected type: <non-expanded, small type, like "Producer a m ()">
> Actual type: <your type, like "Proxy a a' b b' m v">
>
> I would be glad if we could have an expansions enabling flag in GHC, and
> could consider turning it on by default if it will look good for that.
>
> 16 ????. 2015 22:44 "Richard Eisenberg" <eir at cis.upenn.edu> ????:
>
>> GHC tries hard to preserve type synonyms where possible, but of course, it
>> can't preserve all of them. The general rule it tries to follow is: preserve
>> vanilla type synonyms; expand type families. This is true both in expected
>> types and actual types.
>> If you have a case where you believe that GHC could preserve a type
>> synonym in an expected type, submit a bug report. (Note that constraint
>> synonyms are particularly hard to preserve!)
>>
>> It would be very easy to report both the synonym-preserving form and the
>> expanded form in an error report, at the cost of making error reports even
>> more verbose. You're welcome to submit a feature request, and this would
>> likely make a good first patch to GHC if you want to get your hands dirty.
>> I'd personally prefer the feature to be protected behind a flag (to avoid
>> seeing that `String` expands to `[Char]` everywhere, for example), but
>> others may feel differently here.
>>
>> Richard
>>
>> On Jun 16, 2015, at 11:20 AM, ?mer Sinan A?acan <omeragacan at gmail.com>
>> wrote:
>>
>> > Hi all,
>> >
>> > While working with complex types with lots of arguments etc. errors are
>> > becoming annoying very fast. For example, GHC prints errors in this way:
>> >
>> >    Expected type: <type without any synonyms>
>> >      Actual type: <type with synonyms>
>> >
>> > Now I have to expand that synonym in my head to understand the error.
>> >
>> > I was wondering if implementing something like this is possible:
>> >
>> > In type error messages, GHC also prints types that are cleaned from type
>> > synonyms. Maybe something like this:
>> >
>> >         Expected type: <type1>
>> >    (without synonyms): <type1, synonyms are expanded>
>> >           Actual type: <type2>
>> >    (without synonyms): <type2, synonyms are expanded>
>> >
>> > If this is not always desirable for some reason, we can hide this
>> > behavior
>> > behind a flag.
>> >
>> > What do GHC devs think about this? Is this, in theory, possible to do?
>> > How hard
>> > would it be to implement this?
>> >
>> > Thanks.
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From cma at bitemyapp.com  Fri Jun 19 03:27:23 2015
From: cma at bitemyapp.com (Christopher Allen)
Date: Thu, 18 Jun 2015 22:27:23 -0500
Subject: expanding type synonyms in error messages
In-Reply-To: <CAMQQO3kOosf1NJVQs8pctjKB2_cGoC2G2PWDUz6nwODmq6MfVw@mail.gmail.com>
References: <CAMQQO3=i2-38x5hDAUyww_x=08GJ7c2Yi3HJLFAQvfqO=qEc9g@mail.gmail.com>
 <DA74706D-FA4C-4AEA-B3CC-61718109F15D@cis.upenn.edu>
 <CAAbahfTuSx6EXN2=PCq=S7a2_4XbKvqhEh2oeHoYGJgS8T9s=w@mail.gmail.com>
 <CAMQQO3kOosf1NJVQs8pctjKB2_cGoC2G2PWDUz6nwODmq6MfVw@mail.gmail.com>
Message-ID: <CADnndOr5Bzzv2LV6hC=eRYv3ZzPaEDTwSwUk0TweSqgoH8o8mg@mail.gmail.com>

Just to add my own +1, having this when working with streaming libraries
(I've needed it less with lens, oddly) would be a tremendous help for
people learning them I think. I think I've run into the same thing as
Kostiantyn in the past.

On Thu, Jun 18, 2015 at 9:42 PM, ?mer Sinan A?acan <omeragacan at gmail.com>
wrote:

> It's good to see that I'm not the only one who wants this. I'm doing
> some GHC hacking nowadays and I'll give it a try.
>
> 2015-06-18 4:41 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
> > I wanted to add that synonym expansion would be especially helpful in
> > error-messages like:
> >
> > Expected type: <non-expanded, small type, like "Producer a m ()">
> > Actual type: <your type, like "Proxy a a' b b' m v">
> >
> > I would be glad if we could have an expansions enabling flag in GHC, and
> > could consider turning it on by default if it will look good for that.
> >
> > 16 ????. 2015 22:44 "Richard Eisenberg" <eir at cis.upenn.edu> ????:
> >
> >> GHC tries hard to preserve type synonyms where possible, but of course,
> it
> >> can't preserve all of them. The general rule it tries to follow is:
> preserve
> >> vanilla type synonyms; expand type families. This is true both in
> expected
> >> types and actual types.
> >> If you have a case where you believe that GHC could preserve a type
> >> synonym in an expected type, submit a bug report. (Note that constraint
> >> synonyms are particularly hard to preserve!)
> >>
> >> It would be very easy to report both the synonym-preserving form and the
> >> expanded form in an error report, at the cost of making error reports
> even
> >> more verbose. You're welcome to submit a feature request, and this would
> >> likely make a good first patch to GHC if you want to get your hands
> dirty.
> >> I'd personally prefer the feature to be protected behind a flag (to
> avoid
> >> seeing that `String` expands to `[Char]` everywhere, for example), but
> >> others may feel differently here.
> >>
> >> Richard
> >>
> >> On Jun 16, 2015, at 11:20 AM, ?mer Sinan A?acan <omeragacan at gmail.com>
> >> wrote:
> >>
> >> > Hi all,
> >> >
> >> > While working with complex types with lots of arguments etc. errors
> are
> >> > becoming annoying very fast. For example, GHC prints errors in this
> way:
> >> >
> >> >    Expected type: <type without any synonyms>
> >> >      Actual type: <type with synonyms>
> >> >
> >> > Now I have to expand that synonym in my head to understand the error.
> >> >
> >> > I was wondering if implementing something like this is possible:
> >> >
> >> > In type error messages, GHC also prints types that are cleaned from
> type
> >> > synonyms. Maybe something like this:
> >> >
> >> >         Expected type: <type1>
> >> >    (without synonyms): <type1, synonyms are expanded>
> >> >           Actual type: <type2>
> >> >    (without synonyms): <type2, synonyms are expanded>
> >> >
> >> > If this is not always desirable for some reason, we can hide this
> >> > behavior
> >> > behind a flag.
> >> >
> >> > What do GHC devs think about this? Is this, in theory, possible to do?
> >> > How hard
> >> > would it be to implement this?
> >> >
> >> > Thanks.
> >> > _______________________________________________
> >> > ghc-devs mailing list
> >> > ghc-devs at haskell.org
> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150618/7a2637f1/attachment.html>

From simonpj at microsoft.com  Fri Jun 19 07:39:54 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 19 Jun 2015 07:39:54 +0000
Subject: [Diffusion] [Build Failed] rGHCc45f8ceb0de0: Elaborate test for
 Trac #10403
In-Reply-To: <20150618230844.24108.1501@phabricator.haskell.org>
References: <diffusion-audit-PHID-CMIT-e5tvrbc7xbgwksabzz2n@phabricator.haskell.org>
 <20150618230844.24108.1501@phabricator.haskell.org>
Message-ID: <f13da01e6d10447889e1bc0a5b7c137a@DB4PR30MB030.064d.mgd.msft.net>

I think 4945 is failing again -- although not on my machine.  Can someone mark it expect_broken again?  I'm on a train

S

| -----Original Message-----
| From: noreply at phabricator.haskell.org
| [mailto:noreply at phabricator.haskell.org]
| Sent: 19 June 2015 00:09
| To: Simon Peyton Jones
| Subject: [Diffusion] [Build Failed] rGHCc45f8ceb0de0: Elaborate test for
| Trac #10403
| 
| Harbormaster failed to build B4473: rGHCc45f8ceb0de0: Elaborate test for
| Trac #10403!
| 
| BRANCHES
|   master
| 
| USERS
|   simonpj (Author)
|   GHC - Testsuite (Auditor)
| 
| COMMIT
|   https://phabricator.haskell.org/rGHCc45f8ceb0de0
| 
| EMAIL PREFERENCES
|   https://phabricator.haskell.org/settings/panel/emailpreferences/
| 
| To: simonpj, GHC - Testsuite

From simonpj at microsoft.com  Fri Jun 19 07:42:35 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 19 Jun 2015 07:42:35 +0000
Subject: expanding type synonyms in error messages
In-Reply-To: <CADnndOr5Bzzv2LV6hC=eRYv3ZzPaEDTwSwUk0TweSqgoH8o8mg@mail.gmail.com>
References: <CAMQQO3=i2-38x5hDAUyww_x=08GJ7c2Yi3HJLFAQvfqO=qEc9g@mail.gmail.com>
 <DA74706D-FA4C-4AEA-B3CC-61718109F15D@cis.upenn.edu>
 <CAAbahfTuSx6EXN2=PCq=S7a2_4XbKvqhEh2oeHoYGJgS8T9s=w@mail.gmail.com>
 <CAMQQO3kOosf1NJVQs8pctjKB2_cGoC2G2PWDUz6nwODmq6MfVw@mail.gmail.com>
 <CADnndOr5Bzzv2LV6hC=eRYv3ZzPaEDTwSwUk0TweSqgoH8o8mg@mail.gmail.com>
Message-ID: <15b9703055c74bd28aca095ab9d80ea6@DB4PR30MB030.064d.mgd.msft.net>

On this thread, a representative collection of *reproducible examples* with the actual error message and the desired one, would be tremendously helpful.  Lacking that, it?s hard to know where to begin.   (Creating the examples takes a bit of work, I know.)

Start a wiki page!  Stuff in email threads gets lost

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Christopher Allen
Sent: 19 June 2015 04:27
To: ?mer Sinan A?acan
Cc: ghc-devs
Subject: Re: expanding type synonyms in error messages

Just to add my own +1, having this when working with streaming libraries (I've needed it less with lens, oddly) would be a tremendous help for people learning them I think. I think I've run into the same thing as Kostiantyn in the past.

On Thu, Jun 18, 2015 at 9:42 PM, ?mer Sinan A?acan <omeragacan at gmail.com<mailto:omeragacan at gmail.com>> wrote:
It's good to see that I'm not the only one who wants this. I'm doing
some GHC hacking nowadays and I'll give it a try.

2015-06-18 4:41 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com<mailto:k-bx at k-bx.com>>:
> I wanted to add that synonym expansion would be especially helpful in
> error-messages like:
>
> Expected type: <non-expanded, small type, like "Producer a m ()">
> Actual type: <your type, like "Proxy a a' b b' m v">
>
> I would be glad if we could have an expansions enabling flag in GHC, and
> could consider turning it on by default if it will look good for that.
>
> 16 ????. 2015 22:44 "Richard Eisenberg" <eir at cis.upenn.edu<mailto:eir at cis.upenn.edu>> ????:
>
>> GHC tries hard to preserve type synonyms where possible, but of course, it
>> can't preserve all of them. The general rule it tries to follow is: preserve
>> vanilla type synonyms; expand type families. This is true both in expected
>> types and actual types.
>> If you have a case where you believe that GHC could preserve a type
>> synonym in an expected type, submit a bug report. (Note that constraint
>> synonyms are particularly hard to preserve!)
>>
>> It would be very easy to report both the synonym-preserving form and the
>> expanded form in an error report, at the cost of making error reports even
>> more verbose. You're welcome to submit a feature request, and this would
>> likely make a good first patch to GHC if you want to get your hands dirty.
>> I'd personally prefer the feature to be protected behind a flag (to avoid
>> seeing that `String` expands to `[Char]` everywhere, for example), but
>> others may feel differently here.
>>
>> Richard
>>
>> On Jun 16, 2015, at 11:20 AM, ?mer Sinan A?acan <omeragacan at gmail.com<mailto:omeragacan at gmail.com>>
>> wrote:
>>
>> > Hi all,
>> >
>> > While working with complex types with lots of arguments etc. errors are
>> > becoming annoying very fast. For example, GHC prints errors in this way:
>> >
>> >    Expected type: <type without any synonyms>
>> >      Actual type: <type with synonyms>
>> >
>> > Now I have to expand that synonym in my head to understand the error.
>> >
>> > I was wondering if implementing something like this is possible:
>> >
>> > In type error messages, GHC also prints types that are cleaned from type
>> > synonyms. Maybe something like this:
>> >
>> >         Expected type: <type1>
>> >    (without synonyms): <type1, synonyms are expanded>
>> >           Actual type: <type2>
>> >    (without synonyms): <type2, synonyms are expanded>
>> >
>> > If this is not always desirable for some reason, we can hide this
>> > behavior
>> > behind a flag.
>> >
>> > What do GHC devs think about this? Is this, in theory, possible to do?
>> > How hard
>> > would it be to implement this?
>> >
>> > Thanks.
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



--
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150619/df32c00c/attachment.html>

From k-bx at k-bx.com  Fri Jun 19 09:16:17 2015
From: k-bx at k-bx.com (Kostiantyn Rybnikov)
Date: Fri, 19 Jun 2015 12:16:17 +0300
Subject: expanding type synonyms in error messages
In-Reply-To: <15b9703055c74bd28aca095ab9d80ea6@DB4PR30MB030.064d.mgd.msft.net>
References: <CAMQQO3=i2-38x5hDAUyww_x=08GJ7c2Yi3HJLFAQvfqO=qEc9g@mail.gmail.com>
 <DA74706D-FA4C-4AEA-B3CC-61718109F15D@cis.upenn.edu>
 <CAAbahfTuSx6EXN2=PCq=S7a2_4XbKvqhEh2oeHoYGJgS8T9s=w@mail.gmail.com>
 <CAMQQO3kOosf1NJVQs8pctjKB2_cGoC2G2PWDUz6nwODmq6MfVw@mail.gmail.com>
 <CADnndOr5Bzzv2LV6hC=eRYv3ZzPaEDTwSwUk0TweSqgoH8o8mg@mail.gmail.com>
 <15b9703055c74bd28aca095ab9d80ea6@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAAbahfTxk-Qt4+MLZjhbRY=okGL0PmcVDc2gAjk9P9o5QoPe2g@mail.gmail.com>

Created some initial wiki-page with just one example, will keep it in mind
to add more as seen.

https://wiki.haskell.org/Expanding_type_synonyms_in_error_messages_proposal

On Fri, Jun 19, 2015 at 10:42 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>  On this thread, a representative collection of **reproducible* *examples**
> with the actual error message and the desired one, would be tremendously
> helpful.  Lacking that, it?s hard to know where to begin.   (Creating the
> examples takes a bit of work, I know.)
>
>
>
> Start a wiki page!  Stuff in email threads gets lost
>
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Christopher
> Allen
> *Sent:* 19 June 2015 04:27
> *To:* ?mer Sinan A?acan
> *Cc:* ghc-devs
> *Subject:* Re: expanding type synonyms in error messages
>
>
>
> Just to add my own +1, having this when working with streaming libraries
> (I've needed it less with lens, oddly) would be a tremendous help for
> people learning them I think. I think I've run into the same thing as
> Kostiantyn in the past.
>
>
>
> On Thu, Jun 18, 2015 at 9:42 PM, ?mer Sinan A?acan <omeragacan at gmail.com>
> wrote:
>
>  It's good to see that I'm not the only one who wants this. I'm doing
> some GHC hacking nowadays and I'll give it a try.
>
>
> 2015-06-18 4:41 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
> > I wanted to add that synonym expansion would be especially helpful in
> > error-messages like:
> >
> > Expected type: <non-expanded, small type, like "Producer a m ()">
> > Actual type: <your type, like "Proxy a a' b b' m v">
> >
> > I would be glad if we could have an expansions enabling flag in GHC, and
> > could consider turning it on by default if it will look good for that.
> >
> > 16 ????. 2015 22:44 "Richard Eisenberg" <eir at cis.upenn.edu> ????:
> >
> >> GHC tries hard to preserve type synonyms where possible, but of course,
> it
> >> can't preserve all of them. The general rule it tries to follow is:
> preserve
> >> vanilla type synonyms; expand type families. This is true both in
> expected
> >> types and actual types.
> >> If you have a case where you believe that GHC could preserve a type
> >> synonym in an expected type, submit a bug report. (Note that constraint
> >> synonyms are particularly hard to preserve!)
> >>
> >> It would be very easy to report both the synonym-preserving form and the
> >> expanded form in an error report, at the cost of making error reports
> even
> >> more verbose. You're welcome to submit a feature request, and this would
> >> likely make a good first patch to GHC if you want to get your hands
> dirty.
> >> I'd personally prefer the feature to be protected behind a flag (to
> avoid
> >> seeing that `String` expands to `[Char]` everywhere, for example), but
> >> others may feel differently here.
> >>
> >> Richard
> >>
> >> On Jun 16, 2015, at 11:20 AM, ?mer Sinan A?acan <omeragacan at gmail.com>
> >> wrote:
> >>
> >> > Hi all,
> >> >
> >> > While working with complex types with lots of arguments etc. errors
> are
> >> > becoming annoying very fast. For example, GHC prints errors in this
> way:
> >> >
> >> >    Expected type: <type without any synonyms>
> >> >      Actual type: <type with synonyms>
> >> >
> >> > Now I have to expand that synonym in my head to understand the error.
> >> >
> >> > I was wondering if implementing something like this is possible:
> >> >
> >> > In type error messages, GHC also prints types that are cleaned from
> type
> >> > synonyms. Maybe something like this:
> >> >
> >> >         Expected type: <type1>
> >> >    (without synonyms): <type1, synonyms are expanded>
> >> >           Actual type: <type2>
> >> >    (without synonyms): <type2, synonyms are expanded>
> >> >
> >> > If this is not always desirable for some reason, we can hide this
> >> > behavior
> >> > behind a flag.
> >> >
> >> > What do GHC devs think about this? Is this, in theory, possible to do?
> >> > How hard
> >> > would it be to implement this?
> >> >
> >> > Thanks.
> >> > _______________________________________________
> >> > ghc-devs mailing list
> >> > ghc-devs at haskell.org
> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
>
>
> --
>
> Chris Allen
>
> Currently working on http://haskellbook.com
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150619/9362fc50/attachment-0001.html>

From omeragacan at gmail.com  Fri Jun 19 13:07:09 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Fri, 19 Jun 2015 09:07:09 -0400
Subject: expanding type synonyms in error messages
In-Reply-To: <CAAbahfTxk-Qt4+MLZjhbRY=okGL0PmcVDc2gAjk9P9o5QoPe2g@mail.gmail.com>
References: <CAMQQO3=i2-38x5hDAUyww_x=08GJ7c2Yi3HJLFAQvfqO=qEc9g@mail.gmail.com>
 <DA74706D-FA4C-4AEA-B3CC-61718109F15D@cis.upenn.edu>
 <CAAbahfTuSx6EXN2=PCq=S7a2_4XbKvqhEh2oeHoYGJgS8T9s=w@mail.gmail.com>
 <CAMQQO3kOosf1NJVQs8pctjKB2_cGoC2G2PWDUz6nwODmq6MfVw@mail.gmail.com>
 <CADnndOr5Bzzv2LV6hC=eRYv3ZzPaEDTwSwUk0TweSqgoH8o8mg@mail.gmail.com>
 <15b9703055c74bd28aca095ab9d80ea6@DB4PR30MB030.064d.mgd.msft.net>
 <CAAbahfTxk-Qt4+MLZjhbRY=okGL0PmcVDc2gAjk9P9o5QoPe2g@mail.gmail.com>
Message-ID: <CAMQQO3kgheBi17rY+wYOKf4k3xe5DpVUHKOgX8-SfmZHCy7Wsg@mail.gmail.com>

Great, thanks Kostiantyn! I'm looking for simple examples that we can
add to GHC testsuite, if I find something I'll update the wiki page
also.

I made some progress on the patch, I think I can hopefully submit
something this weekend for reviews.

2015-06-19 5:16 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
> Created some initial wiki-page with just one example, will keep it in mind
> to add more as seen.
>
> https://wiki.haskell.org/Expanding_type_synonyms_in_error_messages_proposal
>
> On Fri, Jun 19, 2015 at 10:42 AM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>>
>> On this thread, a representative collection of *reproducible examples*
>> with the actual error message and the desired one, would be tremendously
>> helpful.  Lacking that, it?s hard to know where to begin.   (Creating the
>> examples takes a bit of work, I know.)
>>
>>
>>
>> Start a wiki page!  Stuff in email threads gets lost
>>
>>
>>
>> Simon
>>
>>
>>
>> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
>> Christopher Allen
>> Sent: 19 June 2015 04:27
>> To: ?mer Sinan A?acan
>> Cc: ghc-devs
>> Subject: Re: expanding type synonyms in error messages
>>
>>
>>
>> Just to add my own +1, having this when working with streaming libraries
>> (I've needed it less with lens, oddly) would be a tremendous help for people
>> learning them I think. I think I've run into the same thing as Kostiantyn in
>> the past.
>>
>>
>>
>> On Thu, Jun 18, 2015 at 9:42 PM, ?mer Sinan A?acan <omeragacan at gmail.com>
>> wrote:
>>
>> It's good to see that I'm not the only one who wants this. I'm doing
>> some GHC hacking nowadays and I'll give it a try.
>>
>>
>> 2015-06-18 4:41 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
>> > I wanted to add that synonym expansion would be especially helpful in
>> > error-messages like:
>> >
>> > Expected type: <non-expanded, small type, like "Producer a m ()">
>> > Actual type: <your type, like "Proxy a a' b b' m v">
>> >
>> > I would be glad if we could have an expansions enabling flag in GHC, and
>> > could consider turning it on by default if it will look good for that.
>> >
>> > 16 ????. 2015 22:44 "Richard Eisenberg" <eir at cis.upenn.edu> ????:
>> >
>> >> GHC tries hard to preserve type synonyms where possible, but of course,
>> >> it
>> >> can't preserve all of them. The general rule it tries to follow is:
>> >> preserve
>> >> vanilla type synonyms; expand type families. This is true both in
>> >> expected
>> >> types and actual types.
>> >> If you have a case where you believe that GHC could preserve a type
>> >> synonym in an expected type, submit a bug report. (Note that constraint
>> >> synonyms are particularly hard to preserve!)
>> >>
>> >> It would be very easy to report both the synonym-preserving form and
>> >> the
>> >> expanded form in an error report, at the cost of making error reports
>> >> even
>> >> more verbose. You're welcome to submit a feature request, and this
>> >> would
>> >> likely make a good first patch to GHC if you want to get your hands
>> >> dirty.
>> >> I'd personally prefer the feature to be protected behind a flag (to
>> >> avoid
>> >> seeing that `String` expands to `[Char]` everywhere, for example), but
>> >> others may feel differently here.
>> >>
>> >> Richard
>> >>
>> >> On Jun 16, 2015, at 11:20 AM, ?mer Sinan A?acan <omeragacan at gmail.com>
>> >> wrote:
>> >>
>> >> > Hi all,
>> >> >
>> >> > While working with complex types with lots of arguments etc. errors
>> >> > are
>> >> > becoming annoying very fast. For example, GHC prints errors in this
>> >> > way:
>> >> >
>> >> >    Expected type: <type without any synonyms>
>> >> >      Actual type: <type with synonyms>
>> >> >
>> >> > Now I have to expand that synonym in my head to understand the error.
>> >> >
>> >> > I was wondering if implementing something like this is possible:
>> >> >
>> >> > In type error messages, GHC also prints types that are cleaned from
>> >> > type
>> >> > synonyms. Maybe something like this:
>> >> >
>> >> >         Expected type: <type1>
>> >> >    (without synonyms): <type1, synonyms are expanded>
>> >> >           Actual type: <type2>
>> >> >    (without synonyms): <type2, synonyms are expanded>
>> >> >
>> >> > If this is not always desirable for some reason, we can hide this
>> >> > behavior
>> >> > behind a flag.
>> >> >
>> >> > What do GHC devs think about this? Is this, in theory, possible to
>> >> > do?
>> >> > How hard
>> >> > would it be to implement this?
>> >> >
>> >> > Thanks.
>> >> > _______________________________________________
>> >> > ghc-devs mailing list
>> >> > ghc-devs at haskell.org
>> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >>
>> >> _______________________________________________
>> >> ghc-devs mailing list
>> >> ghc-devs at haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>>
>>
>>
>> --
>>
>> Chris Allen
>>
>> Currently working on http://haskellbook.com
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>

From eir at cis.upenn.edu  Fri Jun 19 13:12:34 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 19 Jun 2015 09:12:34 -0400
Subject: expanding type synonyms in error messages
In-Reply-To: <CAMQQO3kgheBi17rY+wYOKf4k3xe5DpVUHKOgX8-SfmZHCy7Wsg@mail.gmail.com>
References: <CAMQQO3=i2-38x5hDAUyww_x=08GJ7c2Yi3HJLFAQvfqO=qEc9g@mail.gmail.com>
 <DA74706D-FA4C-4AEA-B3CC-61718109F15D@cis.upenn.edu>
 <CAAbahfTuSx6EXN2=PCq=S7a2_4XbKvqhEh2oeHoYGJgS8T9s=w@mail.gmail.com>
 <CAMQQO3kOosf1NJVQs8pctjKB2_cGoC2G2PWDUz6nwODmq6MfVw@mail.gmail.com>
 <CADnndOr5Bzzv2LV6hC=eRYv3ZzPaEDTwSwUk0TweSqgoH8o8mg@mail.gmail.com>
 <15b9703055c74bd28aca095ab9d80ea6@DB4PR30MB030.064d.mgd.msft.net>
 <CAAbahfTxk-Qt4+MLZjhbRY=okGL0PmcVDc2gAjk9P9o5QoPe2g@mail.gmail.com>
 <CAMQQO3kgheBi17rY+wYOKf4k3xe5DpVUHKOgX8-SfmZHCy7Wsg@mail.gmail.com>
Message-ID: <7B42ECD0-1B1B-4F9B-AE4F-E156E75C4AF4@cis.upenn.edu>

Don't forget to make a Feature Request on Trac (https://ghc.haskell.org/trac/ghc/newticket) with a link to the wiki page. Trac is really the only way things like this don't get lost.

Thanks!

Richard


On Jun 19, 2015, at 9:07 AM, ?mer Sinan A?acan <omeragacan at gmail.com> wrote:

> Great, thanks Kostiantyn! I'm looking for simple examples that we can
> add to GHC testsuite, if I find something I'll update the wiki page
> also.
> 
> I made some progress on the patch, I think I can hopefully submit
> something this weekend for reviews.
> 
> 2015-06-19 5:16 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
>> Created some initial wiki-page with just one example, will keep it in mind
>> to add more as seen.
>> 
>> https://wiki.haskell.org/Expanding_type_synonyms_in_error_messages_proposal
>> 
>> On Fri, Jun 19, 2015 at 10:42 AM, Simon Peyton Jones <simonpj at microsoft.com>
>> wrote:
>>> 
>>> On this thread, a representative collection of *reproducible examples*
>>> with the actual error message and the desired one, would be tremendously
>>> helpful.  Lacking that, it?s hard to know where to begin.   (Creating the
>>> examples takes a bit of work, I know.)
>>> 
>>> 
>>> 
>>> Start a wiki page!  Stuff in email threads gets lost
>>> 
>>> 
>>> 
>>> Simon
>>> 
>>> 
>>> 
>>> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
>>> Christopher Allen
>>> Sent: 19 June 2015 04:27
>>> To: ?mer Sinan A?acan
>>> Cc: ghc-devs
>>> Subject: Re: expanding type synonyms in error messages
>>> 
>>> 
>>> 
>>> Just to add my own +1, having this when working with streaming libraries
>>> (I've needed it less with lens, oddly) would be a tremendous help for people
>>> learning them I think. I think I've run into the same thing as Kostiantyn in
>>> the past.
>>> 
>>> 
>>> 
>>> On Thu, Jun 18, 2015 at 9:42 PM, ?mer Sinan A?acan <omeragacan at gmail.com>
>>> wrote:
>>> 
>>> It's good to see that I'm not the only one who wants this. I'm doing
>>> some GHC hacking nowadays and I'll give it a try.
>>> 
>>> 
>>> 2015-06-18 4:41 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
>>>> I wanted to add that synonym expansion would be especially helpful in
>>>> error-messages like:
>>>> 
>>>> Expected type: <non-expanded, small type, like "Producer a m ()">
>>>> Actual type: <your type, like "Proxy a a' b b' m v">
>>>> 
>>>> I would be glad if we could have an expansions enabling flag in GHC, and
>>>> could consider turning it on by default if it will look good for that.
>>>> 
>>>> 16 ????. 2015 22:44 "Richard Eisenberg" <eir at cis.upenn.edu> ????:
>>>> 
>>>>> GHC tries hard to preserve type synonyms where possible, but of course,
>>>>> it
>>>>> can't preserve all of them. The general rule it tries to follow is:
>>>>> preserve
>>>>> vanilla type synonyms; expand type families. This is true both in
>>>>> expected
>>>>> types and actual types.
>>>>> If you have a case where you believe that GHC could preserve a type
>>>>> synonym in an expected type, submit a bug report. (Note that constraint
>>>>> synonyms are particularly hard to preserve!)
>>>>> 
>>>>> It would be very easy to report both the synonym-preserving form and
>>>>> the
>>>>> expanded form in an error report, at the cost of making error reports
>>>>> even
>>>>> more verbose. You're welcome to submit a feature request, and this
>>>>> would
>>>>> likely make a good first patch to GHC if you want to get your hands
>>>>> dirty.
>>>>> I'd personally prefer the feature to be protected behind a flag (to
>>>>> avoid
>>>>> seeing that `String` expands to `[Char]` everywhere, for example), but
>>>>> others may feel differently here.
>>>>> 
>>>>> Richard
>>>>> 
>>>>> On Jun 16, 2015, at 11:20 AM, ?mer Sinan A?acan <omeragacan at gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> While working with complex types with lots of arguments etc. errors
>>>>>> are
>>>>>> becoming annoying very fast. For example, GHC prints errors in this
>>>>>> way:
>>>>>> 
>>>>>>   Expected type: <type without any synonyms>
>>>>>>     Actual type: <type with synonyms>
>>>>>> 
>>>>>> Now I have to expand that synonym in my head to understand the error.
>>>>>> 
>>>>>> I was wondering if implementing something like this is possible:
>>>>>> 
>>>>>> In type error messages, GHC also prints types that are cleaned from
>>>>>> type
>>>>>> synonyms. Maybe something like this:
>>>>>> 
>>>>>>        Expected type: <type1>
>>>>>>   (without synonyms): <type1, synonyms are expanded>
>>>>>>          Actual type: <type2>
>>>>>>   (without synonyms): <type2, synonyms are expanded>
>>>>>> 
>>>>>> If this is not always desirable for some reason, we can hide this
>>>>>> behavior
>>>>>> behind a flag.
>>>>>> 
>>>>>> What do GHC devs think about this? Is this, in theory, possible to
>>>>>> do?
>>>>>> How hard
>>>>>> would it be to implement this?
>>>>>> 
>>>>>> Thanks.
>>>>>> _______________________________________________
>>>>>> ghc-devs mailing list
>>>>>> ghc-devs at haskell.org
>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>> 
>>>>> _______________________________________________
>>>>> ghc-devs mailing list
>>>>> ghc-devs at haskell.org
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> 
>>> Chris Allen
>>> 
>>> Currently working on http://haskellbook.com
>>> 
>>> 
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> 
>> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 


From omeragacan at gmail.com  Fri Jun 19 13:18:47 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Fri, 19 Jun 2015 09:18:47 -0400
Subject: expanding type synonyms in error messages
In-Reply-To: <7B42ECD0-1B1B-4F9B-AE4F-E156E75C4AF4@cis.upenn.edu>
References: <CAMQQO3=i2-38x5hDAUyww_x=08GJ7c2Yi3HJLFAQvfqO=qEc9g@mail.gmail.com>
 <DA74706D-FA4C-4AEA-B3CC-61718109F15D@cis.upenn.edu>
 <CAAbahfTuSx6EXN2=PCq=S7a2_4XbKvqhEh2oeHoYGJgS8T9s=w@mail.gmail.com>
 <CAMQQO3kOosf1NJVQs8pctjKB2_cGoC2G2PWDUz6nwODmq6MfVw@mail.gmail.com>
 <CADnndOr5Bzzv2LV6hC=eRYv3ZzPaEDTwSwUk0TweSqgoH8o8mg@mail.gmail.com>
 <15b9703055c74bd28aca095ab9d80ea6@DB4PR30MB030.064d.mgd.msft.net>
 <CAAbahfTxk-Qt4+MLZjhbRY=okGL0PmcVDc2gAjk9P9o5QoPe2g@mail.gmail.com>
 <CAMQQO3kgheBi17rY+wYOKf4k3xe5DpVUHKOgX8-SfmZHCy7Wsg@mail.gmail.com>
 <7B42ECD0-1B1B-4F9B-AE4F-E156E75C4AF4@cis.upenn.edu>
Message-ID: <CAMQQO3mB1_Ev9xL+xTCrvt1J+wwnKUq1SL29Xo3AGR59CVAtEQ@mail.gmail.com>

Done: https://ghc.haskell.org/trac/ghc/ticket/10547

2015-06-19 9:12 GMT-04:00 Richard Eisenberg <eir at cis.upenn.edu>:
> Don't forget to make a Feature Request on Trac (https://ghc.haskell.org/trac/ghc/newticket) with a link to the wiki page. Trac is really the only way things like this don't get lost.
>
> Thanks!
>
> Richard
>
>
> On Jun 19, 2015, at 9:07 AM, ?mer Sinan A?acan <omeragacan at gmail.com> wrote:
>
>> Great, thanks Kostiantyn! I'm looking for simple examples that we can
>> add to GHC testsuite, if I find something I'll update the wiki page
>> also.
>>
>> I made some progress on the patch, I think I can hopefully submit
>> something this weekend for reviews.
>>
>> 2015-06-19 5:16 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
>>> Created some initial wiki-page with just one example, will keep it in mind
>>> to add more as seen.
>>>
>>> https://wiki.haskell.org/Expanding_type_synonyms_in_error_messages_proposal
>>>
>>> On Fri, Jun 19, 2015 at 10:42 AM, Simon Peyton Jones <simonpj at microsoft.com>
>>> wrote:
>>>>
>>>> On this thread, a representative collection of *reproducible examples*
>>>> with the actual error message and the desired one, would be tremendously
>>>> helpful.  Lacking that, it?s hard to know where to begin.   (Creating the
>>>> examples takes a bit of work, I know.)
>>>>
>>>>
>>>>
>>>> Start a wiki page!  Stuff in email threads gets lost
>>>>
>>>>
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
>>>> Christopher Allen
>>>> Sent: 19 June 2015 04:27
>>>> To: ?mer Sinan A?acan
>>>> Cc: ghc-devs
>>>> Subject: Re: expanding type synonyms in error messages
>>>>
>>>>
>>>>
>>>> Just to add my own +1, having this when working with streaming libraries
>>>> (I've needed it less with lens, oddly) would be a tremendous help for people
>>>> learning them I think. I think I've run into the same thing as Kostiantyn in
>>>> the past.
>>>>
>>>>
>>>>
>>>> On Thu, Jun 18, 2015 at 9:42 PM, ?mer Sinan A?acan <omeragacan at gmail.com>
>>>> wrote:
>>>>
>>>> It's good to see that I'm not the only one who wants this. I'm doing
>>>> some GHC hacking nowadays and I'll give it a try.
>>>>
>>>>
>>>> 2015-06-18 4:41 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
>>>>> I wanted to add that synonym expansion would be especially helpful in
>>>>> error-messages like:
>>>>>
>>>>> Expected type: <non-expanded, small type, like "Producer a m ()">
>>>>> Actual type: <your type, like "Proxy a a' b b' m v">
>>>>>
>>>>> I would be glad if we could have an expansions enabling flag in GHC, and
>>>>> could consider turning it on by default if it will look good for that.
>>>>>
>>>>> 16 ????. 2015 22:44 "Richard Eisenberg" <eir at cis.upenn.edu> ????:
>>>>>
>>>>>> GHC tries hard to preserve type synonyms where possible, but of course,
>>>>>> it
>>>>>> can't preserve all of them. The general rule it tries to follow is:
>>>>>> preserve
>>>>>> vanilla type synonyms; expand type families. This is true both in
>>>>>> expected
>>>>>> types and actual types.
>>>>>> If you have a case where you believe that GHC could preserve a type
>>>>>> synonym in an expected type, submit a bug report. (Note that constraint
>>>>>> synonyms are particularly hard to preserve!)
>>>>>>
>>>>>> It would be very easy to report both the synonym-preserving form and
>>>>>> the
>>>>>> expanded form in an error report, at the cost of making error reports
>>>>>> even
>>>>>> more verbose. You're welcome to submit a feature request, and this
>>>>>> would
>>>>>> likely make a good first patch to GHC if you want to get your hands
>>>>>> dirty.
>>>>>> I'd personally prefer the feature to be protected behind a flag (to
>>>>>> avoid
>>>>>> seeing that `String` expands to `[Char]` everywhere, for example), but
>>>>>> others may feel differently here.
>>>>>>
>>>>>> Richard
>>>>>>
>>>>>> On Jun 16, 2015, at 11:20 AM, ?mer Sinan A?acan <omeragacan at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> While working with complex types with lots of arguments etc. errors
>>>>>>> are
>>>>>>> becoming annoying very fast. For example, GHC prints errors in this
>>>>>>> way:
>>>>>>>
>>>>>>>   Expected type: <type without any synonyms>
>>>>>>>     Actual type: <type with synonyms>
>>>>>>>
>>>>>>> Now I have to expand that synonym in my head to understand the error.
>>>>>>>
>>>>>>> I was wondering if implementing something like this is possible:
>>>>>>>
>>>>>>> In type error messages, GHC also prints types that are cleaned from
>>>>>>> type
>>>>>>> synonyms. Maybe something like this:
>>>>>>>
>>>>>>>        Expected type: <type1>
>>>>>>>   (without synonyms): <type1, synonyms are expanded>
>>>>>>>          Actual type: <type2>
>>>>>>>   (without synonyms): <type2, synonyms are expanded>
>>>>>>>
>>>>>>> If this is not always desirable for some reason, we can hide this
>>>>>>> behavior
>>>>>>> behind a flag.
>>>>>>>
>>>>>>> What do GHC devs think about this? Is this, in theory, possible to
>>>>>>> do?
>>>>>>> How hard
>>>>>>> would it be to implement this?
>>>>>>>
>>>>>>> Thanks.
>>>>>>> _______________________________________________
>>>>>>> ghc-devs mailing list
>>>>>>> ghc-devs at haskell.org
>>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>>>
>>>>>> _______________________________________________
>>>>>> ghc-devs mailing list
>>>>>> ghc-devs at haskell.org
>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Chris Allen
>>>>
>>>> Currently working on http://haskellbook.com
>>>>
>>>>
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>
>>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>

From k-bx at k-bx.com  Fri Jun 19 14:13:34 2015
From: k-bx at k-bx.com (Kostiantyn Rybnikov)
Date: Fri, 19 Jun 2015 17:13:34 +0300
Subject: expanding type synonyms in error messages
In-Reply-To: <CAMQQO3mB1_Ev9xL+xTCrvt1J+wwnKUq1SL29Xo3AGR59CVAtEQ@mail.gmail.com>
References: <CAMQQO3=i2-38x5hDAUyww_x=08GJ7c2Yi3HJLFAQvfqO=qEc9g@mail.gmail.com>
 <DA74706D-FA4C-4AEA-B3CC-61718109F15D@cis.upenn.edu>
 <CAAbahfTuSx6EXN2=PCq=S7a2_4XbKvqhEh2oeHoYGJgS8T9s=w@mail.gmail.com>
 <CAMQQO3kOosf1NJVQs8pctjKB2_cGoC2G2PWDUz6nwODmq6MfVw@mail.gmail.com>
 <CADnndOr5Bzzv2LV6hC=eRYv3ZzPaEDTwSwUk0TweSqgoH8o8mg@mail.gmail.com>
 <15b9703055c74bd28aca095ab9d80ea6@DB4PR30MB030.064d.mgd.msft.net>
 <CAAbahfTxk-Qt4+MLZjhbRY=okGL0PmcVDc2gAjk9P9o5QoPe2g@mail.gmail.com>
 <CAMQQO3kgheBi17rY+wYOKf4k3xe5DpVUHKOgX8-SfmZHCy7Wsg@mail.gmail.com>
 <7B42ECD0-1B1B-4F9B-AE4F-E156E75C4AF4@cis.upenn.edu>
 <CAMQQO3mB1_Ev9xL+xTCrvt1J+wwnKUq1SL29Xo3AGR59CVAtEQ@mail.gmail.com>
Message-ID: <CAAbahfT3mDag5Rm5p+K02CA491Of6ySD4cJgA4fuCh-iuQ=WBg@mail.gmail.com>

Great, thanks for doing this! I'm afraid even if you succeed with patch we
would still need more "real-world examples" that show the need for this
feature, and I think this is separate from GHC tests, as they don't need to
be realistic, but of course please continue and hopefully more examples
will come.
19 ????. 2015 16:19 "?mer Sinan A?acan" <omeragacan at gmail.com> ????:

> Done: https://ghc.haskell.org/trac/ghc/ticket/10547
>
> 2015-06-19 9:12 GMT-04:00 Richard Eisenberg <eir at cis.upenn.edu>:
> > Don't forget to make a Feature Request on Trac (
> https://ghc.haskell.org/trac/ghc/newticket) with a link to the wiki page.
> Trac is really the only way things like this don't get lost.
> >
> > Thanks!
> >
> > Richard
> >
> >
> > On Jun 19, 2015, at 9:07 AM, ?mer Sinan A?acan <omeragacan at gmail.com>
> wrote:
> >
> >> Great, thanks Kostiantyn! I'm looking for simple examples that we can
> >> add to GHC testsuite, if I find something I'll update the wiki page
> >> also.
> >>
> >> I made some progress on the patch, I think I can hopefully submit
> >> something this weekend for reviews.
> >>
> >> 2015-06-19 5:16 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
> >>> Created some initial wiki-page with just one example, will keep it in
> mind
> >>> to add more as seen.
> >>>
> >>>
> https://wiki.haskell.org/Expanding_type_synonyms_in_error_messages_proposal
> >>>
> >>> On Fri, Jun 19, 2015 at 10:42 AM, Simon Peyton Jones <
> simonpj at microsoft.com>
> >>> wrote:
> >>>>
> >>>> On this thread, a representative collection of *reproducible examples*
> >>>> with the actual error message and the desired one, would be
> tremendously
> >>>> helpful.  Lacking that, it?s hard to know where to begin.   (Creating
> the
> >>>> examples takes a bit of work, I know.)
> >>>>
> >>>>
> >>>>
> >>>> Start a wiki page!  Stuff in email threads gets lost
> >>>>
> >>>>
> >>>>
> >>>> Simon
> >>>>
> >>>>
> >>>>
> >>>> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> >>>> Christopher Allen
> >>>> Sent: 19 June 2015 04:27
> >>>> To: ?mer Sinan A?acan
> >>>> Cc: ghc-devs
> >>>> Subject: Re: expanding type synonyms in error messages
> >>>>
> >>>>
> >>>>
> >>>> Just to add my own +1, having this when working with streaming
> libraries
> >>>> (I've needed it less with lens, oddly) would be a tremendous help for
> people
> >>>> learning them I think. I think I've run into the same thing as
> Kostiantyn in
> >>>> the past.
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Jun 18, 2015 at 9:42 PM, ?mer Sinan A?acan <
> omeragacan at gmail.com>
> >>>> wrote:
> >>>>
> >>>> It's good to see that I'm not the only one who wants this. I'm doing
> >>>> some GHC hacking nowadays and I'll give it a try.
> >>>>
> >>>>
> >>>> 2015-06-18 4:41 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
> >>>>> I wanted to add that synonym expansion would be especially helpful in
> >>>>> error-messages like:
> >>>>>
> >>>>> Expected type: <non-expanded, small type, like "Producer a m ()">
> >>>>> Actual type: <your type, like "Proxy a a' b b' m v">
> >>>>>
> >>>>> I would be glad if we could have an expansions enabling flag in GHC,
> and
> >>>>> could consider turning it on by default if it will look good for
> that.
> >>>>>
> >>>>> 16 ????. 2015 22:44 "Richard Eisenberg" <eir at cis.upenn.edu> ????:
> >>>>>
> >>>>>> GHC tries hard to preserve type synonyms where possible, but of
> course,
> >>>>>> it
> >>>>>> can't preserve all of them. The general rule it tries to follow is:
> >>>>>> preserve
> >>>>>> vanilla type synonyms; expand type families. This is true both in
> >>>>>> expected
> >>>>>> types and actual types.
> >>>>>> If you have a case where you believe that GHC could preserve a type
> >>>>>> synonym in an expected type, submit a bug report. (Note that
> constraint
> >>>>>> synonyms are particularly hard to preserve!)
> >>>>>>
> >>>>>> It would be very easy to report both the synonym-preserving form and
> >>>>>> the
> >>>>>> expanded form in an error report, at the cost of making error
> reports
> >>>>>> even
> >>>>>> more verbose. You're welcome to submit a feature request, and this
> >>>>>> would
> >>>>>> likely make a good first patch to GHC if you want to get your hands
> >>>>>> dirty.
> >>>>>> I'd personally prefer the feature to be protected behind a flag (to
> >>>>>> avoid
> >>>>>> seeing that `String` expands to `[Char]` everywhere, for example),
> but
> >>>>>> others may feel differently here.
> >>>>>>
> >>>>>> Richard
> >>>>>>
> >>>>>> On Jun 16, 2015, at 11:20 AM, ?mer Sinan A?acan <
> omeragacan at gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> While working with complex types with lots of arguments etc. errors
> >>>>>>> are
> >>>>>>> becoming annoying very fast. For example, GHC prints errors in this
> >>>>>>> way:
> >>>>>>>
> >>>>>>>   Expected type: <type without any synonyms>
> >>>>>>>     Actual type: <type with synonyms>
> >>>>>>>
> >>>>>>> Now I have to expand that synonym in my head to understand the
> error.
> >>>>>>>
> >>>>>>> I was wondering if implementing something like this is possible:
> >>>>>>>
> >>>>>>> In type error messages, GHC also prints types that are cleaned from
> >>>>>>> type
> >>>>>>> synonyms. Maybe something like this:
> >>>>>>>
> >>>>>>>        Expected type: <type1>
> >>>>>>>   (without synonyms): <type1, synonyms are expanded>
> >>>>>>>          Actual type: <type2>
> >>>>>>>   (without synonyms): <type2, synonyms are expanded>
> >>>>>>>
> >>>>>>> If this is not always desirable for some reason, we can hide this
> >>>>>>> behavior
> >>>>>>> behind a flag.
> >>>>>>>
> >>>>>>> What do GHC devs think about this? Is this, in theory, possible to
> >>>>>>> do?
> >>>>>>> How hard
> >>>>>>> would it be to implement this?
> >>>>>>>
> >>>>>>> Thanks.
> >>>>>>> _______________________________________________
> >>>>>>> ghc-devs mailing list
> >>>>>>> ghc-devs at haskell.org
> >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> ghc-devs mailing list
> >>>>>> ghc-devs at haskell.org
> >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>>> _______________________________________________
> >>>> ghc-devs mailing list
> >>>> ghc-devs at haskell.org
> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Chris Allen
> >>>>
> >>>> Currently working on http://haskellbook.com
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> ghc-devs mailing list
> >>>> ghc-devs at haskell.org
> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>>>
> >>>
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150619/213ae384/attachment-0001.html>

From austin at well-typed.com  Fri Jun 19 17:30:06 2015
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 19 Jun 2015 12:30:06 -0500
Subject: [Diffusion] [Build Failed] rGHCc45f8ceb0de0: Elaborate test for
 Trac #10403
In-Reply-To: <f13da01e6d10447889e1bc0a5b7c137a@DB4PR30MB030.064d.mgd.msft.net>
References: <diffusion-audit-PHID-CMIT-e5tvrbc7xbgwksabzz2n@phabricator.haskell.org>
 <20150618230844.24108.1501@phabricator.haskell.org>
 <f13da01e6d10447889e1bc0a5b7c137a@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAEs96n1P5_iDUP8OW9mmUO+GPcWf8x=1SDzC-Eb-qjRZZ9T7SA@mail.gmail.com>

Strange stuff. I just pushed this, so the builds should start going
green again soon.

On Fri, Jun 19, 2015 at 2:39 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> I think 4945 is failing again -- although not on my machine.  Can someone mark it expect_broken again?  I'm on a train
>
> S
>
> | -----Original Message-----
> | From: noreply at phabricator.haskell.org
> | [mailto:noreply at phabricator.haskell.org]
> | Sent: 19 June 2015 00:09
> | To: Simon Peyton Jones
> | Subject: [Diffusion] [Build Failed] rGHCc45f8ceb0de0: Elaborate test for
> | Trac #10403
> |
> | Harbormaster failed to build B4473: rGHCc45f8ceb0de0: Elaborate test for
> | Trac #10403!
> |
> | BRANCHES
> |   master
> |
> | USERS
> |   simonpj (Author)
> |   GHC - Testsuite (Auditor)
> |
> | COMMIT
> |   https://phabricator.haskell.org/rGHCc45f8ceb0de0
> |
> | EMAIL PREFERENCES
> |   https://phabricator.haskell.org/settings/panel/emailpreferences/
> |
> | To: simonpj, GHC - Testsuite
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Regards,

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

From marlowsd at gmail.com  Fri Jun 19 18:48:48 2015
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 19 Jun 2015 19:48:48 +0100
Subject: Native -XCPP Conclusion
In-Reply-To: <87oakdo1ru.fsf@gmail.com>
References: <87zj5i55gs.fsf@gmail.com> <87oakdo1ru.fsf@gmail.com>
Message-ID: <55846410.2060209@gmail.com>

I have no problem with plan 4.  However, I'll point out that 
implementing CPP is not *that* hard... :)

Cheers,
Simon

On 18/06/2015 09:32, Herbert Valerio Riedel wrote:
> Hello *,
>
> Following up on the "Native -XCPP" Proposal discussion, it appears that
> cpphs' current LGPL+SLE licensing doesn't pose an *objective*
> showstopper problem but is rather more of an inconvenience as it causes
> argumentation/discussion overhead (which then /may/ actually result in
> Haskell being turned down eventually over alternatives that do without
> LGPL components).
>
> In order to acknowledge this discomfort, for GHC 7.12 we propose to follow
> "plan 4" according to [1] (i.e. calling out to a cpphs-executable as a
> separate process), thereby avoiding pulling any LGPL-subjected cpphs
> code into produced executables when linking against the 'ghc' package.
>
> "Plan 2" (i.e. embedding/linking cpphs' code directly into ghc) would
> reduce fork/exec overhead, which can be substantial on Windows [2],
> but plan 4 is no worse than what we have now.
>
> Last Call: Are there any objections with GHC adopting "plan 4"[1]?
>
>   [1]: <https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp>
>
>   [2]: <http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/8869>
>
> Thanks,
>    HVR
>
> On 2015-05-06 at 13:08:03 +0200, Herbert Valerio Riedel wrote:
>> Hello *,
>>
>> As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
>> currently relies on the system's C-compiler bundled `cpp` program to
>> provide a "traditional mode" c-preprocessor.
>>
>> This has caused several problems in the past, since parsing Haskell code
>> with a preprocessor mode designed for use with C's tokenizer has caused
>> already quite some problems[1] in the past. I'd like to see GHC 7.12
>> adopt an implemntation of `-XCPP` that does not rely on the shaky
>> system-`cpp` foundation. To this end I've created a wiki page
>>
>>    https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp
>>
>> to describe the actual problems in more detail, and a couple of possible
>> ways forward. Ideally, we'd simply integrate `cpphs` into GHC
>> (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be
>> discussed and debated since affects the overall-license of the GHC
>> code-base, which may or may not be a problem to GHC's user-base (and
>> that's what I hope this discussion will help to find out).
>>
>> So please go ahead and read the Wiki page... and then speak your mind!
>>
>>
>> Thanks,
>>    HVR
>>
>>
>> [1]: ...does anybody remember the issues Haskell packages (& GHC)
>>       encountered when Apple switched to the Clang tool-chain, thereby
>>       causing code using `-XCPP` to suddenly break due to subtly
>>       different `cpp`-semantics?
>

From george.colpitts at gmail.com  Sat Jun 20 17:47:41 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Sat, 20 Jun 2015 14:47:41 -0300
Subject: [GHC] #10491: Regression, simplifier explosion with Accelerate,
 cannot compile, increasing tick factor is not a workaround
In-Reply-To: <062.b959100b53d774afb1512a073ab02037@haskell.org>
References: <047.c2033819512d1e97c05e7e5c7544fd15@haskell.org>
 <062.b959100b53d774afb1512a073ab02037@haskell.org>
Message-ID: <CAB-d4A7xV8BsKUbPfb28jf08ArVBsa7C6SuDVRgLk1xu3DKLfw@mail.gmail.com>

7.10.1.20150612

It's very sensitive, I see today. Sometimes it fails with

Simplifier ticks exhausted

other times it works. Bizarre

I think the latter is the more common case and I think the former case has
something to do with existing .o file or order of args and -fforce-recomp
may mean it always works but that is very speculative.

The two casesor

$ time ghc -fno-specialise -O2 Slice.hs
[1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs,
Slice.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.1.20150612 for x86_64-apple-darwin):
    Simplifier ticks exhausted
  When trying UnfoldingDone $j_s1FS5
  To increase the limit, use -fsimpl-tick-factor=N (default 100)
  If you need to do this, let GHC HQ know, and what factor you needed
  To see detailed counts use -ddump-simpl-stats
  Total ticks: 1668604

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug


real    0m19.714s
user    0m18.264s
sys    0m0.875s

$ time ghc -O2 -fno-specialise Slice.hs
[1 of 1] Compiling Data.Array.Accelerate.CUDA.Array.Slice ( Slice.hs,
Slice.o )

real    0m3.228s
user    0m3.040s
sys    0m0.155s

On Sat, Jun 20, 2015 at 2:03 PM, GHC <ghc-devs at haskell.org> wrote:

> #10491: Regression, simplifier explosion with Accelerate, cannot compile,
> increasing tick factor is not a workaround
> -------------------------------------+-------------------------------------
>         Reporter:  robertce          |                   Owner:
>             Type:  bug               |                  Status:  new
>         Priority:  highest           |               Milestone:  7.10.2
>        Component:  Compiler          |                 Version:  7.10.1
>       Resolution:                    |                Keywords:
> Operating System:  Unknown/Multiple  |            Architecture:
>  Type of failure:  Compile-time      |  Unknown/Multiple
>   performance bug                    |               Test Case:
>       Blocked By:                    |                Blocking:
>  Related Tickets:                    |  Differential Revisions:
> -------------------------------------+-------------------------------------
>
> Comment (by bgamari):
>
>  George, what GHC version did you test `-fno-specialise` on? While
>  yesterday I was able to confirm that `-fno-specialise` seemed to make no
>  difference on a test machine running what should have been 7.10.1 I am now
>  having trouble replicating this on my laptop. Unfortunately I no longer
>  have access to the test environment on which I tested this yesterday but
>  clearly something was inconsistent.
>
>  I am now seeing on multiple machines that `-fno-specialise` indeed allows
>  things to compile,
>  {{{
>  $ ghc -V
>  The Glorious Glasgow Haskell Compilation System, version 7.10.1
>  $$ time ghc Slice.hs -fforce-recomp -O2 -fno-specialise
>  [1 of 1] Compiling Slice            ( Slice.hs, Slice.o )
>
>  real    0m3.759s
>  user    0m1.688s
>  sys     0m0.044s
>  $ time ghc Slice.hs -fforce-recomp -O2
>  [1 of 1] Compiling Slice            ( Slice.hs, Slice.o )
>  ^C
>
>  real    0m51.103s
>  user    0m44.336s
>  sys     0m0.948s
>  }}}
>
>  I am now looking at whether disabling only cross-module specialisation is
>  enough to eliminate the blow-up.
>
> --
> Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10491#comment:27>
> GHC <http://www.haskell.org/ghc/>
> The Glasgow Haskell Compiler
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150620/d0e63147/attachment.html>

From lonetiger at gmail.com  Sun Jun 21 15:17:28 2015
From: lonetiger at gmail.com (Tamar Christina)
Date: Sun, 21 Jun 2015 08:17:28 -0700
Subject: ANNOUNCE: GHC 7.10.2 Release Candidate 1
Message-ID: <1393432244581616983@unknownmsgid>

For the Windows users:

I have pushed GHC to the chocolatey package manager. You can find the
packages including this rc1 here https://chocolatey.org/packages/ghc

cinst ghc -pre

To install it.

The rest of the packages are still under moderation so until then you need
to specify the full version of the one you want.

Tamar

Sent from my Windows Phone
------------------------------
From: Mark Lentczner <mark.lentczner at gmail.com>
Sent: ?6/?15/?2015 21:02
To: ghc-devs at haskell.org; haskell-platform at projects.haskell.org
Subject: Re: ANNOUNCE: GHC 7.10.2 Release Candidate 1

And the Windows install for HP 7.10.2 RC1 is out too:
HaskellPlatform-7.10.1.20150612-x86_64-setup.exe
<http://www.ozonehouse.com/mark/platform/HaskellPlatform-7.10.1.20150612-x86_64-setup.exe>

08c5f2168bdf9147b548263d2b45e1db6b602830002f27bbbbf92bf066b761f0
HaskellPlatform-7.10.1.20150612-x86_64-setup.exe
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150621/45b42d82/attachment.html>

From simonpj at microsoft.com  Fri Jun 26 07:55:39 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 26 Jun 2015 07:55:39 +0000
Subject: Template Haskell working group
Message-ID: <5eeb3bd21e054ba58802012c9a5402d9@DB4PR30MB030.064d.mgd.msft.net>

Friends
I'm looking for someone, or a small group, to act as a Supreme Being for Template Haskell.  Might you be willing?
There is a steady trickle of bug reports / feature requests relating to Template Haskell, which I find that I simply don't have the time to pay proper attention to.  Here is a recent example http://ghc.haskell.org/trac/ghc/ticket/10572.   But if no one pays attention, they languish.
None of them is very hard, but all require a little careful thought.  What should the Template Haskell API be like?  What semantics do we want?
My hope is that if someone, or a small group, felt mandated to push TH forward, then we might make some progress.  At the moment I have the uneasy feeling that while everyone can make suggestions, it's all waiting for SPJ to decide something, and SPJ is not paying enough attention.  I don't want to be a bottleneck.  Moreover, since I'm not a heavy-duty TH user, I'm poorly placed to make design choices.
The reason I'm optimistic is because the steady trickle tells me that TH is in fact highly valued and widely used.  So perhaps among that group there are some people who would be willing to debate alternative designs, make choices, and implement them.
I would be more than willing to act as consultant, both on design and implementation.
GHC absolutely relies on its community.   Please consider making an offer to help.   Thanks!
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150626/f4140a7b/attachment.html>

From eir at cis.upenn.edu  Fri Jun 26 12:19:19 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 26 Jun 2015 08:19:19 -0400
Subject: Template Haskell working group
In-Reply-To: <5eeb3bd21e054ba58802012c9a5402d9@DB4PR30MB030.064d.mgd.msft.net>
References: <5eeb3bd21e054ba58802012c9a5402d9@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <E9CA5690-1D3E-41B9-BC6E-E60208E52955@cis.upenn.edu>

Hi Simon,

I'm happy to take this on. Through `singletons`, I am a heavy TH user and know that end of GHC well.

The one caveat I offer is that I vastly prefer to chunk up similar bits of work, and generally intend to let TH tickets languish until I sweep them all up, somewhere near the planned feature freeze. The plus side of this approach is that it gives oodles of time for new contributors to GHC to take a stab. As I've commented on Trac, TH is a fantastic way to introduce yourself to GHC hacking. Small enhancements to TH generally involve only a few files and have a predictable pattern.

So, do get involved! I'll help along the way.

In any case, I'll continue to monitor TH's overall evolution.

Richard

On Jun 26, 2015, at 3:55 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> Friends
> 
> I?m looking for someone, or a small group, to act as a Supreme Being for Template Haskell.  Might you be willing?
> 
> There is a steady trickle of bug reports / feature requests relating to Template Haskell, which I find that I simply don?t have the time to pay proper attention to.  Here is a recent example http://ghc.haskell.org/trac/ghc/ticket/10572.   But if no one pays attention, they languish.
> 
> None of them is very hard, but all require a little careful thought.  What should the Template Haskell API be like?  What semantics do we want?
> 
> My hope is that if someone, or a small group, felt mandated to push TH forward, then we might make some progress.  At the moment I have the uneasy feeling that while everyone can make suggestions, it?s all waiting for SPJ to decide something, and SPJ is not paying enough attention.  I don?t want to be a bottleneck.  Moreover, since I?m not a heavy-duty TH user, I?m poorly placed to make design choices.
> 
> The reason I?m optimistic is because the steady trickle tells me that TH is in fact highly valued and widely used.  So perhaps among that group there are some people who would be willing to debate alternative designs, make choices, and implement them.
> 
> I would be more than willing to act as consultant, both on design and implementation.
> 
> GHC absolutely relies on its community.   Please consider making an offer to help.   Thanks!
> 
> Simon
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150626/30257b11/attachment.html>

From simonpj at microsoft.com  Fri Jun 26 14:38:04 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 26 Jun 2015 14:38:04 +0000
Subject: Template Haskell working group
In-Reply-To: <E9CA5690-1D3E-41B9-BC6E-E60208E52955@cis.upenn.edu>
References: <5eeb3bd21e054ba58802012c9a5402d9@DB4PR30MB030.064d.mgd.msft.net>
 <E9CA5690-1D3E-41B9-BC6E-E60208E52955@cis.upenn.edu>
Message-ID: <7c5ae6cfdbad45ffac9785d1a462d6d5@DB4PR30MB030.064d.mgd.msft.net>

Thanks Richard, that's great.

How about starting  a Template Haskell status wiki page, along the lines of
https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.12.1


*         The lists of tickets on these status pages are auto-generated, so you could do the same to list open TH tickets.

*         Then in manual commentary at the top you can describe any plans, ideas, links to work in progress.

*         You can also identify yourself (and any other co-leaders) as someone to ask.

Anything to give someone a better place to start than "hunt through all the tickets".

You could link to the page from https://ghc.haskell.org/trac/ghc/wiki/Status

Simon


From: Richard Eisenberg [mailto:eir at cis.upenn.edu]
Sent: 26 June 2015 13:19
To: Simon Peyton Jones
Cc: ghc-devs
Subject: Re: Template Haskell working group

Hi Simon,

I'm happy to take this on. Through `singletons`, I am a heavy TH user and know that end of GHC well.

The one caveat I offer is that I vastly prefer to chunk up similar bits of work, and generally intend to let TH tickets languish until I sweep them all up, somewhere near the planned feature freeze. The plus side of this approach is that it gives oodles of time for new contributors to GHC to take a stab. As I've commented on Trac, TH is a fantastic way to introduce yourself to GHC hacking. Small enhancements to TH generally involve only a few files and have a predictable pattern.

So, do get involved! I'll help along the way.

In any case, I'll continue to monitor TH's overall evolution.

Richard

On Jun 26, 2015, at 3:55 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:


Friends
I'm looking for someone, or a small group, to act as a Supreme Being for Template Haskell.  Might you be willing?
There is a steady trickle of bug reports / feature requests relating to Template Haskell, which I find that I simply don't have the time to pay proper attention to.  Here is a recent example http://ghc.haskell.org/trac/ghc/ticket/10572.   But if no one pays attention, they languish.
None of them is very hard, but all require a little careful thought.  What should the Template Haskell API be like?  What semantics do we want?
My hope is that if someone, or a small group, felt mandated to push TH forward, then we might make some progress.  At the moment I have the uneasy feeling that while everyone can make suggestions, it's all waiting for SPJ to decide something, and SPJ is not paying enough attention.  I don't want to be a bottleneck.  Moreover, since I'm not a heavy-duty TH user, I'm poorly placed to make design choices.
The reason I'm optimistic is because the steady trickle tells me that TH is in fact highly valued and widely used.  So perhaps among that group there are some people who would be willing to debate alternative designs, make choices, and implement them.
I would be more than willing to act as consultant, both on design and implementation.
GHC absolutely relies on its community.   Please consider making an offer to help.   Thanks!
Simon
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150626/2aa90ef3/attachment-0001.html>

From hvr at gnu.org  Fri Jun 26 16:08:57 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Fri, 26 Jun 2015 18:08:57 +0200
Subject: Abstract FilePath Proposal
Message-ID: <874mlu8nae.fsf@gnu.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello *,

What?
=====

We (see From: & CC: headers) propose, plain and simple, to turn the
currently defined type-synonym

  type FilePath = String

into an abstract/opaque data type instead.

Why/How/When?
=============

For details (including motivation and a suggested transition scheme)
please consult

  https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath



Suggested discussion period: 4 weeks
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
HjIPRrJbVK9AABo4AZ/Y
=lg0o
-----END PGP SIGNATURE-----

From eir at cis.upenn.edu  Fri Jun 26 16:20:25 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 26 Jun 2015 12:20:25 -0400
Subject: Template Haskell working group
In-Reply-To: <7c5ae6cfdbad45ffac9785d1a462d6d5@DB4PR30MB030.064d.mgd.msft.net>
References: <5eeb3bd21e054ba58802012c9a5402d9@DB4PR30MB030.064d.mgd.msft.net>
 <E9CA5690-1D3E-41B9-BC6E-E60208E52955@cis.upenn.edu>
 <7c5ae6cfdbad45ffac9785d1a462d6d5@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <58843B60-6E21-41AE-ABB4-E21381FCC75F@cis.upenn.edu>

Done, at TemplateHaskell/Status.

If any dev out there has plans for changes to TH, please link to these changes from TemplateHaskell/Status. I don't believe there are any currently afoot, but please do correct me if I'm wrong.

Thanks!
Richard

On Jun 26, 2015, at 10:38 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> Thanks Richard, that?s great.
>  
> How about starting  a Template Haskell status wiki page, along the lines of
> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.12.1
>  
> ?         The lists of tickets on these status pages are auto-generated, so you could do the same to list open TH tickets.
> ?         Then in manual commentary at the top you can describe any plans, ideas, links to work in progress. 
> ?         You can also identify yourself (and any other co-leaders) as someone to ask.
>  
> Anything to give someone a better place to start than ?hunt through all the tickets?.
>  
> You could link to the page from https://ghc.haskell.org/trac/ghc/wiki/Status
>  
> Simon
>  
>  
> From: Richard Eisenberg [mailto:eir at cis.upenn.edu] 
> Sent: 26 June 2015 13:19
> To: Simon Peyton Jones
> Cc: ghc-devs
> Subject: Re: Template Haskell working group
>  
> Hi Simon,
>  
> I'm happy to take this on. Through `singletons`, I am a heavy TH user and know that end of GHC well.
>  
> The one caveat I offer is that I vastly prefer to chunk up similar bits of work, and generally intend to let TH tickets languish until I sweep them all up, somewhere near the planned feature freeze. The plus side of this approach is that it gives oodles of time for new contributors to GHC to take a stab. As I've commented on Trac, TH is a fantastic way to introduce yourself to GHC hacking. Small enhancements to TH generally involve only a few files and have a predictable pattern.
>  
> So, do get involved! I'll help along the way.
>  
> In any case, I'll continue to monitor TH's overall evolution.
>  
> Richard
>  
> On Jun 26, 2015, at 3:55 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> 
> Friends
> 
> I?m looking for someone, or a small group, to act as a Supreme Being for Template Haskell.  Might you be willing?
> 
> There is a steady trickle of bug reports / feature requests relating to Template Haskell, which I find that I simply don?t have the time to pay proper attention to.  Here is a recent example http://ghc.haskell.org/trac/ghc/ticket/10572.   But if no one pays attention, they languish.
> 
> None of them is very hard, but all require a little careful thought.  What should the Template Haskell API be like?  What semantics do we want?
> 
> My hope is that if someone, or a small group, felt mandated to push TH forward, then we might make some progress.  At the moment I have the uneasy feeling that while everyone can make suggestions, it?s all waiting for SPJ to decide something, and SPJ is not paying enough attention.  I don?t want to be a bottleneck.  Moreover, since I?m not a heavy-duty TH user, I?m poorly placed to make design choices.
> 
> The reason I?m optimistic is because the steady trickle tells me that TH is in fact highly valued and widely used.  So perhaps among that group there are some people who would be willing to debate alternative designs, make choices, and implement them.
> 
> I would be more than willing to act as consultant, both on design and implementation.
> 
> GHC absolutely relies on its community.   Please consider making an offer to help.   Thanks!
> 
> Simon
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150626/3a355bcb/attachment.html>

From simonpj at microsoft.com  Fri Jun 26 16:40:28 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 26 Jun 2015 16:40:28 +0000
Subject: [Diffusion] [Build Failed] rGHC0aaea5b8345f: Tiny refactor plus
 comments
In-Reply-To: <20150626154710.15386.27836@phabricator.haskell.org>
References: <diffusion-audit-PHID-CMIT-v6iku3mmohsk3fftrbcl@phabricator.haskell.org>
 <20150626154710.15386.27836@phabricator.haskell.org>
Message-ID: <ef3e412c0d1f49e8a8ca3959d1e84490@DB4PR30MB030.064d.mgd.msft.net>

The builds seem to be failing with perf failures for
	haddock.Cabal
	haddock.compiler

but that doesn't seem to happen for me.  It looks as though it started with

    rGHC*rGHC0b7e538a09bc: Allow recursive unwrapping of data families

but since I can't reproduce it, it's hard to investigate. I can't even see what performance number has changed, because harbourmaster only shows the tail of the log.

Any insight from others would be useful.

Joachim: do the nofib logs show any changes?

Simon

|  -----Original Message-----
|  From: noreply at phabricator.haskell.org
|  [mailto:noreply at phabricator.haskell.org]
|  Sent: 26 June 2015 16:47
|  To: Simon Peyton Jones
|  Subject: [Diffusion] [Build Failed] rGHC0aaea5b8345f: Tiny refactor
|  plus comments
|  
|  Harbormaster failed to build B4562: rGHC0aaea5b8345f: Tiny refactor
|  plus comments!
|  
|  BRANCHES
|    master
|  
|  USERS
|    simonpj (Author)
|    GHC - Type checker/inferencer (Auditor)
|  
|  COMMIT
|    https://phabricator.haskell.org/rGHC0aaea5b8345f
|  
|  EMAIL PREFERENCES
|    https://phabricator.haskell.org/settings/panel/emailpreferences/
|  
|  To: simonpj, GHC - Type checker/inferencer

From omeragacan at gmail.com  Fri Jun 26 16:40:17 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Fri, 26 Jun 2015 12:40:17 -0400
Subject: expanding type synonyms in error messages
In-Reply-To: <CAAbahfT3mDag5Rm5p+K02CA491Of6ySD4cJgA4fuCh-iuQ=WBg@mail.gmail.com>
References: <CAMQQO3=i2-38x5hDAUyww_x=08GJ7c2Yi3HJLFAQvfqO=qEc9g@mail.gmail.com>
 <DA74706D-FA4C-4AEA-B3CC-61718109F15D@cis.upenn.edu>
 <CAAbahfTuSx6EXN2=PCq=S7a2_4XbKvqhEh2oeHoYGJgS8T9s=w@mail.gmail.com>
 <CAMQQO3kOosf1NJVQs8pctjKB2_cGoC2G2PWDUz6nwODmq6MfVw@mail.gmail.com>
 <CADnndOr5Bzzv2LV6hC=eRYv3ZzPaEDTwSwUk0TweSqgoH8o8mg@mail.gmail.com>
 <15b9703055c74bd28aca095ab9d80ea6@DB4PR30MB030.064d.mgd.msft.net>
 <CAAbahfTxk-Qt4+MLZjhbRY=okGL0PmcVDc2gAjk9P9o5QoPe2g@mail.gmail.com>
 <CAMQQO3kgheBi17rY+wYOKf4k3xe5DpVUHKOgX8-SfmZHCy7Wsg@mail.gmail.com>
 <7B42ECD0-1B1B-4F9B-AE4F-E156E75C4AF4@cis.upenn.edu>
 <CAMQQO3mB1_Ev9xL+xTCrvt1J+wwnKUq1SL29Xo3AGR59CVAtEQ@mail.gmail.com>
 <CAAbahfT3mDag5Rm5p+K02CA491Of6ySD4cJgA4fuCh-iuQ=WBg@mail.gmail.com>
Message-ID: <CAMQQO3=y9R24WWvH_vRqNk_tVZNXPBWVgRyzBPEhovEJ=RkR2Q@mail.gmail.com>

Update: I have a patch, it's not quite ready for reviews, but I'm now
getting this error message:

Main.hs:17:26: error:
    Couldn't match type ?[Char]? with ?()?
    Expected type: Proxy () String () X IO ()
             (aka. Proxy () [Char] () X IO ())
      Actual type: Consumer String IO String
             (aka. Proxy () [Char] () X IO [Char])
    In the second argument of ?(>->)?, namely ?doubleUp?
    In the second argument of ?($)?, namely ?loop >-> doubleUp?
cabal: Error: some packages failed to install:
ghc-ty-patch-0.1.0.0 failed during the building phase. The exception was:
ExitFailure 1

I'll tidy the code a bit, add a command line flag etc. and submit for reviews.

2015-06-19 10:13 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
> Great, thanks for doing this! I'm afraid even if you succeed with patch we
> would still need more "real-world examples" that show the need for this
> feature, and I think this is separate from GHC tests, as they don't need to
> be realistic, but of course please continue and hopefully more examples will
> come.
>
> 19 ????. 2015 16:19 "?mer Sinan A?acan" <omeragacan at gmail.com> ????:
>
>> Done: https://ghc.haskell.org/trac/ghc/ticket/10547
>>
>> 2015-06-19 9:12 GMT-04:00 Richard Eisenberg <eir at cis.upenn.edu>:
>> > Don't forget to make a Feature Request on Trac
>> > (https://ghc.haskell.org/trac/ghc/newticket) with a link to the wiki page.
>> > Trac is really the only way things like this don't get lost.
>> >
>> > Thanks!
>> >
>> > Richard
>> >
>> >
>> > On Jun 19, 2015, at 9:07 AM, ?mer Sinan A?acan <omeragacan at gmail.com>
>> > wrote:
>> >
>> >> Great, thanks Kostiantyn! I'm looking for simple examples that we can
>> >> add to GHC testsuite, if I find something I'll update the wiki page
>> >> also.
>> >>
>> >> I made some progress on the patch, I think I can hopefully submit
>> >> something this weekend for reviews.
>> >>
>> >> 2015-06-19 5:16 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
>> >>> Created some initial wiki-page with just one example, will keep it in
>> >>> mind
>> >>> to add more as seen.
>> >>>
>> >>>
>> >>> https://wiki.haskell.org/Expanding_type_synonyms_in_error_messages_proposal
>> >>>
>> >>> On Fri, Jun 19, 2015 at 10:42 AM, Simon Peyton Jones
>> >>> <simonpj at microsoft.com>
>> >>> wrote:
>> >>>>
>> >>>> On this thread, a representative collection of *reproducible
>> >>>> examples*
>> >>>> with the actual error message and the desired one, would be
>> >>>> tremendously
>> >>>> helpful.  Lacking that, it?s hard to know where to begin.   (Creating
>> >>>> the
>> >>>> examples takes a bit of work, I know.)
>> >>>>
>> >>>>
>> >>>>
>> >>>> Start a wiki page!  Stuff in email threads gets lost
>> >>>>
>> >>>>
>> >>>>
>> >>>> Simon
>> >>>>
>> >>>>
>> >>>>
>> >>>> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
>> >>>> Christopher Allen
>> >>>> Sent: 19 June 2015 04:27
>> >>>> To: ?mer Sinan A?acan
>> >>>> Cc: ghc-devs
>> >>>> Subject: Re: expanding type synonyms in error messages
>> >>>>
>> >>>>
>> >>>>
>> >>>> Just to add my own +1, having this when working with streaming
>> >>>> libraries
>> >>>> (I've needed it less with lens, oddly) would be a tremendous help for
>> >>>> people
>> >>>> learning them I think. I think I've run into the same thing as
>> >>>> Kostiantyn in
>> >>>> the past.
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Thu, Jun 18, 2015 at 9:42 PM, ?mer Sinan A?acan
>> >>>> <omeragacan at gmail.com>
>> >>>> wrote:
>> >>>>
>> >>>> It's good to see that I'm not the only one who wants this. I'm doing
>> >>>> some GHC hacking nowadays and I'll give it a try.
>> >>>>
>> >>>>
>> >>>> 2015-06-18 4:41 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
>> >>>>> I wanted to add that synonym expansion would be especially helpful
>> >>>>> in
>> >>>>> error-messages like:
>> >>>>>
>> >>>>> Expected type: <non-expanded, small type, like "Producer a m ()">
>> >>>>> Actual type: <your type, like "Proxy a a' b b' m v">
>> >>>>>
>> >>>>> I would be glad if we could have an expansions enabling flag in GHC,
>> >>>>> and
>> >>>>> could consider turning it on by default if it will look good for
>> >>>>> that.
>> >>>>>
>> >>>>> 16 ????. 2015 22:44 "Richard Eisenberg" <eir at cis.upenn.edu> ????:
>> >>>>>
>> >>>>>> GHC tries hard to preserve type synonyms where possible, but of
>> >>>>>> course,
>> >>>>>> it
>> >>>>>> can't preserve all of them. The general rule it tries to follow is:
>> >>>>>> preserve
>> >>>>>> vanilla type synonyms; expand type families. This is true both in
>> >>>>>> expected
>> >>>>>> types and actual types.
>> >>>>>> If you have a case where you believe that GHC could preserve a type
>> >>>>>> synonym in an expected type, submit a bug report. (Note that
>> >>>>>> constraint
>> >>>>>> synonyms are particularly hard to preserve!)
>> >>>>>>
>> >>>>>> It would be very easy to report both the synonym-preserving form
>> >>>>>> and
>> >>>>>> the
>> >>>>>> expanded form in an error report, at the cost of making error
>> >>>>>> reports
>> >>>>>> even
>> >>>>>> more verbose. You're welcome to submit a feature request, and this
>> >>>>>> would
>> >>>>>> likely make a good first patch to GHC if you want to get your hands
>> >>>>>> dirty.
>> >>>>>> I'd personally prefer the feature to be protected behind a flag (to
>> >>>>>> avoid
>> >>>>>> seeing that `String` expands to `[Char]` everywhere, for example),
>> >>>>>> but
>> >>>>>> others may feel differently here.
>> >>>>>>
>> >>>>>> Richard
>> >>>>>>
>> >>>>>> On Jun 16, 2015, at 11:20 AM, ?mer Sinan A?acan
>> >>>>>> <omeragacan at gmail.com>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>> Hi all,
>> >>>>>>>
>> >>>>>>> While working with complex types with lots of arguments etc.
>> >>>>>>> errors
>> >>>>>>> are
>> >>>>>>> becoming annoying very fast. For example, GHC prints errors in
>> >>>>>>> this
>> >>>>>>> way:
>> >>>>>>>
>> >>>>>>>   Expected type: <type without any synonyms>
>> >>>>>>>     Actual type: <type with synonyms>
>> >>>>>>>
>> >>>>>>> Now I have to expand that synonym in my head to understand the
>> >>>>>>> error.
>> >>>>>>>
>> >>>>>>> I was wondering if implementing something like this is possible:
>> >>>>>>>
>> >>>>>>> In type error messages, GHC also prints types that are cleaned
>> >>>>>>> from
>> >>>>>>> type
>> >>>>>>> synonyms. Maybe something like this:
>> >>>>>>>
>> >>>>>>>        Expected type: <type1>
>> >>>>>>>   (without synonyms): <type1, synonyms are expanded>
>> >>>>>>>          Actual type: <type2>
>> >>>>>>>   (without synonyms): <type2, synonyms are expanded>
>> >>>>>>>
>> >>>>>>> If this is not always desirable for some reason, we can hide this
>> >>>>>>> behavior
>> >>>>>>> behind a flag.
>> >>>>>>>
>> >>>>>>> What do GHC devs think about this? Is this, in theory, possible to
>> >>>>>>> do?
>> >>>>>>> How hard
>> >>>>>>> would it be to implement this?
>> >>>>>>>
>> >>>>>>> Thanks.
>> >>>>>>> _______________________________________________
>> >>>>>>> ghc-devs mailing list
>> >>>>>>> ghc-devs at haskell.org
>> >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> ghc-devs mailing list
>> >>>>>> ghc-devs at haskell.org
>> >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >>>> _______________________________________________
>> >>>> ghc-devs mailing list
>> >>>> ghc-devs at haskell.org
>> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>>
>> >>>> Chris Allen
>> >>>>
>> >>>> Currently working on http://haskellbook.com
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> ghc-devs mailing list
>> >>>> ghc-devs at haskell.org
>> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >>>>
>> >>>
>> >> _______________________________________________
>> >> ghc-devs mailing list
>> >> ghc-devs at haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >>
>> >

From thomasmiedema at gmail.com  Fri Jun 26 16:50:15 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Fri, 26 Jun 2015 18:50:15 +0200
Subject: [Diffusion] [Build Failed] rGHC0aaea5b8345f: Tiny refactor plus
 comments
In-Reply-To: <ef3e412c0d1f49e8a8ca3959d1e84490@DB4PR30MB030.064d.mgd.msft.net>
References: <diffusion-audit-PHID-CMIT-v6iku3mmohsk3fftrbcl@phabricator.haskell.org>
 <20150626154710.15386.27836@phabricator.haskell.org>
 <ef3e412c0d1f49e8a8ca3959d1e84490@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAD3WKggEtBGqyMxdS63WL24kEfxEPQtiO5cyj8vLb+4FDJ8FvQ@mail.gmail.com>

>
> I can't even see what performance number has changed, because
> harbourmaster only shows the tail of the log.
>

>From https://phabricator.haskell.org/harbormaster/build/4553:

10 bytes allocated value is too high:
11 Expected haddock.Cabal(normal) bytes allocated: 6710234312 +/-5%
12 Lower bound haddock.Cabal(normal) bytes allocated: 6374722596
13 Upper bound haddock.Cabal(normal) bytes allocated: 7045746028
14 Actual haddock.Cabal(normal) bytes allocated: 7417348832
15 Deviation haddock.Cabal(normal) bytes allocated: 10.5 %
16 *** unexpected stat test failure for haddock.Cabal(normal)
17 bytes allocated value is too high:
18 Expected haddock.compiler(normal) bytes allocated: 36740649320 +/-10%
19 Lower bound haddock.compiler(normal) bytes allocated: 33066584388
20 Upper bound haddock.compiler(normal) bytes allocated: 40414714252
21 Actual haddock.compiler(normal) bytes allocated: 40681382656
22 Deviation haddock.compiler(normal) bytes allocated: 10.7 %
23 *** unexpected stat test failure for haddock.compiler(normal)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150626/c2cb5058/attachment.html>

From mail at joachim-breitner.de  Fri Jun 26 18:16:28 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 26 Jun 2015 20:16:28 +0200
Subject: [Diffusion] [Build Failed] rGHC0aaea5b8345f: Tiny refactor plus
 comments
In-Reply-To: <ef3e412c0d1f49e8a8ca3959d1e84490@DB4PR30MB030.064d.mgd.msft.net>
References: <diffusion-audit-PHID-CMIT-v6iku3mmohsk3fftrbcl@phabricator.haskell.org>
 <20150626154710.15386.27836@phabricator.haskell.org>
 <ef3e412c0d1f49e8a8ca3959d1e84490@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <1435342588.25795.1.camel@joachim-breitner.de>

Hi,

Am Freitag, den 26.06.2015, 16:40 +0000 schrieb Simon Peyton Jones:
> The builds seem to be failing with perf failures for
> 	haddock.Cabal
> 	haddock.compiler
> 
> but that doesn't seem to happen for me.  It looks as though it 
> started with
> 
>     rGHC*rGHC0b7e538a09bc: Allow recursive unwrapping of data 
> families

I can confirm this, if you look at 
https://perf.haskell.org/ghc/
you see that that commit is the only in red?

Here is the report for that commit:
https://perf.haskell.org/ghc/#revision/0b7e538a09bc958474ec704063eaa088
36e9270e
and you can fetch the numbers from there, or from the full build log at
https://raw.githubusercontent.com/nomeata/ghc-speed-logs/master/0b7e538a09bc958474ec704063eaa08836e9270e.log

It looks very reproducible as well:
https://perf.haskell.org/ghc/#graph/tests/alloc/haddock.Cabal;hl=0b7e53
8a09bc958474ec704063eaa08836e9270e


Greetings,
Joachim


? for a very leight, not very aggressive taint of red.



-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150626/22a59255/attachment.sig>

From omeragacan at gmail.com  Fri Jun 26 20:17:04 2015
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Fri, 26 Jun 2015 16:17:04 -0400
Subject: expanding type synonyms in error messages
In-Reply-To: <CAMQQO3=y9R24WWvH_vRqNk_tVZNXPBWVgRyzBPEhovEJ=RkR2Q@mail.gmail.com>
References: <CAMQQO3=i2-38x5hDAUyww_x=08GJ7c2Yi3HJLFAQvfqO=qEc9g@mail.gmail.com>
 <DA74706D-FA4C-4AEA-B3CC-61718109F15D@cis.upenn.edu>
 <CAAbahfTuSx6EXN2=PCq=S7a2_4XbKvqhEh2oeHoYGJgS8T9s=w@mail.gmail.com>
 <CAMQQO3kOosf1NJVQs8pctjKB2_cGoC2G2PWDUz6nwODmq6MfVw@mail.gmail.com>
 <CADnndOr5Bzzv2LV6hC=eRYv3ZzPaEDTwSwUk0TweSqgoH8o8mg@mail.gmail.com>
 <15b9703055c74bd28aca095ab9d80ea6@DB4PR30MB030.064d.mgd.msft.net>
 <CAAbahfTxk-Qt4+MLZjhbRY=okGL0PmcVDc2gAjk9P9o5QoPe2g@mail.gmail.com>
 <CAMQQO3kgheBi17rY+wYOKf4k3xe5DpVUHKOgX8-SfmZHCy7Wsg@mail.gmail.com>
 <7B42ECD0-1B1B-4F9B-AE4F-E156E75C4AF4@cis.upenn.edu>
 <CAMQQO3mB1_Ev9xL+xTCrvt1J+wwnKUq1SL29Xo3AGR59CVAtEQ@mail.gmail.com>
 <CAAbahfT3mDag5Rm5p+K02CA491Of6ySD4cJgA4fuCh-iuQ=WBg@mail.gmail.com>
 <CAMQQO3=y9R24WWvH_vRqNk_tVZNXPBWVgRyzBPEhovEJ=RkR2Q@mail.gmail.com>
Message-ID: <CAMQQO3nPU0ro1aWyT-6fQoMGfvGs5EFdz5OF-WPY7tO90RbwmQ@mail.gmail.com>

Created a patch for reviews/feedbacks: https://phabricator.haskell.org/D1016

2015-06-26 12:40 GMT-04:00 ?mer Sinan A?acan <omeragacan at gmail.com>:
> Update: I have a patch, it's not quite ready for reviews, but I'm now
> getting this error message:
>
> Main.hs:17:26: error:
>     Couldn't match type ?[Char]? with ?()?
>     Expected type: Proxy () String () X IO ()
>              (aka. Proxy () [Char] () X IO ())
>       Actual type: Consumer String IO String
>              (aka. Proxy () [Char] () X IO [Char])
>     In the second argument of ?(>->)?, namely ?doubleUp?
>     In the second argument of ?($)?, namely ?loop >-> doubleUp?
> cabal: Error: some packages failed to install:
> ghc-ty-patch-0.1.0.0 failed during the building phase. The exception was:
> ExitFailure 1
>
> I'll tidy the code a bit, add a command line flag etc. and submit for reviews.
>
> 2015-06-19 10:13 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
>> Great, thanks for doing this! I'm afraid even if you succeed with patch we
>> would still need more "real-world examples" that show the need for this
>> feature, and I think this is separate from GHC tests, as they don't need to
>> be realistic, but of course please continue and hopefully more examples will
>> come.
>>
>> 19 ????. 2015 16:19 "?mer Sinan A?acan" <omeragacan at gmail.com> ????:
>>
>>> Done: https://ghc.haskell.org/trac/ghc/ticket/10547
>>>
>>> 2015-06-19 9:12 GMT-04:00 Richard Eisenberg <eir at cis.upenn.edu>:
>>> > Don't forget to make a Feature Request on Trac
>>> > (https://ghc.haskell.org/trac/ghc/newticket) with a link to the wiki page.
>>> > Trac is really the only way things like this don't get lost.
>>> >
>>> > Thanks!
>>> >
>>> > Richard
>>> >
>>> >
>>> > On Jun 19, 2015, at 9:07 AM, ?mer Sinan A?acan <omeragacan at gmail.com>
>>> > wrote:
>>> >
>>> >> Great, thanks Kostiantyn! I'm looking for simple examples that we can
>>> >> add to GHC testsuite, if I find something I'll update the wiki page
>>> >> also.
>>> >>
>>> >> I made some progress on the patch, I think I can hopefully submit
>>> >> something this weekend for reviews.
>>> >>
>>> >> 2015-06-19 5:16 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
>>> >>> Created some initial wiki-page with just one example, will keep it in
>>> >>> mind
>>> >>> to add more as seen.
>>> >>>
>>> >>>
>>> >>> https://wiki.haskell.org/Expanding_type_synonyms_in_error_messages_proposal
>>> >>>
>>> >>> On Fri, Jun 19, 2015 at 10:42 AM, Simon Peyton Jones
>>> >>> <simonpj at microsoft.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> On this thread, a representative collection of *reproducible
>>> >>>> examples*
>>> >>>> with the actual error message and the desired one, would be
>>> >>>> tremendously
>>> >>>> helpful.  Lacking that, it?s hard to know where to begin.   (Creating
>>> >>>> the
>>> >>>> examples takes a bit of work, I know.)
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> Start a wiki page!  Stuff in email threads gets lost
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> Simon
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
>>> >>>> Christopher Allen
>>> >>>> Sent: 19 June 2015 04:27
>>> >>>> To: ?mer Sinan A?acan
>>> >>>> Cc: ghc-devs
>>> >>>> Subject: Re: expanding type synonyms in error messages
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> Just to add my own +1, having this when working with streaming
>>> >>>> libraries
>>> >>>> (I've needed it less with lens, oddly) would be a tremendous help for
>>> >>>> people
>>> >>>> learning them I think. I think I've run into the same thing as
>>> >>>> Kostiantyn in
>>> >>>> the past.
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> On Thu, Jun 18, 2015 at 9:42 PM, ?mer Sinan A?acan
>>> >>>> <omeragacan at gmail.com>
>>> >>>> wrote:
>>> >>>>
>>> >>>> It's good to see that I'm not the only one who wants this. I'm doing
>>> >>>> some GHC hacking nowadays and I'll give it a try.
>>> >>>>
>>> >>>>
>>> >>>> 2015-06-18 4:41 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
>>> >>>>> I wanted to add that synonym expansion would be especially helpful
>>> >>>>> in
>>> >>>>> error-messages like:
>>> >>>>>
>>> >>>>> Expected type: <non-expanded, small type, like "Producer a m ()">
>>> >>>>> Actual type: <your type, like "Proxy a a' b b' m v">
>>> >>>>>
>>> >>>>> I would be glad if we could have an expansions enabling flag in GHC,
>>> >>>>> and
>>> >>>>> could consider turning it on by default if it will look good for
>>> >>>>> that.
>>> >>>>>
>>> >>>>> 16 ????. 2015 22:44 "Richard Eisenberg" <eir at cis.upenn.edu> ????:
>>> >>>>>
>>> >>>>>> GHC tries hard to preserve type synonyms where possible, but of
>>> >>>>>> course,
>>> >>>>>> it
>>> >>>>>> can't preserve all of them. The general rule it tries to follow is:
>>> >>>>>> preserve
>>> >>>>>> vanilla type synonyms; expand type families. This is true both in
>>> >>>>>> expected
>>> >>>>>> types and actual types.
>>> >>>>>> If you have a case where you believe that GHC could preserve a type
>>> >>>>>> synonym in an expected type, submit a bug report. (Note that
>>> >>>>>> constraint
>>> >>>>>> synonyms are particularly hard to preserve!)
>>> >>>>>>
>>> >>>>>> It would be very easy to report both the synonym-preserving form
>>> >>>>>> and
>>> >>>>>> the
>>> >>>>>> expanded form in an error report, at the cost of making error
>>> >>>>>> reports
>>> >>>>>> even
>>> >>>>>> more verbose. You're welcome to submit a feature request, and this
>>> >>>>>> would
>>> >>>>>> likely make a good first patch to GHC if you want to get your hands
>>> >>>>>> dirty.
>>> >>>>>> I'd personally prefer the feature to be protected behind a flag (to
>>> >>>>>> avoid
>>> >>>>>> seeing that `String` expands to `[Char]` everywhere, for example),
>>> >>>>>> but
>>> >>>>>> others may feel differently here.
>>> >>>>>>
>>> >>>>>> Richard
>>> >>>>>>
>>> >>>>>> On Jun 16, 2015, at 11:20 AM, ?mer Sinan A?acan
>>> >>>>>> <omeragacan at gmail.com>
>>> >>>>>> wrote:
>>> >>>>>>
>>> >>>>>>> Hi all,
>>> >>>>>>>
>>> >>>>>>> While working with complex types with lots of arguments etc.
>>> >>>>>>> errors
>>> >>>>>>> are
>>> >>>>>>> becoming annoying very fast. For example, GHC prints errors in
>>> >>>>>>> this
>>> >>>>>>> way:
>>> >>>>>>>
>>> >>>>>>>   Expected type: <type without any synonyms>
>>> >>>>>>>     Actual type: <type with synonyms>
>>> >>>>>>>
>>> >>>>>>> Now I have to expand that synonym in my head to understand the
>>> >>>>>>> error.
>>> >>>>>>>
>>> >>>>>>> I was wondering if implementing something like this is possible:
>>> >>>>>>>
>>> >>>>>>> In type error messages, GHC also prints types that are cleaned
>>> >>>>>>> from
>>> >>>>>>> type
>>> >>>>>>> synonyms. Maybe something like this:
>>> >>>>>>>
>>> >>>>>>>        Expected type: <type1>
>>> >>>>>>>   (without synonyms): <type1, synonyms are expanded>
>>> >>>>>>>          Actual type: <type2>
>>> >>>>>>>   (without synonyms): <type2, synonyms are expanded>
>>> >>>>>>>
>>> >>>>>>> If this is not always desirable for some reason, we can hide this
>>> >>>>>>> behavior
>>> >>>>>>> behind a flag.
>>> >>>>>>>
>>> >>>>>>> What do GHC devs think about this? Is this, in theory, possible to
>>> >>>>>>> do?
>>> >>>>>>> How hard
>>> >>>>>>> would it be to implement this?
>>> >>>>>>>
>>> >>>>>>> Thanks.
>>> >>>>>>> _______________________________________________
>>> >>>>>>> ghc-devs mailing list
>>> >>>>>>> ghc-devs at haskell.org
>>> >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> >>>>>>
>>> >>>>>> _______________________________________________
>>> >>>>>> ghc-devs mailing list
>>> >>>>>> ghc-devs at haskell.org
>>> >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> >>>> _______________________________________________
>>> >>>> ghc-devs mailing list
>>> >>>> ghc-devs at haskell.org
>>> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>>
>>> >>>> Chris Allen
>>> >>>>
>>> >>>> Currently working on http://haskellbook.com
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> ghc-devs mailing list
>>> >>>> ghc-devs at haskell.org
>>> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> >>>>
>>> >>>
>>> >> _______________________________________________
>>> >> ghc-devs mailing list
>>> >> ghc-devs at haskell.org
>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> >>
>>> >

From spam at scientician.net  Sat Jun 27 01:30:56 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Sat, 27 Jun 2015 03:30:56 +0200
Subject: Abstract FilePath Proposal
In-Reply-To: <874mlu8nae.fsf@gnu.org>
References: <874mlu8nae.fsf@gnu.org>
Message-ID: <mmkucg$bu3$1@ger.gmane.org>

On 06/26/2015 06:08 PM, Herbert Valerio Riedel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello *,
> 
> What?
> =====
> 
[--snip--]

I am *entirely* behind this in priciple and if it doesn't break too much
of Hackage, also in practice, but...

... how much of Hackage *does* this break?

The reason that I'm in favor in principle is that paths really *are*
opaque things -- platforms have entirely different conventions. AFAICT
the only thing that they seem to agree on is that there is a "hierarchy"
of some sort. (And not much else, including such things as case
(in-)sensivity or character sets.). For example, in POSIX they're just
strings of bytes without any specified encoding, and I'd love if they
could be make to work like that when dealing with files in Haskell.

Regards,



From djsamperi at gmail.com  Sat Jun 27 03:05:55 2015
From: djsamperi at gmail.com (Dominick Samperi)
Date: Fri, 26 Jun 2015 23:05:55 -0400
Subject: Different behavior in ghci 7.8.3 vs 7.10.1?
Message-ID: <CADUbQ5iCKSBwk2gi3mr8FMVYAMKt4mE2_vDcpeoVaXDZOB0QDA@mail.gmail.com>

Hello,

I'm trying to run code that works with ghci 7.8.3 under ghci 7.10.1
but this fails.

Under 7.8.3, when I run from the shell:
export LD_LIBRARY_PATH=thepath
ghci -lmylib -fno-ghci-sandbox mydriver.hs

I see the usual startup diagnostics along with
Loading object (dynamic) mylib ... done
final link ... done
[1 of 1] Compiling Main
Main>

But under 7.10.1, when I do the same, there is no indication that
linking happens, and when I try to run the program there are
undefined references.

I probably missed the post that explains this behavior. Can somebody
provide a pointer to a work-around?

Thanks,
Dominick

From hvr at gnu.org  Sat Jun 27 07:54:30 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Sat, 27 Jun 2015 09:54:30 +0200
Subject: Abstract FilePath Proposal
In-Reply-To: <mmkucg$bu3$1@ger.gmane.org> (Bardur Arantsson's message of "Sat, 
 27 Jun 2015 03:30:56 +0200")
References: <874mlu8nae.fsf@gnu.org> <mmkucg$bu3$1@ger.gmane.org>
Message-ID: <87bng1r3gp.fsf@gnu.org>

On 2015-06-27 at 03:30:56 +0200, Bardur Arantsson wrote:

[...]

> I am *entirely* behind this in priciple and if it doesn't break too much
> of Hackage, also in practice, but...
>
> ... how much of Hackage *does* this break?

This won't be for free: I expect most packages which currently do more
than just opaquely pass around FilePaths to require fixes.

Some examples:

 - `writeFile "doo/foo.bar" ...`
   `_ <- readFile ("doo" </> "foo" <.> "bar")`

   This will break unless -XOverloadedStrings happens to be enabled

 - Unless we generalise (++) to (<>), all cases where `FilePath`s are
   concatenated via (++) will break.

 - Code that uses Data.List rather than the `filepath` package for
   FilePath manipulation will need fixups (simplest fix: explicitly
   convert to/from String for the manipulation)

 - Some code, like e.g.

     fnames <- System.Environment.getArgs
     forM fnames $ \fn -> print =<< readFile fn

   will inevitably need to insert explicit conversions to/from FilePaths

I tried to simulate the effect on Hackage, but this turned out to be
more time-demanding than I hoped for and I had to abort. But the above
is what I encountered in my attempt.

> The reason that I'm in favor in principle is that paths really *are*
> opaque things -- platforms have entirely different conventions. AFAICT
> the only thing that they seem to agree on is that there is a "hierarchy"
> of some sort. (And not much else, including such things as case
> (in-)sensivity or character sets.).

> For example, in POSIX they're just strings of bytes without any
> specified encoding, and I'd love if they could be make to work like
> that when dealing with files in Haskell.

Yes, if you look e.g. at

  http://hackage.haskell.org/package/unix

you see a lot of API duplication, which wouldn't have been needed if
FilePath was an opaque type w/ lossless conversion to/from
ByteString.

From metaniklas at gmail.com  Sat Jun 27 09:33:21 2015
From: metaniklas at gmail.com (Niklas Larsson)
Date: Sat, 27 Jun 2015 11:33:21 +0200
Subject: SV: Abstract FilePath Proposal
In-Reply-To: <874mlu8nae.fsf@gnu.org>
References: <874mlu8nae.fsf@gnu.org>
Message-ID: <558e6de1.63a6700a.5f03.2b03@mx.google.com>

Hi!

Instead of trying to minimally patch the existing API and still breaking loads of code, why not make a new API that doesn't have to compromise and depreciate the old one?

Niklas 

----- Ursprungligt meddelande -----
Fr?n: "Herbert Valerio Riedel" <hvr at gnu.org>
Skickat: ?2015-?06-?26 18:09
Till: "libraries at haskell.org" <libraries at haskell.org>; "ghc-devs at haskell.org" <ghc-devs at haskell.org>
?mne: Abstract FilePath Proposal

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello *,

What?
=====

We (see From: & CC: headers) propose, plain and simple, to turn the
currently defined type-synonym

  type FilePath = String

into an abstract/opaque data type instead.

Why/How/When?
=============

For details (including motivation and a suggested transition scheme)
please consult

  https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath



Suggested discussion period: 4 weeks
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
HjIPRrJbVK9AABo4AZ/Y
=lg0o
-----END PGP SIGNATURE-----
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150627/a6f2d48e/attachment.html>

From slyich at gmail.com  Sat Jun 27 10:01:48 2015
From: slyich at gmail.com (Sergei Trofimovich)
Date: Sat, 27 Jun 2015 11:01:48 +0100
Subject: Different behavior in ghci 7.8.3 vs 7.10.1?
In-Reply-To: <CADUbQ5iCKSBwk2gi3mr8FMVYAMKt4mE2_vDcpeoVaXDZOB0QDA@mail.gmail.com>
References: <CADUbQ5iCKSBwk2gi3mr8FMVYAMKt4mE2_vDcpeoVaXDZOB0QDA@mail.gmail.com>
Message-ID: <20150627110148.70369363@sf>

On Fri, 26 Jun 2015 23:05:55 -0400
Dominick Samperi <djsamperi at gmail.com> wrote:

> Hello,
> 
> I'm trying to run code that works with ghci 7.8.3 under ghci 7.10.1
> but this fails.
> 
> Under 7.8.3, when I run from the shell:
> export LD_LIBRARY_PATH=thepath
> ghci -lmylib -fno-ghci-sandbox mydriver.hs
> 
> I see the usual startup diagnostics along with
> Loading object (dynamic) mylib ... done
> final link ... done
> [1 of 1] Compiling Main
> Main>
> 
> But under 7.10.1, when I do the same, there is no indication that
> linking happens, and when I try to run the program there are
> undefined references.
> 
> I probably missed the post that explains this behavior. Can somebody
> provide a pointer to a work-around?

There is two separate issues:

1. ghc-7.10 became less chatty when loads libraries.
  'ghci -v2' gets it back with a bit of noise

2. looks more like actual problem. is your mylib
    fully linked against it's depends?
    LD_LIBRARY_PATH=/the/path ldd -u /path/to/mylib.so
    LD_LIBRARY_PATH=/the/path ldd /path/to/mylib.so
    you can also try to inspect LD_DEBUG=help ghci ...

-- 

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150627/c7b52700/attachment.sig>

From k-bx at k-bx.com  Sat Jun 27 10:03:33 2015
From: k-bx at k-bx.com (Kostiantyn Rybnikov)
Date: Sat, 27 Jun 2015 13:03:33 +0300
Subject: SV: Abstract FilePath Proposal
In-Reply-To: <558e6de1.63a6700a.5f03.2b03@mx.google.com>
References: <874mlu8nae.fsf@gnu.org>
 <558e6de1.63a6700a.5f03.2b03@mx.google.com>
Message-ID: <CAAbahfSAoQ3ktDLUa=uUNH=vYWbp7X67pb=Smb2ZdAn4WD1Miw@mail.gmail.com>

Because new api already exists in libraries, but FilePath from base is
still being used, which makes things worse (now your programs have all
those conversions all over).

I like the idea with gradual deprecation warning, but it's not clear if
it's feasible to implement.
27 ????. 2015 12:33 "Niklas Larsson" <metaniklas at gmail.com> ????:

> Hi!
>
> Instead of trying to minimally patch the existing API and still breaking
> loads of code, why not make a new API that doesn't have to compromise and
> depreciate the old one?
>
> Niklas
> ------------------------------
> Fr?n: Herbert Valerio Riedel <hvr at gnu.org>
> Skickat: ?2015-?06-?26 18:09
> Till: libraries at haskell.org; ghc-devs at haskell.org
> ?mne: Abstract FilePath Proposal
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello *,
>
> What?
> =====
>
> We (see From: & CC: headers) propose, plain and simple, to turn the
> currently defined type-synonym
>
>   type FilePath = String
>
> into an abstract/opaque data type instead.
>
> Why/How/When?
> =============
>
> For details (including motivation and a suggested transition scheme)
> please consult
>
>   https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath
>
>
>
> Suggested discussion period: 4 weeks
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
> BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
> YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
> 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
> koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
> qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
> KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
> NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
> tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
> awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
> aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
> HjIPRrJbVK9AABo4AZ/Y
> =lg0o
> -----END PGP SIGNATURE-----
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150627/0fc1b66d/attachment-0001.html>

From ndmitchell at gmail.com  Sat Jun 27 10:12:43 2015
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Sat, 27 Jun 2015 11:12:43 +0100
Subject: Abstract FilePath Proposal
In-Reply-To: <CAAbahfSAoQ3ktDLUa=uUNH=vYWbp7X67pb=Smb2ZdAn4WD1Miw@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <558e6de1.63a6700a.5f03.2b03@mx.google.com>
 <CAAbahfSAoQ3ktDLUa=uUNH=vYWbp7X67pb=Smb2ZdAn4WD1Miw@mail.gmail.com>
Message-ID: <CAKcFpmJ=uvqF6PV-VHt-72Jd5fJkNATG=QVfuK1ZPwfva__fbA@mail.gmail.com>

Hi Niklas,

The function writeFile takes a FilePath. We could fork base or tell
everyone to use writeFile2, but in practice everyone will keep using
writeFile, and this String for FilePath. This approach is the only thing we
could figure that made sense.

Henning: we do not propose normalisation on initialisation. For ASCII
strings fromFilePath . toFilePath will be id. It might also be for unicode
on some/all platforms. Of course, you can write your own FilePath creator
that does normalisation on construction.

Thanks, Neil

On Saturday, 27 June 2015, Niklas Larsson <metaniklas at gmail.com
<javascript:_e(%7B%7D,'cvml','metaniklas at gmail.com');>> wrote:

> Hi!
>
> Instead of trying to minimally patch the existing API and still breaking
> loads of code, why not make a new API that doesn't have to compromise and
> depreciate the old one?
>
> Niklas
> ------------------------------
> Fr?n: Herbert Valerio Riedel
> Skickat: ?2015-?06-?26 18:09
> Till: libraries at haskell.org; ghc-devs at haskell.org
> ?mne: Abstract FilePath Proposal
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello *,
>
> What?
> =====
>
> We (see From: & CC: headers) propose, plain and simple, to turn the
> currently defined type-synonym
>
>   type FilePath = String
>
> into an abstract/opaque data type instead.
>
> Why/How/When?
> =============
>
> For details (including motivation and a suggested transition scheme)
> please consult
>
>   https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath
>
>
>
> Suggested discussion period: 4 weeks
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
> BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
> YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
> 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
> koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
> qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
> KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
> NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
> tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
> awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
> aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
> HjIPRrJbVK9AABo4AZ/Y
> =lg0o
> -----END PGP SIGNATURE-----
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150627/1b747af4/attachment.html>

From djsamperi at gmail.com  Sat Jun 27 11:26:49 2015
From: djsamperi at gmail.com (Dominick Samperi)
Date: Sat, 27 Jun 2015 07:26:49 -0400
Subject: Different behavior in ghci 7.8.3 vs 7.10.1?
In-Reply-To: <20150627110148.70369363@sf>
References: <CADUbQ5iCKSBwk2gi3mr8FMVYAMKt4mE2_vDcpeoVaXDZOB0QDA@mail.gmail.com>
 <20150627110148.70369363@sf>
Message-ID: <CADUbQ5ivY61whFLZCt+00w_N4G6zZu8t29TYzBZ=bsaWSmFQVA@mail.gmail.com>

Thank you, the 'ghci -v2' suggestion was helpful. I now see the
expected link steps.

But when I try to run there are unresolved symbols (with ghci 7.10.1;
everything works fine
with ghci 7.8.3). This may be due to the fact that
I have not installed the Haskell Platform with ghci 7.10.1 under
Fedora 21. I'm using
the latest released HP with ghci 7.8.3.

To test ghci 7.10.1 I compiled from source and simply placed the
resulting bin in
my PATH. Perhaps this is not enough?


On Sat, Jun 27, 2015 at 6:01 AM, Sergei Trofimovich <slyich at gmail.com> wrote:
> On Fri, 26 Jun 2015 23:05:55 -0400
> Dominick Samperi <djsamperi at gmail.com> wrote:
>
>> Hello,
>>
>> I'm trying to run code that works with ghci 7.8.3 under ghci 7.10.1
>> but this fails.
>>
>> Under 7.8.3, when I run from the shell:
>> export LD_LIBRARY_PATH=thepath
>> ghci -lmylib -fno-ghci-sandbox mydriver.hs
>>
>> I see the usual startup diagnostics along with
>> Loading object (dynamic) mylib ... done
>> final link ... done
>> [1 of 1] Compiling Main
>> Main>
>>
>> But under 7.10.1, when I do the same, there is no indication that
>> linking happens, and when I try to run the program there are
>> undefined references.
>>
>> I probably missed the post that explains this behavior. Can somebody
>> provide a pointer to a work-around?
>
> There is two separate issues:
>
> 1. ghc-7.10 became less chatty when loads libraries.
>   'ghci -v2' gets it back with a bit of noise
>
> 2. looks more like actual problem. is your mylib
>     fully linked against it's depends?
>     LD_LIBRARY_PATH=/the/path ldd -u /path/to/mylib.so
>     LD_LIBRARY_PATH=/the/path ldd /path/to/mylib.so
>     you can also try to inspect LD_DEBUG=help ghci ...
>
> --
>
>   Sergei

From spam at scientician.net  Sat Jun 27 11:42:11 2015
From: spam at scientician.net (Bardur Arantsson)
Date: Sat, 27 Jun 2015 13:42:11 +0200
Subject: SV: Abstract FilePath Proposal
In-Reply-To: <558e6de1.63a6700a.5f03.2b03@mx.google.com>
References: <874mlu8nae.fsf@gnu.org>
 <558e6de1.63a6700a.5f03.2b03@mx.google.com>
Message-ID: <mmm26j$c66$2@ger.gmane.org>

On 06/27/2015 11:33 AM, Niklas Larsson wrote:
> Hi!
> 
> Instead of trying to minimally patch the existing API and still
> breaking loads of code, why not make a new API that doesn't have
> to compromise and depreciate the old one?
>

This is a good idea in theory, but it's how we end up in situations like

   https://xkcd.com/927/

:)

Regards,


From djsamperi at gmail.com  Sat Jun 27 11:59:33 2015
From: djsamperi at gmail.com (Dominick Samperi)
Date: Sat, 27 Jun 2015 07:59:33 -0400
Subject: Different behavior in ghci 7.8.3 vs 7.10.1?
In-Reply-To: <CADUbQ5ivY61whFLZCt+00w_N4G6zZu8t29TYzBZ=bsaWSmFQVA@mail.gmail.com>
References: <CADUbQ5iCKSBwk2gi3mr8FMVYAMKt4mE2_vDcpeoVaXDZOB0QDA@mail.gmail.com>
 <20150627110148.70369363@sf>
 <CADUbQ5ivY61whFLZCt+00w_N4G6zZu8t29TYzBZ=bsaWSmFQVA@mail.gmail.com>
Message-ID: <CADUbQ5gWW=qOW7qG02yqSRfNCqHjoADNfSCVBQGVCDnf8NzcGw@mail.gmail.com>

On the second suggestion, I tried ldd and found that the undefined
symbol is flagged 'B' in the nm output (.bss section).

This symbol is defined in the shared library, and the output of ghc
-v2 shows that this shared library is
linked without problems on startup of ghci. When the Haskell/FFI
function is run the symbol is undefined.


On Sat, Jun 27, 2015 at 7:26 AM, Dominick Samperi <djsamperi at gmail.com> wrote:
> Thank you, the 'ghci -v2' suggestion was helpful. I now see the
> expected link steps.
>
> But when I try to run there are unresolved symbols (with ghci 7.10.1;
> everything works fine
> with ghci 7.8.3). This may be due to the fact that
> I have not installed the Haskell Platform with ghci 7.10.1 under
> Fedora 21. I'm using
> the latest released HP with ghci 7.8.3.
>
> To test ghci 7.10.1 I compiled from source and simply placed the
> resulting bin in
> my PATH. Perhaps this is not enough?
>
>
> On Sat, Jun 27, 2015 at 6:01 AM, Sergei Trofimovich <slyich at gmail.com> wrote:
>> On Fri, 26 Jun 2015 23:05:55 -0400
>> Dominick Samperi <djsamperi at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I'm trying to run code that works with ghci 7.8.3 under ghci 7.10.1
>>> but this fails.
>>>
>>> Under 7.8.3, when I run from the shell:
>>> export LD_LIBRARY_PATH=thepath
>>> ghci -lmylib -fno-ghci-sandbox mydriver.hs
>>>
>>> I see the usual startup diagnostics along with
>>> Loading object (dynamic) mylib ... done
>>> final link ... done
>>> [1 of 1] Compiling Main
>>> Main>
>>>
>>> But under 7.10.1, when I do the same, there is no indication that
>>> linking happens, and when I try to run the program there are
>>> undefined references.
>>>
>>> I probably missed the post that explains this behavior. Can somebody
>>> provide a pointer to a work-around?
>>
>> There is two separate issues:
>>
>> 1. ghc-7.10 became less chatty when loads libraries.
>>   'ghci -v2' gets it back with a bit of noise
>>
>> 2. looks more like actual problem. is your mylib
>>     fully linked against it's depends?
>>     LD_LIBRARY_PATH=/the/path ldd -u /path/to/mylib.so
>>     LD_LIBRARY_PATH=/the/path ldd /path/to/mylib.so
>>     you can also try to inspect LD_DEBUG=help ghci ...
>>
>> --
>>
>>   Sergei

From slyich at gmail.com  Sat Jun 27 12:16:10 2015
From: slyich at gmail.com (Sergei Trofimovich)
Date: Sat, 27 Jun 2015 13:16:10 +0100
Subject: Different behavior in ghci 7.8.3 vs 7.10.1?
In-Reply-To: <CADUbQ5gWW=qOW7qG02yqSRfNCqHjoADNfSCVBQGVCDnf8NzcGw@mail.gmail.com>
References: <CADUbQ5iCKSBwk2gi3mr8FMVYAMKt4mE2_vDcpeoVaXDZOB0QDA@mail.gmail.com>
 <20150627110148.70369363@sf>
 <CADUbQ5ivY61whFLZCt+00w_N4G6zZu8t29TYzBZ=bsaWSmFQVA@mail.gmail.com>
 <CADUbQ5gWW=qOW7qG02yqSRfNCqHjoADNfSCVBQGVCDnf8NzcGw@mail.gmail.com>
Message-ID: <20150627131610.2cd53e2a@sf>

On Sat, 27 Jun 2015 07:59:33 -0400
Dominick Samperi <djsamperi at gmail.com> wrote:

> To test ghci 7.10.1 I compiled from source and simply placed the
> resulting bin in my PATH. Perhaps this is not enough?

Sounds right. What does 'ghc --info' show?

> On the second suggestion, I tried ldd and found that the undefined
> symbol is flagged 'B' in the nm output (.bss section).
> 
> This symbol is defined in the shared library, and the output of ghc
> -v2 shows that this shared library is
> linked without problems on startup of ghci. When the Haskell/FFI
> function is run the symbol is undefined.

Can you craft a complete small example with a build script that shows the error?

-- 

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150627/e4e1181c/attachment.sig>

From dsf at seereason.com  Sat Jun 27 12:56:33 2015
From: dsf at seereason.com (David Fox)
Date: Sat, 27 Jun 2015 05:56:33 -0700
Subject: Abstract FilePath Proposal
In-Reply-To: <874mlu8nae.fsf@gnu.org>
References: <874mlu8nae.fsf@gnu.org>
Message-ID: <CAM8C2CBOQ9jJuD0A3b5tkTd=nDXK70ERybU=8LkH4+2RXbLZnQ@mail.gmail.com>

On Fri, Jun 26, 2015 at 9:08 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:
>
>
> We (see From: & CC: headers) propose, plain and simple, to turn the
> currently defined type-synonym
>
>   type FilePath = String
>
> into an abstract/opaque data type instead.
>
> Why/How/When?


?I've had success with a slightly different "How":

Phase 1: Replace FilePath with a type class, with instances for the old
FilePath (i.e. String) and the new implementation.

Phase 2:  Wait until a suitable amount of hackage builds without the string
instance.

Phase 3: Deprecate the String instance - move it to an old-filepath package.

Phase 4: Replace the type class with the new implementation
?
This way the new implementation is available immediately, packages can
begin converting at once, benefits can be assessed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150627/512fbb8b/attachment.html>

From djsamperi at gmail.com  Sat Jun 27 13:07:53 2015
From: djsamperi at gmail.com (Dominick Samperi)
Date: Sat, 27 Jun 2015 09:07:53 -0400
Subject: Different behavior in ghci 7.8.3 vs 7.10.1?
In-Reply-To: <20150627131610.2cd53e2a@sf>
References: <CADUbQ5iCKSBwk2gi3mr8FMVYAMKt4mE2_vDcpeoVaXDZOB0QDA@mail.gmail.com>
 <20150627110148.70369363@sf>
 <CADUbQ5ivY61whFLZCt+00w_N4G6zZu8t29TYzBZ=bsaWSmFQVA@mail.gmail.com>
 <CADUbQ5gWW=qOW7qG02yqSRfNCqHjoADNfSCVBQGVCDnf8NzcGw@mail.gmail.com>
 <20150627131610.2cd53e2a@sf>
Message-ID: <CADUbQ5g3=d6iYZ85XBOb2fpP_Zw4zSBTSkMjouz5Y6oMBG05ig@mail.gmail.com>

I've attached the output of ghc --info. Will have to work on
crafting a small example...

On Sat, Jun 27, 2015 at 8:16 AM, Sergei Trofimovich <slyich at gmail.com> wrote:
> On Sat, 27 Jun 2015 07:59:33 -0400
> Dominick Samperi <djsamperi at gmail.com> wrote:
>
>> To test ghci 7.10.1 I compiled from source and simply placed the
>> resulting bin in my PATH. Perhaps this is not enough?
>
> Sounds right. What does 'ghc --info' show?
>
>> On the second suggestion, I tried ldd and found that the undefined
>> symbol is flagged 'B' in the nm output (.bss section).
>>
>> This symbol is defined in the shared library, and the output of ghc
>> -v2 shows that this shared library is
>> linked without problems on startup of ghci. When the Haskell/FFI
>> function is run the symbol is undefined.
>
> Can you craft a complete small example with a build script that shows the error?
>
> --
>
>   Sergei
-------------- next part --------------
 [("Project name","The Glorious Glasgow Haskell Compilation System")
 ,("GCC extra via C opts"," -fwrapv")
 ,("C compiler command","/usr/bin/gcc")
 ,("C compiler flags"," -fno-stack-protector")
 ,("C compiler link flags","")
 ,("Haskell CPP command","/usr/bin/gcc")
 ,("Haskell CPP flags","-E -undef -traditional ")
 ,("ld command","/usr/bin/ld")
 ,("ld flags","")
 ,("ld supports compact unwind","YES")
 ,("ld supports build-id","YES")
 ,("ld supports filelist","NO")
 ,("ld is GNU ld","YES")
 ,("ar command","/usr/bin/ar")
 ,("ar flags","q")
 ,("ar supports at file","YES")
 ,("touch command","touch")
 ,("dllwrap command","/bin/false")
 ,("windres command","/bin/false")
 ,("libtool command","libtool")
 ,("perl command","/usr/bin/perl")
 ,("target os","OSLinux")
 ,("target arch","ArchX86_64")
 ,("target word size","8")
 ,("target has GNU nonexec stack","True")
 ,("target has .ident directive","True")
 ,("target has subsections via symbols","False")
 ,("Unregisterised","NO")
 ,("LLVM llc command","llc")
 ,("LLVM opt command","opt")
 ,("Project version","7.10.1")
 ,("Project Git commit id","ca00def1d7093d6b5b2a937ddfc8a01c152038eb")
 ,("Booter version","7.8.3")
 ,("Stage","2")
 ,("Build platform","x86_64-unknown-linux")
 ,("Host platform","x86_64-unknown-linux")
 ,("Target platform","x86_64-unknown-linux")
 ,("Have interpreter","YES")
 ,("Object splitting supported","YES")
 ,("Have native code generator","YES")
 ,("Support SMP","YES")
 ,("Tables next to code","YES")
 ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn")
 ,("Support dynamic-too","YES")
 ,("Support parallel --make","YES")
 ,("Support reexported-modules","YES")
 ,("Support thinning and renaming package flags","YES")
 ,("Uses package keys","YES")
 ,("Dynamic by default","NO")
 ,("GHC Dynamic","YES")
 ,("Leading underscore","NO")
 ,("Debug on","False")
 ,("LibDir","/home/dsamperi/bin/ghc-7.10.1/lib/ghc-7.10.1")
 ,("Global Package DB","/home/dsamperi/bin/ghc-7.10.1/lib/ghc-7.10.1/package.conf.d")
 ]

From djsamperi at gmail.com  Sat Jun 27 13:18:32 2015
From: djsamperi at gmail.com (Dominick Samperi)
Date: Sat, 27 Jun 2015 09:18:32 -0400
Subject: Different behavior in ghci 7.8.3 vs 7.10.1?
In-Reply-To: <CADUbQ5g3=d6iYZ85XBOb2fpP_Zw4zSBTSkMjouz5Y6oMBG05ig@mail.gmail.com>
References: <CADUbQ5iCKSBwk2gi3mr8FMVYAMKt4mE2_vDcpeoVaXDZOB0QDA@mail.gmail.com>
 <20150627110148.70369363@sf>
 <CADUbQ5ivY61whFLZCt+00w_N4G6zZu8t29TYzBZ=bsaWSmFQVA@mail.gmail.com>
 <CADUbQ5gWW=qOW7qG02yqSRfNCqHjoADNfSCVBQGVCDnf8NzcGw@mail.gmail.com>
 <20150627131610.2cd53e2a@sf>
 <CADUbQ5g3=d6iYZ85XBOb2fpP_Zw4zSBTSkMjouz5Y6oMBG05ig@mail.gmail.com>
Message-ID: <CADUbQ5gT2d7NrvQM4qZc0Ct2-N0cbwx=T-AbAe1-PR-1GXeGVg@mail.gmail.com>

In case this is not obvious, I should also note that this is a ghci
problem. When
compiled using ghc 7.10.1 there are no probelms with unresolved references.

On Sat, Jun 27, 2015 at 9:07 AM, Dominick Samperi <djsamperi at gmail.com> wrote:
> I've attached the output of ghc --info. Will have to work on
> crafting a small example...
>
> On Sat, Jun 27, 2015 at 8:16 AM, Sergei Trofimovich <slyich at gmail.com> wrote:
>> On Sat, 27 Jun 2015 07:59:33 -0400
>> Dominick Samperi <djsamperi at gmail.com> wrote:
>>
>>> To test ghci 7.10.1 I compiled from source and simply placed the
>>> resulting bin in my PATH. Perhaps this is not enough?
>>
>> Sounds right. What does 'ghc --info' show?
>>
>>> On the second suggestion, I tried ldd and found that the undefined
>>> symbol is flagged 'B' in the nm output (.bss section).
>>>
>>> This symbol is defined in the shared library, and the output of ghc
>>> -v2 shows that this shared library is
>>> linked without problems on startup of ghci. When the Haskell/FFI
>>> function is run the symbol is undefined.
>>
>> Can you craft a complete small example with a build script that shows the error?
>>
>> --
>>
>>   Sergei

From hvriedel at gmail.com  Sat Jun 27 13:37:04 2015
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Sat, 27 Jun 2015 15:37:04 +0200
Subject: Abstract FilePath Proposal
In-Reply-To: <CAM8C2CBOQ9jJuD0A3b5tkTd=nDXK70ERybU=8LkH4+2RXbLZnQ@mail.gmail.com>
 (David Fox's message of "Sat, 27 Jun 2015 05:56:33 -0700")
References: <874mlu8nae.fsf@gnu.org>
 <CAM8C2CBOQ9jJuD0A3b5tkTd=nDXK70ERybU=8LkH4+2RXbLZnQ@mail.gmail.com>
Message-ID: <87h9ptp91b.fsf@gmail.com>

On 2015-06-27 at 14:56:33 +0200, David Fox wrote:

[...]

> ?I've had success with a slightly different "How":

What was your concrete use-case btw?

> Phase 1: Replace FilePath with a type class, with instances for the old
> FilePath (i.e. String) and the new implementation.

what would that comprise in the FilePath case?

I assume adding a transitional class whose methods are not exposed (and
whose typeclass name is exported from some GHC-specific internal-marked
module)? i.e.

  class IsFilePath a where
    privateToFilePath :: a -> FilePath
    privateFromFilePath :: FilePath -> a
   
  instance IsFilePath FilePath where
    privateToFilePath   = id
    privateFromFilePath = id
   
  instance IsFilePath [Char] where
    privateToFilePath   = System.IO.toFilePath
    privateFromFilePath = System.IO.fromFilePath

?

as well as changing a lot of type-sigs in base & filepath from
e.g.

  writeFile :: FilePath -> String -> IO ()
  openTempFile :: FilePath -> String -> IO (FilePath, Handle)

to

  writeFile    :: IsFilePath a => a -> String -> IO ()
  openTempFile :: IsFilePath a => a -> String -> IO (a, Handle)


?

> Phase 2:  Wait until a suitable amount of hackage builds without the string
> instance.

I can see Stackage helping with that by using a custom GHC which lacks
the legacy `IsFilePath [Char]`-instance. So I'd be optimistic that Phase2 could be
accomplished within one year for the Stackage-subset of Hackage.

> Phase 3: Deprecate the String instance - move it to an old-filepath package.
>
> Phase 4: Replace the type class with the new implementation

I assume this means getting rid again of the typeclass, and changing the
type-sigs back to i.e.

  writeFile :: FilePath -> String -> IO ()
  openTempFile :: FilePath -> String -> IO (FilePath, Handle)
?
(but now with with the new opaque `FilePath`)?

> This way the new implementation is available immediately, packages can
> begin converting at once, benefits can be assessed.

This scheme seems feasible at first glance, as long as the typeclass
doesn't start spreading across packages and find its way into type-sigs
(in which case it'd become more disruptive to get rid of it
again). Otoh, I'm not sure (assuming I understood how your scheme works)
it can be avoided to have the typeclass spread, since if not every API
that now has `FilePath` arguments in their type-sigs gets generalised to
have `IsFilePath a => a` arguments instead, we can't reach the goal of
"Phase 2".

But I suspect that I didn't fully understand how your proposed
transition scheme works exactly... so please correct me where I got it
wrong!


Cheers,
  hvr

From dsf at seereason.com  Sat Jun 27 14:17:57 2015
From: dsf at seereason.com (David Fox)
Date: Sat, 27 Jun 2015 07:17:57 -0700
Subject: Abstract FilePath Proposal
In-Reply-To: <87h9ptp91b.fsf@gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <CAM8C2CBOQ9jJuD0A3b5tkTd=nDXK70ERybU=8LkH4+2RXbLZnQ@mail.gmail.com>
 <87h9ptp91b.fsf@gmail.com>
Message-ID: <CAM8C2CCGsP=-qEOCaD6Pwk0AOs43GRWBET37vEV6xOkp-bbsog@mail.gmail.com>

On Sat, Jun 27, 2015 at 6:37 AM, Herbert Valerio Riedel <hvriedel at gmail.com>
wrote:

> On 2015-06-27 at 14:56:33 +0200, David Fox wrote:
>
> [...]
>
> > ?I've had success with a slightly different "How":
>
> What was your concrete use-case btw?
>
> > Phase 1: Replace FilePath with a type class, with instances for the old
> > FilePath (i.e. String) and the new implementation.
>
> what would that comprise in the FilePath case?
>
> I assume adding a transitional class whose methods are not exposed (and
> whose typeclass name is exported from some GHC-specific internal-marked
> module)? i.e.
>
>   class IsFilePath a where
>     privateToFilePath :: a -> FilePath
>     privateFromFilePath :: FilePath -> a
>
>   instance IsFilePath FilePath where
>     privateToFilePath   = id
>     privateFromFilePath = id
>
>   instance IsFilePath [Char] where
>     privateToFilePath   = System.IO.toFilePath
>     privateFromFilePath = System.IO.fromFilePath
>
> ?
>
> as well as changing a lot of type-sigs in base & filepath from
> e.g.
>
>   writeFile :: FilePath -> String -> IO ()
>   openTempFile :: FilePath -> String -> IO (FilePath, Handle)
>
> to
>
>   writeFile    :: IsFilePath a => a -> String -> IO ()
>   openTempFile :: IsFilePath a => a -> String -> IO (a, Handle)
>
>
> ?
>
> > Phase 2:  Wait until a suitable amount of hackage builds without the
> string
> > instance.
>
> I can see Stackage helping with that by using a custom GHC which lacks
> the legacy `IsFilePath [Char]`-instance. So I'd be optimistic that Phase2
> could be
> accomplished within one year for the Stackage-subset of Hackage.
>
> > Phase 3: Deprecate the String instance - move it to an old-filepath
> package.
> >
> > Phase 4: Replace the type class with the new implementation
>
> I assume this means getting rid again of the typeclass, and changing the
> type-sigs back to i.e.
>
>   writeFile :: FilePath -> String -> IO ()
>   openTempFile :: FilePath -> String -> IO (FilePath, Handle)
> ?
> (but now with with the new opaque `FilePath`)?
>
> > This way the new implementation is available immediately, packages can
> > begin converting at once, benefits can be assessed.
>
> This scheme seems feasible at first glance, as long as the typeclass
> doesn't start spreading across packages and find its way into type-sigs
> (in which case it'd become more disruptive to get rid of it
> again). Otoh, I'm not sure (assuming I understood how your scheme works)
> it can be avoided to have the typeclass spread, since if not every API
> that now has `FilePath` arguments in their type-sigs gets generalised to
> have `IsFilePath a => a` arguments instead, we can't reach the goal of
> "Phase 2".
>
> But I suspect that I didn't fully understand how your proposed
> transition scheme works exactly... so please correct me where I got it
> wrong!
>

?You are right, your approach is more appropriate for use by a community.?
 I missed some of the problems that would arise.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150627/0115017c/attachment-0001.html>

From eir at cis.upenn.edu  Sat Jun 27 14:36:05 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sat, 27 Jun 2015 10:36:05 -0400
Subject: help with recognizing symbolic identifiers
Message-ID: <146267BC-717F-4889-912C-09727391DBFD@cis.upenn.edu>

Hi devs,

I've just posted #10583 (http://ghc.haskell.org/trac/ghc/ticket/10583) about fixing up basicTypes/Lexeme.hs. As stated in the ticket, I'm happy to do the hacking, but I need some advice. My most pressing question is this:

Examine the following functions, which all should do the same thing
  * isVarSymChar: https://github.com/ghc/ghc/blob/master/compiler/basicTypes/Lexeme.hs#L102
  * okSymChar: https://github.com/ghc/ghc/blob/master/compiler/basicTypes/Lexeme.hs#L215
  * notFollowedBySymbol: https://github.com/ghc/ghc/blob/master/compiler/parser/Lexer.x#L904

These functions intend to identify characters that can appear in symbolic identifiers. They all have different implementations. Which one is right? Or is there a better way to do this operation?

There are other questions in the ticket, but I can probably sort those out on my own. If you can help, ideally you will respond in the ticket itself.

Many thanks!
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150627/d10a234b/attachment.html>

From djsamperi at gmail.com  Sat Jun 27 18:53:45 2015
From: djsamperi at gmail.com (Dominick Samperi)
Date: Sat, 27 Jun 2015 14:53:45 -0400
Subject: Different behavior in ghci 7.8.3 vs 7.10.1?
In-Reply-To: <CADUbQ5gT2d7NrvQM4qZc0Ct2-N0cbwx=T-AbAe1-PR-1GXeGVg@mail.gmail.com>
References: <CADUbQ5iCKSBwk2gi3mr8FMVYAMKt4mE2_vDcpeoVaXDZOB0QDA@mail.gmail.com>
 <20150627110148.70369363@sf>
 <CADUbQ5ivY61whFLZCt+00w_N4G6zZu8t29TYzBZ=bsaWSmFQVA@mail.gmail.com>
 <CADUbQ5gWW=qOW7qG02yqSRfNCqHjoADNfSCVBQGVCDnf8NzcGw@mail.gmail.com>
 <20150627131610.2cd53e2a@sf>
 <CADUbQ5g3=d6iYZ85XBOb2fpP_Zw4zSBTSkMjouz5Y6oMBG05ig@mail.gmail.com>
 <CADUbQ5gT2d7NrvQM4qZc0Ct2-N0cbwx=T-AbAe1-PR-1GXeGVg@mail.gmail.com>
Message-ID: <CADUbQ5g7JER8DyFoi5h2ENqUNZLZtWhhm=w_tNMNJ6oHkj1USg@mail.gmail.com>

After much trial-and-error and web searching I found a work-around for
ghci 7.10.1.

It appears that BOTH extra-libraries and extra-lib-dirs must be
specified in the cabal file. Previously the link parameters were
specified using a <pkgname>.buildinfo file. It appears that with ghci
7.10.1 this information is no longer used? Specifically, the
ld-options setting in that file is ignored.

This work-around is not satisfactory because I do not want to
hard-code the path to the exra lib in the cabal file for obvious
reasons.

It appears that some changes were made recently to the way cabal
handles external linkage, and this is probably related to the problems
reported here.

On Sat, Jun 27, 2015 at 9:18 AM, Dominick Samperi <djsamperi at gmail.com> wrote:
> In case this is not obvious, I should also note that this is a ghci
> problem. When
> compiled using ghc 7.10.1 there are no probelms with unresolved references.
>
> On Sat, Jun 27, 2015 at 9:07 AM, Dominick Samperi <djsamperi at gmail.com> wrote:
>> I've attached the output of ghc --info. Will have to work on
>> crafting a small example...
>>
>> On Sat, Jun 27, 2015 at 8:16 AM, Sergei Trofimovich <slyich at gmail.com> wrote:
>>> On Sat, 27 Jun 2015 07:59:33 -0400
>>> Dominick Samperi <djsamperi at gmail.com> wrote:
>>>
>>>> To test ghci 7.10.1 I compiled from source and simply placed the
>>>> resulting bin in my PATH. Perhaps this is not enough?
>>>
>>> Sounds right. What does 'ghc --info' show?
>>>
>>>> On the second suggestion, I tried ldd and found that the undefined
>>>> symbol is flagged 'B' in the nm output (.bss section).
>>>>
>>>> This symbol is defined in the shared library, and the output of ghc
>>>> -v2 shows that this shared library is
>>>> linked without problems on startup of ghci. When the Haskell/FFI
>>>> function is run the symbol is undefined.
>>>
>>> Can you craft a complete small example with a build script that shows the error?
>>>
>>> --
>>>
>>>   Sergei

From djsamperi at gmail.com  Sat Jun 27 23:40:10 2015
From: djsamperi at gmail.com (Dominick Samperi)
Date: Sat, 27 Jun 2015 19:40:10 -0400
Subject: Different behavior in ghci 7.8.3 vs 7.10.1?
In-Reply-To: <CADUbQ5g7JER8DyFoi5h2ENqUNZLZtWhhm=w_tNMNJ6oHkj1USg@mail.gmail.com>
References: <CADUbQ5iCKSBwk2gi3mr8FMVYAMKt4mE2_vDcpeoVaXDZOB0QDA@mail.gmail.com>
 <20150627110148.70369363@sf>
 <CADUbQ5ivY61whFLZCt+00w_N4G6zZu8t29TYzBZ=bsaWSmFQVA@mail.gmail.com>
 <CADUbQ5gWW=qOW7qG02yqSRfNCqHjoADNfSCVBQGVCDnf8NzcGw@mail.gmail.com>
 <20150627131610.2cd53e2a@sf>
 <CADUbQ5g3=d6iYZ85XBOb2fpP_Zw4zSBTSkMjouz5Y6oMBG05ig@mail.gmail.com>
 <CADUbQ5gT2d7NrvQM4qZc0Ct2-N0cbwx=T-AbAe1-PR-1GXeGVg@mail.gmail.com>
 <CADUbQ5g7JER8DyFoi5h2ENqUNZLZtWhhm=w_tNMNJ6oHkj1USg@mail.gmail.com>
Message-ID: <CADUbQ5gwqqbDz9r8LHEJ-LjWrFXtVeXt1F0rXY7dX=NUsp85cA@mail.gmail.com>

It turns out the problem was due to a very old Setup.hs that I was
working with. After replacing it with the version recommended by the
latest cabal docs the undefined reference issues disappeared. Sorry!
I also added 'buildable: True' to the buildinfo file, following the latest docs.

On Sat, Jun 27, 2015 at 2:53 PM, Dominick Samperi <djsamperi at gmail.com> wrote:
> After much trial-and-error and web searching I found a work-around for
> ghci 7.10.1.
>
> It appears that BOTH extra-libraries and extra-lib-dirs must be
> specified in the cabal file. Previously the link parameters were
> specified using a <pkgname>.buildinfo file. It appears that with ghci
> 7.10.1 this information is no longer used? Specifically, the
> ld-options setting in that file is ignored.
>
> This work-around is not satisfactory because I do not want to
> hard-code the path to the exra lib in the cabal file for obvious
> reasons.
>
> It appears that some changes were made recently to the way cabal
> handles external linkage, and this is probably related to the problems
> reported here.
>
> On Sat, Jun 27, 2015 at 9:18 AM, Dominick Samperi <djsamperi at gmail.com> wrote:
>> In case this is not obvious, I should also note that this is a ghci
>> problem. When
>> compiled using ghc 7.10.1 there are no probelms with unresolved references.
>>
>> On Sat, Jun 27, 2015 at 9:07 AM, Dominick Samperi <djsamperi at gmail.com> wrote:
>>> I've attached the output of ghc --info. Will have to work on
>>> crafting a small example...
>>>
>>> On Sat, Jun 27, 2015 at 8:16 AM, Sergei Trofimovich <slyich at gmail.com> wrote:
>>>> On Sat, 27 Jun 2015 07:59:33 -0400
>>>> Dominick Samperi <djsamperi at gmail.com> wrote:
>>>>
>>>>> To test ghci 7.10.1 I compiled from source and simply placed the
>>>>> resulting bin in my PATH. Perhaps this is not enough?
>>>>
>>>> Sounds right. What does 'ghc --info' show?
>>>>
>>>>> On the second suggestion, I tried ldd and found that the undefined
>>>>> symbol is flagged 'B' in the nm output (.bss section).
>>>>>
>>>>> This symbol is defined in the shared library, and the output of ghc
>>>>> -v2 shows that this shared library is
>>>>> linked without problems on startup of ghci. When the Haskell/FFI
>>>>> function is run the symbol is undefined.
>>>>
>>>> Can you craft a complete small example with a build script that shows the error?
>>>>
>>>> --
>>>>
>>>>   Sergei

From m at tweag.io  Sun Jun 28 10:03:59 2015
From: m at tweag.io (Boespflug, Mathieu)
Date: Sun, 28 Jun 2015 12:03:59 +0200
Subject: Abstract FilePath Proposal
In-Reply-To: <CAKcFpmJ=uvqF6PV-VHt-72Jd5fJkNATG=QVfuK1ZPwfva__fbA@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <558e6de1.63a6700a.5f03.2b03@mx.google.com>
 <CAAbahfSAoQ3ktDLUa=uUNH=vYWbp7X67pb=Smb2ZdAn4WD1Miw@mail.gmail.com>
 <CAKcFpmJ=uvqF6PV-VHt-72Jd5fJkNATG=QVfuK1ZPwfva__fbA@mail.gmail.com>
Message-ID: <CAJ0eudoZDNLsp4w=OeBPtz3wbiQNGkhyzRzAKu7daE9_6ZbiBQ@mail.gmail.com>

Hi Neil,

why does the proposal *not* include normalization?

There are four advantages that I see to making FilePath a datatype:

1. it makes it possible to implement the correct semantics for some
systems (including POSIX),
2. it allows for information hiding, which in turn helps modularity,
3. the type is distinct from any other type, hence static checks are stronger,
4. it becomes possible to quotient values over some arbitrary set of
identities that makes sense. i.e. in the case of FilePath, arguably
"foo/bar//baz" *is* "foo/bar/baz" *is* "foo//bar/baz" for all intents
and purposes, so it is not useful to distinguish these three ways of
writing down the same path (and in fact in practice distinguishing
them leads to subtle bugs). That is, the Eq instance compares
FilePath's modulo a few laws.

Do you propose to forego (4)? If so why so?

If we're going through a deprecation process, could we do so once, by
getting the notion of path equality we want right the first time?
Contrary to type indexing FilePath, it seems to me that the design
space for path identities is much smaller. Essentially, exactly the
ones here: https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-Posix.html#v:normalise.

Best,

Mathieu


On 27 June 2015 at 12:12, Neil Mitchell <ndmitchell at gmail.com> wrote:
> Hi Niklas,
>
> The function writeFile takes a FilePath. We could fork base or tell everyone
> to use writeFile2, but in practice everyone will keep using writeFile, and
> this String for FilePath. This approach is the only thing we could figure
> that made sense.
>
> Henning: we do not propose normalisation on initialisation. For ASCII
> strings fromFilePath . toFilePath will be id. It might also be for unicode
> on some/all platforms. Of course, you can write your own FilePath creator
> that does normalisation on construction.
>
> Thanks, Neil
>
>
> On Saturday, 27 June 2015, Niklas Larsson <metaniklas at gmail.com> wrote:
>>
>> Hi!
>>
>> Instead of trying to minimally patch the existing API and still breaking
>> loads of code, why not make a new API that doesn't have to compromise and
>> depreciate the old one?
>>
>> Niklas
>> ________________________________
>> Fr?n: Herbert Valerio Riedel
>> Skickat: ?2015-?06-?26 18:09
>> Till: libraries at haskell.org; ghc-devs at haskell.org
>> ?mne: Abstract FilePath Proposal
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello *,
>>
>> What?
>> =====
>>
>> We (see From: & CC: headers) propose, plain and simple, to turn the
>> currently defined type-synonym
>>
>>   type FilePath = String
>>
>> into an abstract/opaque data type instead.
>>
>> Why/How/When?
>> =============
>>
>> For details (including motivation and a suggested transition scheme)
>> please consult
>>
>>   https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath
>>
>>
>>
>> Suggested discussion period: 4 weeks
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
>> BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
>> YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
>> 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
>> koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
>> qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
>> KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
>> NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
>> tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
>> awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
>> aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
>> HjIPRrJbVK9AABo4AZ/Y
>> =lg0o
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From dct25-561bs at mythic-beasts.com  Sun Jun 28 12:09:10 2015
From: dct25-561bs at mythic-beasts.com (David Turner)
Date: Sun, 28 Jun 2015 13:09:10 +0100
Subject: Abstract FilePath Proposal
In-Reply-To: <CAJ0eudoZDNLsp4w=OeBPtz3wbiQNGkhyzRzAKu7daE9_6ZbiBQ@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <558e6de1.63a6700a.5f03.2b03@mx.google.com>
 <CAAbahfSAoQ3ktDLUa=uUNH=vYWbp7X67pb=Smb2ZdAn4WD1Miw@mail.gmail.com>
 <CAKcFpmJ=uvqF6PV-VHt-72Jd5fJkNATG=QVfuK1ZPwfva__fbA@mail.gmail.com>
 <CAJ0eudoZDNLsp4w=OeBPtz3wbiQNGkhyzRzAKu7daE9_6ZbiBQ@mail.gmail.com>
Message-ID: <CAErCyQ-9Vrat6JTdHqPqO+5SV3A6Bryy3bA7F-qV5+5R5A5wNw@mail.gmail.com>

Hi,

I think it'd be more robust to handle normalisation when converting from
String/Text to FilePath (and combining things with (</>) and so on) rather
than in the underlying representation.

It's absolutely crucial that you can ask the OS for a filename (which it
gives you as a sequence of bytes) and then pass that exact same sequence of
bytes back to the OS without any normalisation or other useful alterations
having taken place.

You can do some deeply weird stuff in Windows by starting an absolute path
with \\?\, including apparently using '.' and '..' as the name of a
filesystem component:

Because it turns off automatic expansion of the path string, the "\\?\"
prefix also allows the use of ".." and "." in the path names, which can be
useful if you are attempting to perform operations on a file with these
otherwise reserved relative path specifiers as part of the fully qualified
path.


(from
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
)

I don't fancy shaking all the corner cases out of this. An explicit
'normalise' function seems ok, but baking normalisation into the type
itself seems bad.

Cheers,

David


On 28 June 2015 at 11:03, Boespflug, Mathieu <m at tweag.io> wrote:

> Hi Neil,
>
> why does the proposal *not* include normalization?
>
> There are four advantages that I see to making FilePath a datatype:
>
> 1. it makes it possible to implement the correct semantics for some
> systems (including POSIX),
> 2. it allows for information hiding, which in turn helps modularity,
> 3. the type is distinct from any other type, hence static checks are
> stronger,
> 4. it becomes possible to quotient values over some arbitrary set of
> identities that makes sense. i.e. in the case of FilePath, arguably
> "foo/bar//baz" *is* "foo/bar/baz" *is* "foo//bar/baz" for all intents
> and purposes, so it is not useful to distinguish these three ways of
> writing down the same path (and in fact in practice distinguishing
> them leads to subtle bugs). That is, the Eq instance compares
> FilePath's modulo a few laws.
>
> Do you propose to forego (4)? If so why so?
>
> If we're going through a deprecation process, could we do so once, by
> getting the notion of path equality we want right the first time?
> Contrary to type indexing FilePath, it seems to me that the design
> space for path identities is much smaller. Essentially, exactly the
> ones here:
> https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-Posix.html#v:normalise
> .
>
> Best,
>
> Mathieu
>
>
> On 27 June 2015 at 12:12, Neil Mitchell <ndmitchell at gmail.com> wrote:
> > Hi Niklas,
> >
> > The function writeFile takes a FilePath. We could fork base or tell
> everyone
> > to use writeFile2, but in practice everyone will keep using writeFile,
> and
> > this String for FilePath. This approach is the only thing we could figure
> > that made sense.
> >
> > Henning: we do not propose normalisation on initialisation. For ASCII
> > strings fromFilePath . toFilePath will be id. It might also be for
> unicode
> > on some/all platforms. Of course, you can write your own FilePath creator
> > that does normalisation on construction.
> >
> > Thanks, Neil
> >
> >
> > On Saturday, 27 June 2015, Niklas Larsson <metaniklas at gmail.com> wrote:
> >>
> >> Hi!
> >>
> >> Instead of trying to minimally patch the existing API and still breaking
> >> loads of code, why not make a new API that doesn't have to compromise
> and
> >> depreciate the old one?
> >>
> >> Niklas
> >> ________________________________
> >> Fr?n: Herbert Valerio Riedel
> >> Skickat: ?2015-?06-?26 18:09
> >> Till: libraries at haskell.org; ghc-devs at haskell.org
> >> ?mne: Abstract FilePath Proposal
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Hello *,
> >>
> >> What?
> >> =====
> >>
> >> We (see From: & CC: headers) propose, plain and simple, to turn the
> >> currently defined type-synonym
> >>
> >>   type FilePath = String
> >>
> >> into an abstract/opaque data type instead.
> >>
> >> Why/How/When?
> >> =============
> >>
> >> For details (including motivation and a suggested transition scheme)
> >> please consult
> >>
> >>   https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath
> >>
> >>
> >>
> >> Suggested discussion period: 4 weeks
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1
> >>
> >> iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
> >> BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
> >> YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
> >> 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
> >> koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
> >> qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
> >> KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
> >> NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
> >> tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
> >> awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
> >> aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
> >> HjIPRrJbVK9AABo4AZ/Y
> >> =lg0o
> >> -----END PGP SIGNATURE-----
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150628/3f847f30/attachment.html>

From m at tweag.io  Sun Jun 28 14:47:59 2015
From: m at tweag.io (Boespflug, Mathieu)
Date: Sun, 28 Jun 2015 16:47:59 +0200
Subject: Abstract FilePath Proposal
In-Reply-To: <CANBN=ms=vnFOjfbP24h5Ta6th4qau3ZookzFAmPHtqhbi5dvoA@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <558e6de1.63a6700a.5f03.2b03@mx.google.com>
 <CAAbahfSAoQ3ktDLUa=uUNH=vYWbp7X67pb=Smb2ZdAn4WD1Miw@mail.gmail.com>
 <CAKcFpmJ=uvqF6PV-VHt-72Jd5fJkNATG=QVfuK1ZPwfva__fbA@mail.gmail.com>
 <CAJ0eudoZDNLsp4w=OeBPtz3wbiQNGkhyzRzAKu7daE9_6ZbiBQ@mail.gmail.com>
 <CANBN=ms=vnFOjfbP24h5Ta6th4qau3ZookzFAmPHtqhbi5dvoA@mail.gmail.com>
Message-ID: <CAJ0eudpKPKxRuKVH0k13dnEcX=XsKHvrj7+PathY0xNVFN9MoQ@mail.gmail.com>

On 28 June 2015 at 16:34, Sven Panne <svenpanne at gmail.com> wrote:
> 2015-06-28 12:03 GMT+02:00 Boespflug, Mathieu <m at tweag.io>:
>>
>> why does the proposal *not* include normalization? [...]
>
>
> I think this is intentional, because otherwise we are in the IO monad for
> basically all operations. What's the normalized representation of
> "foo/bar/../baz"?

Notice that the kind of normalization I'm talking about, specified in
the link I provided, does not include this kind of normalization.
Because it requires the IO monad to perform correctly, and only on
real paths.

Here is the link again:

https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-Posix.html#v:normalise

Full canonicalization of paths, stripping out redundant ".." and
whatnot, should certainly be done in a separate function, in IO.

From svenpanne at gmail.com  Sun Jun 28 16:21:00 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Sun, 28 Jun 2015 18:21:00 +0200
Subject: Abstract FilePath Proposal
In-Reply-To: <CAJ0eudpKPKxRuKVH0k13dnEcX=XsKHvrj7+PathY0xNVFN9MoQ@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <558e6de1.63a6700a.5f03.2b03@mx.google.com>
 <CAAbahfSAoQ3ktDLUa=uUNH=vYWbp7X67pb=Smb2ZdAn4WD1Miw@mail.gmail.com>
 <CAKcFpmJ=uvqF6PV-VHt-72Jd5fJkNATG=QVfuK1ZPwfva__fbA@mail.gmail.com>
 <CAJ0eudoZDNLsp4w=OeBPtz3wbiQNGkhyzRzAKu7daE9_6ZbiBQ@mail.gmail.com>
 <CANBN=ms=vnFOjfbP24h5Ta6th4qau3ZookzFAmPHtqhbi5dvoA@mail.gmail.com>
 <CAJ0eudpKPKxRuKVH0k13dnEcX=XsKHvrj7+PathY0xNVFN9MoQ@mail.gmail.com>
Message-ID: <CANBN=muK2=Ofv=hSCKA5GCHRUaaZG5ymgYZfbpqrbt3fWqJ4YA@mail.gmail.com>

2015-06-28 16:47 GMT+02:00 Boespflug, Mathieu <m at tweag.io>:

> Notice that the kind of normalization I'm talking about, specified in
> the link I provided, does not include this kind of normalization.
> Because it requires the IO monad to perform correctly, and only on
> real paths.
>
> Here is the link again:
>
>
> https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-Posix.html#v:normalise
> [...]
>

OK, then I misunderstood what you meant by "normalizing". But a question
remains then: What is a use case for having equality modulo "normalise"? It
throws together a few more paths which plain equality on strings would
consider different, but it is still not semantic equality in the sense of
"these 2 paths refer to the same dir/file". So unless there is a compelling
use case (which I don't see), I don't see a point in always doing
"normalise". Or do I miss something?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150628/44575353/attachment.html>

From ekmett at gmail.com  Sun Jun 28 19:05:05 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 28 Jun 2015 15:05:05 -0400
Subject: Abstract FilePath Proposal
In-Reply-To: <CAErCyQ-9Vrat6JTdHqPqO+5SV3A6Bryy3bA7F-qV5+5R5A5wNw@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <558e6de1.63a6700a.5f03.2b03@mx.google.com>
 <CAAbahfSAoQ3ktDLUa=uUNH=vYWbp7X67pb=Smb2ZdAn4WD1Miw@mail.gmail.com>
 <CAKcFpmJ=uvqF6PV-VHt-72Jd5fJkNATG=QVfuK1ZPwfva__fbA@mail.gmail.com>
 <CAJ0eudoZDNLsp4w=OeBPtz3wbiQNGkhyzRzAKu7daE9_6ZbiBQ@mail.gmail.com>
 <CAErCyQ-9Vrat6JTdHqPqO+5SV3A6Bryy3bA7F-qV5+5R5A5wNw@mail.gmail.com>
Message-ID: <CAJumaK9BRyf8h2Z0S=JzbhNGxMPbqeLTx2ZpWCw3DeAu3adMow@mail.gmail.com>

Worse there are situations where you absolutely _have_ to be able to use
\\?\ encoding of a path on Windows to read, modify or delete files with
"impossible names" that were created by other means.

e.g. Filenames like AUX, that had traditional roles under DOS cause weird
interactions, or that were created with "impossibly long names" -- which
can happen in the wild when you move directories around, etc.

I'm weakly in favor of the proposal precisely because it is the first
version of this concept that I've seen that DOESN'T try to get too clever
with regards to adding all sorts of normalization and this proposal seems
to be the simplest move that would enable us to do something correctly in
the future, regardless of what that correct thing winds up being.

-Edward

On Sun, Jun 28, 2015 at 8:09 AM, David Turner <dct25-561bs at mythic-beasts.com
> wrote:

> Hi,
>
> I think it'd be more robust to handle normalisation when converting from
> String/Text to FilePath (and combining things with (</>) and so on) rather
> than in the underlying representation.
>
> It's absolutely crucial that you can ask the OS for a filename (which it
> gives you as a sequence of bytes) and then pass that exact same sequence of
> bytes back to the OS without any normalisation or other useful alterations
> having taken place.
>
> You can do some deeply weird stuff in Windows by starting an absolute path
> with \\?\, including apparently using '.' and '..' as the name of a
> filesystem component:
>
> Because it turns off automatic expansion of the path string, the "\\?\"
> prefix also allows the use of ".." and "." in the path names, which can be
> useful if you are attempting to perform operations on a file with these
> otherwise reserved relative path specifiers as part of the fully qualified
> path.
>
>
> (from
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
> )
>
> I don't fancy shaking all the corner cases out of this. An explicit
> 'normalise' function seems ok, but baking normalisation into the type
> itself seems bad.
>
> Cheers,
>
> David
>
>
> On 28 June 2015 at 11:03, Boespflug, Mathieu <m at tweag.io> wrote:
>
>> Hi Neil,
>>
>> why does the proposal *not* include normalization?
>>
>> There are four advantages that I see to making FilePath a datatype:
>>
>> 1. it makes it possible to implement the correct semantics for some
>> systems (including POSIX),
>> 2. it allows for information hiding, which in turn helps modularity,
>> 3. the type is distinct from any other type, hence static checks are
>> stronger,
>> 4. it becomes possible to quotient values over some arbitrary set of
>> identities that makes sense. i.e. in the case of FilePath, arguably
>> "foo/bar//baz" *is* "foo/bar/baz" *is* "foo//bar/baz" for all intents
>> and purposes, so it is not useful to distinguish these three ways of
>> writing down the same path (and in fact in practice distinguishing
>> them leads to subtle bugs). That is, the Eq instance compares
>> FilePath's modulo a few laws.
>>
>> Do you propose to forego (4)? If so why so?
>>
>> If we're going through a deprecation process, could we do so once, by
>> getting the notion of path equality we want right the first time?
>> Contrary to type indexing FilePath, it seems to me that the design
>> space for path identities is much smaller. Essentially, exactly the
>> ones here:
>> https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-Posix.html#v:normalise
>> .
>>
>> Best,
>>
>> Mathieu
>>
>>
>> On 27 June 2015 at 12:12, Neil Mitchell <ndmitchell at gmail.com> wrote:
>> > Hi Niklas,
>> >
>> > The function writeFile takes a FilePath. We could fork base or tell
>> everyone
>> > to use writeFile2, but in practice everyone will keep using writeFile,
>> and
>> > this String for FilePath. This approach is the only thing we could
>> figure
>> > that made sense.
>> >
>> > Henning: we do not propose normalisation on initialisation. For ASCII
>> > strings fromFilePath . toFilePath will be id. It might also be for
>> unicode
>> > on some/all platforms. Of course, you can write your own FilePath
>> creator
>> > that does normalisation on construction.
>> >
>> > Thanks, Neil
>> >
>> >
>> > On Saturday, 27 June 2015, Niklas Larsson <metaniklas at gmail.com> wrote:
>> >>
>> >> Hi!
>> >>
>> >> Instead of trying to minimally patch the existing API and still
>> breaking
>> >> loads of code, why not make a new API that doesn't have to compromise
>> and
>> >> depreciate the old one?
>> >>
>> >> Niklas
>> >> ________________________________
>> >> Fr?n: Herbert Valerio Riedel
>> >> Skickat: ?2015-?06-?26 18:09
>> >> Till: libraries at haskell.org; ghc-devs at haskell.org
>> >> ?mne: Abstract FilePath Proposal
>> >>
>> >> -----BEGIN PGP SIGNED MESSAGE-----
>> >> Hash: SHA1
>> >>
>> >> Hello *,
>> >>
>> >> What?
>> >> =====
>> >>
>> >> We (see From: & CC: headers) propose, plain and simple, to turn the
>> >> currently defined type-synonym
>> >>
>> >>   type FilePath = String
>> >>
>> >> into an abstract/opaque data type instead.
>> >>
>> >> Why/How/When?
>> >> =============
>> >>
>> >> For details (including motivation and a suggested transition scheme)
>> >> please consult
>> >>
>> >>   https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath
>> >>
>> >>
>> >>
>> >> Suggested discussion period: 4 weeks
>> >> -----BEGIN PGP SIGNATURE-----
>> >> Version: GnuPG v1
>> >>
>> >> iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
>> >> BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
>> >> YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
>> >> 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
>> >> koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
>> >> qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
>> >> KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
>> >> NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
>> >> tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
>> >> awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
>> >> aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
>> >> HjIPRrJbVK9AABo4AZ/Y
>> >> =lg0o
>> >> -----END PGP SIGNATURE-----
>> >> _______________________________________________
>> >> ghc-devs mailing list
>> >> ghc-devs at haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150628/30401524/attachment-0001.html>

From ndmitchell at gmail.com  Sun Jun 28 21:09:41 2015
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Sun, 28 Jun 2015 22:09:41 +0100
Subject: Abstract FilePath Proposal
In-Reply-To: <CAJ0eudpKPKxRuKVH0k13dnEcX=XsKHvrj7+PathY0xNVFN9MoQ@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <558e6de1.63a6700a.5f03.2b03@mx.google.com>
 <CAAbahfSAoQ3ktDLUa=uUNH=vYWbp7X67pb=Smb2ZdAn4WD1Miw@mail.gmail.com>
 <CAKcFpmJ=uvqF6PV-VHt-72Jd5fJkNATG=QVfuK1ZPwfva__fbA@mail.gmail.com>
 <CAJ0eudoZDNLsp4w=OeBPtz3wbiQNGkhyzRzAKu7daE9_6ZbiBQ@mail.gmail.com>
 <CANBN=ms=vnFOjfbP24h5Ta6th4qau3ZookzFAmPHtqhbi5dvoA@mail.gmail.com>
 <CAJ0eudpKPKxRuKVH0k13dnEcX=XsKHvrj7+PathY0xNVFN9MoQ@mail.gmail.com>
Message-ID: <CAKcFpmKPZ=rYstCmpK1N3KQnfoUuGzOrJRajFBXC6y5-4btxiA@mail.gmail.com>

When talking about "filepath" specifically as something you prod at a
specific file system, you can think about normalisation, provided you
have a specific drive in mind. However, if you're going to do that, on
Linux it's almost better to use an inode number. I have two specific
problems with normalisation:

* You might hope for the property that after normalisation equality of
file locations is equality of FilePath values. That's not true. On
Linux you have symlinks. On Windows you have case sensitivity, which
is a property of the filesystem, not the OS. You might be able to
assume a == b ==> same a b, but you can never assume a /= b ==> not
(same a b), so normalisation doesn't really change the guarantee.

* I believe some Emacs user once told me that a//b is not the same as
a/b in some circumstances. On Windows, there are lots of programs that
require / or \. Some programs require ./foo and some require foo. The
exact path you pass to some programs gets baked into their output,
which is visible in the final release. While paths might be equal for
the purpose of asking a file system to get some bytes back, they are
often different for the other things people want to do with them, like
pass them to other programs that use the paths.



On Sun, Jun 28, 2015 at 3:47 PM, Boespflug, Mathieu <m at tweag.io> wrote:
> On 28 June 2015 at 16:34, Sven Panne <svenpanne at gmail.com> wrote:
>> 2015-06-28 12:03 GMT+02:00 Boespflug, Mathieu <m at tweag.io>:
>>>
>>> why does the proposal *not* include normalization? [...]
>>
>>
>> I think this is intentional, because otherwise we are in the IO monad for
>> basically all operations. What's the normalized representation of
>> "foo/bar/../baz"?
>
> Notice that the kind of normalization I'm talking about, specified in
> the link I provided, does not include this kind of normalization.
> Because it requires the IO monad to perform correctly, and only on
> real paths.
>
> Here is the link again:
>
> https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-Posix.html#v:normalise
>
> Full canonicalization of paths, stripping out redundant ".." and
> whatnot, should certainly be done in a separate function, in IO.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From bob at redivi.com  Sun Jun 28 21:09:53 2015
From: bob at redivi.com (Bob Ippolito)
Date: Sun, 28 Jun 2015 14:09:53 -0700
Subject: Abstract FilePath Proposal
In-Reply-To: <CAJumaK9BRyf8h2Z0S=JzbhNGxMPbqeLTx2ZpWCw3DeAu3adMow@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <558e6de1.63a6700a.5f03.2b03@mx.google.com>
 <CAAbahfSAoQ3ktDLUa=uUNH=vYWbp7X67pb=Smb2ZdAn4WD1Miw@mail.gmail.com>
 <CAKcFpmJ=uvqF6PV-VHt-72Jd5fJkNATG=QVfuK1ZPwfva__fbA@mail.gmail.com>
 <CAJ0eudoZDNLsp4w=OeBPtz3wbiQNGkhyzRzAKu7daE9_6ZbiBQ@mail.gmail.com>
 <CAErCyQ-9Vrat6JTdHqPqO+5SV3A6Bryy3bA7F-qV5+5R5A5wNw@mail.gmail.com>
 <CAJumaK9BRyf8h2Z0S=JzbhNGxMPbqeLTx2ZpWCw3DeAu3adMow@mail.gmail.com>
Message-ID: <CACwMPm-tr4fJXQxi=W=E6S8o+rFmoRTmVkzTweSn0aLgEKXBxA@mail.gmail.com>

Normalization is a very hairy issue, which is not just platform specific
but also filesystem specific. Mac OS X is probably the worst of all words
in that respect, where HFS+ will do NFD normalization and may or may not
have case sensitivity depending on how that partition was formatted.
Network file shares and disk images may or may not have case sensitivity
and can use either NFD or NFC normalization based on mount options.

Contrary to statements earlier in the thread, NFD normalization happens on
HFS+ filesystems (the default) regardless of whether you're using POSIX
APIs or not. It's easy to prove this to yourself by creating a file with
U+00c9 (LATIN SMALL LETTER E WITH ACUTE) in the name (from any of the APIs)
and you'll see it come back out (e.g. from readdir) as two code points: 'e'
and then U+0301 (COMBINING ACUTE ACCENT). It'll also do some weird
transformations to file names that contain byte sequences that are not
valid UTF-8.



On Sun, Jun 28, 2015 at 12:05 PM, Edward Kmett <ekmett at gmail.com> wrote:

> Worse there are situations where you absolutely _have_ to be able to use
> \\?\ encoding of a path on Windows to read, modify or delete files with
> "impossible names" that were created by other means.
>
> e.g. Filenames like AUX, that had traditional roles under DOS cause weird
> interactions, or that were created with "impossibly long names" -- which
> can happen in the wild when you move directories around, etc.
>
> I'm weakly in favor of the proposal precisely because it is the first
> version of this concept that I've seen that DOESN'T try to get too clever
> with regards to adding all sorts of normalization and this proposal seems
> to be the simplest move that would enable us to do something correctly in
> the future, regardless of what that correct thing winds up being.
>
> -Edward
>
> On Sun, Jun 28, 2015 at 8:09 AM, David Turner <
> dct25-561bs at mythic-beasts.com> wrote:
>
>> Hi,
>>
>> I think it'd be more robust to handle normalisation when converting from
>> String/Text to FilePath (and combining things with (</>) and so on) rather
>> than in the underlying representation.
>>
>> It's absolutely crucial that you can ask the OS for a filename (which it
>> gives you as a sequence of bytes) and then pass that exact same sequence of
>> bytes back to the OS without any normalisation or other useful alterations
>> having taken place.
>>
>> You can do some deeply weird stuff in Windows by starting an absolute
>> path with \\?\, including apparently using '.' and '..' as the name of a
>> filesystem component:
>>
>> Because it turns off automatic expansion of the path string, the "\\?\"
>> prefix also allows the use of ".." and "." in the path names, which can be
>> useful if you are attempting to perform operations on a file with these
>> otherwise reserved relative path specifiers as part of the fully qualified
>> path.
>>
>>
>> (from
>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
>> )
>>
>> I don't fancy shaking all the corner cases out of this. An explicit
>> 'normalise' function seems ok, but baking normalisation into the type
>> itself seems bad.
>>
>> Cheers,
>>
>> David
>>
>>
>> On 28 June 2015 at 11:03, Boespflug, Mathieu <m at tweag.io> wrote:
>>
>>> Hi Neil,
>>>
>>> why does the proposal *not* include normalization?
>>>
>>> There are four advantages that I see to making FilePath a datatype:
>>>
>>> 1. it makes it possible to implement the correct semantics for some
>>> systems (including POSIX),
>>> 2. it allows for information hiding, which in turn helps modularity,
>>> 3. the type is distinct from any other type, hence static checks are
>>> stronger,
>>> 4. it becomes possible to quotient values over some arbitrary set of
>>> identities that makes sense. i.e. in the case of FilePath, arguably
>>> "foo/bar//baz" *is* "foo/bar/baz" *is* "foo//bar/baz" for all intents
>>> and purposes, so it is not useful to distinguish these three ways of
>>> writing down the same path (and in fact in practice distinguishing
>>> them leads to subtle bugs). That is, the Eq instance compares
>>> FilePath's modulo a few laws.
>>>
>>> Do you propose to forego (4)? If so why so?
>>>
>>> If we're going through a deprecation process, could we do so once, by
>>> getting the notion of path equality we want right the first time?
>>> Contrary to type indexing FilePath, it seems to me that the design
>>> space for path identities is much smaller. Essentially, exactly the
>>> ones here:
>>> https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-Posix.html#v:normalise
>>> .
>>>
>>> Best,
>>>
>>> Mathieu
>>>
>>>
>>> On 27 June 2015 at 12:12, Neil Mitchell <ndmitchell at gmail.com> wrote:
>>> > Hi Niklas,
>>> >
>>> > The function writeFile takes a FilePath. We could fork base or tell
>>> everyone
>>> > to use writeFile2, but in practice everyone will keep using writeFile,
>>> and
>>> > this String for FilePath. This approach is the only thing we could
>>> figure
>>> > that made sense.
>>> >
>>> > Henning: we do not propose normalisation on initialisation. For ASCII
>>> > strings fromFilePath . toFilePath will be id. It might also be for
>>> unicode
>>> > on some/all platforms. Of course, you can write your own FilePath
>>> creator
>>> > that does normalisation on construction.
>>> >
>>> > Thanks, Neil
>>> >
>>> >
>>> > On Saturday, 27 June 2015, Niklas Larsson <metaniklas at gmail.com>
>>> wrote:
>>> >>
>>> >> Hi!
>>> >>
>>> >> Instead of trying to minimally patch the existing API and still
>>> breaking
>>> >> loads of code, why not make a new API that doesn't have to compromise
>>> and
>>> >> depreciate the old one?
>>> >>
>>> >> Niklas
>>> >> ________________________________
>>> >> Fr?n: Herbert Valerio Riedel
>>> >> Skickat: ?2015-?06-?26 18:09
>>> >> Till: libraries at haskell.org; ghc-devs at haskell.org
>>> >> ?mne: Abstract FilePath Proposal
>>> >>
>>> >> -----BEGIN PGP SIGNED MESSAGE-----
>>> >> Hash: SHA1
>>> >>
>>> >> Hello *,
>>> >>
>>> >> What?
>>> >> =====
>>> >>
>>> >> We (see From: & CC: headers) propose, plain and simple, to turn the
>>> >> currently defined type-synonym
>>> >>
>>> >>   type FilePath = String
>>> >>
>>> >> into an abstract/opaque data type instead.
>>> >>
>>> >> Why/How/When?
>>> >> =============
>>> >>
>>> >> For details (including motivation and a suggested transition scheme)
>>> >> please consult
>>> >>
>>> >>   https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath
>>> >>
>>> >>
>>> >>
>>> >> Suggested discussion period: 4 weeks
>>> >> -----BEGIN PGP SIGNATURE-----
>>> >> Version: GnuPG v1
>>> >>
>>> >> iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
>>> >> BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
>>> >> YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
>>> >> 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
>>> >> koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
>>> >> qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
>>> >> KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
>>> >> NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
>>> >> tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
>>> >> awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
>>> >> aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
>>> >> HjIPRrJbVK9AABo4AZ/Y
>>> >> =lg0o
>>> >> -----END PGP SIGNATURE-----
>>> >> _______________________________________________
>>> >> ghc-devs mailing list
>>> >> ghc-devs at haskell.org
>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> >
>>> >
>>> > _______________________________________________
>>> > ghc-devs mailing list
>>> > ghc-devs at haskell.org
>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> >
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150628/142d6e72/attachment.html>

From allbery.b at gmail.com  Sun Jun 28 21:11:42 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 28 Jun 2015 17:11:42 -0400
Subject: Abstract FilePath Proposal
In-Reply-To: <CAKcFpmKPZ=rYstCmpK1N3KQnfoUuGzOrJRajFBXC6y5-4btxiA@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <558e6de1.63a6700a.5f03.2b03@mx.google.com>
 <CAAbahfSAoQ3ktDLUa=uUNH=vYWbp7X67pb=Smb2ZdAn4WD1Miw@mail.gmail.com>
 <CAKcFpmJ=uvqF6PV-VHt-72Jd5fJkNATG=QVfuK1ZPwfva__fbA@mail.gmail.com>
 <CAJ0eudoZDNLsp4w=OeBPtz3wbiQNGkhyzRzAKu7daE9_6ZbiBQ@mail.gmail.com>
 <CANBN=ms=vnFOjfbP24h5Ta6th4qau3ZookzFAmPHtqhbi5dvoA@mail.gmail.com>
 <CAJ0eudpKPKxRuKVH0k13dnEcX=XsKHvrj7+PathY0xNVFN9MoQ@mail.gmail.com>
 <CAKcFpmKPZ=rYstCmpK1N3KQnfoUuGzOrJRajFBXC6y5-4btxiA@mail.gmail.com>
Message-ID: <CAKFCL4WLbD6aAy8XsQFhXE8=Mg-9g8aAFMoP4fh2LeU94YrPew@mail.gmail.com>

On Sun, Jun 28, 2015 at 5:09 PM, Neil Mitchell <ndmitchell at gmail.com> wrote:

> * I believe some Emacs user once told me that a//b is not the same as
> a/b in some circumstances.
>

Only when typing to an interactive path prompt; it lets you reset to /
without erasing the existing path prefix. This should never happen in
elisp, for example.

-- 
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://mail.haskell.org/pipermail/ghc-devs/attachments/20150628/470c344d/attachment-0001.html>

From nikita at karetnikov.org  Sun Jun 28 22:15:11 2015
From: nikita at karetnikov.org (Nikita Karetnikov)
Date: Mon, 29 Jun 2015 01:15:11 +0300
Subject: Handling overflow and division by zero
Message-ID: <87wpyn4h00.fsf@karetnikov.org>

Haskell is often marketed as a safe (or safer) language, but there's
an issue that makes it less safe as it could be.  I'm talking about
arithmetic overflows and division by zero.  The safeint package tries
to address this, but it only supports the Int type because (as I
understand it) there are no useful primitives for other common types
defined in Data.Int and Data.Word.

I've tried adding Int64 support to safeint just to see how it would work
without primops.  Here's a snippet (I haven't tested this code well, so
it may be wrong, sorry about that):

shiftRUnsigned :: Word64 -> Int -> Word64
shiftRUnsigned = shiftR

-- http://git.haskell.org/ghc.git/blob/HEAD:/compiler/codeGen/StgCmmPrim.hs#l930
plusSI64 :: SafeInt64 -> SafeInt64 -> SafeInt64
plusSI64 (SI64 a) (SI64 b) = if c == 0 then SI64 r else overflowError
  where
    r = a + b
    c = (fromIntegral $ (complement (a `xor` b)) .&. (a `xor` r))
        `shiftRUnsigned`
        ((finiteBitSize a) - 1)

-- http://git.haskell.org/ghc.git/blob/HEAD:/compiler/codeGen/StgCmmPrim.hs#l966
minusSI64 :: SafeInt64 -> SafeInt64 -> SafeInt64
minusSI64 (SI64 a) (SI64 b) = if c == 0 then SI64 r else overflowError
  where
    r = a - b
    c = (fromIntegral $ (a `xor` b) .&. (a `xor` r))
        `shiftRUnsigned`
        ((finiteBitSize a) - 1)

-- https://stackoverflow.com/a/1815371
timesSI64 :: SafeInt64 -> SafeInt64 -> SafeInt64
timesSI64 (SI64 a) (SI64 b) =
  let x = a * b
  in if a /= 0 && x `div` a /= b
     then overflowError
     else SI64 x

I may be wrong, but my understanding is that new primops could reduce
overhead here.  If so, would a patch adding them be accepted?  Are
there any caveats?

In the safeint package, would it be reasonable to return an Either
value instead of throwing an exception?  Or would it be too much?

I haven't created a wiki page or ticket because I don't know much, so
I want to get some feedback before doing so.  That would be my first
patch to GHC (if ever), so maybe I'm not the best candidate, but I've
been thinking about it for too long to ignore. :\

From ekmett at gmail.com  Sun Jun 28 22:30:14 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 28 Jun 2015 18:30:14 -0400
Subject: Handling overflow and division by zero
In-Reply-To: <87wpyn4h00.fsf@karetnikov.org>
References: <87wpyn4h00.fsf@karetnikov.org>
Message-ID: <CAJumaK_mnad9vNj+ft_GoH6JojkSKOjvhKbjvNLQC6m2L_3Q_w@mail.gmail.com>

You should be able to reduce the bit-twiddling a great deal IIRC in the
word case.

SW a + SW b
  | c <- a + b, c >= min a b = SW c
  | otherwise = throw Overflow

There is a similar trick that escapes me at the moment for the signed case.


On Sun, Jun 28, 2015 at 6:15 PM, Nikita Karetnikov <nikita at karetnikov.org>
wrote:

> Haskell is often marketed as a safe (or safer) language, but there's
> an issue that makes it less safe as it could be.  I'm talking about
> arithmetic overflows and division by zero.  The safeint package tries
> to address this, but it only supports the Int type because (as I
> understand it) there are no useful primitives for other common types
> defined in Data.Int and Data.Word.
>
> I've tried adding Int64 support to safeint just to see how it would work
> without primops.  Here's a snippet (I haven't tested this code well, so
> it may be wrong, sorry about that):
>
> shiftRUnsigned :: Word64 -> Int -> Word64
> shiftRUnsigned = shiftR
>
> --
> http://git.haskell.org/ghc.git/blob/HEAD:/compiler/codeGen/StgCmmPrim.hs#l930
> plusSI64 :: SafeInt64 -> SafeInt64 -> SafeInt64
> plusSI64 (SI64 a) (SI64 b) = if c == 0 then SI64 r else overflowError
>   where
>     r = a + b
>     c = (fromIntegral $ (complement (a `xor` b)) .&. (a `xor` r))
>         `shiftRUnsigned`
>         ((finiteBitSize a) - 1)
>
> --
> http://git.haskell.org/ghc.git/blob/HEAD:/compiler/codeGen/StgCmmPrim.hs#l966
> minusSI64 :: SafeInt64 -> SafeInt64 -> SafeInt64
> minusSI64 (SI64 a) (SI64 b) = if c == 0 then SI64 r else overflowError
>   where
>     r = a - b
>     c = (fromIntegral $ (a `xor` b) .&. (a `xor` r))
>         `shiftRUnsigned`
>         ((finiteBitSize a) - 1)
>
> -- https://stackoverflow.com/a/1815371
> timesSI64 :: SafeInt64 -> SafeInt64 -> SafeInt64
> timesSI64 (SI64 a) (SI64 b) =
>   let x = a * b
>   in if a /= 0 && x `div` a /= b
>      then overflowError
>      else SI64 x
>
> I may be wrong, but my understanding is that new primops could reduce
> overhead here.  If so, would a patch adding them be accepted?  Are
> there any caveats?
>
> In the safeint package, would it be reasonable to return an Either
> value instead of throwing an exception?  Or would it be too much?
>
> I haven't created a wiki page or ticket because I don't know much, so
> I want to get some feedback before doing so.  That would be my first
> patch to GHC (if ever), so maybe I'm not the best candidate, but I've
> been thinking about it for too long to ignore. :\
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150628/49129f06/attachment.html>

From simonpj at microsoft.com  Mon Jun 29 07:00:53 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 29 Jun 2015 07:00:53 +0000
Subject: Handling overflow and division by zero
In-Reply-To: <87wpyn4h00.fsf@karetnikov.org>
References: <87wpyn4h00.fsf@karetnikov.org>
Message-ID: <0b59f46065264e4f8d244feed3a1b34b@DB4PR30MB030.064d.mgd.msft.net>

I'm no expert on arithmetic, but I'd have thought that a well-designed and well-documented plan for handling arithmetic exceptions (as values) would be good.

Start a wiki page on the GHC Trac!  

Are there primops for Int, so the only issue is making ones for other types?

S

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Nikita Karetnikov
|  Sent: 28 June 2015 23:15
|  To: ghc-devs at haskell.org
|  Subject: Handling overflow and division by zero
|  
|  Haskell is often marketed as a safe (or safer) language, but there's
|  an issue that makes it less safe as it could be.  I'm talking about
|  arithmetic overflows and division by zero.  The safeint package tries
|  to address this, but it only supports the Int type because (as I
|  understand it) there are no useful primitives for other common types
|  defined in Data.Int and Data.Word.
|  
|  I've tried adding Int64 support to safeint just to see how it would
|  work without primops.  Here's a snippet (I haven't tested this code
|  well, so it may be wrong, sorry about that):
|  
|  shiftRUnsigned :: Word64 -> Int -> Word64 shiftRUnsigned = shiftR
|  
|  --
|  http://git.haskell.org/ghc.git/blob/HEAD:/compiler/codeGen/StgCmmPrim.
|  hs#l930
|  plusSI64 :: SafeInt64 -> SafeInt64 -> SafeInt64
|  plusSI64 (SI64 a) (SI64 b) = if c == 0 then SI64 r else overflowError
|    where
|      r = a + b
|      c = (fromIntegral $ (complement (a `xor` b)) .&. (a `xor` r))
|          `shiftRUnsigned`
|          ((finiteBitSize a) - 1)
|  
|  --
|  http://git.haskell.org/ghc.git/blob/HEAD:/compiler/codeGen/StgCmmPrim.
|  hs#l966
|  minusSI64 :: SafeInt64 -> SafeInt64 -> SafeInt64
|  minusSI64 (SI64 a) (SI64 b) = if c == 0 then SI64 r else overflowError
|    where
|      r = a - b
|      c = (fromIntegral $ (a `xor` b) .&. (a `xor` r))
|          `shiftRUnsigned`
|          ((finiteBitSize a) - 1)
|  
|  -- https://stackoverflow.com/a/1815371
|  timesSI64 :: SafeInt64 -> SafeInt64 -> SafeInt64
|  timesSI64 (SI64 a) (SI64 b) =
|    let x = a * b
|    in if a /= 0 && x `div` a /= b
|       then overflowError
|       else SI64 x
|  
|  I may be wrong, but my understanding is that new primops could reduce
|  overhead here.  If so, would a patch adding them be accepted?  Are
|  there any caveats?
|  
|  In the safeint package, would it be reasonable to return an Either
|  value instead of throwing an exception?  Or would it be too much?
|  
|  I haven't created a wiki page or ticket because I don't know much, so
|  I want to get some feedback before doing so.  That would be my first
|  patch to GHC (if ever), so maybe I'm not the best candidate, but I've
|  been thinking about it for too long to ignore. :\
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From alexander at plaimi.net  Mon Jun 29 07:25:24 2015
From: alexander at plaimi.net (Alexander Berntsen)
Date: Mon, 29 Jun 2015 09:25:24 +0200
Subject: Abstract FilePath Proposal
In-Reply-To: <874mlu8nae.fsf@gnu.org>
References: <874mlu8nae.fsf@gnu.org>
Message-ID: <5590F2E4.3040800@plaimi.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

+1.
- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVkPLeAAoJENQqWdRUGk8BPmAQAIIdqvoB9buiDEUEb9pdKnuf
q/+/iPo65QDTntDx8izQqHPcUt8h/f2u5JG7/S+78mTtzLkn0pkj/pQt3FjhdJwX
hcJz4KFf3IHPRndKRDeGvW21m6A3OS9hxzwyvuzGFtBca3w/xQJVruViY2jto816
YK9VCZGkSoHqkQNBsGs+mh0WKpQ7FTGjHYhytQ0+CflhssWs+auHuf1Fm7sfb62t
2shjFLjnEatv0QnD31dZfHCdSiy0I+Htc5W8boS5w6LW/uAK4QUr6PAt9TTAsYUq
vOD7naeVgcUMuUx9hAkrbaigPbGW+jd2WvDq8C5EH2FRTJnzpY/srHiy+AJA/Yae
l9DkaQxrlTCfn7JXja15Kc+Ln0T7trnc7Xq9hz6AUfM8Tf6aOvL1O03bNXgnoHVP
dAi7KiFC+lOvA37zfZk1Prk6aO5GQi9XLy4lqw9xbMayK4mztB1WTDi6UVBLXJVw
jnxOwL79SnkKt8lt3GJhtFAMV0r+NR1+bFmI/b2bSC+SVCc8lA9D91L/ZdaU+r1d
hzihRbIpl2FhryE4rwXeObymc31xQsrWlTvxLSr0v+QG/uduw77EXJhfWAX505ma
k/C+uwCi8ErBgE81bt6rsXJZfugDZcEQmV9yKZlpQ8ypxVWqhz5GVlHI7If7XYH8
e0v2AHQnrcVQOimk9jCu
=hPFP
-----END PGP SIGNATURE-----

From m at tweag.io  Mon Jun 29 07:47:38 2015
From: m at tweag.io (Boespflug, Mathieu)
Date: Mon, 29 Jun 2015 09:47:38 +0200
Subject: Abstract FilePath Proposal
In-Reply-To: <CAKcFpmKPZ=rYstCmpK1N3KQnfoUuGzOrJRajFBXC6y5-4btxiA@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <558e6de1.63a6700a.5f03.2b03@mx.google.com>
 <CAAbahfSAoQ3ktDLUa=uUNH=vYWbp7X67pb=Smb2ZdAn4WD1Miw@mail.gmail.com>
 <CAKcFpmJ=uvqF6PV-VHt-72Jd5fJkNATG=QVfuK1ZPwfva__fbA@mail.gmail.com>
 <CAJ0eudoZDNLsp4w=OeBPtz3wbiQNGkhyzRzAKu7daE9_6ZbiBQ@mail.gmail.com>
 <CANBN=ms=vnFOjfbP24h5Ta6th4qau3ZookzFAmPHtqhbi5dvoA@mail.gmail.com>
 <CAJ0eudpKPKxRuKVH0k13dnEcX=XsKHvrj7+PathY0xNVFN9MoQ@mail.gmail.com>
 <CAKcFpmKPZ=rYstCmpK1N3KQnfoUuGzOrJRajFBXC6y5-4btxiA@mail.gmail.com>
Message-ID: <CAJ0eudqQqpdZ8nXfr7rz53Hs4SfJUTbZypSWK_Qa7+rDhWwaAA@mail.gmail.com>

Right - given that filepath is a path manipulation library, not tied
to any particular filesystem, and indeed one in which arbitrary
imaginary paths can be manipulated, any normalization under
consideration can only be that which is independent of global system
state. What does happen in practice is that people compare paths
without taking into account that a user might have written "a//b"
where you have an entry for say "a/b" in your database. Normalization
avoids these errors, but I can see the appeal of not interpreting the
byte sequences at all, and the kind of normalization that can be done
without appeal to global system state ends up being smaller than
expected anyways.

So +1 for the proposal as-is.

On 28 June 2015 at 23:09, Neil Mitchell <ndmitchell at gmail.com> wrote:
> When talking about "filepath" specifically as something you prod at a
> specific file system, you can think about normalisation, provided you
> have a specific drive in mind. However, if you're going to do that, on
> Linux it's almost better to use an inode number. I have two specific
> problems with normalisation:
>
> * You might hope for the property that after normalisation equality of
> file locations is equality of FilePath values. That's not true. On
> Linux you have symlinks. On Windows you have case sensitivity, which
> is a property of the filesystem, not the OS. You might be able to
> assume a == b ==> same a b, but you can never assume a /= b ==> not
> (same a b), so normalisation doesn't really change the guarantee.
>
> * I believe some Emacs user once told me that a//b is not the same as
> a/b in some circumstances. On Windows, there are lots of programs that
> require / or \. Some programs require ./foo and some require foo. The
> exact path you pass to some programs gets baked into their output,
> which is visible in the final release. While paths might be equal for
> the purpose of asking a file system to get some bytes back, they are
> often different for the other things people want to do with them, like
> pass them to other programs that use the paths.
>
>
>
> On Sun, Jun 28, 2015 at 3:47 PM, Boespflug, Mathieu <m at tweag.io> wrote:
>> On 28 June 2015 at 16:34, Sven Panne <svenpanne at gmail.com> wrote:
>>> 2015-06-28 12:03 GMT+02:00 Boespflug, Mathieu <m at tweag.io>:
>>>>
>>>> why does the proposal *not* include normalization? [...]
>>>
>>>
>>> I think this is intentional, because otherwise we are in the IO monad for
>>> basically all operations. What's the normalized representation of
>>> "foo/bar/../baz"?
>>
>> Notice that the kind of normalization I'm talking about, specified in
>> the link I provided, does not include this kind of normalization.
>> Because it requires the IO monad to perform correctly, and only on
>> real paths.
>>
>> Here is the link again:
>>
>> https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-Posix.html#v:normalise
>>
>> Full canonicalization of paths, stripping out redundant ".." and
>> whatnot, should certainly be done in a separate function, in IO.
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

From hesselink at gmail.com  Mon Jun 29 08:38:51 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Mon, 29 Jun 2015 10:38:51 +0200
Subject: Abstract FilePath Proposal
In-Reply-To: <874mlu8nae.fsf@gnu.org>
References: <874mlu8nae.fsf@gnu.org>
Message-ID: <CAPeieQGJ0zeFZM43e5sdVkHav82EW8rsP7Wsb4HHpGeXFw2Dhw@mail.gmail.com>

I think this proposal is currently underspecified. For example, it's
not clear to me what the semantics of a FilePath are. I have the
feeling that `toFilePah` should return a Maybe, for example, but it's
hard to say without knowing what it's converting to, exactly.

I also worry about the immense breakage this will cause. This is not
just an issue of causing a lot of work for maintainers, but also of
lots of unmaintained libraries, printed code etc breaking. I feel that
there is not enough gain in this proposal relative to the amount of
breakage.

Has any thought been given to introduce new modules for this type, and
leave the old ones in place?

Erik

On Fri, Jun 26, 2015 at 6:08 PM, Herbert Valerio Riedel <hvr at gnu.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello *,
>
> What?
> =====
>
> We (see From: & CC: headers) propose, plain and simple, to turn the
> currently defined type-synonym
>
>   type FilePath = String
>
> into an abstract/opaque data type instead.
>
> Why/How/When?
> =============
>
> For details (including motivation and a suggested transition scheme)
> please consult
>
>   https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath
>
>
>
> Suggested discussion period: 4 weeks
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
> BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
> YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
> 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
> koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
> qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
> KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
> NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
> tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
> awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
> aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
> HjIPRrJbVK9AABo4AZ/Y
> =lg0o
> -----END PGP SIGNATURE-----
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From michael at snoyman.com  Mon Jun 29 08:46:08 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Mon, 29 Jun 2015 08:46:08 +0000
Subject: Abstract FilePath Proposal
In-Reply-To: <CAPeieQGJ0zeFZM43e5sdVkHav82EW8rsP7Wsb4HHpGeXFw2Dhw@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <CAPeieQGJ0zeFZM43e5sdVkHav82EW8rsP7Wsb4HHpGeXFw2Dhw@mail.gmail.com>
Message-ID: <CAKA2JgLMF=VXPxyHh92c-ncM8jjy56g+nAnjGYZL0xijvrCRNw@mail.gmail.com>

Regarding underspecified: I think that's appropriate at this phase. The
main proposal is: maybe FilePath an abstract type. It will take multiple
GHC releases before we switch over fully, with plenty of time to hash out
details of how the filepath package should work, and the opportunity to
experiment with different wrappers around a core abstract type.

Having used an alternate FilePath type for a while (via system-filepath), I
can say that it doesn't give the same benefit of just fixing the central
FilePath type. Having to convert between types all over the place is
tedious, defeats a lot of the performance benefits we're going for, and
hurts type safety.

As someone who typically is very much opposed to breaking changes in core
libraries: I think this one is well worth it.

On Mon, Jun 29, 2015 at 11:39 AM Erik Hesselink <hesselink at gmail.com> wrote:

> I think this proposal is currently underspecified. For example, it's
> not clear to me what the semantics of a FilePath are. I have the
> feeling that `toFilePah` should return a Maybe, for example, but it's
> hard to say without knowing what it's converting to, exactly.
>
> I also worry about the immense breakage this will cause. This is not
> just an issue of causing a lot of work for maintainers, but also of
> lots of unmaintained libraries, printed code etc breaking. I feel that
> there is not enough gain in this proposal relative to the amount of
> breakage.
>
> Has any thought been given to introduce new modules for this type, and
> leave the old ones in place?
>
> Erik
>
> On Fri, Jun 26, 2015 at 6:08 PM, Herbert Valerio Riedel <hvr at gnu.org>
> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hello *,
> >
> > What?
> > =====
> >
> > We (see From: & CC: headers) propose, plain and simple, to turn the
> > currently defined type-synonym
> >
> >   type FilePath = String
> >
> > into an abstract/opaque data type instead.
> >
> > Why/How/When?
> > =============
> >
> > For details (including motivation and a suggested transition scheme)
> > please consult
> >
> >   https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath
> >
> >
> >
> > Suggested discussion period: 4 weeks
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> >
> > iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
> > BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
> > YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
> > 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
> > koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
> > qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
> > KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
> > NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
> > tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
> > awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
> > aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
> > HjIPRrJbVK9AABo4AZ/Y
> > =lg0o
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150629/114c0b24/attachment.html>

From hesselink at gmail.com  Mon Jun 29 09:07:36 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Mon, 29 Jun 2015 11:07:36 +0200
Subject: Abstract FilePath Proposal
In-Reply-To: <CAKA2JgLMF=VXPxyHh92c-ncM8jjy56g+nAnjGYZL0xijvrCRNw@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <CAPeieQGJ0zeFZM43e5sdVkHav82EW8rsP7Wsb4HHpGeXFw2Dhw@mail.gmail.com>
 <CAKA2JgLMF=VXPxyHh92c-ncM8jjy56g+nAnjGYZL0xijvrCRNw@mail.gmail.com>
Message-ID: <CAPeieQGi5Ti73UjkL4PoXJpnd3-jGM4hm_u0thnGZCOdoCq7kQ@mail.gmail.com>

On Mon, Jun 29, 2015 at 10:46 AM, Michael Snoyman <michael at snoyman.com> wrote:
> Regarding underspecified: I think that's appropriate at this phase. The main
> proposal is: maybe FilePath an abstract type. It will take multiple GHC
> releases before we switch over fully, with plenty of time to hash out
> details of how the filepath package should work, and the opportunity to
> experiment with different wrappers around a core abstract type.

But changing the semantics of an established newtype is very tricky
business, since the resulting breakage won't be indicated by the
types!

> Having used an alternate FilePath type for a while (via system-filepath), I
> can say that it doesn't give the same benefit of just fixing the central
> FilePath type. Having to convert between types all over the place is
> tedious, defeats a lot of the performance benefits we're going for, and
> hurts type safety.

Why would you have to convert 'all over the place'? If the alternative
library also provides the basic IO functions, the only places you'd
have to convert are interfaces with other libraries, and things from
e.g. config file, both of which don't happen a lot.

> As someone who typically is very much opposed to breaking changes in core
> libraries: I think this one is well worth it.

Do you have any insight in the amount of breakage this will cause? I
have a gut feeling that it's a lot more than any of the previous
changes we've had, and those have already caused a lot of grumbling.
But the only way to be sure is to run the builds on hackage (or
stackage, but that's a smaller sample size).

Erik

> On Mon, Jun 29, 2015 at 11:39 AM Erik Hesselink <hesselink at gmail.com> wrote:
>>
>> I think this proposal is currently underspecified. For example, it's
>> not clear to me what the semantics of a FilePath are. I have the
>> feeling that `toFilePah` should return a Maybe, for example, but it's
>> hard to say without knowing what it's converting to, exactly.
>>
>> I also worry about the immense breakage this will cause. This is not
>> just an issue of causing a lot of work for maintainers, but also of
>> lots of unmaintained libraries, printed code etc breaking. I feel that
>> there is not enough gain in this proposal relative to the amount of
>> breakage.
>>
>> Has any thought been given to introduce new modules for this type, and
>> leave the old ones in place?
>>
>> Erik
>>
>> On Fri, Jun 26, 2015 at 6:08 PM, Herbert Valerio Riedel <hvr at gnu.org>
>> wrote:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > Hello *,
>> >
>> > What?
>> > =====
>> >
>> > We (see From: & CC: headers) propose, plain and simple, to turn the
>> > currently defined type-synonym
>> >
>> >   type FilePath = String
>> >
>> > into an abstract/opaque data type instead.
>> >
>> > Why/How/When?
>> > =============
>> >
>> > For details (including motivation and a suggested transition scheme)
>> > please consult
>> >
>> >   https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath
>> >
>> >
>> >
>> > Suggested discussion period: 4 weeks
>> > -----BEGIN PGP SIGNATURE-----
>> > Version: GnuPG v1
>> >
>> > iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
>> > BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
>> > YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
>> > 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
>> > koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
>> > qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
>> > KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
>> > NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
>> > tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
>> > awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
>> > aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
>> > HjIPRrJbVK9AABo4AZ/Y
>> > =lg0o
>> > -----END PGP SIGNATURE-----
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From michael at snoyman.com  Mon Jun 29 09:22:49 2015
From: michael at snoyman.com (Michael Snoyman)
Date: Mon, 29 Jun 2015 09:22:49 +0000
Subject: Abstract FilePath Proposal
In-Reply-To: <CAPeieQGi5Ti73UjkL4PoXJpnd3-jGM4hm_u0thnGZCOdoCq7kQ@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <CAPeieQGJ0zeFZM43e5sdVkHav82EW8rsP7Wsb4HHpGeXFw2Dhw@mail.gmail.com>
 <CAKA2JgLMF=VXPxyHh92c-ncM8jjy56g+nAnjGYZL0xijvrCRNw@mail.gmail.com>
 <CAPeieQGi5Ti73UjkL4PoXJpnd3-jGM4hm_u0thnGZCOdoCq7kQ@mail.gmail.com>
Message-ID: <CAKA2JgJHtyk3uRAdxgda_M0bxSPJAbh6Vzm+6a8b813JRmYubA@mail.gmail.com>

On Mon, Jun 29, 2015 at 12:07 PM Erik Hesselink <hesselink at gmail.com> wrote:

> On Mon, Jun 29, 2015 at 10:46 AM, Michael Snoyman <michael at snoyman.com>
> wrote:
> > Regarding underspecified: I think that's appropriate at this phase. The
> main
> > proposal is: maybe FilePath an abstract type. It will take multiple GHC
> > releases before we switch over fully, with plenty of time to hash out
> > details of how the filepath package should work, and the opportunity to
> > experiment with different wrappers around a core abstract type.
>
> But changing the semantics of an established newtype is very tricky
> business, since the resulting breakage won't be indicated by the
> types!
>
>
My suggestion isn't to roll out one breaking change and then another silent
semantics change later. Rather, my point is: getting FilePath to be an
abstract type is the meat of the proposal, and what we need to agree on.
Working out the exact semantics of how the filepath package interacts with
that is important, but not urgent. Let's get to an agreement that an
abstract type is an improvement, and then we can figure out exactly how it
should behave. After all, we'll have about 2 years to figure that out.


> > Having used an alternate FilePath type for a while (via
> system-filepath), I
> > can say that it doesn't give the same benefit of just fixing the central
> > FilePath type. Having to convert between types all over the place is
> > tedious, defeats a lot of the performance benefits we're going for, and
> > hurts type safety.
>
> Why would you have to convert 'all over the place'? If the alternative
> library also provides the basic IO functions, the only places you'd
> have to convert are interfaces with other libraries, and things from
> e.g. config file, both of which don't happen a lot.
>
>
By having two different types, we know that not everyone will convert over.
In fact, the very argument for having two types is so that not everyone
will need to convert. Especially if Prelude continues to export the current
`type FilePath = [Char]`, it will be difficult to get all libraries to use
the new type.


> > As someone who typically is very much opposed to breaking changes in core
> > libraries: I think this one is well worth it.
>
> Do you have any insight in the amount of breakage this will cause? I
> have a gut feeling that it's a lot more than any of the previous
> changes we've had, and those have already caused a lot of grumbling.
> But the only way to be sure is to run the builds on hackage (or
> stackage, but that's a smaller sample size).
>
>
I agree, this is going to be a big one. It does not lend itself to elegant
migrations like FTP did, for instance. But the scope of the current problem
is also large, which is why I believe this breakage is warranted. Doing it
gradually with a deprecation plan will hopefully make it possible for us to
make it as easy as possible.


> Erik
>
> > On Mon, Jun 29, 2015 at 11:39 AM Erik Hesselink <hesselink at gmail.com>
> wrote:
> >>
> >> I think this proposal is currently underspecified. For example, it's
> >> not clear to me what the semantics of a FilePath are. I have the
> >> feeling that `toFilePah` should return a Maybe, for example, but it's
> >> hard to say without knowing what it's converting to, exactly.
> >>
> >> I also worry about the immense breakage this will cause. This is not
> >> just an issue of causing a lot of work for maintainers, but also of
> >> lots of unmaintained libraries, printed code etc breaking. I feel that
> >> there is not enough gain in this proposal relative to the amount of
> >> breakage.
> >>
> >> Has any thought been given to introduce new modules for this type, and
> >> leave the old ones in place?
> >>
> >> Erik
> >>
> >> On Fri, Jun 26, 2015 at 6:08 PM, Herbert Valerio Riedel <hvr at gnu.org>
> >> wrote:
> >> > -----BEGIN PGP SIGNED MESSAGE-----
> >> > Hash: SHA1
> >> >
> >> > Hello *,
> >> >
> >> > What?
> >> > =====
> >> >
> >> > We (see From: & CC: headers) propose, plain and simple, to turn the
> >> > currently defined type-synonym
> >> >
> >> >   type FilePath = String
> >> >
> >> > into an abstract/opaque data type instead.
> >> >
> >> > Why/How/When?
> >> > =============
> >> >
> >> > For details (including motivation and a suggested transition scheme)
> >> > please consult
> >> >
> >> >   https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath
> >> >
> >> >
> >> >
> >> > Suggested discussion period: 4 weeks
> >> > -----BEGIN PGP SIGNATURE-----
> >> > Version: GnuPG v1
> >> >
> >> > iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
> >> > BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
> >> > YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
> >> > 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
> >> > koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
> >> > qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
> >> > KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
> >> > NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
> >> > tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
> >> > awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
> >> > aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
> >> > HjIPRrJbVK9AABo4AZ/Y
> >> > =lg0o
> >> > -----END PGP SIGNATURE-----
> >> > _______________________________________________
> >> > ghc-devs mailing list
> >> > ghc-devs at haskell.org
> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150629/fea5a251/attachment-0001.html>

From dct25-561bs at mythic-beasts.com  Mon Jun 29 09:27:24 2015
From: dct25-561bs at mythic-beasts.com (David Turner)
Date: Mon, 29 Jun 2015 10:27:24 +0100
Subject: Abstract FilePath Proposal
In-Reply-To: <874mlu8nae.fsf@gnu.org>
References: <874mlu8nae.fsf@gnu.org>
Message-ID: <CAErCyQ-Ux3kU-74_9tkZL12hpa7FDppnwE-kEJyfBL9Anfhy1A@mail.gmail.com>

One tiny amendment to a comment(!) in the non-normative(!) code in Phase 3:

data WindowsFilePath = WFP ByteArray# -- UTF16 data


If a Windows file path is valid UTF-16 then it is displayed as such in the
GUI, but if not it's still a legal file path. It really is just wchar_t[]
data:

data WindowsFilePath = WFP ByteArray# -- wchar_t[] data as passed to syscalls


This seems to be the source of some confusion.


Cheers,


David



On 26 June 2015 at 17:08, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello *,
>
> What?
> =====
>
> We (see From: & CC: headers) propose, plain and simple, to turn the
> currently defined type-synonym
>
>   type FilePath = String
>
> into an abstract/opaque data type instead.
>
> Why/How/When?
> =============
>
> For details (including motivation and a suggested transition scheme)
> please consult
>
>   https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath
>
>
>
> Suggested discussion period: 4 weeks
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
> BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
> YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
> 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
> koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
> qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
> KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
> NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
> tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
> awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
> aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
> HjIPRrJbVK9AABo4AZ/Y
> =lg0o
> -----END PGP SIGNATURE-----
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150629/1591427e/attachment.html>

From marlowsd at gmail.com  Mon Jun 29 09:28:40 2015
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 29 Jun 2015 10:28:40 +0100
Subject: arc land failing
Message-ID: <55910FC8.5010605@gmail.com>

I haven't been able to arc land in GHC for a while, it always complains 
about not being able to fast-forward, like this:

$ git pull --rebase
First, rewinding head to replay your work on top of it...
Applying: Mask to avoid uncaught ^C exceptions
$ arc land
Landing current branch 'ghci-mask'.
Switched to branch master. Updating branch...
Switched back to branch ghci-mask.
Exception
Command failed with error #128!
COMMAND
git pull --ff-only --no-stat

STDOUT
(empty)

STDERR
fatal: Not possible to fast-forward, aborting.

(Run with --trace for a full exception trace.)
[1]    11904 exit 1     arc land


Anyone able to look into this?

Cheers,
Simon

From alois.cochard at gmail.com  Mon Jun 29 09:57:46 2015
From: alois.cochard at gmail.com (Alois Cochard)
Date: Mon, 29 Jun 2015 11:57:46 +0200
Subject: Abstract FilePath Proposal
In-Reply-To: <CAErCyQ-Ux3kU-74_9tkZL12hpa7FDppnwE-kEJyfBL9Anfhy1A@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <CAErCyQ-Ux3kU-74_9tkZL12hpa7FDppnwE-kEJyfBL9Anfhy1A@mail.gmail.com>
Message-ID: <CAJHA+wqZL4-JUb9v-tUq=76sk=cSxA+s1UjE8CTxnKtkmtCpmg@mail.gmail.com>

+1 for the first two phase of the original proposal. I always wished it was
not a type alias.

No strong opinion of phase 3, I have propabaly never run into sophisticated
enough issues to fully get the picture... but I doubt we'll be able to
craft an ideal cross-platform API, I like what is in spirit in the original
proposal.

On 29 June 2015 at 11:27, David Turner <dct25-561bs at mythic-beasts.com>
wrote:

> One tiny amendment to a comment(!) in the non-normative(!) code in Phase 3:
>
> data WindowsFilePath = WFP ByteArray# -- UTF16 data
>
>
> If a Windows file path is valid UTF-16 then it is displayed as such in the
> GUI, but if not it's still a legal file path. It really is just wchar_t[]
> data:
>
> data WindowsFilePath = WFP ByteArray# -- wchar_t[] data as passed to syscalls
>
>
> This seems to be the source of some confusion.
>
>
> Cheers,
>
>
> David
>
>
>
> On 26 June 2015 at 17:08, Herbert Valerio Riedel <hvr at gnu.org> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello *,
>>
>> What?
>> =====
>>
>> We (see From: & CC: headers) propose, plain and simple, to turn the
>> currently defined type-synonym
>>
>>   type FilePath = String
>>
>> into an abstract/opaque data type instead.
>>
>> Why/How/When?
>> =============
>>
>> For details (including motivation and a suggested transition scheme)
>> please consult
>>
>>   https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath
>>
>>
>>
>> Suggested discussion period: 4 weeks
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
>> BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
>> YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
>> 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
>> koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
>> qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
>> KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
>> NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
>> tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
>> awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
>> aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
>> HjIPRrJbVK9AABo4AZ/Y
>> =lg0o
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


-- 
*?\ois*
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150629/66322262/attachment.html>

From mail at joachim-breitner.de  Mon Jun 29 13:01:24 2015
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 29 Jun 2015 15:01:24 +0200
Subject: [Diffusion] [Build Failed] rGHC0aaea5b8345f: Tiny refactor plus
 comments
In-Reply-To: <1435342588.25795.1.camel@joachim-breitner.de>
References: <diffusion-audit-PHID-CMIT-v6iku3mmohsk3fftrbcl@phabricator.haskell.org>
 <20150626154710.15386.27836@phabricator.haskell.org>
 <ef3e412c0d1f49e8a8ca3959d1e84490@DB4PR30MB030.064d.mgd.msft.net>
 <1435342588.25795.1.camel@joachim-breitner.de>
Message-ID: <1435582884.1257.16.camel@joachim-breitner.de>

Hi,

Am Freitag, den 26.06.2015, 20:16 +0200 schrieb Joachim Breitner:
> Am Freitag, den 26.06.2015, 16:40 +0000 schrieb Simon Peyton Jones:
> > The builds seem to be failing with perf failures for
> > 	> > haddock.Cabal
> > 	> > haddock.compiler
> > 
> > but that doesn't seem to happen for me.  It looks as though it 
> > started with
> > 
> >     rGHC*rGHC0b7e538a09bc: Allow recursive unwrapping of data 
> > families
> 
> I can confirm this, if you look at 
> https://perf.haskell.org/ghc/
> you see that that commit is the only in red?
> 
> Here is the report for that commit:
> https://perf.haskell.org/ghc/#revision/0b7e538a09bc958474ec704063eaa088
> 36e9270e
> and you can fetch the numbers from there, or from the full build log at
> https://raw.githubusercontent.com/nomeata/ghc-speed-logs/master/0b7e538a09bc958474ec704063eaa08836e9270e.log
> 
> It looks very reproducible as well:
> https://perf.haskell.org/ghc/#graph/tests/alloc/haddock.Cabal;hl=0b7e53
> 8a09bc958474ec704063eaa08836e9270e

has this confusion cleared up? According to
https://perf.haskell.org/ghc/#graph/testsuite/unexpected%20stats;hl=0b7
e538a09bc958474ec704063eaa08836e9270e
these tests are still failing on my machine.

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150629/e089058a/attachment.sig>

From simonpj at microsoft.com  Mon Jun 29 13:03:17 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 29 Jun 2015 13:03:17 +0000
Subject: [Diffusion] [Build Failed] rGHC0aaea5b8345f: Tiny refactor plus
 comments
In-Reply-To: <1435582884.1257.16.camel@joachim-breitner.de>
References: <diffusion-audit-PHID-CMIT-v6iku3mmohsk3fftrbcl@phabricator.haskell.org>
 <20150626154710.15386.27836@phabricator.haskell.org>
 <ef3e412c0d1f49e8a8ca3959d1e84490@DB4PR30MB030.064d.mgd.msft.net>
 <1435342588.25795.1.camel@joachim-breitner.de>
 <1435582884.1257.16.camel@joachim-breitner.de>
Message-ID: <51bce40f28a744ee937768cc4993629b@DB4PR30MB030.064d.mgd.msft.net>

It has not, alas.  We can revert the change or mark them as broken on the ticket. Then I'll investigate, but #10527 seems like higher priority 

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Joachim Breitner
|  Sent: 29 June 2015 14:01
|  To: ghc-devs at haskell.org
|  Subject: Re: [Diffusion] [Build Failed] rGHC0aaea5b8345f: Tiny
|  refactor plus comments
|  
|  Hi,
|  
|  Am Freitag, den 26.06.2015, 20:16 +0200 schrieb Joachim Breitner:
|  > Am Freitag, den 26.06.2015, 16:40 +0000 schrieb Simon Peyton Jones:
|  > > The builds seem to be failing with perf failures for
|  > > 	> > haddock.Cabal
|  > > 	> > haddock.compiler
|  > >
|  > > but that doesn't seem to happen for me.  It looks as though it
|  > > started with
|  > >
|  > >     rGHC*rGHC0b7e538a09bc: Allow recursive unwrapping of data
|  > > families
|  >
|  > I can confirm this, if you look at
|  > https://perf.haskell.org/ghc/
|  > you see that that commit is the only in red?
|  >
|  > Here is the report for that commit:
|  >
|  https://perf.haskell.org/ghc/#revision/0b7e538a09bc958474ec704063eaa08
|  > 8
|  > 36e9270e
|  > and you can fetch the numbers from there, or from the full build log
|  > at
|  > https://raw.githubusercontent.com/nomeata/ghc-speed-
|  logs/master/0b7e53
|  > 8a09bc958474ec704063eaa08836e9270e.log
|  >
|  > It looks very reproducible as well:
|  >
|  https://perf.haskell.org/ghc/#graph/tests/alloc/haddock.Cabal;hl=0b7e5
|  > 3
|  > 8a09bc958474ec704063eaa08836e9270e
|  
|  has this confusion cleared up? According to
|  https://perf.haskell.org/ghc/#graph/testsuite/unexpected%20stats;hl=0b
|  7
|  e538a09bc958474ec704063eaa08836e9270e
|  these tests are still failing on my machine.
|  
|  Greetings,
|  Joachim
|  
|  --
|  Joachim ?nomeata? Breitner
|    mail at joachim-breitner.de ? http://www.joachim-breitner.de/
|    Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
|    Debian Developer: nomeata at debian.org

From ndmitchell at gmail.com  Tue Jun 30 09:25:02 2015
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Tue, 30 Jun 2015 10:25:02 +0100
Subject: Abstract FilePath Proposal
In-Reply-To: <CAErCyQ-Ux3kU-74_9tkZL12hpa7FDppnwE-kEJyfBL9Anfhy1A@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <CAErCyQ-Ux3kU-74_9tkZL12hpa7FDppnwE-kEJyfBL9Anfhy1A@mail.gmail.com>
Message-ID: <CAKcFpmK1-LxzpdzHbXULyLGYYzL6yUJX-GtDy40aQ=fyj0ncug@mail.gmail.com>

Hi David,

> One tiny amendment to a comment(!) in the non-normative(!) code in Phase 3:
>
> data WindowsFilePath = WFP ByteArray# -- UTF16 data
>
> If a Windows file path is valid UTF-16 then it is displayed as such in the
> GUI, but if not it's still a legal file path. It really is just wchar_t[]
> data.

Thanks for bringing this up. It's tricky - I think in practice:

toFilePath x = WPF (encodeStringAsUTF16 x)

But the data in WPF will be treated as UCS2 (aka wchar_t) when passing
to the API calls, so it's really both. While on Windows NT it really
was UCS2, but Win 7 it's always treated as UTF16 in the GUI, so that
seems to be consistent with what people expect and ensures we don't
throw away information when converting to/from FilePath. Given it
seems you are quite knowledgeable in this area, please shout if that
seems misguided!

To all the people who are worried about breakage, I can guarantee this
will cause breakage. It's a sad fact, and certainly the main negative
to this proposal. I was on the fence initially when hvr suggested this
change to me, but was convinced by performance and correctness.
Whether the Haskell community as a whole thinks that makes it worth it
is why it's a proposal. If anything, I'm concerned by the lack of
people saying -1, please don't break my code...

Thanks, Neil

From hesselink at gmail.com  Tue Jun 30 09:45:36 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 30 Jun 2015 11:45:36 +0200
Subject: Abstract FilePath Proposal
In-Reply-To: <CAKcFpmK1-LxzpdzHbXULyLGYYzL6yUJX-GtDy40aQ=fyj0ncug@mail.gmail.com>
References: <874mlu8nae.fsf@gnu.org>
 <CAErCyQ-Ux3kU-74_9tkZL12hpa7FDppnwE-kEJyfBL9Anfhy1A@mail.gmail.com>
 <CAKcFpmK1-LxzpdzHbXULyLGYYzL6yUJX-GtDy40aQ=fyj0ncug@mail.gmail.com>
Message-ID: <CAPeieQH=uD4XBzdgtXGr-43XwKYfb4z_4qv2ApzUyT5sjsgyGg@mail.gmail.com>

On Tue, Jun 30, 2015 at 11:25 AM, Neil Mitchell <ndmitchell at gmail.com> wrote:
> To all the people who are worried about breakage, I can guarantee this
> will cause breakage. It's a sad fact, and certainly the main negative
> to this proposal. I was on the fence initially when hvr suggested this
> change to me, but was convinced by performance and correctness.
> Whether the Haskell community as a whole thinks that makes it worth it
> is why it's a proposal. If anything, I'm concerned by the lack of
> people saying -1, please don't break my code...

I'm not convinced by the performance argument. Most people don't need
performance from the small amount of FilePath usage they have. Those
who do can switch to a different package. Now correctness would be a
good argument, but this proposal doesn't really add that much in that
respect, it seems.

I'm still on the fence, but leaning towards -1, but I'm not saying
please don't break my code. My code will be fine, I'm around to fix
it. I'm more worried about other people's code (that I might rely on),
maintainers that have left, or aren't that responsive, newcomers
reading old tutorials, people getting angry about needing more
CPP/fixing more code on new GHC releases, etc. We're still breaking
code on every new GHC release, and it seems the amount of breakage is
only increasing.

Erik