From simonpj at microsoft.com  Tue Mar  1 11:33:10 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 1 Mar 2016 11:33:10 +0000
Subject: Patches/proposals waiting for review
In-Reply-To: <CAD3WKghtgJ9JAUX=UoFtG8kpAYC6CNjyp7nw-H6twiNYLYyoPA@mail.gmail.com>
References: <CAD3WKghtgJ9JAUX=UoFtG8kpAYC6CNjyp7nw-H6twiNYLYyoPA@mail.gmail.com>
Message-ID: <1454081da04a418daac602c0c28ec6ce@DB4PR30MB030.064d.mgd.msft.net>

Thomas (and others)

Thanks for the summary.

I?m painfully aware of these ? though I didn?t know about the ?Block others? link, thank you.

But I?m under the gun for (a) GHC 8.0 and (b) ICFP deadline on 16 March.  I believe that none of these three are on the must-do list for 8.0 which is why I?ve been deferring.

I feel bad but I?m just over-subscribed. Post ICFP will be easier.

Simon

From: Thomas Miedema [mailto:thomasmiedema at gmail.com]
Sent: 24 February 2016 14:30
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: aovieth at gmail.com; rik at ewps.nl; acowley at seas.upenn.edu; ghc-devs at haskell.org
Subject: Patches/proposals waiting for review

Hi Simon,

the following issues are waiting for your review:

* https://phabricator.haskell.org/D1762
 "Fix #11348 handle instance dependencies"
by Alexander Vieth

* https://phabricator.haskell.org/D1896
 "Improve printing of pattern synonym types"
by Rik Steenkamp

* https://ghc.haskell.org/trac/ghc/wiki/ShorterImportSyntax
by Anthony Cowley

Maybe others, they should show up under "Blocking Others" when you go to https://phabricator.haskell.org/

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160301/17ce85aa/attachment.html>

From hesselink at gmail.com  Tue Mar  1 12:16:06 2016
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 1 Mar 2016 13:16:06 +0100
Subject: GHC 8.0.1 status
In-Reply-To: <87wppqz26d.fsf@smart-cactus.org>
References: <87wppqz26d.fsf@smart-cactus.org>
Message-ID: <CAPeieQEpp2xpmfny41me+aWP3hKN=rXCEHZGvpSFZdfsBLyLLw@mail.gmail.com>

I've found what I believe to be a regression in GHC 8 rc2 [1], and the
wiki says to yell if I want to bring it to the attention of GHC
developers. So this is me yelling, I guess :) I'm not sure if this bug
is important enough to be included, but I think it would be good for
someone to look at it and make that call. It's at least breaking one
package that I maintain (but it can be worked around).

Erik

[1] https://ghc.haskell.org/trac/ghc/ticket/11662

On 27 February 2016 at 14:57, Ben Gamari <ben at well-typed.com> wrote:
> tl;dr. Stabilizing the ghc-8.0 is taking a bit longer than was anticipated.
>        The release schedule is being pushed back a bit.
>
>
> Hello everyone,
>
> As you likely know we are currently in the depths of the 8.0 release. In
> fact, under more ideal circumstances I would probably be cutting another
> release candidate right now instead of writing this email, in
> preparation for a final release next week or so.
>
> However, our world is far from ideal as evidenced by the number
> [1] of significant bugs present on the 8.0 branch. This isn't altogether
> unexpected; we knew we were taking a bit of a risk in merging so many
> high-impact patches in one release. However, we thought that given a
> longer-than-usual period between first-candidate and the final release,
> we'd have enough time to smooth out the wrinkles. Sadly, this has taken
> a bit longer than we anticipated.
>
> Of course, the last thing we want is to push a known buggy release out
> the door. Consequently, we won't be delivering the 8.0.1 release next
> week as originally planned. Instead, we'll be pushing the release back
> by about three weeks. This will give developers a bit more breathing
> room in which to work out the remaining issues. Hopefully in a few weeks
> the tree will be in such a state that we can push out yet another
> candidate which, with luck, will be the last before the release.
>
> If you'd like to expedite the process (and have fun in the process), you
> could do worse than to having a look at Trac [1], choosing a bug of your
> liking, and trying your hand at solving it.
>
> Thanks to everyone who has contributed to this effort thusfar.
> If you have any questions about the release process or how you can help,
> don't hesistate to ask.
>
> Cheers,
>
> - Ben
>
>
> [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From ben at well-typed.com  Tue Mar  1 12:24:55 2016
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 01 Mar 2016 13:24:55 +0100
Subject: GHC 8.0.1 status
In-Reply-To: <CAPeieQEpp2xpmfny41me+aWP3hKN=rXCEHZGvpSFZdfsBLyLLw@mail.gmail.com>
References: <87wppqz26d.fsf@smart-cactus.org>
 <CAPeieQEpp2xpmfny41me+aWP3hKN=rXCEHZGvpSFZdfsBLyLLw@mail.gmail.com>
Message-ID: <87k2lmz8q0.fsf@smart-cactus.org>

Erik Hesselink <hesselink at gmail.com> writes:

> I've found what I believe to be a regression in GHC 8 rc2 [1], and the
> wiki says to yell if I want to bring it to the attention of GHC
> developers. So this is me yelling, I guess :) I'm not sure if this bug
> is important enough to be included, but I think it would be good for
> someone to look at it and make that call. It's at least breaking one
> package that I maintain (but it can be worked around).
>
Thanks Erik!

Indeed this looks to me to be a regression.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160301/8b4a0bb3/attachment.sig>

From anton.dessiatov at gmail.com  Tue Mar  1 15:24:59 2016
From: anton.dessiatov at gmail.com (=?UTF-8?B?0JDQvdGC0L7QvSDQlNC10YHRj9GC0L7Qsg==?=)
Date: Tue, 1 Mar 2016 21:24:59 +0600
Subject: Simple "Hello World" Warp-based web server crashes on Ubuntu x86_64
Message-ID: <CAGkP6gMHstx0HFqxd7Fg3Z-U-eFPFTE8_p142JJeu6nLdv5Wdg@mail.gmail.com>

Hello dear GHC developers,

I have recently experienced what I believe to be a bug either in GHC or in
Warp library (if it is indeed in Warp then sorry for posting to wrong
mailing list). I've managed to shrink it to a few lines of code and publish
on a GitHub. Here is the link:
https://github.com/anton-dessiatov/warp-ghc-issue

What I wanted to do is to establish network connection in my code and then
at some point pass it to Warp for further processing. What I got is that
after successfully processing first HTTP request my program consumes 100%
CPU and eventually crashes with an error like this:

*** Error in
`/home/farnsworth/work/warp-ghc-issue/.stack-work/install/x86_64-linux/lts-5.5/7.10.3/bin/warp-ghc-issue':
double free or corruption (!prev): 0x00000000016214b0 ***
Aborted (core dumped)

When compiled with -debug I see another message:

repro: internal error: ASSERTION FAILED: file rts/Schedule.h, line 137

    (GHC version 7.10.3 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Aborted (core dumped)

I tried to debug it by enabling -dcore-lint and -debug in my
~/.stack/config.yaml and what worries me is that in this case Warp itself
doesn't compile (tried with 7.10.2 and 7.10.3) giving core lint failure in
Network.Wai.Handler.Warp.HTTP2.Worker. Not sure if it is relevant, but
looks suspicious.

Could anybody please try building my code on x64 Linux, run it, open
localhost:8080 in a web browser and confirm that there is indeed a bug?

Regards,
  Anton.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160301/a1bc12b5/attachment.html>

From ben at well-typed.com  Tue Mar  1 15:53:38 2016
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 01 Mar 2016 16:53:38 +0100
Subject: Simple "Hello World" Warp-based web server crashes on Ubuntu
 x86_64
In-Reply-To: <CAGkP6gMHstx0HFqxd7Fg3Z-U-eFPFTE8_p142JJeu6nLdv5Wdg@mail.gmail.com>
References: <CAGkP6gMHstx0HFqxd7Fg3Z-U-eFPFTE8_p142JJeu6nLdv5Wdg@mail.gmail.com>
Message-ID: <87h9gqyz25.fsf@smart-cactus.org>

????? ??????? <anton.dessiatov at gmail.com> writes:

> Hello dear GHC developers,
>
> I have recently experienced what I believe to be a bug either in GHC or in
> Warp library (if it is indeed in Warp then sorry for posting to wrong
> mailing list). I've managed to shrink it to a few lines of code and publish
> on a GitHub. Here is the link:
> https://github.com/anton-dessiatov/warp-ghc-issue
>
> What I wanted to do is to establish network connection in my code and then
> at some point pass it to Warp for further processing. What I got is that
> after successfully processing first HTTP request my program consumes 100%
> CPU and eventually crashes with an error like this:
>
> *** Error in
> `/home/farnsworth/work/warp-ghc-issue/.stack-work/install/x86_64-linux/lts-5.5/7.10.3/bin/warp-ghc-issue':
> double free or corruption (!prev): 0x00000000016214b0 ***
> Aborted (core dumped)
>
> When compiled with -debug I see another message:
>
> repro: internal error: ASSERTION FAILED: file rts/Schedule.h, line 137
>
>     (GHC version 7.10.3 for x86_64_unknown_linux)
>     Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
> Aborted (core dumped)
>
> I tried to debug it by enabling -dcore-lint and -debug in my
> ~/.stack/config.yaml and what worries me is that in this case Warp itself
> doesn't compile (tried with 7.10.2 and 7.10.3) giving core lint failure in
> Network.Wai.Handler.Warp.HTTP2.Worker. Not sure if it is relevant, but
> looks suspicious.
>
This indeed quite relevant and concerning. Core lint issues should not
occur; they mean that somehow GHC has taken correct code (it
typechecked, afterall) and turned it into something horrible.

That being said, I'm afraid I can't reproduce this issue locally. What
warp version are you building against?

In the meantime, could you open a bug on the GHC Trac for this issue? It
would be quite helpful if you could attach the output from Core Lint
when you do so.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160301/c30e87ba/attachment.sig>

From eric at seidel.io  Tue Mar  1 15:54:51 2016
From: eric at seidel.io (Eric Seidel)
Date: Tue, 1 Mar 2016 07:54:51 -0800
Subject: Patches/proposals waiting for review
In-Reply-To: <1454081da04a418daac602c0c28ec6ce@DB4PR30MB030.064d.mgd.msft.net>
References: <CAD3WKghtgJ9JAUX=UoFtG8kpAYC6CNjyp7nw-H6twiNYLYyoPA@mail.gmail.com>
 <1454081da04a418daac602c0c28ec6ce@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <678EA040-5082-4AFD-8003-6B2DEE9D038D@seidel.io>

Are we planning to release 8.0 before the ICFP deadline? I'm also swamped between it and impending finals, but I want to make sure I get https://phabricator.haskell.org/D1912 merged in time. 

Eric

Sent from my iPhone

> On Mar 1, 2016, at 03:33, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> Thomas (and others)
>  
> Thanks for the summary.
>  
> I?m painfully aware of these ? though I didn?t know about the ?Block others? link, thank you.
>  
> But I?m under the gun for (a) GHC 8.0 and (b) ICFP deadline on 16 March.  I believe that none of these three are on the must-do list for 8.0 which is why I?ve been deferring.
>  
> I feel bad but I?m just over-subscribed. Post ICFP will be easier.
>  
> Simon
>  
> From: Thomas Miedema [mailto:thomasmiedema at gmail.com] 
> Sent: 24 February 2016 14:30
> To: Simon Peyton Jones <simonpj at microsoft.com>
> Cc: aovieth at gmail.com; rik at ewps.nl; acowley at seas.upenn.edu; ghc-devs at haskell.org
> Subject: Patches/proposals waiting for review
>  
> Hi Simon,
> 
>  
> 
> the following issues are waiting for your review:
> 
>  
> 
> * https://phabricator.haskell.org/D1762
> 
>  "Fix #11348 handle instance dependencies"
> 
> by Alexander Vieth
> 
>  
> 
> * https://phabricator.haskell.org/D1896
> 
>  "Improve printing of pattern synonym types"
> 
> by Rik Steenkamp
> 
>  
> 
> * https://ghc.haskell.org/trac/ghc/wiki/ShorterImportSyntax
> 
> by Anthony Cowley
> 
>  
> 
> Maybe others, they should show up under "Blocking Others" when you go to https://phabricator.haskell.org/
> 
>  
> 
> Thanks,
> 
> Thomas
> 
> _______________________________________________
> 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/20160301/cd0138ea/attachment-0001.html>

From cma at bitemyapp.com  Tue Mar  1 16:04:07 2016
From: cma at bitemyapp.com (Christopher Allen)
Date: Tue, 1 Mar 2016 10:04:07 -0600
Subject: Patches/proposals waiting for review
In-Reply-To: <678EA040-5082-4AFD-8003-6B2DEE9D038D@seidel.io>
References: <CAD3WKghtgJ9JAUX=UoFtG8kpAYC6CNjyp7nw-H6twiNYLYyoPA@mail.gmail.com>
 <1454081da04a418daac602c0c28ec6ce@DB4PR30MB030.064d.mgd.msft.net>
 <678EA040-5082-4AFD-8003-6B2DEE9D038D@seidel.io>
Message-ID: <9F04C4BA-D829-4FF0-A9E4-1D141904F13E@bitemyapp.com>

I would very much like to see this get in as well.

-- Chris

> On Mar 1, 2016, at 9:54 AM, Eric Seidel <eric at seidel.io> wrote:
> 
> Are we planning to release 8.0 before the ICFP deadline? I'm also swamped between it and impending finals, but I want to make sure I get https://phabricator.haskell.org/D1912 merged in time. 
> 
> Eric
> 
> Sent from my iPhone
> 
>> On Mar 1, 2016, at 03:33, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>> 
>> Thomas (and others)
>>  
>> Thanks for the summary.
>>  
>> I?m painfully aware of these ? though I didn?t know about the ?Block others? link, thank you.
>>  
>> But I?m under the gun for (a) GHC 8.0 and (b) ICFP deadline on 16 March.  I believe that none of these three are on the must-do list for 8.0 which is why I?ve been deferring.
>>  
>> I feel bad but I?m just over-subscribed. Post ICFP will be easier.
>>  
>> Simon
>>  
>> From: Thomas Miedema [mailto:thomasmiedema at gmail.com] 
>> Sent: 24 February 2016 14:30
>> To: Simon Peyton Jones <simonpj at microsoft.com>
>> Cc: aovieth at gmail.com; rik at ewps.nl; acowley at seas.upenn.edu; ghc-devs at haskell.org
>> Subject: Patches/proposals waiting for review
>>  
>> Hi Simon,
>> 
>>  
>> 
>> the following issues are waiting for your review:
>> 
>>  
>> 
>> * https://phabricator.haskell.org/D1762
>> 
>>  "Fix #11348 handle instance dependencies"
>> 
>> by Alexander Vieth
>> 
>>  
>> 
>> * https://phabricator.haskell.org/D1896
>> 
>>  "Improve printing of pattern synonym types"
>> 
>> by Rik Steenkamp
>> 
>>  
>> 
>> * https://ghc.haskell.org/trac/ghc/wiki/ShorterImportSyntax
>> 
>> by Anthony Cowley
>> 
>>  
>> 
>> Maybe others, they should show up under "Blocking Others" when you go to https://phabricator.haskell.org/
>> 
>>  
>> 
>> Thanks,
>> 
>> Thomas
>> 
>> _______________________________________________
>> 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/20160301/caf56679/attachment.html>

From ben at well-typed.com  Tue Mar  1 16:15:37 2016
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 01 Mar 2016 17:15:37 +0100
Subject: Patches/proposals waiting for review
In-Reply-To: <678EA040-5082-4AFD-8003-6B2DEE9D038D@seidel.io>
References: <CAD3WKghtgJ9JAUX=UoFtG8kpAYC6CNjyp7nw-H6twiNYLYyoPA@mail.gmail.com>
 <1454081da04a418daac602c0c28ec6ce@DB4PR30MB030.064d.mgd.msft.net>
 <678EA040-5082-4AFD-8003-6B2DEE9D038D@seidel.io>
Message-ID: <87bn6yyy1i.fsf@smart-cactus.org>

Eric Seidel <eric at seidel.io> writes:

> Are we planning to release 8.0 before the ICFP deadline? I'm also
> swamped between it and impending finals, but I want to make sure I get
> https://phabricator.haskell.org/D1912 merged in time.
>
No, I think you still have time. That being said, the sooner you can get
the patch done the better.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160301/bbb5f37a/attachment.sig>

From simonpj at microsoft.com  Tue Mar  1 16:56:27 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 1 Mar 2016 16:56:27 +0000
Subject: Generalising the demand analysis to sum types
In-Reply-To: <CAK+ijdvcLKZw-WcYHsEN0TFvn--2uaraFCTJdHB=XTc9_SXOuw@mail.gmail.com>
References: <CAK+ijds8hEGKEk9EhxBoapfNC3g6HAfOjYcvg1KLJD2wyP9ZoA@mail.gmail.com>
 <5ef58ac4619940608835ec3662591316@DB4PR30MB030.064d.mgd.msft.net>
 <CAK+ijdvcLKZw-WcYHsEN0TFvn--2uaraFCTJdHB=XTc9_SXOuw@mail.gmail.com>
Message-ID: <0886734b02f14ac28c9bef340c1f94dc@DB4PR30MB030.064d.mgd.msft.net>

OK yes, once we have unboxed sums, then we can in principle at least, do worker/wrapper on arguments of sum type.  So then we need strictness analysis on sumtypes, for which your proposed extension of StrDmd looks plausible.  

Don't forget AbsDmd too!

Do start a wiki page to explain all this.

Simon

|  -----Original Message-----
|  From: Jos? Manuel Calder?n Trilla [mailto:jmct at jmct.cc]
|  Sent: 20 February 2016 23:02
|  To: Simon Peyton Jones <simonpj at microsoft.com>; Joachim Breitner
|  <mail at joachim-breitner.de>; ?mer Sinan A?acan <omeragacan at gmail.com>
|  Cc: ghc-devs at haskell.org
|  Subject: Re: Generalising the demand analysis to sum types
|  
|  Hello again,
|  
|  The way I see it, the information would allow us to automatically unbox
|  the arguments to constructors in sum types.
|  
|  For example, with a Maybe Int, you would be able to automatically
|  unpack the Int within the Just constructor whenever the strictness
|  analysis determines that a function is strict in Just's argument.
|  Currently we can't determine any strictness greater than HeadStr for
|  sum types, which would not give us this information (since HeadStr
|  means it's only safe the evaluate up to the outermost constructor;
|  'Just' in this case).
|  
|  Combining this with the unboxed sums work, the idea is to be able to
|  not only unbox the sum, but the fields of a constructor when possible,
|  removing as many indirections as possible.
|  
|  At least, that's the plan :)
|  
|  Cheers,
|  
|  Jose
|  
|  
|  On Wed, Feb 17, 2016 at 9:09 AM, Simon Peyton Jones
|  <simonpj at microsoft.com> wrote:
|  > I think you could do that.  The key question is (as someone asked)
|  what use you would make of the information.  That is, what's the
|  payoff?
|  >
|  > Simon
|  >
|  > |  -----Original Message-----
|  > |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  > | Jos?  Manuel Calder?n Trilla
|  > |  Sent: 17 February 2016 04:50
|  > |  To: ghc-devs at haskell.org
|  > |  Subject: Generalising the demand analysis to sum types
|  > |
|  > |  Hello ghc-devs,
|  > |
|  > |  Apologies for the longish email.
|  > |
|  > |  I'm looking to generalise GHC's demand analysis to work on sum
|  types.
|  > |  This is in connection with the work on unboxed sums. The idea is
|  > | that  if the strictness analysis tells us that a sum type is strict
|  > | in all  the fields of all of its constructors, it is safe to unbox
|  > | that sum  automatically. We hope for this to feed into a
|  > | worker/wrapper like  transformation for sum types.
|  > |
|  > |  I am new to the GHC codebase and wanted to make sure that my plan
|  > | of  attack seemed sensible to you all.
|  > |
|  > |  GHC's current type representing demand is StrDmd, which is defined
|  > | as
|  > |  follows:
|  > |
|  > |  data StrDmd
|  > |      = HyperStrict
|  > |      | SCall StrDmd
|  > |      | SProd [ArgStr]
|  > |      | HeadStr
|  > |
|  > |  I believe that adding sum types will be as simple as adding a
|  > | single  new constructor for Sums:
|  > |
|  > |  data StrDmd
|  > |      = HyperStrict
|  > |      | SCall StrDmd
|  > |      | SProd [ArgStr]
|  > |      | SSum [(Tag, StrDmd)]
|  > |      | HeadStr
|  > |
|  > |  We need the constructor tag so that we can analyze each branch of
|  a
|  > | case expression independently before combining the results of each
|  > | branch. Since we only care if all fields are strict for all
|  > | constructors, we won't actually use the tag information except in
|  > | the  analysis itself.
|  > |
|  > |  Projection-based strictness analysis on sum types is not new
|  > | (though  sum types + higher-order seems to be). That being said,
|  all
|  > | previous  treatments of the subject that I'm aware of forbid
|  > | polymorphic  recursion. Luckily for us we aren't trying to unbox
|  > | recursive types, so  for now [1] we will not attempt to analyze
|  > | recursive types, hence no  SMu or SRec constructor above.
|  > |
|  > |  With the analysis accepting sum types we will be able to analyze
|  > | functions with sum types as parameters, as a trivial example:
|  > |
|  > |  fromMaybe2 x y = case x of
|  > |          Just v -> v
|  > |          Nothing -> y
|  > |
|  > |  You would get a demand signature like:
|  > |
|  > |  Str=Dmdtype <S[("Just", <S,U>), ("Nothing", <>)],U><L,U>
|  > |
|  > |  Which says that the function is strict in its first argument and
|  > | that  if the value is a 'Just' then its field is used strictly, if
|  > | the value  is a 'Nothing' then there is no further demand (a
|  nullary product).
|  > |
|  > |  For those with more experience in these matter, does this seem to
|  > | be a  sensible approach?
|  > |
|  > |  Thanks in advance for any insight,
|  > |
|  > |  Jose
|  > |
|  > |
|  > |  [1]: Those of you who saw my Haskell Symposium talk on implicit
|  > | parallelism last year might remember that we will need the analysis
|  > | to  work on recursive types in order to automatically generate
|  > | parallel  strategies, but that's for later (I've spoken with Ilya
|  > | Sergey about  working on that).
|  > |  _______________________________________________
|  > |  ghc-devs mailing list
|  > |  ghc-devs at haskell.org
|  > |
|  > |
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail
|  > | .ha
|  > |  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  > |
|  > |
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cf731333e0c5d4
|  > | 5f3
|  > |
|  298408d33755dc98%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=hWHFSU
|  > | Vrr  ZQqTPeQsFMQVlveHgV5ozx6%2bdpsylRIwhg%3d

From simonpj at microsoft.com  Tue Mar  1 17:01:27 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 1 Mar 2016 17:01:27 +0000
Subject: 'lub' and 'both' on strictness - what does it mean for products
 to have different arity?
In-Reply-To: <CAMQQO3=vTcsJLyOwfYshFmALx3V7GRqVCz5Ag3AfXP=YTt=9hQ@mail.gmail.com>
References: <CAMQQO3=vTcsJLyOwfYshFmALx3V7GRqVCz5Ag3AfXP=YTt=9hQ@mail.gmail.com>
Message-ID: <6a452a23dc2a47e0bf0244ad510845a6@DB4PR30MB030.064d.mgd.msft.net>

Omer

Joachim is right.  The strictness analyser just looks inside casts, so these unexpectedly ill-typed cases could show up.  For example

f :: T a -> a -> Int
f x y = case x of
          P1 -> case y of (a,b,c) -> a+b+c
          P2 -> case y of (p,q) -> p+q

data T a where
  P1 :: T (Int,Int,Int)
  P2 :: T (Int,Int)

In the P1 branch we have that y::(Int,Int,Int), so we'll get a demand S(SSS).  And similarly in the P2 branch.  Now we combine them.  And there you have it.


Could I ask that you add this example as a Note to the relevant functions, so that the next time someone asks this question they'll find the answer right there?

Thanks

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer
|  Sinan Agacan
|  Sent: 19 February 2016 17:27
|  To: ghc-devs <ghc-devs at haskell.org>
|  Subject: 'lub' and 'both' on strictness - what does it mean for
|  products to have different arity?
|  
|  I was looking at implementations of LUB and AND on demand signatures
|  and I found this interesting case:
|  
|      lubStr (SProd s1) (SProd s2)
|          | length s1 == length s2   = mkSProd (zipWith lubArgStr s1 s2)
|          | otherwise                = HeadStr
|  
|  The "otherwise" case is interesting, I'd expect that to be an error.
|  I'm trying to come up with an example, let's say I have a case
|  expression:
|  
|      case x of
|         P1 -> RHS1
|         P2 -> RHS2
|  
|  and y is used in RHS1 with S(SS) and in RHS2 with S(SSS). This seems to
|  me like a type error leaked into the demand analysis.
|  
|  Same thing applies to `bothDmd` too. Funnily, it has this extra comment
|  on this same code:
|  
|      bothStr (SProd s1) (SProd s2)
|          | length s1 == length s2   = mkSProd (zipWith bothArgStr s1 s2)
|          | otherwise                = HyperStr  -- Weird
|  
|  Does "Weird" here means "type error and/or bug" ?
|  
|  Should I try replacing these cases with panics and try to validate?
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cdd8ae326a8e14ef8
|  9e8608d339520cb9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sRFRKgj3y
|  zQdEZT4y7KLk18cP43Rv1J%2bx8oPZyr1QzA%3d

From iavor.diatchki at gmail.com  Tue Mar  1 18:47:07 2016
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 1 Mar 2016 10:47:07 -0800
Subject: GADTs and functional dependencies?
In-Reply-To: <CAD6SzR+kaVnFCYJzRHNoMYVRPccymvRW9DDyMQDVZHNQOPWtcA@mail.gmail.com>
References: <CAD6SzR+kaVnFCYJzRHNoMYVRPccymvRW9DDyMQDVZHNQOPWtcA@mail.gmail.com>
Message-ID: <CAGK9nuqH44s8Nafptrdu6Y=0Hyi4=66K3VLzXNCWir+GG9+KGw@mail.gmail.com>

Hello Conal,

the implementation of fun-deps in GHC is quite limited, and they don't do
what you'd expect with existential types (like in your example),
type-signatures, or GADTs.   Basically, GHC only uses fun-deps to fill-in
types for unification variables, but it won't use them to reason about
quantified variables.

Here is an example that shows the problem, just using type signatures:

> class F a b | a -> b where
>   f :: a -> b -> ()
>
> instance F Bool Char where
>  f _ _ = ()
>
> test :: F Bool a => a -> Char
> test a = a

GHC rejects the declaration for `test` because there it needs to prove that
`a ~ Char`.  Using the theory of fun-deps, the equality follows because
from the fun-dep we know that:

forall x y z. (F x y, F x z) => (y ~ z)

Now, if we instantiate this axiom with `Bool`, `Char`, and `a`, we can
prove that `Char ~ a` by combining the instance and the local assumption
from the signature.

Unfortunately, this is exactly the kind of reasoning GHC does not do.   I
am not 100% sure on why not, but at present GHC will basically do all the
work to ensure that the fun-dep axiom for each class is valid (that's all
the checking that instances are consistent with their fun-deps), but then
it won't use that invariant when solving equalities.

I hope this helps!
-Iavor























On Tue, Mar 1, 2016 at 9:38 AM, Conal Elliott <conal at conal.net> wrote:

> Do GADTs and functional dependencies get along? I'm wondering why the
> following code doesn't type-check under GHC 7.10.3 and 8.1.20160224:
>
> > {-# OPTIONS_GHC -Wall #-}
> > {-# LANGUAGE GADTs, KindSignatures, MultiParamTypeClasses,
> FunctionalDependencies #-}
> >
> > module FundepGadt where
> >
> > class C a b | a -> b
> >
> > data G :: * -> * where
> >   -- ...
> >   GC :: C a b => G b -> G a
> >
> > instance Eq (G a) where
> >   -- ...
> >   GC b  == GC b' = b == b'
>
> Error message:
>
>     FundepGadt.hs:14:25: error:
>         ? Couldn't match type 'b1? with 'b?
>           'b1? is a rigid type variable bound by
>             a pattern with constructor: GC :: forall a b. C a b => G b ->
> G a,
>             in an equation for '==?
>             at FundepGadt.hs:14:12
>           'b? is a rigid type variable bound by
>             a pattern with constructor: GC :: forall a b. C a b => G b ->
> G a,
>             in an equation for '==?
>             at FundepGadt.hs:14:3
>           Expected type: G b
>             Actual type: G b1
>         ? In the second argument of '(==)?, namely 'b'?
>           In the expression: b == b'
>           In an equation for '==?: (GC b) == (GC b') = b == b'
>         ? Relevant bindings include
>             b' :: G b1 (bound at FundepGadt.hs:14:15)
>             b :: G b (bound at FundepGadt.hs:14:6)
>
> I think the functional dependency does ensure that "b == b" is well-typed.
>
> In contrast, the following type-family version does type-check:
>
> >     {-# OPTIONS_GHC -Wall #-}
> >     {-# LANGUAGE GADTs, KindSignatures, TypeFamilies #-}
> >
> >     module TyfamGadt where
> >
> >     class C a where
> >       type B a
> >
> >     data G :: * -> * where
> >       -- ...
> >       GC :: C a => G (B a) -> G a
> >
> >     instance Eq (G a) where
> >       -- ...
> >       GC b  == GC b' = b == b'
>
> Thanks, - Conal
>
> _______________________________________________
> ghc-tickets mailing list
> 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/20160301/ec66f8ac/attachment.html>

From iavor.diatchki at gmail.com  Tue Mar  1 18:49:13 2016
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 1 Mar 2016 10:49:13 -0800
Subject: GADTs and functional dependencies?
In-Reply-To: <CAGK9nuqH44s8Nafptrdu6Y=0Hyi4=66K3VLzXNCWir+GG9+KGw@mail.gmail.com>
References: <CAD6SzR+kaVnFCYJzRHNoMYVRPccymvRW9DDyMQDVZHNQOPWtcA@mail.gmail.com>
 <CAGK9nuqH44s8Nafptrdu6Y=0Hyi4=66K3VLzXNCWir+GG9+KGw@mail.gmail.com>
Message-ID: <CAGK9nuocEHxY2zKt8msOkAauAMWJ22n76wB4gRHgXAzYRTrA2A@mail.gmail.com>

The method `f` of the class is not important---I simplified the example I'd
written before and forgot to delete it.  Apologies for the noise!

On Tue, Mar 1, 2016 at 10:47 AM, Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> Hello Conal,
>
> the implementation of fun-deps in GHC is quite limited, and they don't do
> what you'd expect with existential types (like in your example),
> type-signatures, or GADTs.   Basically, GHC only uses fun-deps to fill-in
> types for unification variables, but it won't use them to reason about
> quantified variables.
>
> Here is an example that shows the problem, just using type signatures:
>
> > class F a b | a -> b where
> >   f :: a -> b -> ()
> >
> > instance F Bool Char where
> >  f _ _ = ()
> >
> > test :: F Bool a => a -> Char
> > test a = a
>
> GHC rejects the declaration for `test` because there it needs to prove
> that `a ~ Char`.  Using the theory of fun-deps, the equality follows
> because from the fun-dep we know that:
>
> forall x y z. (F x y, F x z) => (y ~ z)
>
> Now, if we instantiate this axiom with `Bool`, `Char`, and `a`, we can
> prove that `Char ~ a` by combining the instance and the local assumption
> from the signature.
>
> Unfortunately, this is exactly the kind of reasoning GHC does not do.   I
> am not 100% sure on why not, but at present GHC will basically do all the
> work to ensure that the fun-dep axiom for each class is valid (that's all
> the checking that instances are consistent with their fun-deps), but then
> it won't use that invariant when solving equalities.
>
> I hope this helps!
> -Iavor
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Mar 1, 2016 at 9:38 AM, Conal Elliott <conal at conal.net> wrote:
>
>> Do GADTs and functional dependencies get along? I'm wondering why the
>> following code doesn't type-check under GHC 7.10.3 and 8.1.20160224:
>>
>> > {-# OPTIONS_GHC -Wall #-}
>> > {-# LANGUAGE GADTs, KindSignatures, MultiParamTypeClasses,
>> FunctionalDependencies #-}
>> >
>> > module FundepGadt where
>> >
>> > class C a b | a -> b
>> >
>> > data G :: * -> * where
>> >   -- ...
>> >   GC :: C a b => G b -> G a
>> >
>> > instance Eq (G a) where
>> >   -- ...
>> >   GC b  == GC b' = b == b'
>>
>> Error message:
>>
>>     FundepGadt.hs:14:25: error:
>>         ? Couldn't match type 'b1? with 'b?
>>           'b1? is a rigid type variable bound by
>>             a pattern with constructor: GC :: forall a b. C a b => G b ->
>> G a,
>>             in an equation for '==?
>>             at FundepGadt.hs:14:12
>>           'b? is a rigid type variable bound by
>>             a pattern with constructor: GC :: forall a b. C a b => G b ->
>> G a,
>>             in an equation for '==?
>>             at FundepGadt.hs:14:3
>>           Expected type: G b
>>             Actual type: G b1
>>         ? In the second argument of '(==)?, namely 'b'?
>>           In the expression: b == b'
>>           In an equation for '==?: (GC b) == (GC b') = b == b'
>>         ? Relevant bindings include
>>             b' :: G b1 (bound at FundepGadt.hs:14:15)
>>             b :: G b (bound at FundepGadt.hs:14:6)
>>
>> I think the functional dependency does ensure that "b == b" is
>> well-typed.
>>
>> In contrast, the following type-family version does type-check:
>>
>> >     {-# OPTIONS_GHC -Wall #-}
>> >     {-# LANGUAGE GADTs, KindSignatures, TypeFamilies #-}
>> >
>> >     module TyfamGadt where
>> >
>> >     class C a where
>> >       type B a
>> >
>> >     data G :: * -> * where
>> >       -- ...
>> >       GC :: C a => G (B a) -> G a
>> >
>> >     instance Eq (G a) where
>> >       -- ...
>> >       GC b  == GC b' = b == b'
>>
>> Thanks, - Conal
>>
>> _______________________________________________
>> ghc-tickets mailing list
>> 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/20160301/7feab548/attachment-0001.html>

From ekmett at gmail.com  Tue Mar  1 20:45:23 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 1 Mar 2016 15:45:23 -0500
Subject: GADTs and functional dependencies?
In-Reply-To: <CAGK9nuqH44s8Nafptrdu6Y=0Hyi4=66K3VLzXNCWir+GG9+KGw@mail.gmail.com>
References: <CAD6SzR+kaVnFCYJzRHNoMYVRPccymvRW9DDyMQDVZHNQOPWtcA@mail.gmail.com>
 <CAGK9nuqH44s8Nafptrdu6Y=0Hyi4=66K3VLzXNCWir+GG9+KGw@mail.gmail.com>
Message-ID: <CAJumaK8Ygn7G5F2gdisju0+d22RCFHSq=JT1UdvMnqAqaO9+Vw@mail.gmail.com>

https://ghc.haskell.org/trac/ghc/ticket/11534 is somewhat relevant to this
issue. Solving it would seem likely to fix this one as well.

-Edward

On Tue, Mar 1, 2016 at 1:47 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> Hello Conal,
>
> the implementation of fun-deps in GHC is quite limited, and they don't do
> what you'd expect with existential types (like in your example),
> type-signatures, or GADTs.   Basically, GHC only uses fun-deps to fill-in
> types for unification variables, but it won't use them to reason about
> quantified variables.
>
> Here is an example that shows the problem, just using type signatures:
>
> > class F a b | a -> b where
> >   f :: a -> b -> ()
> >
> > instance F Bool Char where
> >  f _ _ = ()
> >
> > test :: F Bool a => a -> Char
> > test a = a
>
> GHC rejects the declaration for `test` because there it needs to prove
> that `a ~ Char`.  Using the theory of fun-deps, the equality follows
> because from the fun-dep we know that:
>
> forall x y z. (F x y, F x z) => (y ~ z)
>
> Now, if we instantiate this axiom with `Bool`, `Char`, and `a`, we can
> prove that `Char ~ a` by combining the instance and the local assumption
> from the signature.
>
> Unfortunately, this is exactly the kind of reasoning GHC does not do.   I
> am not 100% sure on why not, but at present GHC will basically do all the
> work to ensure that the fun-dep axiom for each class is valid (that's all
> the checking that instances are consistent with their fun-deps), but then
> it won't use that invariant when solving equalities.
>
> I hope this helps!
> -Iavor
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Mar 1, 2016 at 9:38 AM, Conal Elliott <conal at conal.net> wrote:
>
>> Do GADTs and functional dependencies get along? I'm wondering why the
>> following code doesn't type-check under GHC 7.10.3 and 8.1.20160224:
>>
>> > {-# OPTIONS_GHC -Wall #-}
>> > {-# LANGUAGE GADTs, KindSignatures, MultiParamTypeClasses,
>> FunctionalDependencies #-}
>> >
>> > module FundepGadt where
>> >
>> > class C a b | a -> b
>> >
>> > data G :: * -> * where
>> >   -- ...
>> >   GC :: C a b => G b -> G a
>> >
>> > instance Eq (G a) where
>> >   -- ...
>> >   GC b  == GC b' = b == b'
>>
>> Error message:
>>
>>     FundepGadt.hs:14:25: error:
>>         ? Couldn't match type 'b1? with 'b?
>>           'b1? is a rigid type variable bound by
>>             a pattern with constructor: GC :: forall a b. C a b => G b ->
>> G a,
>>             in an equation for '==?
>>             at FundepGadt.hs:14:12
>>           'b? is a rigid type variable bound by
>>             a pattern with constructor: GC :: forall a b. C a b => G b ->
>> G a,
>>             in an equation for '==?
>>             at FundepGadt.hs:14:3
>>           Expected type: G b
>>             Actual type: G b1
>>         ? In the second argument of '(==)?, namely 'b'?
>>           In the expression: b == b'
>>           In an equation for '==?: (GC b) == (GC b') = b == b'
>>         ? Relevant bindings include
>>             b' :: G b1 (bound at FundepGadt.hs:14:15)
>>             b :: G b (bound at FundepGadt.hs:14:6)
>>
>> I think the functional dependency does ensure that "b == b" is
>> well-typed.
>>
>> In contrast, the following type-family version does type-check:
>>
>> >     {-# OPTIONS_GHC -Wall #-}
>> >     {-# LANGUAGE GADTs, KindSignatures, TypeFamilies #-}
>> >
>> >     module TyfamGadt where
>> >
>> >     class C a where
>> >       type B a
>> >
>> >     data G :: * -> * where
>> >       -- ...
>> >       GC :: C a => G (B a) -> G a
>> >
>> >     instance Eq (G a) where
>> >       -- ...
>> >       GC b  == GC b' = b == b'
>>
>> Thanks, - Conal
>>
>> _______________________________________________
>> ghc-tickets mailing list
>> ghc-tickets at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
>>
>>
>
> _______________________________________________
> 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/20160301/ecb79436/attachment.html>

From kazu at iij.ad.jp  Wed Mar  2 00:59:19 2016
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Wed, 02 Mar 2016 09:59:19 +0900 (JST)
Subject: Simple "Hello World" Warp-based web server crashes on Ubuntu
 x86_64
In-Reply-To: <CAGkP6gMHstx0HFqxd7Fg3Z-U-eFPFTE8_p142JJeu6nLdv5Wdg@mail.gmail.com>
References: <CAGkP6gMHstx0HFqxd7Fg3Z-U-eFPFTE8_p142JJeu6nLdv5Wdg@mail.gmail.com>
Message-ID: <20160302.095919.1539829753529108199.kazu@iij.ad.jp>

Hi,

> repro: internal error: ASSERTION FAILED: file rts/Schedule.h, line 137
> 
>     (GHC version 7.10.3 for x86_64_unknown_linux)
>     Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
> Aborted (core dumped)

I can reproduce this on my 64bit Mac.

But the code in https://github.com/anton-dessiatov/warp-ghc-issue is
very starange to me. Why do you use interal APIs such as
socketConnection runSettingsConnection? Why don't you use normal APIs
such as runSettingsSocket?

I guess your usage of the internal APIs triggers an infinite loop.

--Kazu

From omeragacan at gmail.com  Wed Mar  2 06:07:04 2016
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Wed, 2 Mar 2016 01:07:04 -0500
Subject: 'lub' and 'both' on strictness - what does it mean for products
 to have different arity?
In-Reply-To: <6a452a23dc2a47e0bf0244ad510845a6@DB4PR30MB030.064d.mgd.msft.net>
References: <CAMQQO3=vTcsJLyOwfYshFmALx3V7GRqVCz5Ag3AfXP=YTt=9hQ@mail.gmail.com>
 <6a452a23dc2a47e0bf0244ad510845a6@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAMQQO3=JxvECHk7Q+YxRM-zntNdmV21Q5+8iRV1xM8HYiPiwLw@mail.gmail.com>

> Could I ask that you add this example as a Note to the relevant functions, so
> that the next time someone asks this question they'll find the answer right
> there?

Yep, I'll do that soon.

2016-03-01 12:01 GMT-05:00 Simon Peyton Jones <simonpj at microsoft.com>:
> Omer
>
> Joachim is right.  The strictness analyser just looks inside casts, so these unexpectedly ill-typed cases could show up.  For example
>
> f :: T a -> a -> Int
> f x y = case x of
>           P1 -> case y of (a,b,c) -> a+b+c
>           P2 -> case y of (p,q) -> p+q
>
> data T a where
>   P1 :: T (Int,Int,Int)
>   P2 :: T (Int,Int)
>
> In the P1 branch we have that y::(Int,Int,Int), so we'll get a demand S(SSS).  And similarly in the P2 branch.  Now we combine them.  And there you have it.
>
>
> Could I ask that you add this example as a Note to the relevant functions, so that the next time someone asks this question they'll find the answer right there?
>
> Thanks
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer
> |  Sinan Agacan
> |  Sent: 19 February 2016 17:27
> |  To: ghc-devs <ghc-devs at haskell.org>
> |  Subject: 'lub' and 'both' on strictness - what does it mean for
> |  products to have different arity?
> |
> |  I was looking at implementations of LUB and AND on demand signatures
> |  and I found this interesting case:
> |
> |      lubStr (SProd s1) (SProd s2)
> |          | length s1 == length s2   = mkSProd (zipWith lubArgStr s1 s2)
> |          | otherwise                = HeadStr
> |
> |  The "otherwise" case is interesting, I'd expect that to be an error.
> |  I'm trying to come up with an example, let's say I have a case
> |  expression:
> |
> |      case x of
> |         P1 -> RHS1
> |         P2 -> RHS2
> |
> |  and y is used in RHS1 with S(SS) and in RHS2 with S(SSS). This seems to
> |  me like a type error leaked into the demand analysis.
> |
> |  Same thing applies to `bothDmd` too. Funnily, it has this extra comment
> |  on this same code:
> |
> |      bothStr (SProd s1) (SProd s2)
> |          | length s1 == length s2   = mkSProd (zipWith bothArgStr s1 s2)
> |          | otherwise                = HyperStr  -- Weird
> |
> |  Does "Weird" here means "type error and/or bug" ?
> |
> |  Should I try replacing these cases with panics and try to validate?
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
> |  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cdd8ae326a8e14ef8
> |  9e8608d339520cb9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sRFRKgj3y
> |  zQdEZT4y7KLk18cP43Rv1J%2bx8oPZyr1QzA%3d

From omeragacan at gmail.com  Wed Mar  2 06:14:20 2016
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Wed, 2 Mar 2016 01:14:20 -0500
Subject: 'lub' and 'both' on strictness - what does it mean for products
 to have different arity?
In-Reply-To: <CAMQQO3=JxvECHk7Q+YxRM-zntNdmV21Q5+8iRV1xM8HYiPiwLw@mail.gmail.com>
References: <CAMQQO3=vTcsJLyOwfYshFmALx3V7GRqVCz5Ag3AfXP=YTt=9hQ@mail.gmail.com>
 <6a452a23dc2a47e0bf0244ad510845a6@DB4PR30MB030.064d.mgd.msft.net>
 <CAMQQO3=JxvECHk7Q+YxRM-zntNdmV21Q5+8iRV1xM8HYiPiwLw@mail.gmail.com>
Message-ID: <CAMQQO3=48qYRiuUjW-BKT2Oxp++2=eKQE-pb_S7ve8BCt4ousw@mail.gmail.com>

Simon, one more thing. `lubUse` has this:

    -- lubUse (UProd {}) Used             = Used
    lubUse (UProd ux) Used             = UProd (map (`lubArgUse` useTop) ux)
    lubUse Used       (UProd ux)       = UProd (map (`lubArgUse` useTop) ux)

And then somewhere around that code there's this:

    Note [Used should win]
    ~~~~~~~~~~~~~~~~~~~~~~
    Both in lubUse and bothUse we want (Used `both` UProd us) to be Used.
    Why?  Because Used carries the implication the whole thing is used,
    box and all, so we don't want to w/w it.  If we use it both boxed and
    unboxed, then we are definitely using the box, and so we are quite
    likely to pay a reboxing cost.  So we make Used win here.

    ...

It seems like at some point the note was valid, but now the code seems to be
doing the opposite. Any ideas which one needs an update?

I'm also a bit confused about why both and lub are not commutative, or if
they're commutative, why do they have redundant cases. For example, lubUse has
this:

    lubUse UHead       u               = u
    lubUse (UCall c u) UHead           = UCall c u

instead of something like:

    lubUse UHead u = u
    lubUse u UHead = u

I didn't check all the cases to see if it's really commutative or not, but can
I assume that they need to be commutative and simplify the code? Otherwise
let's add a note about why they're not commutative?

Thanks..

2016-03-02 1:07 GMT-05:00 ?mer Sinan A?acan <omeragacan at gmail.com>:
>> Could I ask that you add this example as a Note to the relevant functions, so
>> that the next time someone asks this question they'll find the answer right
>> there?
>
> Yep, I'll do that soon.
>
> 2016-03-01 12:01 GMT-05:00 Simon Peyton Jones <simonpj at microsoft.com>:
>> Omer
>>
>> Joachim is right.  The strictness analyser just looks inside casts, so these unexpectedly ill-typed cases could show up.  For example
>>
>> f :: T a -> a -> Int
>> f x y = case x of
>>           P1 -> case y of (a,b,c) -> a+b+c
>>           P2 -> case y of (p,q) -> p+q
>>
>> data T a where
>>   P1 :: T (Int,Int,Int)
>>   P2 :: T (Int,Int)
>>
>> In the P1 branch we have that y::(Int,Int,Int), so we'll get a demand S(SSS).  And similarly in the P2 branch.  Now we combine them.  And there you have it.
>>
>>
>> Could I ask that you add this example as a Note to the relevant functions, so that the next time someone asks this question they'll find the answer right there?
>>
>> Thanks
>>
>> Simon
>>
>> |  -----Original Message-----
>> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of ?mer
>> |  Sinan Agacan
>> |  Sent: 19 February 2016 17:27
>> |  To: ghc-devs <ghc-devs at haskell.org>
>> |  Subject: 'lub' and 'both' on strictness - what does it mean for
>> |  products to have different arity?
>> |
>> |  I was looking at implementations of LUB and AND on demand signatures
>> |  and I found this interesting case:
>> |
>> |      lubStr (SProd s1) (SProd s2)
>> |          | length s1 == length s2   = mkSProd (zipWith lubArgStr s1 s2)
>> |          | otherwise                = HeadStr
>> |
>> |  The "otherwise" case is interesting, I'd expect that to be an error.
>> |  I'm trying to come up with an example, let's say I have a case
>> |  expression:
>> |
>> |      case x of
>> |         P1 -> RHS1
>> |         P2 -> RHS2
>> |
>> |  and y is used in RHS1 with S(SS) and in RHS2 with S(SSS). This seems to
>> |  me like a type error leaked into the demand analysis.
>> |
>> |  Same thing applies to `bothDmd` too. Funnily, it has this extra comment
>> |  on this same code:
>> |
>> |      bothStr (SProd s1) (SProd s2)
>> |          | length s1 == length s2   = mkSProd (zipWith bothArgStr s1 s2)
>> |          | otherwise                = HyperStr  -- Weird
>> |
>> |  Does "Weird" here means "type error and/or bug" ?
>> |
>> |  Should I try replacing these cases with panics and try to validate?
>> |  _______________________________________________
>> |  ghc-devs mailing list
>> |  ghc-devs at haskell.org
>> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
>> |  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
>> |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cdd8ae326a8e14ef8
>> |  9e8608d339520cb9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sRFRKgj3y
>> |  zQdEZT4y7KLk18cP43Rv1J%2bx8oPZyr1QzA%3d

From anton.dessiatov at gmail.com  Wed Mar  2 08:19:38 2016
From: anton.dessiatov at gmail.com (Anton Dessiatov)
Date: Wed, 2 Mar 2016 14:19:38 +0600
Subject: Simple "Hello World" Warp-based web server crashes on Ubuntu
 x86_64
In-Reply-To: <20160302.095919.1539829753529108199.kazu@iij.ad.jp>
References: <CAGkP6gMHstx0HFqxd7Fg3Z-U-eFPFTE8_p142JJeu6nLdv5Wdg@mail.gmail.com>
 <20160302.095919.1539829753529108199.kazu@iij.ad.jp>
Message-ID: <56D6A21A.7010606@gmail.com>

Hello Kazu,

My original intent was to accept different kinds of traffic on the same 
port. Then I wanted to figure out what protocol is used by analyzing 
first few received bytes and if that's HTTP, pass it to Warp. So I used 
internal runSettingsConnection to continue processing after connection 
has already been established.

Current "warp-ghc-issue" repository doesn't have all the protocol 
detection machinery and all that it does is simply accepting socket and 
passing it to runSettingsConnection. At the first glance it seems fully 
legitimate, but triggers behavior described.

I have studied Warp source code to figure out what could possibly go 
wrong, but currently it just looks to me that I do almost exactly the 
same things as public Network.Wai.Handler.Warp.run function (except for 
async exceptions handling, supporting TLS and other features). I don't 
see how could I trigger an infinite loop (although I admit that 
something goes very wrong with my code and doesn't go wrong with Warp's 
run function).

Even if that's an infinite loop - why does it crash instead of just 
looping? Do you think I should create an issue at Warp's bug tracker?

Regards,
   Anton.

02.03.2016 6:59, Kazu Yamamoto (????) ?????:
> Hi,
>
>> repro: internal error: ASSERTION FAILED: file rts/Schedule.h, line 137
>>
>>      (GHC version 7.10.3 for x86_64_unknown_linux)
>>      Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>> Aborted (core dumped)
> I can reproduce this on my 64bit Mac.
>
> But the code in https://github.com/anton-dessiatov/warp-ghc-issue is
> very starange to me. Why do you use interal APIs such as
> socketConnection runSettingsConnection? Why don't you use normal APIs
> such as runSettingsSocket?
>
> I guess your usage of the internal APIs triggers an infinite loop.
>
> --Kazu


From simonpj at microsoft.com  Wed Mar  2 08:47:21 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 2 Mar 2016 08:47:21 +0000
Subject: 'lub' and 'both' on strictness - what does it mean for products
 to have different arity?
In-Reply-To: <CAMQQO3=48qYRiuUjW-BKT2Oxp++2=eKQE-pb_S7ve8BCt4ousw@mail.gmail.com>
References: <CAMQQO3=vTcsJLyOwfYshFmALx3V7GRqVCz5Ag3AfXP=YTt=9hQ@mail.gmail.com>
 <6a452a23dc2a47e0bf0244ad510845a6@DB4PR30MB030.064d.mgd.msft.net>
 <CAMQQO3=JxvECHk7Q+YxRM-zntNdmV21Q5+8iRV1xM8HYiPiwLw@mail.gmail.com>
 <CAMQQO3=48qYRiuUjW-BKT2Oxp++2=eKQE-pb_S7ve8BCt4ousw@mail.gmail.com>
Message-ID: <0a47f37356a741cdab879d2f57f52aaf@DB4PR30MB030.064d.mgd.msft.net>


|      -- lubUse (UProd {}) Used             = Used
|      lubUse (UProd ux) Used             = UProd (map (`lubArgUse`
|  useTop) ux)
|      lubUse Used       (UProd ux)       = UProd (map (`lubArgUse`
|  useTop) ux)
|  
|  And then somewhere around that code there's this:
|  
|      Note [Used should win]
|      ~~~~~~~~~~~~~~~~~~~~~~
|      Both in lubUse and bothUse we want (Used `both` UProd us) to be
|  Used.
|      Why?  Because Used carries the implication the whole thing is used,
|      box and all, so we don't want to w/w it.  If we use it both boxed
|  and
|      unboxed, then we are definitely using the box, and so we are quite
|      likely to pay a reboxing cost.  So we make Used win here.
|  
|      ...
|  
|  It seems like at some point the note was valid, but now the code seems
|  to be doing the opposite. Any ideas which one needs an update?

I have no idea.  It seems that the entire definition of lubUse, including the Note and the commented-out line, appeared in a single big patch 99d4e5b4.   So no clues there.

However the Note has some nofib numbers.

So yes, it's puzzling.   The argument in the Note seems plausible.  Would you like to try reverting to "Used should win" and see what happens to performance?  Probably something will get worse and you'll have do some digging with ticky-ticky.


|  I'm also a bit confused about why both and lub are not commutative, or
|  if they're commutative, why do they have redundant cases.

Yes: lub and both should be commutative; yell if not.  (In contrast see Note [Asymmetry of 'both' for DmdType and DmdResult]; but that's well documented.)

| For example,
|  lubUse has
|  this:
|  
|      lubUse UHead       u               = u
|      lubUse (UCall c u) UHead           = UCall c u
|  
|  instead of something like:
|  
|      lubUse UHead u = u
|      lubUse u UHead = u

I think this is just stylistic. I was dealing with all the cases for UHead in the first arg, then all the cases for UCall, and so on. That way I know I've got coverage.

(And perhaps it's more efficient: we pattern match at most once on each argument.

Simon

|  
|  I didn't check all the cases to see if it's really commutative or not,
|  but can I assume that they need to be commutative and simplify the
|  code? Otherwise let's add a note about why they're not commutative?
|  
|  Thanks..
|  
|  2016-03-02 1:07 GMT-05:00 ?mer Sinan A?acan <omeragacan at gmail.com>:
|  >> Could I ask that you add this example as a Note to the relevant
|  >> functions, so that the next time someone asks this question they'll
|  >> find the answer right there?
|  >
|  > Yep, I'll do that soon.
|  >
|  > 2016-03-01 12:01 GMT-05:00 Simon Peyton Jones
|  <simonpj at microsoft.com>:
|  >> Omer
|  >>
|  >> Joachim is right.  The strictness analyser just looks inside casts,
|  >> so these unexpectedly ill-typed cases could show up.  For example
|  >>
|  >> f :: T a -> a -> Int
|  >> f x y = case x of
|  >>           P1 -> case y of (a,b,c) -> a+b+c
|  >>           P2 -> case y of (p,q) -> p+q
|  >>
|  >> data T a where
|  >>   P1 :: T (Int,Int,Int)
|  >>   P2 :: T (Int,Int)
|  >>
|  >> In the P1 branch we have that y::(Int,Int,Int), so we'll get a
|  demand S(SSS).  And similarly in the P2 branch.  Now we combine them.
|  And there you have it.
|  >>
|  >>
|  >> Could I ask that you add this example as a Note to the relevant
|  functions, so that the next time someone asks this question they'll
|  find the answer right there?
|  >>
|  >> Thanks
|  >>
|  >> Simon
|  >>
|  >> |  -----Original Message-----
|  >> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  >> | ?mer  Sinan Agacan
|  >> |  Sent: 19 February 2016 17:27
|  >> |  To: ghc-devs <ghc-devs at haskell.org>
|  >> |  Subject: 'lub' and 'both' on strictness - what does it mean for
|  >> | products to have different arity?
|  >> |
|  >> |  I was looking at implementations of LUB and AND on demand
|  >> | signatures  and I found this interesting case:
|  >> |
|  >> |      lubStr (SProd s1) (SProd s2)
|  >> |          | length s1 == length s2   = mkSProd (zipWith lubArgStr
|  s1 s2)
|  >> |          | otherwise                = HeadStr
|  >> |
|  >> |  The "otherwise" case is interesting, I'd expect that to be an
|  error.
|  >> |  I'm trying to come up with an example, let's say I have a case
|  >> |  expression:
|  >> |
|  >> |      case x of
|  >> |         P1 -> RHS1
|  >> |         P2 -> RHS2
|  >> |
|  >> |  and y is used in RHS1 with S(SS) and in RHS2 with S(SSS). This
|  >> | seems to  me like a type error leaked into the demand analysis.
|  >> |
|  >> |  Same thing applies to `bothDmd` too. Funnily, it has this extra
|  >> | comment  on this same code:
|  >> |
|  >> |      bothStr (SProd s1) (SProd s2)
|  >> |          | length s1 == length s2   = mkSProd (zipWith bothArgStr
|  s1 s2)
|  >> |          | otherwise                = HyperStr  -- Weird
|  >> |
|  >> |  Does "Weird" here means "type error and/or bug" ?
|  >> |
|  >> |  Should I try replacing these cases with panics and try to
|  validate?
|  >> |  _______________________________________________
|  >> |  ghc-devs mailing list
|  >> |  ghc-devs at haskell.org
|  >> |
|  >> |
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmai
|  >> | l.ha
|  >> |  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  >> |
|  >> |
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cdd8ae326a8e1
|  >> | 4ef8
|  >> |
|  9e8608d339520cb9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sRFRK
|  >> | gj3y  zQdEZT4y7KLk18cP43Rv1J%2bx8oPZyr1QzA%3d

From anton.dessiatov at gmail.com  Wed Mar  2 09:05:13 2016
From: anton.dessiatov at gmail.com (Anton Dessiatov)
Date: Wed, 2 Mar 2016 15:05:13 +0600
Subject: Simple "Hello World" Warp-based web server crashes on Ubuntu
 x86_64
In-Reply-To: <87h9gqyz25.fsf@smart-cactus.org>
References: <CAGkP6gMHstx0HFqxd7Fg3Z-U-eFPFTE8_p142JJeu6nLdv5Wdg@mail.gmail.com>
 <87h9gqyz25.fsf@smart-cactus.org>
Message-ID: <56D6ACC9.1030907@gmail.com>

Hello Ben,

I am bulding warp-3.2.2 with stack (lts-5.5 snapshot) using GHC 7.10.3. 
I have also created a ticket in GHC trac: 
https://ghc.haskell.org/trac/ghc/ticket/11664.

Hope this helps.

Regards,
   Anton.

01.03.2016 21:53, Ben Gamari ?????:
> ????? ??????? <anton.dessiatov at gmail.com> writes:
>
>> Hello dear GHC developers,
>>
>> I have recently experienced what I believe to be a bug either in GHC or in
>> Warp library (if it is indeed in Warp then sorry for posting to wrong
>> mailing list). I've managed to shrink it to a few lines of code and publish
>> on a GitHub. Here is the link:
>> https://github.com/anton-dessiatov/warp-ghc-issue
>>
>> What I wanted to do is to establish network connection in my code and then
>> at some point pass it to Warp for further processing. What I got is that
>> after successfully processing first HTTP request my program consumes 100%
>> CPU and eventually crashes with an error like this:
>>
>> *** Error in
>> `/home/farnsworth/work/warp-ghc-issue/.stack-work/install/x86_64-linux/lts-5.5/7.10.3/bin/warp-ghc-issue':
>> double free or corruption (!prev): 0x00000000016214b0 ***
>> Aborted (core dumped)
>>
>> When compiled with -debug I see another message:
>>
>> repro: internal error: ASSERTION FAILED: file rts/Schedule.h, line 137
>>
>>      (GHC version 7.10.3 for x86_64_unknown_linux)
>>      Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
>> Aborted (core dumped)
>>
>> I tried to debug it by enabling -dcore-lint and -debug in my
>> ~/.stack/config.yaml and what worries me is that in this case Warp itself
>> doesn't compile (tried with 7.10.2 and 7.10.3) giving core lint failure in
>> Network.Wai.Handler.Warp.HTTP2.Worker. Not sure if it is relevant, but
>> looks suspicious.
>>
> This indeed quite relevant and concerning. Core lint issues should not
> occur; they mean that somehow GHC has taken correct code (it
> typechecked, afterall) and turned it into something horrible.
>
> That being said, I'm afraid I can't reproduce this issue locally. What
> warp version are you building against?
>
> In the meantime, could you open a bug on the GHC Trac for this issue? It
> would be quite helpful if you could attach the output from Core Lint
> when you do so.
>
> Cheers,
>
> - Ben


From anton.dessiatov at gmail.com  Wed Mar  2 14:33:49 2016
From: anton.dessiatov at gmail.com (Anton Dessiatov)
Date: Wed, 2 Mar 2016 20:33:49 +0600
Subject: Simple "Hello World" Warp-based web server crashes on Ubuntu
 x86_64
In-Reply-To: <56D6A21A.7010606@gmail.com>
References: <CAGkP6gMHstx0HFqxd7Fg3Z-U-eFPFTE8_p142JJeu6nLdv5Wdg@mail.gmail.com>
 <20160302.095919.1539829753529108199.kazu@iij.ad.jp>
 <56D6A21A.7010606@gmail.com>
Message-ID: <56D6F9CD.2000702@gmail.com>

Ouch! Looks like I nailed down this one. Indeed that's my bad and that's 
an infinite loop I have unwillingly created in 
Network.Wai.Handler.Warp.Run.acceptConnection.

Sorry for suspecting GHC failure where there is my fault.

At the very least I have an excuse that this mistake of mine helped to 
identify at least one actual bug in GHC master.

02.03.2016 14:19, Anton Dessiatov ?????:
> Hello Kazu,
>
> My original intent was to accept different kinds of traffic on the 
> same port. Then I wanted to figure out what protocol is used by 
> analyzing first few received bytes and if that's HTTP, pass it to 
> Warp. So I used internal runSettingsConnection to continue processing 
> after connection has already been established.
>
> Current "warp-ghc-issue" repository doesn't have all the protocol 
> detection machinery and all that it does is simply accepting socket 
> and passing it to runSettingsConnection. At the first glance it seems 
> fully legitimate, but triggers behavior described.
>
> I have studied Warp source code to figure out what could possibly go 
> wrong, but currently it just looks to me that I do almost exactly the 
> same things as public Network.Wai.Handler.Warp.run function (except 
> for async exceptions handling, supporting TLS and other features). I 
> don't see how could I trigger an infinite loop (although I admit that 
> something goes very wrong with my code and doesn't go wrong with 
> Warp's run function).
>
> Even if that's an infinite loop - why does it crash instead of just 
> looping? Do you think I should create an issue at Warp's bug tracker?
>
> Regards,
>   Anton.
>
> 02.03.2016 6:59, Kazu Yamamoto (????) ?????:
>> Hi,
>>
>>> repro: internal error: ASSERTION FAILED: file rts/Schedule.h, line 137
>>>
>>>      (GHC version 7.10.3 for x86_64_unknown_linux)
>>>      Please report this as a GHC bug: 
>>> http://www.haskell.org/ghc/reportabug
>>> Aborted (core dumped)
>> I can reproduce this on my 64bit Mac.
>>
>> But the code in https://github.com/anton-dessiatov/warp-ghc-issue is
>> very starange to me. Why do you use interal APIs such as
>> socketConnection runSettingsConnection? Why don't you use normal APIs
>> such as runSettingsSocket?
>>
>> I guess your usage of the internal APIs triggers an infinite loop.
>>
>> --Kazu
>


From dan at kernelim.com  Wed Mar  2 14:38:56 2016
From: dan at kernelim.com (Dan Aloni)
Date: Wed, 2 Mar 2016 16:38:56 +0200
Subject: RTS's (old?) invariant regarding OS blocking
Message-ID: <20160302143856.GA21211@gmail.com>

Hi,

While trying to gain insights into the RTS, I've noticed the following in
the Wiki page [1] on the topic of the scheduler:

    Invariant: a task that holds a capability is not blocked in the operating system.

    This makes some parts of the system simpler - for example, we can use spin locks that spin indefinitely, because we can ensure that the spin lock is only held by a currently executing CPU, and will therefore be released in a finite (and short) amount of time.

Does it still apply to modern day GHC, or was it addressed by [2]?

[1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Scheduler#Capabilities
[2] https://ghc.haskell.org/trac/ghc/ticket/3553

--
Dan Aloni

From ben at well-typed.com  Wed Mar  2 14:50:21 2016
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 02 Mar 2016 15:50:21 +0100
Subject: Simple "Hello World" Warp-based web server crashes on Ubuntu
 x86_64
In-Reply-To: <56D6F9CD.2000702@gmail.com>
References: <CAGkP6gMHstx0HFqxd7Fg3Z-U-eFPFTE8_p142JJeu6nLdv5Wdg@mail.gmail.com>
 <20160302.095919.1539829753529108199.kazu@iij.ad.jp>
 <56D6A21A.7010606@gmail.com> <56D6F9CD.2000702@gmail.com>
Message-ID: <87ziuhx7bm.fsf@smart-cactus.org>

Anton Dessiatov <anton.dessiatov at gmail.com> writes:

> Ouch! Looks like I nailed down this one. Indeed that's my bad and that's 
> an infinite loop I have unwillingly created in 
> Network.Wai.Handler.Warp.Run.acceptConnection.
>
Well, that being said, the various Core Lint issues that you found are
quite concerning. It would be greatly appreciated if you could follow up
with those (in particular the unresolved attoparsec issue).

> Sorry for suspecting GHC failure where there is my fault.
>
Quite alright; GHC certainly isn't infallible.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160302/9bbad322/attachment.sig>

From anton.dessiatov at gmail.com  Wed Mar  2 14:59:15 2016
From: anton.dessiatov at gmail.com (Anton Dessiatov)
Date: Wed, 2 Mar 2016 20:59:15 +0600
Subject: Simple "Hello World" Warp-based web server crashes on Ubuntu
 x86_64
In-Reply-To: <87ziuhx7bm.fsf@smart-cactus.org>
References: <CAGkP6gMHstx0HFqxd7Fg3Z-U-eFPFTE8_p142JJeu6nLdv5Wdg@mail.gmail.com>
 <20160302.095919.1539829753529108199.kazu@iij.ad.jp>
 <56D6A21A.7010606@gmail.com> <56D6F9CD.2000702@gmail.com>
 <87ziuhx7bm.fsf@smart-cactus.org>
Message-ID: <56D6FFC3.4040003@gmail.com>

Simon Peyton Jones have recently commented on #11665 (attoparsec one) 
and it looks like he has it well under control. Of course I would be 
glad to try reproducing that again if needed.

Talking about #11664 I think it's worth knowing that GHC 7.10.3 has some 
hard time compiling recent Warp, but the good point is that (supposedly) 
GHC 8.0 doesn't have this problem anymore, so the ticket could be 
relatively safely closed.

02.03.2016 20:50, Ben Gamari ?????:
> Anton Dessiatov <anton.dessiatov at gmail.com> writes:
>
>> Ouch! Looks like I nailed down this one. Indeed that's my bad and that's
>> an infinite loop I have unwillingly created in
>> Network.Wai.Handler.Warp.Run.acceptConnection.
>>
> Well, that being said, the various Core Lint issues that you found are
> quite concerning. It would be greatly appreciated if you could follow up
> with those (in particular the unresolved attoparsec issue).
>
>> Sorry for suspecting GHC failure where there is my fault.
>>
> Quite alright; GHC certainly isn't infallible.
>
> Cheers,
>
> - Ben
>


From ben at well-typed.com  Wed Mar  2 15:48:22 2016
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 02 Mar 2016 16:48:22 +0100
Subject: Simple "Hello World" Warp-based web server crashes on Ubuntu
 x86_64
In-Reply-To: <56D6FFC3.4040003@gmail.com>
References: <CAGkP6gMHstx0HFqxd7Fg3Z-U-eFPFTE8_p142JJeu6nLdv5Wdg@mail.gmail.com>
 <20160302.095919.1539829753529108199.kazu@iij.ad.jp>
 <56D6A21A.7010606@gmail.com> <56D6F9CD.2000702@gmail.com>
 <87ziuhx7bm.fsf@smart-cactus.org> <56D6FFC3.4040003@gmail.com>
Message-ID: <87wppkyj7d.fsf@smart-cactus.org>

Anton Dessiatov <anton.dessiatov at gmail.com> writes:

> Simon Peyton Jones have recently commented on #11665 (attoparsec one) 
> and it looks like he has it well under control. Of course I would be 
> glad to try reproducing that again if needed.
>
Ahh, I missed this. Thanks for your help Anton!

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160302/6f0da540/attachment.sig>

From john_ericson at brown.edu  Wed Mar  2 17:56:29 2016
From: john_ericson at brown.edu (Ericson, John)
Date: Wed, 2 Mar 2016 09:56:29 -0800
Subject: New type of ($) operator in GHC 8.0 is problematic
In-Reply-To: <C90C0188-2850-4262-B40E-0CF192AA48CF@justtesting.org>
References: <CADdQpRDFNhDE79D37DZAw2Z2fpY73=2hts9W4-DVZx5iK13pCQ@mail.gmail.com>
 <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com>
 <DE67E064-0CD4-42A3-82D8-DBDBECDB36C5@cis.upenn.edu>
 <CAJ0eudoPdQ23SniL7NE2dMFvJOCzG0rv9uh+MkbRFkVghuT2Sw@mail.gmail.com>
 <87si0u6y9h.fsf@smart-cactus.org>
 <CAJ0eudpmejY8Tefr98jNSzRH4qJ4-d6FHX3=D9a0GSywEO337Q@mail.gmail.com>
 <8737st6iyg.fsf@smart-cactus.org>
 <98EE8A62-8397-4D21-ABB4-63D4604D7062@cis.upenn.edu>
 <9723F5A2-8FA7-4389-AE55-B46481748216@justtesting.org>
 <CADnndOrb_CACoOG4nphk+NF4HPfknT14ibSTav=d3c0gZDVHtw@mail.gmail.com>
 <1455764544.2889103.524482378.1C9DA511@webmail.messagingengine.com>
 <C90C0188-2850-4262-B40E-0CF192AA48CF@justtesting.org>
Message-ID: <CA+Vhx4T3B1b+JidNzNU0vJnL=NTcdU_ewycOoctCfdw6dC7TtQ@mail.gmail.com>

I dispute your second point a bit: I consider any Prelude changes a
standard library change than a language change, not withstanding the fact
the Prelude is imported by default. Any beginner-language library can still
be imported from normal code. Likewise a "hygienic copy paste" would simply
import the beginner prelude qualified and mangle identifiers as necessary.

I'm inclined to think the Racket way is the only true solution here.

John

On Wed, Feb 24, 2016 at 6:07 PM, Manuel M T Chakravarty <
chak at justtesting.org> wrote:

> Two notable differences between Racket and the situation in Haskell is
> that (1) Racket has a full blown IDE to support the staged languages and
> (2) AFIK any Racket program in a simpler language is still a valid Racket
> program in a more advanced language. (The latter wouldn?t be the case with,
> e.g., a Prelude omitting type classes as you need to introduce new names
> ?to avoid overloading? that are no longer valid in the full Prelude.)
>
> Manuel
>
> > Eric Seidel <eric at seidel.io>:
> >
> > On Wed, Feb 17, 2016, at 08:09, Christopher Allen wrote:
> >> I have tried a beginner's Prelude with people. I don't have a lot of
> data
> >> because it was clearly a failure early on so I bailed them out into the
> >> usual thing. It's just not worth it and it deprives them of the
> >> preparedness to go write real Haskell code. That's not something I'm
> >> willing to give up just so I can teach _less_.
> >
> > Chris, have you written about your experiences teaching with a
> > beginner's Prelude? I'd be quite interested to read about it, as (1) it
> > seems like a natural thing to do and (2) the Racket folks seem to have
> > had good success with their staged teaching languages.
> >
> > In particular, I'm curious if your experience is in the context of
> > teaching people with no experience programming at all, vs programming
> > experience but no Haskell (or generally FP) experience. The Racket "How
> > to Design Programs" curriculum seems very much geared towards absolute
> > beginners, and that could be a relevant distinction.
> >
> > Thanks!
> > Eric
> > _______________________________________________
> > 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/20160302/9920e675/attachment.html>

From jmct at jmct.cc  Thu Mar  3 04:53:11 2016
From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=)
Date: Wed, 2 Mar 2016 23:53:11 -0500
Subject: Generalising the demand analysis to sum types
In-Reply-To: <0886734b02f14ac28c9bef340c1f94dc@DB4PR30MB030.064d.mgd.msft.net>
References: <CAK+ijds8hEGKEk9EhxBoapfNC3g6HAfOjYcvg1KLJD2wyP9ZoA@mail.gmail.com>
 <5ef58ac4619940608835ec3662591316@DB4PR30MB030.064d.mgd.msft.net>
 <CAK+ijdvcLKZw-WcYHsEN0TFvn--2uaraFCTJdHB=XTc9_SXOuw@mail.gmail.com>
 <0886734b02f14ac28c9bef340c1f94dc@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAK+ijdty2QhC=VYoT58MhurAedV3pYYbtJeiHVcieLZrWaefCg@mail.gmail.com>

Hello again,

On Tue, Mar 1, 2016 at 11:56 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
>
> Don't forget AbsDmd too!
>

Yes, we're working on this too. Currently we're doing something
analogous to what we're doing with StrDmd:

data UseDmd
  = UCall Count UseDmd
  | UProd [ArgUse]
  | USum [(Tag, UseDmd)]
  | UHead
  | Used

The big question deals with how to 'insert' a usage demand on an
alternative of a case into a usage demand on the entire sum. The
current thought is that you collect the usage demands on the fields of
the constructor for the alternative you're analysing (let's say it's
tag 1) and insert that into a USum where the usage demands on all the
other constructors (all the tags except 1) is UHead. The rational
behind using UHead is that the constructor itself is demanded at UHead
by the case expression. Once you have one of these for every
alternative, you lub them together appropriately, so anywhere you
actually used a field would be represented in the final demand on the
sum since UHead `lubUse` u = u


> Do start a wiki page to explain all this.
>

Definitely.

Cheers,

Jose

From cma at bitemyapp.com  Thu Mar  3 07:54:55 2016
From: cma at bitemyapp.com (Christopher Allen)
Date: Thu, 3 Mar 2016 01:54:55 -0600
Subject: Specialized type hints
Message-ID: <CADnndOrpRRSALBTUZ6jcVZF3uVVwOHJhirRqrV+zd88GX51QzA@mail.gmail.com>

I'd like to see how warm people would be to catching GHC's type error
quality up a bit.

I did a write-up on a confusion a reader of our book had:

https://gist.github.com/bitemyapp/c27c721b92dab0248433

This is not new. A lot of people complain about this particular type error
in particular when they say GHC has bad type errors. I don't think GHC's
type errors are bad, but I do think they could be improved and this
particular issue has an unfortunate source to sink distance.

I would rather type error improvements not be buried behind a "silly
beginners only" flag and that they just be part of improving the UX for
everyone. With that proviso, how likely would specialized type error hints
and some general error message fix ups be regarded?

By specialized I mean, "detect that they tried to find an instance of Num
for (-> something something) and suggest that they did the wrong thing,
with possible fixes: X Y Z". Ideally before the "hey do you want
FlexibleContexts?!" thing fires.

I do not think I am capable of doing this, but being able to zoom in, clang
style, to the expression where they are (probably accidentally) using a
function like a Num or a Num like a function would be pretty valuable so
they don't have to guess-n-check parenthesize their code.


-- 
Chris Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160303/4d0ae6a9/attachment.html>

From spitzenb at fim.uni-passau.de  Thu Mar  3 08:29:49 2016
From: spitzenb at fim.uni-passau.de (David Spitzenberg)
Date: Thu, 3 Mar 2016 09:29:49 +0100
Subject: Questions on 'proc point splitting' again
In-Reply-To: <566EF96E.2010302@fim.uni-passau.de>
References: <566D6721.9050500@fim.uni-passau.de>
 <566EF96E.2010302@fim.uni-passau.de>
Message-ID: <56D7F5FD.6060403@fim.uni-passau.de>

Hello everyone!

First of all, my apologies for letting you wait that long. Especially, I
want to let you know that I really feel sorry for not following up your
offer back in January, Simon.

I somewhat underestimated the amount of time I had to invest in
university during the last semester. Unfortunately, I couldn't find the
time to work out the demonstration I mentioned in my last mail back in
December.

At the moment, I'm making up for this showcase. In doing so, I stumbled
across another question concerning the cmm-pipeline:

Given a CmmGraph, is there a possibility to annotate information to a
single node within this graph? I.e. I want to annotate to certain
CmmCalls that they where introduced by 'proc point splitting'. I would
like to slightly modifiy the generation of LLVM IR for such Calls later on.

Thanks for your help in advance!

Regards,

David



On 12/14/2015 06:16 PM, David Spitzenberg wrote:
> Simon
> 
>> |  Could you explain the need of further info-tables for 'inner'
>> |  proc-points (those, which are not the entry-block of a function) to
>> |  me, please?
>>
>> The main purpose of inner info tables is this.  Given (case e of blah) we push a return address (for 'blah') on the stack and evaluate 'e'.  During evaluation of 'e', garbage collection may take place.  So the garbage collector needs to walk the stack to follow live pointers.  Who knows what pointers are live?  Answer: the code for 'blah' clearly knows what pointers are alive in the current stack frame, because it is going to access them.  So the return address gets an info table that makes that implicit knowledge explicit, as a bitmap describing the liveness/pointer-hood of the stack frame.
>>
>> Addresses that are only jumped to don?t need info tables.
>>
>> It would be great if, as you learn about this stuff, you could add to the Commentary
>> https://ghc.haskell.org/trac/ghc/wiki/Commentary
>> to capture what you have learned.
> 
> Thank you very much! In cases I find the current description imprecise
> or incomplete I can add what I've learned to the Commentary of course.
> 
>> |  The documentation states, that proc-point splitting is only required
>> |  by the LLVM backend (see [2]). Does the cmm-pipeline perform proc-
>> |  point splitting even when using the native code generator?
>>
>> I'm not certain, but I don't think so.
>>
>> |  As stated above, the major problem of LLVM seems to be inferring
>> |  control flow when it comes to call proc-points. As it's hard to avoid
>> |  proc-point splitting, we leave the cmm-pipeline 'as-is'. We modify the
>>
>> I regard the whole proc-point thing as a major wart.  I think we should work hard to eliminate it.  So: another line of thought might be: how could we influence LLVM so that we didn't need proc-point splitting?
> 
> I totally agree with you here. However, determining how LLVM needs to be
> influenced to eliminate proc-point splitting is a thing I won't be
> capable of doing mid term because of my current knowledge and lack of time.
> 
>> |  To make control flow more apparent to LLVM, they came up with the
>> |  following idea. Remark before showing the idea: I know that it greatly
>>
>> I'm sorry to say that I didn't really understand the idea.  Maybe someone else did?  David Terei?
> 
> My apologies for being imprecise. I hope to find the time to
> work out a little demonstration during the upcoming holidays. I'm
> currently fully occupied by university because of upcoming exams this week.
> 
>> If you are seriously about investing effort in the back end, I'd be happy to help; in that case a Skype call is probably the best way.
> 
> That is a great idea. Due to the above mentioned time constraints I
> propose that we follow up in January.
> 
> Regards,
> 
> David
> 
> 
> 
> 
> 
>> Simon
>>
>> |  interferes with CPS. It leaves parts of the continuation-handling to
>> |  the implicit LLVM call-stack. Further, this does not solve the problem
>> |  of proc-point splitting at all. It is more a workaround than a
>> |  solution.
>> |  But it would greatly increase LLVM's possibilities to optimize code
>> |  later on. That's why I found this idea worth mentioning. Especially
>> |  because after reading your answer, Ben, I'm somewhat convinced that
>> |  solving the problem of proc-point splitting is nearly impossible with
>> |  the capabilities of LLVM IR available at the moment. Now back to the
>> |  idea.
>> |  
>> |  As stated above, the major problem of LLVM seems to be inferring
>> |  control flow when it comes to call proc-points. As it's hard to avoid
>> |  proc-point splitting, we leave the cmm-pipeline 'as-is'. We modify the
>> |  code, llvmGen produces when it comes to call proc-points instead. All
>> |  other types of proc-points remain unchanged.
>> |  
>> |  Initial situation in pseudo cmm:
>> |  
>> |  foo() {
>> |  ...
>> |  call bar() returns to cont // bar defined externally
>> |  
>> |  cont:
>> |  ...
>> |  }
>> |  
>> |  After proc-point splitting, this is converted into LLVM IR similar to
>> |  the following:
>> |  
>> |  @foo() {
>> |  ...
>> |  store @cont(), %Sp ; push continuation on the stack tail call @bar() ;
>> |  @bar defined externally }
>> |  
>> |  @cont() {
>> |  ...
>> |  }
>> |  
>> |  To fix the above issue, we introduce a method, which restores the
>> |  pointers Sp, Hp and the register R1 (among everything else, what has
>> |  to be restored) and 'fakes' the continuation. Note, that '@restore'
>> |  returns without calling into the continuation. This way, the call into
>> |  the continuation can be made direct. The above code would be
>> |  transformed into something similar to the following:
>> |  
>> |  @foo() {
>> |  ...
>> |  store @restore(), %Sp ; 'fake' continuation call @bar() ; br label
>> |  restore
>> |  
>> |  restore:
>> |  %Sp = load (getelementptr @environment 0, 0) ; restore what has to be
>> |  ... ; restored tail call @cont() }
>> |  
>> |  @cont() {
>> |  ...
>> |  }
>> |  
>> |  @restore(%Sp, %Hp, %R1, ...) {
>> |  store %Sp, (getelementptr @environment 0, 0) ; store everything into
>> |  ... ; global variable ret void }
>> |  
>> |  @environment ; structure of type similar to {i64*, i64*, i64*, i64,
>> |  i64, ..}
>> |  
>> |  As an alternative, the above transformation could be done by a LLVM
>> |  pass. llvmGen could then annotate the continuation of calls call cite.
>> |  This would greatly simplify the detection of the correct continuation.
>> |  
>> |  What do you think about this idea? Especially when thinking about the
>> |  interference with CPS?
>> |  
>> |  Regards,
>> |  
>> |  David
>> |  
>> |  
>> |  
>> |  
>> |  [1]
>> |  https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GeneratedCod
>> |  e#Importantconceptsinthemachine
>> |  
>> |  [2]
>> |  https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/CodeGen#Seco
>> |  ndstage:theCmmpipeline
>> |  
>> |  
>> |  
>> |  
>> |  On 11/21/2015 12:00 AM, Ben Gamari wrote:
>> |  > Simon Peyton Jones <simonpj at microsoft.com> writes:
>> |  >
>> |  >> David
>> |  >>
>> |  >> All this stuff is terribly paged-out for me. But I'd love someone
>> |  to
>> |  >> pay attention to some of this back-end stuff, so if you'd like to
>> |  >> work there, I'd like to help you.
>> |  >>
>> |  >> David Terei was also thinking of getting rid of proc point
>> |  splitting
>> |  >> for LLVM (see attached email and the notes attached to it)
>> |  >>
>> |  >> Simon Marlow also was thinking about this; see his attached email.
>> |  >>
>> |  >> The main *reason* for establishing a proc-point is so that, when
>> |  >> generating C code (which we don't do any more) you can take its
>> |  >> address. E.g.
>> |  >>
>> |  >> foo() { ... Push &bar onto the stack (effectively a return address)
>> |  >>   Jump to thingumpy }
>> |  >>
>> |  >> bar() { ... }
>> |  >>
>> |  >> Really bar is part of foo, but we have make it a separate top level
>> |  >> thing so that we can take the address of bar and push it on the
>> |  stack.
>> |  >>
>> |  >> The trouble is that if there is a label inside bar that foo wants
>> |  to
>> |  >> jump to (i.e. without pushing &bar etc) then we have to make that
>> |  >> label too into a proc-point, so that both foo and bar can see it.
>> |  >> Urgh.
>> |  >>
>> |  >> In LLVM this probably is not true; presumably you can take the
>> |  >> address of any label?
>> |  >>
>> |  > This is true. While labels themselves have function-local scope in
>> |  > LLVM, there is an expression, `blockaddress`, which allows you to
>> |  take
>> |  > an address to a label in another function [1]. That being said, in
>> |  > reading through the documentation it's not at all clear to me that
>> |  it
>> |  > would be safe to jump to such an address. In fact, given that the
>> |  > instruction that this expression is supposed to be used with,
>> |  > `indirectbr`, can only be used for local blocks, I suspect it is
>> |  not.
>> |  > More information about this feature can be found here [2].
>> |  >
>> |  > The jump issue aside, I don't know how you would deal with
>> |  > tables-next-to-code. The prefix data support that currently
>> |  available
>> |  > in LLVM is attached to functions and I unfortunately don't see that
>> |  > changing any time soon.
>> |  >
>> |  > Ultimately it seems that trying to refer to labels defined in other
>> |  > functions is using LLVM against the way it was intended. One
>> |  > alternative would be to teach llvmGen to merge mutually recusive
>> |  > top-level functions into a single LLVM function during code
>> |  > generation. Otherwise I'm afraid you are stuck with either the
>> |  status
>> |  > quo or attempting to improve on LLVM's own cross-procedure
>> |  optimization ability.
>> |  >
>> |  > That being said, it sounds as though eliminating proc-point
>> |  splitting
>> |  > would make for quite a nice project in the native code generator.
>> |  >
>> |  > Cheers,
>> |  >
>> |  > - Ben
>> |  >
>> |  >
>> |  > [1]
>> |  >
>> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fllvm.o
>> |  > rg%2fdocs%2fLangRef.html%23addresses-of-basic-
>> |  blocks&data=01%7c01%7csi
>> |  >
>> |  monpj%40064d.mgd.microsoft.com%7c7fdbfda0b4514a098c4d08d2f74448f1%7c72
>> |  >
>> |  f988bf86f141af91ab2d7cd011db47%7c1&sdata=nKVLgmZezUdEYL%2fma1exMMPLbcT
>> |  > RkaE1JrvVaR1EesY%3d [2]
>> |  >
>> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fblog.l
>> |  > lvm.org%2f2010%2f01%2faddress-of-label-and-indirect-
>> |  branches.html&data
>> |  >
>> |  =01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c7fdbfda0b4514a098c4d08d2
>> |  >
>> |  f74448f1%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BTMdZESwYS4tZa5W
>> |  > sOAqyFutoI5xNNFDe0b%2bdKC3ODs%3d [3]
>> |  >
>> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fllvm.o
>> |  > rg%2fdocs%2fLangRef.html%23prefix-
>> |  data&data=01%7c01%7csimonpj%40064d.m
>> |  >
>> |  gd.microsoft.com%7c7fdbfda0b4514a098c4d08d2f74448f1%7c72f988bf86f141af
>> |  >
>> |  91ab2d7cd011db47%7c1&sdata=rdo4ZLjjE%2bWxNykVL%2bSuToWioY6nzQpflSk296E
>> |  > 8W70%3d
>> |  >
>>
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 

From slyich at gmail.com  Thu Mar  3 09:52:07 2016
From: slyich at gmail.com (Sergei Trofimovich)
Date: Thu, 3 Mar 2016 09:52:07 +0000
Subject: RTS's (old?) invariant regarding OS blocking
In-Reply-To: <20160302143856.GA21211@gmail.com>
References: <20160302143856.GA21211@gmail.com>
Message-ID: <20160303095207.1cb8519d@sf>

On Wed, 2 Mar 2016 16:38:56 +0200
Dan Aloni <dan at kernelim.com> wrote:

> Hi,
> 
> While trying to gain insights into the RTS, I've noticed the following in
> the Wiki page [1] on the topic of the scheduler:
> 
>     Invariant: a task that holds a capability is not blocked in the operating system.
> 
>     This makes some parts of the system simpler - for example, we can use spin locks that spin indefinitely, because we can ensure that the spin lock is only held by a currently executing CPU, and will therefore be released in a finite (and short) amount of time.
> 
> Does it still apply to modern day GHC, or was it addressed by [2]?

It still does apply. Foreign calls are by default 'safe' and executed
after Capability is released to a separate OS thread.
Capability release is needed as foreign calls can reenter haskell RTS.

You can break that invariant and observe the negative effect.
For example 'unsafe' foreign call to a blocking function stops
all haskell threads happened to be queued on that Capability.

Illustration of adverse effect. [1] runs 2 threads:
- main thread issues 'safe' and 'unsafe' FFI sleeps
- auxiliary thread prints a message on screen every second.

'unsafe_sleep' blocks unrelated haskell thread for 5 seconds
while 'safe_sleep' doesn't.

We disable SIGVTALARM to not interfere with sleep() system call
and use threaded RTS as non-threaded RTS uses SIGVTALARM
for thread switching as well.

$ ghc --make a.hs -o ./a -rtsopts -threaded && ./a +RTS -V0 -N1
[1 of 1] Compiling Main             ( a.hs, a.o )
Linking ./a ...

"start unsafe sleep"
"thread: enter"
"done unsafe sleep"
"entering safe sleep"
"*** thread: tick"
"*** thread: tick"
"*** thread: tick"
"*** thread: tick"
"done safe sleep"
"*** thread: tick"
"*** thread: tick"
"*** thread: tick"
"*** thread: tick"
"*** thread: tick"
"*** thread: tick"
"thread: exit"

-- [1]: example program a.hs:
import Control.Concurrent
import Control.Monad
import Foreign.C

foreign import ccall safe "unistd.h sleep"
    safe_sleep :: CInt -> IO CInt
foreign import ccall unsafe "unistd.h sleep"
    unsafe_sleep :: CInt -> IO CInt

-- sleep for n * 100ms
s :: Int -> IO ()
s slices = threadDelay $ slices * 10^6

main = do
    t1_lock <- newEmptyMVar
    t1 <- forkIO $ do
        print "thread: enter"
        replicateM_ 10 $ do
            s 1
            print "*** thread: tick"
        print "thread: exit"
        putMVar t1_lock ()

    yield -- switch to the ticker

    print "start unsafe sleep"
    unsafe_sleep 5
    print "done unsafe sleep"

    print "entering safe sleep"
    safe_sleep 5
    print "done safe sleep"

    takeMVar t1_lock

-- 

  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/20160303/1d314b47/attachment.sig>

From ben at well-typed.com  Thu Mar  3 10:32:14 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 03 Mar 2016 11:32:14 +0100
Subject: Questions on 'proc point splitting' again
In-Reply-To: <56D7F5FD.6060403@fim.uni-passau.de>
References: <566D6721.9050500@fim.uni-passau.de>
 <566EF96E.2010302@fim.uni-passau.de> <56D7F5FD.6060403@fim.uni-passau.de>
Message-ID: <87twknyhqp.fsf@smart-cactus.org>

David Spitzenberg <spitzenb at fim.uni-passau.de> writes:

> Hello everyone!
>
> First of all, my apologies for letting you wait that long. Especially, I
> want to let you know that I really feel sorry for not following up your
> offer back in January, Simon.
>
Don't worry at all; life happens. Any effort your are able to contribute
is appreciated.

> I somewhat underestimated the amount of time I had to invest in
> university during the last semester. Unfortunately, I couldn't find the
> time to work out the demonstration I mentioned in my last mail back in
> December.
>
> At the moment, I'm making up for this showcase. In doing so, I stumbled
> across another question concerning the cmm-pipeline:
>
> Given a CmmGraph, is there a possibility to annotate information to a
> single node within this graph? I.e. I want to annotate to certain
> CmmCalls that they where introduced by 'proc point splitting'. I would
> like to slightly modifiy the generation of LLVM IR for such Calls later on.
>
My guess here would be to map the CmmGraph (which is simply a type
synonym for `GenCmmGraph CmmNode` to something of type `GenCmmGraph
AnnCmmNode` where AnnCmmNode carries a CmmNode along with whatever other
information you'd like to preserve.

This then poses the question of what you'd like to *do* with this graph,
since you'll be unable to use much of the GHC's existing machinery.
My (possibly mistaken) impression is that we don't have a terribly great
story in GHC for working with arbitrarily annotated Cmm graphs.

I'm afraid we have now scraped past the bounds of my knowledge, however;
hopefully one of the Simons will be able to set you off in the right
direction.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160303/2c9f35c6/attachment.sig>

From dan at kernelim.com  Thu Mar  3 11:00:28 2016
From: dan at kernelim.com (Dan Aloni)
Date: Thu, 3 Mar 2016 13:00:28 +0200
Subject: RTS's (old?) invariant regarding OS blocking
In-Reply-To: <20160303095207.1cb8519d@sf>
References: <20160302143856.GA21211@gmail.com>
 <20160303095207.1cb8519d@sf>
Message-ID: <20160303110028.GA26976@gmail.com>

On Thu, Mar 03, 2016 at 09:52:07AM +0000, Sergei Trofimovich wrote:
> On Wed, 2 Mar 2016 16:38:56 +0200
> Dan Aloni <dan at kernelim.com> wrote:
> 
> > Hi,
> > 
> > While trying to gain insights into the RTS, I've noticed the following in
> > the Wiki page [1] on the topic of the scheduler:
> > 
> >     Invariant: a task that holds a capability is not blocked in the operating system.
> > 
> >     This makes some parts of the system simpler - for example, we can use spin locks that spin indefinitely, because we can ensure that the spin lock is only held by a currently executing CPU, and will therefore be released in a finite (and short) amount of time.
> > 
> > Does it still apply to modern day GHC, or was it addressed by [2]?
> 
> It still does apply. Foreign calls are by default 'safe' and executed
> after Capability is released to a separate OS thread.
> Capability release is needed as foreign calls can reenter haskell RTS.

Thanks for the elborate example - however my concerns extend beyond
the safe vs. unsafe FFI. I was concerned about the spin lock, and about
hard host kernel scheduling assumptions thereof.

I looked into the GHC code now, and the locks in Capability.c on Linux
seem to translate to pthread_mutex_lock(), which is a futex. This is
a relief. Does the wiki need updating?

--
Dan Aloni

From eric at seidel.io  Thu Mar  3 16:58:13 2016
From: eric at seidel.io (Eric Seidel)
Date: Thu, 03 Mar 2016 08:58:13 -0800
Subject: Specialized type hints
In-Reply-To: <CADnndOrpRRSALBTUZ6jcVZF3uVVwOHJhirRqrV+zd88GX51QzA@mail.gmail.com>
References: <CADnndOrpRRSALBTUZ6jcVZF3uVVwOHJhirRqrV+zd88GX51QzA@mail.gmail.com>
Message-ID: <1457024293.2098542.538672666.5A1B26B2@webmail.messagingengine.com>



On Wed, Mar 2, 2016, at 23:54, Christopher Allen wrote:
> I'd like to see how warm people would be to catching GHC's type error
> quality up a bit.
> 
> I did a write-up on a confusion a reader of our book had:
> 
> https://gist.github.com/bitemyapp/c27c721b92dab0248433

Wow, this is a pretty nasty error message. In particular because it
relies on the overloaded nature of integer literals. Compare

ghci> negate * 10
<interactive>:2:1:
    Non type-variable argument in the constraint: Num (a -> a)
    (Use FlexibleContexts to permit this)
    When checking that ?it? has the inferred type
      it :: forall a. (Num a, Num (a -> a)) => a -> a

with

ghci> negate * (10 :: Int)
<interactive>:4:11:
    Couldn't match expected type ?a -> a? with actual type ?Int?
    Relevant bindings include it :: a -> a (bound at <interactive>:4:1)
    In the second argument of ?(*)?, namely ?(10 :: Int)?
    In the expression: negate * (10 :: Int)
    In an equation for ?it?: it = negate * (10 :: Int)

In the first case (your example), GHC actually finds a valid type for
the expression (assuming FlexibleContexts) because `10` is actually
`fromIntegral 10`, which is overloaded. On the other hand, if you
constrain `10` to be an `Int` there's an immediate unification error,
which is much more helpful.

> This is not new. A lot of people complain about this particular type
> error
> in particular when they say GHC has bad type errors. I don't think GHC's
> type errors are bad, but I do think they could be improved and this
> particular issue has an unfortunate source to sink distance.
>
> I would rather type error improvements not be buried behind a "silly
> beginners only" flag and that they just be part of improving the UX for
> everyone. With that proviso, how likely would specialized type error
> hints
> and some general error message fix ups be regarded?
> 
> By specialized I mean, "detect that they tried to find an instance of Num
> for (-> something something) and suggest that they did the wrong thing,
> with possible fixes: X Y Z". Ideally before the "hey do you want
> FlexibleContexts?!" thing fires.
> 
> I do not think I am capable of doing this, but being able to zoom in,
> clang
> style, to the expression where they are (probably accidentally) using a
> function like a Num or a Num like a function would be pretty valuable so
> they don't have to guess-n-check parenthesize their code.

One thing I've noticed other compilers doing (and this might be exactly
what you're hinting at) is provide a sort of provenance of the error, in
the form of warnings and notes. For example, even though using `*` at
`Num (a -> a)` isn't immediately bogus, it is suspicious, so we could
record a note and print it out alongside the error message, should one
arise.

The other thing we could do, which I think would help novices in
particular, is to just allow you to run ill-typed programs in ghci.
Running the program in a debugger gives you so much more information
about what's going on. You did exactly that at the top of your link, but
you had to write out the steps manually, whereas we could have a machine
do it for us! (In fact, I've been working on this lately, albeit for
ocaml programs since we teach ocaml to our undergrads. I think the
results are quite nice http://goto.ucsd.edu:8091)

Eric

From allbery.b at gmail.com  Thu Mar  3 17:00:56 2016
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 3 Mar 2016 12:00:56 -0500
Subject: Specialized type hints
In-Reply-To: <1457024293.2098542.538672666.5A1B26B2@webmail.messagingengine.com>
References: <CADnndOrpRRSALBTUZ6jcVZF3uVVwOHJhirRqrV+zd88GX51QzA@mail.gmail.com>
 <1457024293.2098542.538672666.5A1B26B2@webmail.messagingengine.com>
Message-ID: <CAKFCL4XM3c71P0fsjZnCzzxOdiPXy-aOpjcwGhgcJxM7zwW=TQ@mail.gmail.com>

On Thu, Mar 3, 2016 at 11:58 AM, Eric Seidel <eric at seidel.io> wrote:

> On Wed, Mar 2, 2016, at 23:54, Christopher Allen wrote:
> > I'd like to see how warm people would be to catching GHC's type error
> > quality up a bit.
> >
> > I did a write-up on a confusion a reader of our book had:
> >
> > https://gist.github.com/bitemyapp/c27c721b92dab0248433
>
>
>
> Wow, this is a pretty nasty error message. In particular because it
> relies on the overloaded nature of integer literals.


We actually had another such situation come up in #haskell yesterday, btw.
Someone confused type constructors and data constructors, and the error
message assumed they wanted DataKinds and type level programming. This is
kinda bad for newcomers.

-- 
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/20160303/b28a0941/attachment.html>

From facundo.dominguez at tweag.io  Thu Mar  3 19:41:25 2016
From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=)
Date: Thu, 3 Mar 2016 16:41:25 -0300
Subject: Local bindings in the static form
Message-ID: <CA+Q==SDSA4gncXAAd9dGWvWT28Tre44DZshuMigF-xLX_MXhaQ@mail.gmail.com>

Hello,
  At Tweag I/O we are considering relaxing a bit the constraints on
the static form.

static <exp>

  demands <exp> to be closed. That is, the free variables of <exp>
must be bound at the top level.

However, it would be fine to allow local bindings too. For instance:

test :: StaticPtr ([[Int]] -> [[Int]])
test x = static (filter hasZero)
  where
    hasZero = any isZero
    isZero  = (0 ==)

Where hasZero is local but its body can be considered kind of closed
(all free variables refer to top-level bindings or other *closed*
local bindings.).

We would need for this implementation a way to test closedness in this
sense. Could there be any similar test implemented already in GHC?

Thanks,
Facundo

[1] https://ghc.haskell.org/trac/ghc/ticket/11656

From jmct at jmct.cc  Fri Mar  4 02:46:04 2016
From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=)
Date: Thu, 3 Mar 2016 21:46:04 -0500
Subject: isRecursiveTyCon
Message-ID: <CAK+ijdtVwnqBEmQYm7mKuwctwDv+XCL-Bn1pDNVC2pLgyuZb=w@mail.gmail.com>

Hello,

I'm extending GHC's demand analysis to sum types, but _not_ recursive
types. I was searching for a function that would tell me if a TyCon is
recursive, so that I could analyse Maybes but avoid Lists.

I found isRecursiveTyCon, but it's not actually for this purpose,
there's actually a long note in typecheck/TcTyDecls.hs that explains
why it's not fit for determining which type constructors are recursive
in general. The key point from the note is

"The "recursive" flag for algebraic data types is irrelevant (never
consulted) for types with more than one constructor."

It seems that because the strictness analyser never worked over sum
types it never had to worry about recursive sum types and at some
point the flag that says a data type is recursive broke for sum types
without anyone knowing.

For example the following mutually recursive data types have different
return values from isRecursiveTyCon

data OddNat = One | SuccO EvenNat

data EvenNat = Zero | SuccE OddNat


Does anyone know of the simplest way to test for this?

Thanks for your time,

Jose

From spitzenb at fim.uni-passau.de  Fri Mar  4 08:39:54 2016
From: spitzenb at fim.uni-passau.de (David Spitzenberg)
Date: Fri, 4 Mar 2016 09:39:54 +0100
Subject: Questions on 'proc point splitting' again
In-Reply-To: <87twknyhqp.fsf@smart-cactus.org>
References: <566D6721.9050500@fim.uni-passau.de>
 <566EF96E.2010302@fim.uni-passau.de> <56D7F5FD.6060403@fim.uni-passau.de>
 <87twknyhqp.fsf@smart-cactus.org>
Message-ID: <56D949DA.8070506@fim.uni-passau.de>



On 03/03/2016 11:32 AM, Ben Gamari wrote:

>> Given a CmmGraph, is there a possibility to annotate information to a
>> single node within this graph? I.e. I want to annotate to certain
>> CmmCalls that they where introduced by 'proc point splitting'. I would
>> like to slightly modifiy the generation of LLVM IR for such Calls later on.
>>
> My guess here would be to map the CmmGraph (which is simply a type
> synonym for `GenCmmGraph CmmNode` to something of type `GenCmmGraph
> AnnCmmNode` where AnnCmmNode carries a CmmNode along with whatever other
> information you'd like to preserve.
> 
> This then poses the question of what you'd like to *do* with this graph,
> since you'll be unable to use much of the GHC's existing machinery.
> My (possibly mistaken) impression is that we don't have a terribly great
> story in GHC for working with arbitrarily annotated Cmm graphs.

Thank you very much, Ben. Basically, I just want the annotation to be
propagated all the way down to the backend-code generation (llvmGen in
this case). At the moment, I can't find any need to modify the map you
suggest in between. So using the existing machinery shouldn't be
necessary to do any work on the map itself. Propagating this newly
introduced map to where I want to use it seems harder, though.

I'm going to have a look at it and put some more questions to you, if I
struggle to find a way to propagate the map.

Regards,

David

From simonpj at microsoft.com  Fri Mar  4 10:21:09 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 4 Mar 2016 10:21:09 +0000
Subject: Generalising the demand analysis to sum types
In-Reply-To: <CAK+ijdty2QhC=VYoT58MhurAedV3pYYbtJeiHVcieLZrWaefCg@mail.gmail.com>
References: <CAK+ijds8hEGKEk9EhxBoapfNC3g6HAfOjYcvg1KLJD2wyP9ZoA@mail.gmail.com>
 <5ef58ac4619940608835ec3662591316@DB4PR30MB030.064d.mgd.msft.net>
 <CAK+ijdvcLKZw-WcYHsEN0TFvn--2uaraFCTJdHB=XTc9_SXOuw@mail.gmail.com>
 <0886734b02f14ac28c9bef340c1f94dc@DB4PR30MB030.064d.mgd.msft.net>
 <CAK+ijdty2QhC=VYoT58MhurAedV3pYYbtJeiHVcieLZrWaefCg@mail.gmail.com>
Message-ID: <2fb55da3e9444b719118f19ad3857416@DB4PR30MB030.064d.mgd.msft.net>

|  current thought is that you collect the usage demands on the fields of
|  the constructor for the alternative you're analysing (let's say it's
|  tag 1) and insert that into a USum where the usage demands on all the
|  other constructors (all the tags except 1) is UHead.

I'm not sure you really need that. You could instead say that USum xs implies at least UHead on all the other tags not mentioned in xs.

Simon

|  -----Original Message-----
|  From: Jos? Manuel Calder?n Trilla [mailto:jmct at jmct.cc]
|  Sent: 03 March 2016 04:53
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: Joachim Breitner <mail at joachim-breitner.de>; ?mer Sinan A?acan
|  <omeragacan at gmail.com>; ghc-devs at haskell.org
|  Subject: Re: Generalising the demand analysis to sum types
|  
|  Hello again,
|  
|  On Tue, Mar 1, 2016 at 11:56 AM, Simon Peyton Jones
|  <simonpj at microsoft.com> wrote:
|  >
|  > Don't forget AbsDmd too!
|  >
|  
|  Yes, we're working on this too. Currently we're doing something
|  analogous to what we're doing with StrDmd:
|  
|  data UseDmd
|    = UCall Count UseDmd
|    | UProd [ArgUse]
|    | USum [(Tag, UseDmd)]
|    | UHead
|    | Used
|  
|  The big question deals with how to 'insert' a usage demand on an
|  alternative of a case into a usage demand on the entire sum. The
|  current thought is that you collect the usage demands on the fields of
|  the constructor for the alternative you're analysing (let's say it's
|  tag 1) and insert that into a USum where the usage demands on all the
|  other constructors (all the tags except 1) is UHead. The rational
|  behind using UHead is that the constructor itself is demanded at UHead
|  by the case expression. Once you have one of these for every
|  alternative, you lub them together appropriately, so anywhere you
|  actually used a field would be represented in the final demand on the
|  sum since UHead `lubUse` u = u
|  
|  
|  > Do start a wiki page to explain all this.
|  >
|  
|  Definitely.
|  
|  Cheers,
|  
|  Jose

From simonpj at microsoft.com  Fri Mar  4 10:25:58 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 4 Mar 2016 10:25:58 +0000
Subject: Specialized type hints
In-Reply-To: <CADnndOrpRRSALBTUZ6jcVZF3uVVwOHJhirRqrV+zd88GX51QzA@mail.gmail.com>
References: <CADnndOrpRRSALBTUZ6jcVZF3uVVwOHJhirRqrV+zd88GX51QzA@mail.gmail.com>
Message-ID: <7c4121b67eae470485ef5477931c6714@DB4PR30MB030.064d.mgd.msft.net>

Christopher

Improving error message is an excellent goal, and one that I have spent more hours on than I care to tell you.

If you have a particular one in mind, could you open a Trac ticket with a particular reproducible test case, the error message you get, and the error message you?d like to get.

Thanks

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Christopher Allen
Sent: 03 March 2016 07:55
To: ghc-devs at haskell.org
Subject: Specialized type hints

I'd like to see how warm people would be to catching GHC's type error quality up a bit.

I did a write-up on a confusion a reader of our book had:

https://gist.github.com/bitemyapp/c27c721b92dab0248433<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgist.github.com%2fbitemyapp%2fc27c721b92dab0248433&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c64d227da349847f85fe308d343391dbb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EtjujRikMvoUN%2fBq6RtOrotsPdXdvZggnMU3Cu2BypE%3d>

This is not new. A lot of people complain about this particular type error in particular when they say GHC has bad type errors. I don't think GHC's type errors are bad, but I do think they could be improved and this particular issue has an unfortunate source to sink distance.

I would rather type error improvements not be buried behind a "silly beginners only" flag and that they just be part of improving the UX for everyone. With that proviso, how likely would specialized type error hints and some general error message fix ups be regarded?

By specialized I mean, "detect that they tried to find an instance of Num for (-> something something) and suggest that they did the wrong thing, with possible fixes: X Y Z". Ideally before the "hey do you want FlexibleContexts?!" thing fires.

I do not think I am capable of doing this, but being able to zoom in, clang style, to the expression where they are (probably accidentally) using a function like a Num or a Num like a function would be pretty valuable so they don't have to guess-n-check parenthesize their code.


--
Chris Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160304/04e6a041/attachment.html>

From simonpj at microsoft.com  Fri Mar  4 10:47:34 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 4 Mar 2016 10:47:34 +0000
Subject: Local bindings in the static form
In-Reply-To: <CA+Q==SDSA4gncXAAd9dGWvWT28Tre44DZshuMigF-xLX_MXhaQ@mail.gmail.com>
References: <CA+Q==SDSA4gncXAAd9dGWvWT28Tre44DZshuMigF-xLX_MXhaQ@mail.gmail.com>
Message-ID: <5c2393791c9f4bbbb0aee62b16f30005@DB4PR30MB030.064d.mgd.msft.net>

Facundo

Yes, that makes perfect sense.  Moreover, it is pretty much exactly what the tct_closed flag on `ATcId` does.

The trick will be to guarantee that all those Ids do in fact end up being floated out.

We could have a Skype chat about this, preferably after the March 16 ICFP deadline

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Facundo Dom?nguez
|  Sent: 03 March 2016 19:41
|  To: ghc-devs at haskell.org
|  Subject: Local bindings in the static form
|  
|  Hello,
|    At Tweag I/O we are considering relaxing a bit the constraints on the
|  static form.
|  
|  static <exp>
|  
|    demands <exp> to be closed. That is, the free variables of <exp> must
|  be bound at the top level.
|  
|  However, it would be fine to allow local bindings too. For instance:
|  
|  test :: StaticPtr ([[Int]] -> [[Int]])
|  test x = static (filter hasZero)
|    where
|      hasZero = any isZero
|      isZero  = (0 ==)
|  
|  Where hasZero is local but its body can be considered kind of closed
|  (all free variables refer to top-level bindings or other *closed* local
|  bindings.).
|  
|  We would need for this implementation a way to test closedness in this
|  sense. Could there be any similar test implemented already in GHC?
|  
|  Thanks,
|  Facundo
|  
|  [1] https://ghc.haskell.org/trac/ghc/ticket/11656
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cead97b273efa41c1
|  a49608d3439bd142%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Z1TbBcSgd
|  YLZ%2bXrMJVMvqJIfwc4R2kLeRaPPwuQ5%2fLQ%3d

From simonpj at microsoft.com  Fri Mar  4 10:57:35 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 4 Mar 2016 10:57:35 +0000
Subject: Questions on 'proc point splitting' again
In-Reply-To: <56D949DA.8070506@fim.uni-passau.de>
References: <566D6721.9050500@fim.uni-passau.de>
 <566EF96E.2010302@fim.uni-passau.de> <56D7F5FD.6060403@fim.uni-passau.de>
 <87twknyhqp.fsf@smart-cactus.org> <56D949DA.8070506@fim.uni-passau.de>
Message-ID: <70e17711bda64f27855ce55350f1331c@DB4PR30MB030.064d.mgd.msft.net>

Maybe you could just maintain a separate map "on the side" and push it through to the LLVM code gen?

I hate the whole proc-point machinery.  It's all caused by our inability to take the address of a local label.  So to push a return address on the stack we have to make it a top-level "procedure" and that gives rise to all the proc-point pain.  For the native code generator none of this is necessary (I think).

It's also annoyingly invasive.  Somehow proc-points ought to be localised to the LLVM back end, not pervasive in the Cmm pipeline.

In short, if you get deep into this, do feel free to propose something better!

Simon

|  -----Original Message-----
|  From: David Spitzenberg [mailto:spitzenb at fim.uni-passau.de]
|  Sent: 04 March 2016 08:40
|  To: Ben Gamari <ben at well-typed.com>; Simon Peyton Jones
|  <simonpj at microsoft.com>
|  Cc: ghc-devs at haskell.org
|  Subject: Re: Questions on 'proc point splitting' again
|  
|  
|  
|  On 03/03/2016 11:32 AM, Ben Gamari wrote:
|  
|  >> Given a CmmGraph, is there a possibility to annotate information to
|  a
|  >> single node within this graph? I.e. I want to annotate to certain
|  >> CmmCalls that they where introduced by 'proc point splitting'. I
|  >> would like to slightly modifiy the generation of LLVM IR for such
|  Calls later on.
|  >>
|  > My guess here would be to map the CmmGraph (which is simply a type
|  > synonym for `GenCmmGraph CmmNode` to something of type `GenCmmGraph
|  > AnnCmmNode` where AnnCmmNode carries a CmmNode along with whatever
|  > other information you'd like to preserve.
|  >
|  > This then poses the question of what you'd like to *do* with this
|  > graph, since you'll be unable to use much of the GHC's existing
|  machinery.
|  > My (possibly mistaken) impression is that we don't have a terribly
|  > great story in GHC for working with arbitrarily annotated Cmm graphs.
|  
|  Thank you very much, Ben. Basically, I just want the annotation to be
|  propagated all the way down to the backend-code generation (llvmGen in
|  this case). At the moment, I can't find any need to modify the map you
|  suggest in between. So using the existing machinery shouldn't be
|  necessary to do any work on the map itself. Propagating this newly
|  introduced map to where I want to use it seems harder, though.
|  
|  I'm going to have a look at it and put some more questions to you, if I
|  struggle to find a way to propagate the map.
|  
|  Regards,
|  
|  David

From simonpj at microsoft.com  Fri Mar  4 11:32:31 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 4 Mar 2016 11:32:31 +0000
Subject: isRecursiveTyCon
In-Reply-To: <CAK+ijdtVwnqBEmQYm7mKuwctwDv+XCL-Bn1pDNVC2pLgyuZb=w@mail.gmail.com>
References: <CAK+ijdtVwnqBEmQYm7mKuwctwDv+XCL-Bn1pDNVC2pLgyuZb=w@mail.gmail.com>
Message-ID: <11d9d09f4a064e5fa6bd765016c87e4d@DB4PR30MB030.064d.mgd.msft.net>

Identifying recursive types is an old and unsatisfactory part of GHC.

The code in TcTyDecls was an early attempt and has not received much love since.  Partly because it's not so clear exactly what it is trying to do! What precisely does it mean for a TyCon to be "recursive" and what guarantees do you get?

It's clearly something to do with spotting loops, but with higher kinds it's possible to construct fixpoint combinators (the details escape me this morning).

In most of GHC I've adopted a conservative "online" approach; see Note [Expanding newtypes and products] in TyCon, and the accompanying `RecTcChecker` stuff.  But it builds on isRecursiveTyCon; without that it'd be far too conservative (e.g. Maybe (Maybe t)).

Type/data families make things more interesting; as do hs-boot files.


I believe that a bit of systematic thinking will help here; it'd be great if you could do that.

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Jos?
|  Manuel Calder?n Trilla
|  Sent: 04 March 2016 02:46
|  To: ghc-devs at haskell.org
|  Subject: isRecursiveTyCon
|  
|  Hello,
|  
|  I'm extending GHC's demand analysis to sum types, but _not_ recursive
|  types. I was searching for a function that would tell me if a TyCon is
|  recursive, so that I could analyse Maybes but avoid Lists.
|  
|  I found isRecursiveTyCon, but it's not actually for this purpose,
|  there's actually a long note in typecheck/TcTyDecls.hs that explains
|  why it's not fit for determining which type constructors are recursive
|  in general. The key point from the note is
|  
|  "The "recursive" flag for algebraic data types is irrelevant (never
|  consulted) for types with more than one constructor."
|  
|  It seems that because the strictness analyser never worked over sum
|  types it never had to worry about recursive sum types and at some point
|  the flag that says a data type is recursive broke for sum types without
|  anyone knowing.
|  
|  For example the following mutually recursive data types have different
|  return values from isRecursiveTyCon
|  
|  data OddNat = One | SuccO EvenNat
|  
|  data EvenNat = Zero | SuccE OddNat
|  
|  
|  Does anyone know of the simplest way to test for this?
|  
|  Thanks for your time,
|  
|  Jose
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7caf0464cbbf1a4e18
|  627c08d343d72286%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=700%2bnpJ
|  Iry1DQgeUrTTO29vHQ1mQ3TrwLj2uXVw9QPk%3d

From _deepfire at feelingofgreen.ru  Fri Mar  4 13:43:00 2016
From: _deepfire at feelingofgreen.ru (Kosyrev Serge)
Date: Fri, 04 Mar 2016 16:43:00 +0300
Subject: Impredicative types in 8.0, again
Message-ID: <8760x2bbq3.fsf@feelingofgreen.ru>

Good day!

I realise that ImpredicativeTypes is a problematic extension, but I have
found something that looks like an outright bug -- no polymorphism involved:

,----
| {-# LANGUAGE ImpredicativeTypes #-}
|
| module Foo where
| 
| foo :: IO (Maybe Int)
| foo = do
|   pure $ case undefined :: Maybe String of
|             Nothing
|               -> Nothing
|             Just _
|               -> (undefined :: Maybe Int)
`----

produces the following errors:

,----
| foo.hs:7:3: error:
|     ? Couldn't match type ?forall a. Maybe a? with ?Maybe Int?
|       Expected type: IO (Maybe Int)
|         Actual type: IO (forall a. Maybe a)
|     ? In a stmt of a 'do' block:
|         pure
|         $ case undefined :: Maybe String of {
|             Nothing -> Nothing
|             Just _ -> (undefined :: Maybe Int) }
|       In the expression:
|         do { pure
|              $ case undefined :: Maybe String of {
|                  Nothing -> Nothing
|                  Just _ -> (undefined :: Maybe Int) } }
|       In an equation for ?foo?:
|           foo
|             = do { pure
|                    $ case undefined :: Maybe String of {
|                        Nothing -> Nothing
|                        Just _ -> (undefined :: Maybe Int) } }
| 
| foo.hs:11:19: error:
|     ? Couldn't match type ?a? with ?Int?
|       ?a? is a rigid type variable bound by
|         a type expected by the context:
|           forall a. Maybe a
|         at foo.hs:11:19
|       Expected type: forall a. Maybe a
|         Actual type: Maybe Int
|     ? In the expression: (undefined :: Maybe Int)
|       In a case alternative: Just _ -> (undefined :: Maybe Int)
|       In the second argument of ?($)?, namely
|         ?case undefined :: Maybe String of {
|            Nothing -> Nothing
|            Just _ -> (undefined :: Maybe Int) }?
`----

-- 
? ???????e? / respectfully,
??????? ??????

From omeragacan at gmail.com  Fri Mar  4 14:26:22 2016
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Fri, 4 Mar 2016 09:26:22 -0500
Subject: 'lub' and 'both' on strictness - what does it mean for products
 to have different arity?
In-Reply-To: <0a47f37356a741cdab879d2f57f52aaf@DB4PR30MB030.064d.mgd.msft.net>
References: <CAMQQO3=vTcsJLyOwfYshFmALx3V7GRqVCz5Ag3AfXP=YTt=9hQ@mail.gmail.com>
 <6a452a23dc2a47e0bf0244ad510845a6@DB4PR30MB030.064d.mgd.msft.net>
 <CAMQQO3=JxvECHk7Q+YxRM-zntNdmV21Q5+8iRV1xM8HYiPiwLw@mail.gmail.com>
 <CAMQQO3=48qYRiuUjW-BKT2Oxp++2=eKQE-pb_S7ve8BCt4ousw@mail.gmail.com>
 <0a47f37356a741cdab879d2f57f52aaf@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAMQQO3==_XvNXLhLt4=xz0TxfR5aOq4OkN2Pe54epiJ=u3EtOw@mail.gmail.com>

Simon, your GADT example clearly shows how lub sometimes needs to handle
products with different arities, but the case with bothDmd is still confuses
me. I think we need have a code like this:

    f x + g x

Where f puts a S(SS) demand on x and g puts a S(SSS). This looks like a
bug/type error to me. Do you have any example for bothDmd too?

(I started D1968 for documenting these)

2016-03-02 3:47 GMT-05:00 Simon Peyton Jones <simonpj at microsoft.com>:
>
> |      -- lubUse (UProd {}) Used             = Used
> |      lubUse (UProd ux) Used             = UProd (map (`lubArgUse`
> |  useTop) ux)
> |      lubUse Used       (UProd ux)       = UProd (map (`lubArgUse`
> |  useTop) ux)
> |
> |  And then somewhere around that code there's this:
> |
> |      Note [Used should win]
> |      ~~~~~~~~~~~~~~~~~~~~~~
> |      Both in lubUse and bothUse we want (Used `both` UProd us) to be
> |  Used.
> |      Why?  Because Used carries the implication the whole thing is used,
> |      box and all, so we don't want to w/w it.  If we use it both boxed
> |  and
> |      unboxed, then we are definitely using the box, and so we are quite
> |      likely to pay a reboxing cost.  So we make Used win here.
> |
> |      ...
> |
> |  It seems like at some point the note was valid, but now the code seems
> |  to be doing the opposite. Any ideas which one needs an update?
>
> I have no idea.  It seems that the entire definition of lubUse, including the Note and the commented-out line, appeared in a single big patch 99d4e5b4.   So no clues there.
>
> However the Note has some nofib numbers.
>
> So yes, it's puzzling.   The argument in the Note seems plausible.  Would you like to try reverting to "Used should win" and see what happens to performance?  Probably something will get worse and you'll have do some digging with ticky-ticky.
>
>
> |  I'm also a bit confused about why both and lub are not commutative, or
> |  if they're commutative, why do they have redundant cases.
>
> Yes: lub and both should be commutative; yell if not.  (In contrast see Note [Asymmetry of 'both' for DmdType and DmdResult]; but that's well documented.)
>
> | For example,
> |  lubUse has
> |  this:
> |
> |      lubUse UHead       u               = u
> |      lubUse (UCall c u) UHead           = UCall c u
> |
> |  instead of something like:
> |
> |      lubUse UHead u = u
> |      lubUse u UHead = u
>
> I think this is just stylistic. I was dealing with all the cases for UHead in the first arg, then all the cases for UCall, and so on. That way I know I've got coverage.
>
> (And perhaps it's more efficient: we pattern match at most once on each argument.
>
> Simon
>
> |
> |  I didn't check all the cases to see if it's really commutative or not,
> |  but can I assume that they need to be commutative and simplify the
> |  code? Otherwise let's add a note about why they're not commutative?
> |
> |  Thanks..
> |
> |  2016-03-02 1:07 GMT-05:00 ?mer Sinan A?acan <omeragacan at gmail.com>:
> |  >> Could I ask that you add this example as a Note to the relevant
> |  >> functions, so that the next time someone asks this question they'll
> |  >> find the answer right there?
> |  >
> |  > Yep, I'll do that soon.
> |  >
> |  > 2016-03-01 12:01 GMT-05:00 Simon Peyton Jones
> |  <simonpj at microsoft.com>:
> |  >> Omer
> |  >>
> |  >> Joachim is right.  The strictness analyser just looks inside casts,
> |  >> so these unexpectedly ill-typed cases could show up.  For example
> |  >>
> |  >> f :: T a -> a -> Int
> |  >> f x y = case x of
> |  >>           P1 -> case y of (a,b,c) -> a+b+c
> |  >>           P2 -> case y of (p,q) -> p+q
> |  >>
> |  >> data T a where
> |  >>   P1 :: T (Int,Int,Int)
> |  >>   P2 :: T (Int,Int)
> |  >>
> |  >> In the P1 branch we have that y::(Int,Int,Int), so we'll get a
> |  demand S(SSS).  And similarly in the P2 branch.  Now we combine them.
> |  And there you have it.
> |  >>
> |  >>
> |  >> Could I ask that you add this example as a Note to the relevant
> |  functions, so that the next time someone asks this question they'll
> |  find the answer right there?
> |  >>
> |  >> Thanks
> |  >>
> |  >> Simon
> |  >>
> |  >> |  -----Original Message-----
> |  >> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> |  >> | ?mer  Sinan Agacan
> |  >> |  Sent: 19 February 2016 17:27
> |  >> |  To: ghc-devs <ghc-devs at haskell.org>
> |  >> |  Subject: 'lub' and 'both' on strictness - what does it mean for
> |  >> | products to have different arity?
> |  >> |
> |  >> |  I was looking at implementations of LUB and AND on demand
> |  >> | signatures  and I found this interesting case:
> |  >> |
> |  >> |      lubStr (SProd s1) (SProd s2)
> |  >> |          | length s1 == length s2   = mkSProd (zipWith lubArgStr
> |  s1 s2)
> |  >> |          | otherwise                = HeadStr
> |  >> |
> |  >> |  The "otherwise" case is interesting, I'd expect that to be an
> |  error.
> |  >> |  I'm trying to come up with an example, let's say I have a case
> |  >> |  expression:
> |  >> |
> |  >> |      case x of
> |  >> |         P1 -> RHS1
> |  >> |         P2 -> RHS2
> |  >> |
> |  >> |  and y is used in RHS1 with S(SS) and in RHS2 with S(SSS). This
> |  >> | seems to  me like a type error leaked into the demand analysis.
> |  >> |
> |  >> |  Same thing applies to `bothDmd` too. Funnily, it has this extra
> |  >> | comment  on this same code:
> |  >> |
> |  >> |      bothStr (SProd s1) (SProd s2)
> |  >> |          | length s1 == length s2   = mkSProd (zipWith bothArgStr
> |  s1 s2)
> |  >> |          | otherwise                = HyperStr  -- Weird
> |  >> |
> |  >> |  Does "Weird" here means "type error and/or bug" ?
> |  >> |
> |  >> |  Should I try replacing these cases with panics and try to
> |  validate?
> |  >> |  _______________________________________________
> |  >> |  ghc-devs mailing list
> |  >> |  ghc-devs at haskell.org
> |  >> |
> |  >> |
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmai
> |  >> | l.ha
> |  >> |  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  >> |
> |  >> |
> |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cdd8ae326a8e1
> |  >> | 4ef8
> |  >> |
> |  9e8608d339520cb9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sRFRK
> |  >> | gj3y  zQdEZT4y7KLk18cP43Rv1J%2bx8oPZyr1QzA%3d

From simonpj at microsoft.com  Fri Mar  4 15:23:08 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 4 Mar 2016 15:23:08 +0000
Subject: Impredicative types in 8.0, again
In-Reply-To: <8760x2bbq3.fsf@feelingofgreen.ru>
References: <8760x2bbq3.fsf@feelingofgreen.ru>
Message-ID: <e3d17800c93648a689c3781d1ae65287@DB4PR30MB030.064d.mgd.msft.net>

ImpredicativeTypes is indeed problematic.  Perhaps you can add your example as another Trac ticket?   It's not really going to get fixed until someone pays sustained attention to it.

Alejandro (cc'd) is working on this.  We are working on a paper for ICFP... wait a couple of weeks!

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Kosyrev Serge
|  Sent: 04 March 2016 13:43
|  To: ghc-devs at haskell.org
|  Subject: Impredicative types in 8.0, again
|  
|  Good day!
|  
|  I realise that ImpredicativeTypes is a problematic extension, but I
|  have found something that looks like an outright bug -- no polymorphism
|  involved:
|  
|  ,----
|  | {-# LANGUAGE ImpredicativeTypes #-}
|  |
|  | module Foo where
|  |
|  | foo :: IO (Maybe Int)
|  | foo = do
|  |   pure $ case undefined :: Maybe String of
|  |             Nothing
|  |               -> Nothing
|  |             Just _
|  |               -> (undefined :: Maybe Int)
|  `----
|  
|  produces the following errors:
|  
|  ,----
|  | foo.hs:7:3: error:
|  |     ? Couldn't match type ?forall a. Maybe a? with ?Maybe Int?
|  |       Expected type: IO (Maybe Int)
|  |         Actual type: IO (forall a. Maybe a)
|  |     ? In a stmt of a 'do' block:
|  |         pure
|  |         $ case undefined :: Maybe String of {
|  |             Nothing -> Nothing
|  |             Just _ -> (undefined :: Maybe Int) }
|  |       In the expression:
|  |         do { pure
|  |              $ case undefined :: Maybe String of {
|  |                  Nothing -> Nothing
|  |                  Just _ -> (undefined :: Maybe Int) } }
|  |       In an equation for ?foo?:
|  |           foo
|  |             = do { pure
|  |                    $ case undefined :: Maybe String of {
|  |                        Nothing -> Nothing
|  |                        Just _ -> (undefined :: Maybe Int) } }
|  |
|  | foo.hs:11:19: error:
|  |     ? Couldn't match type ?a? with ?Int?
|  |       ?a? is a rigid type variable bound by
|  |         a type expected by the context:
|  |           forall a. Maybe a
|  |         at foo.hs:11:19
|  |       Expected type: forall a. Maybe a
|  |         Actual type: Maybe Int
|  |     ? In the expression: (undefined :: Maybe Int)
|  |       In a case alternative: Just _ -> (undefined :: Maybe Int)
|  |       In the second argument of ?($)?, namely
|  |         ?case undefined :: Maybe String of {
|  |            Nothing -> Nothing
|  |            Just _ -> (undefined :: Maybe Int) }?
|  `----
|  
|  --
|  ? ???????e? / respectfully,
|  ??????? ??????
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c3150fd5e547f4
|  294afb408d34432eadb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9dlTzi
|  vbVZydfO5zN6i8CEHGoThCN7wR6cQavKkj1ZU%3d

From rwbarton at gmail.com  Fri Mar  4 15:49:34 2016
From: rwbarton at gmail.com (Reid Barton)
Date: Fri, 4 Mar 2016 10:49:34 -0500
Subject: Impredicative types in 8.0, again
In-Reply-To: <8760x2bbq3.fsf@feelingofgreen.ru>
References: <8760x2bbq3.fsf@feelingofgreen.ru>
Message-ID: <CADmwj47Zh12KPAyaFN=QvjsnRQHC9HzTxZhhQ0ZC0Fgcbcar4w@mail.gmail.com>

This looks very similar to https://ghc.haskell.org/trac/ghc/ticket/11319,
but might be worth including as a separate example there. Note that it does
compile if you swap the order of the case alternatives.

Regards,
Reid Barton


On Fri, Mar 4, 2016 at 8:43 AM, Kosyrev Serge <_deepfire at feelingofgreen.ru>
wrote:

> Good day!
>
> I realise that ImpredicativeTypes is a problematic extension, but I have
> found something that looks like an outright bug -- no polymorphism
> involved:
>
> ,----
> | {-# LANGUAGE ImpredicativeTypes #-}
> |
> | module Foo where
> |
> | foo :: IO (Maybe Int)
> | foo = do
> |   pure $ case undefined :: Maybe String of
> |             Nothing
> |               -> Nothing
> |             Just _
> |               -> (undefined :: Maybe Int)
> `----
>
> produces the following errors:
>
> ,----
> | foo.hs:7:3: error:
> |     ? Couldn't match type ?forall a. Maybe a? with ?Maybe Int?
> |       Expected type: IO (Maybe Int)
> |         Actual type: IO (forall a. Maybe a)
> |     ? In a stmt of a 'do' block:
> |         pure
> |         $ case undefined :: Maybe String of {
> |             Nothing -> Nothing
> |             Just _ -> (undefined :: Maybe Int) }
> |       In the expression:
> |         do { pure
> |              $ case undefined :: Maybe String of {
> |                  Nothing -> Nothing
> |                  Just _ -> (undefined :: Maybe Int) } }
> |       In an equation for ?foo?:
> |           foo
> |             = do { pure
> |                    $ case undefined :: Maybe String of {
> |                        Nothing -> Nothing
> |                        Just _ -> (undefined :: Maybe Int) } }
> |
> | foo.hs:11:19: error:
> |     ? Couldn't match type ?a? with ?Int?
> |       ?a? is a rigid type variable bound by
> |         a type expected by the context:
> |           forall a. Maybe a
> |         at foo.hs:11:19
> |       Expected type: forall a. Maybe a
> |         Actual type: Maybe Int
> |     ? In the expression: (undefined :: Maybe Int)
> |       In a case alternative: Just _ -> (undefined :: Maybe Int)
> |       In the second argument of ?($)?, namely
> |         ?case undefined :: Maybe String of {
> |            Nothing -> Nothing
> |            Just _ -> (undefined :: Maybe Int) }?
> `----
>
> --
> ? ???????e? / respectfully,
> ??????? ??????
> _______________________________________________
> 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/20160304/1e7964b3/attachment-0001.html>

From cma at bitemyapp.com  Fri Mar  4 16:24:18 2016
From: cma at bitemyapp.com (Christopher Allen)
Date: Fri, 4 Mar 2016 10:24:18 -0600
Subject: Specialized type hints
In-Reply-To: <7c4121b67eae470485ef5477931c6714@DB4PR30MB030.064d.mgd.msft.net>
References: <CADnndOrpRRSALBTUZ6jcVZF3uVVwOHJhirRqrV+zd88GX51QzA@mail.gmail.com>
 <7c4121b67eae470485ef5477931c6714@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CADnndOozi-3eJotUDGevxBT_+jb8dO8zrE8=YNaEXSo9y9EWHQ@mail.gmail.com>

I was looking for an indication that a more general type error improvement
sweep would be welcome. I could pinpoint a particular type error if you
liked (such as the one that prompted this email), but there are general UX
improvements I would like to undertake.

On Fri, Mar 4, 2016 at 4:25 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Christopher
>
>
>
> Improving error message is an excellent goal, and one that I have spent
> more hours on than I care to tell you.
>
>
>
> If you have a particular one in mind, could you open a Trac ticket with a
> particular reproducible test case, the error message you get, and the error
> message you?d like to get.
>
>
> Thanks
>
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Christopher
> Allen
> *Sent:* 03 March 2016 07:55
> *To:* ghc-devs at haskell.org
> *Subject:* Specialized type hints
>
>
>
> I'd like to see how warm people would be to catching GHC's type error
> quality up a bit.
>
>
>
> I did a write-up on a confusion a reader of our book had:
>
>
>
> https://gist.github.com/bitemyapp/c27c721b92dab0248433
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgist.github.com%2fbitemyapp%2fc27c721b92dab0248433&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c64d227da349847f85fe308d343391dbb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EtjujRikMvoUN%2fBq6RtOrotsPdXdvZggnMU3Cu2BypE%3d>
>
>
>
>
> This is not new. A lot of people complain about this particular type error
> in particular when they say GHC has bad type errors. I don't think GHC's
> type errors are bad, but I do think they could be improved and this
> particular issue has an unfortunate source to sink distance.
>
>
>
> I would rather type error improvements not be buried behind a "silly
> beginners only" flag and that they just be part of improving the UX for
> everyone. With that proviso, how likely would specialized type error hints
> and some general error message fix ups be regarded?
>
>
>
> By specialized I mean, "detect that they tried to find an instance of Num
> for (-> something something) and suggest that they did the wrong thing,
> with possible fixes: X Y Z". Ideally before the "hey do you want
> FlexibleContexts?!" thing fires.
>
>
>
> I do not think I am capable of doing this, but being able to zoom in,
> clang style, to the expression where they are (probably accidentally) using
> a function like a Num or a Num like a function would be pretty valuable so
> they don't have to guess-n-check parenthesize their code.
>
>
>
>
>
> --
>
> Chris Allen
>



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

From simonpj at microsoft.com  Fri Mar  4 16:36:11 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 4 Mar 2016 16:36:11 +0000
Subject: Specialized type hints
In-Reply-To: <CADnndOozi-3eJotUDGevxBT_+jb8dO8zrE8=YNaEXSo9y9EWHQ@mail.gmail.com>
References: <CADnndOrpRRSALBTUZ6jcVZF3uVVwOHJhirRqrV+zd88GX51QzA@mail.gmail.com>
 <7c4121b67eae470485ef5477931c6714@DB4PR30MB030.064d.mgd.msft.net>
 <CADnndOozi-3eJotUDGevxBT_+jb8dO8zrE8=YNaEXSo9y9EWHQ@mail.gmail.com>
Message-ID: <aa2d7e6cb57d4a07addce4e717091e07@DB4PR30MB030.064d.mgd.msft.net>

indication that a more general type error improvement sweep would be welcome

Absolutely yes.  But it depends on someone saying ?I want to do that?; and of course on how hard or easy it turns out to be.

general UX improvements I would like to undertake.

Great!  Make Trac tickets proposing changes; debate them with others to form a consensus about what would be good; implement them? that would all be amazing.

Simon

From: Christopher Allen [mailto:cma at bitemyapp.com]
Sent: 04 March 2016 16:24
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-devs at haskell.org
Subject: Re: Specialized type hints

I was looking for an indication that a more general type error improvement sweep would be welcome. I could pinpoint a particular type error if you liked (such as the one that prompted this email), but there are general UX improvements I would like to undertake.

On Fri, Mar 4, 2016 at 4:25 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Christopher

Improving error message is an excellent goal, and one that I have spent more hours on than I care to tell you.

If you have a particular one in mind, could you open a Trac ticket with a particular reproducible test case, the error message you get, and the error message you?d like to get.

Thanks

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>] On Behalf Of Christopher Allen
Sent: 03 March 2016 07:55
To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Specialized type hints

I'd like to see how warm people would be to catching GHC's type error quality up a bit.

I did a write-up on a confusion a reader of our book had:

https://gist.github.com/bitemyapp/c27c721b92dab0248433<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgist.github.com%2fbitemyapp%2fc27c721b92dab0248433&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c64d227da349847f85fe308d343391dbb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EtjujRikMvoUN%2fBq6RtOrotsPdXdvZggnMU3Cu2BypE%3d>

This is not new. A lot of people complain about this particular type error in particular when they say GHC has bad type errors. I don't think GHC's type errors are bad, but I do think they could be improved and this particular issue has an unfortunate source to sink distance.

I would rather type error improvements not be buried behind a "silly beginners only" flag and that they just be part of improving the UX for everyone. With that proviso, how likely would specialized type error hints and some general error message fix ups be regarded?

By specialized I mean, "detect that they tried to find an instance of Num for (-> something something) and suggest that they did the wrong thing, with possible fixes: X Y Z". Ideally before the "hey do you want FlexibleContexts?!" thing fires.

I do not think I am capable of doing this, but being able to zoom in, clang style, to the expression where they are (probably accidentally) using a function like a Num or a Num like a function would be pretty valuable so they don't have to guess-n-check parenthesize their code.


--
Chris Allen



--
Chris Allen
Currently working on http://haskellbook.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhaskellbook.com&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c757f72d364664cd81b8508d344497063%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EaRmV%2bS3%2f1vgr6klNmr0gM89ofO7CP2%2b7h12bJ%2bJwi8%3d>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160304/a37fe80c/attachment-0001.html>

From simonpj at microsoft.com  Fri Mar  4 17:18:18 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 4 Mar 2016 17:18:18 +0000
Subject: 'lub' and 'both' on strictness - what does it mean for products
 to have different arity?
In-Reply-To: <CAMQQO3==_XvNXLhLt4=xz0TxfR5aOq4OkN2Pe54epiJ=u3EtOw@mail.gmail.com>
References: <CAMQQO3=vTcsJLyOwfYshFmALx3V7GRqVCz5Ag3AfXP=YTt=9hQ@mail.gmail.com>
 <6a452a23dc2a47e0bf0244ad510845a6@DB4PR30MB030.064d.mgd.msft.net>
 <CAMQQO3=JxvECHk7Q+YxRM-zntNdmV21Q5+8iRV1xM8HYiPiwLw@mail.gmail.com>
 <CAMQQO3=48qYRiuUjW-BKT2Oxp++2=eKQE-pb_S7ve8BCt4ousw@mail.gmail.com>
 <0a47f37356a741cdab879d2f57f52aaf@DB4PR30MB030.064d.mgd.msft.net>
 <CAMQQO3==_XvNXLhLt4=xz0TxfR5aOq4OkN2Pe54epiJ=u3EtOw@mail.gmail.com>
Message-ID: <64cee3271b1f4cdab1288f661be6dd52@DB4PR30MB030.064d.mgd.msft.net>

Well suppose

data T a where
  T1 :: T (Int,Int,Int)
  T2 :: T (Int,Int)

f :: T a -> a -> Int
f a b = case a of
         T1 -> case b of { (x,y,z) -> x+y+z }
         _  -> 0

g :: T a -> a -> Int
f a b = case a of
         T2 -> case b of { (x,y) -> x+y }
         _  -> 0


h :: T a -> a -> Int
h x y = f x y + g x y

Then I think you'll get a S(SSS) demand from the f call, and S(SS) from the g call. And then you'll 'both' them.

Please don?t document on Phab!  In a Note in the code, or a wiki page or both.  Maybe that's what you intend.

Simon

|  -----Original Message-----
|  From: ?mer Sinan A?acan [mailto:omeragacan at gmail.com]
|  Sent: 04 March 2016 14:26
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: ghc-devs <ghc-devs at haskell.org>
|  Subject: Re: 'lub' and 'both' on strictness - what does it mean for
|  products to have different arity?
|  
|  Simon, your GADT example clearly shows how lub sometimes needs to
|  handle products with different arities, but the case with bothDmd is
|  still confuses me. I think we need have a code like this:
|  
|      f x + g x
|  
|  Where f puts a S(SS) demand on x and g puts a S(SSS). This looks like a
|  bug/type error to me. Do you have any example for bothDmd too?
|  
|  (I started D1968 for documenting these)
|  
|  2016-03-02 3:47 GMT-05:00 Simon Peyton Jones <simonpj at microsoft.com>:
|  >
|  > |      -- lubUse (UProd {}) Used             = Used
|  > |      lubUse (UProd ux) Used             = UProd (map (`lubArgUse`
|  > |  useTop) ux)
|  > |      lubUse Used       (UProd ux)       = UProd (map (`lubArgUse`
|  > |  useTop) ux)
|  > |
|  > |  And then somewhere around that code there's this:
|  > |
|  > |      Note [Used should win]
|  > |      ~~~~~~~~~~~~~~~~~~~~~~
|  > |      Both in lubUse and bothUse we want (Used `both` UProd us) to
|  be
|  > | Used.
|  > |      Why?  Because Used carries the implication the whole thing is
|  used,
|  > |      box and all, so we don't want to w/w it.  If we use it both
|  > | boxed  and
|  > |      unboxed, then we are definitely using the box, and so we are
|  quite
|  > |      likely to pay a reboxing cost.  So we make Used win here.
|  > |
|  > |      ...
|  > |
|  > |  It seems like at some point the note was valid, but now the code
|  > | seems  to be doing the opposite. Any ideas which one needs an
|  update?
|  >
|  > I have no idea.  It seems that the entire definition of lubUse,
|  including the Note and the commented-out line, appeared in a single big
|  patch 99d4e5b4.   So no clues there.
|  >
|  > However the Note has some nofib numbers.
|  >
|  > So yes, it's puzzling.   The argument in the Note seems plausible.
|  Would you like to try reverting to "Used should win" and see what
|  happens to performance?  Probably something will get worse and you'll
|  have do some digging with ticky-ticky.
|  >
|  >
|  > |  I'm also a bit confused about why both and lub are not
|  commutative,
|  > | or  if they're commutative, why do they have redundant cases.
|  >
|  > Yes: lub and both should be commutative; yell if not.  (In contrast
|  > see Note [Asymmetry of 'both' for DmdType and DmdResult]; but that's
|  > well documented.)
|  >
|  > | For example,
|  > |  lubUse has
|  > |  this:
|  > |
|  > |      lubUse UHead       u               = u
|  > |      lubUse (UCall c u) UHead           = UCall c u
|  > |
|  > |  instead of something like:
|  > |
|  > |      lubUse UHead u = u
|  > |      lubUse u UHead = u
|  >
|  > I think this is just stylistic. I was dealing with all the cases for
|  UHead in the first arg, then all the cases for UCall, and so on. That
|  way I know I've got coverage.
|  >
|  > (And perhaps it's more efficient: we pattern match at most once on
|  each argument.
|  >
|  > Simon
|  >
|  > |
|  > |  I didn't check all the cases to see if it's really commutative or
|  > | not,  but can I assume that they need to be commutative and
|  simplify
|  > | the  code? Otherwise let's add a note about why they're not
|  commutative?
|  > |
|  > |  Thanks..
|  > |
|  > |  2016-03-02 1:07 GMT-05:00 ?mer Sinan A?acan
|  <omeragacan at gmail.com>:
|  > |  >> Could I ask that you add this example as a Note to the relevant
|  > | >> functions, so that the next time someone asks this question
|  > | they'll  >> find the answer right there?
|  > |  >
|  > |  > Yep, I'll do that soon.
|  > |  >
|  > |  > 2016-03-01 12:01 GMT-05:00 Simon Peyton Jones
|  > |  <simonpj at microsoft.com>:
|  > |  >> Omer
|  > |  >>
|  > |  >> Joachim is right.  The strictness analyser just looks inside
|  > | casts,  >> so these unexpectedly ill-typed cases could show up.
|  For
|  > | example  >>  >> f :: T a -> a -> Int  >> f x y = case x of
|  > |  >>           P1 -> case y of (a,b,c) -> a+b+c
|  > |  >>           P2 -> case y of (p,q) -> p+q
|  > |  >>
|  > |  >> data T a where
|  > |  >>   P1 :: T (Int,Int,Int)
|  > |  >>   P2 :: T (Int,Int)
|  > |  >>
|  > |  >> In the P1 branch we have that y::(Int,Int,Int), so we'll get a
|  > | demand S(SSS).  And similarly in the P2 branch.  Now we combine
|  them.
|  > |  And there you have it.
|  > |  >>
|  > |  >>
|  > |  >> Could I ask that you add this example as a Note to the relevant
|  > | functions, so that the next time someone asks this question they'll
|  > | find the answer right there?
|  > |  >>
|  > |  >> Thanks
|  > |  >>
|  > |  >> Simon
|  > |  >>
|  > |  >> |  -----Original Message-----
|  > |  >> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On
|  > | Behalf Of  >> | ?mer  Sinan Agacan  >> |  Sent: 19 February 2016
|  > | 17:27  >> |  To: ghc-devs <ghc-devs at haskell.org>  >> |  Subject:
|  > | 'lub' and 'both' on strictness - what does it mean for  >> |
|  > | products to have different arity?
|  > |  >> |
|  > |  >> |  I was looking at implementations of LUB and AND on demand
|  >>
|  > | | signatures  and I found this interesting case:
|  > |  >> |
|  > |  >> |      lubStr (SProd s1) (SProd s2)
|  > |  >> |          | length s1 == length s2   = mkSProd (zipWith
|  lubArgStr
|  > |  s1 s2)
|  > |  >> |          | otherwise                = HeadStr
|  > |  >> |
|  > |  >> |  The "otherwise" case is interesting, I'd expect that to be
|  an
|  > | error.
|  > |  >> |  I'm trying to come up with an example, let's say I have a
|  > | case  >> |  expression:
|  > |  >> |
|  > |  >> |      case x of
|  > |  >> |         P1 -> RHS1
|  > |  >> |         P2 -> RHS2
|  > |  >> |
|  > |  >> |  and y is used in RHS1 with S(SS) and in RHS2 with S(SSS).
|  > | This  >> | seems to  me like a type error leaked into the demand
|  analysis.
|  > |  >> |
|  > |  >> |  Same thing applies to `bothDmd` too. Funnily, it has this
|  > | extra  >> | comment  on this same code:
|  > |  >> |
|  > |  >> |      bothStr (SProd s1) (SProd s2)
|  > |  >> |          | length s1 == length s2   = mkSProd (zipWith
|  bothArgStr
|  > |  s1 s2)
|  > |  >> |          | otherwise                = HyperStr  -- Weird
|  > |  >> |
|  > |  >> |  Does "Weird" here means "type error and/or bug" ?
|  > |  >> |
|  > |  >> |  Should I try replacing these cases with panics and try to
|  > | validate?
|  > |  >> |  _______________________________________________
|  > |  >> |  ghc-devs mailing list
|  > |  >> |  ghc-devs at haskell.org
|  > |  >> |
|  > |  >> |
|  > |
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmai
|  > |  >> | l.ha
|  > |  >> |  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  > |  >> |
|  > |  >> |
|  > |
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cdd8ae326a8e1
|  > |  >> | 4ef8
|  > |  >> |
|  > |
|  9e8608d339520cb9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sRFRK
|  > |  >> | gj3y  zQdEZT4y7KLk18cP43Rv1J%2bx8oPZyr1QzA%3d

From george.colpitts at gmail.com  Sun Mar  6 17:31:23 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Sun, 06 Mar 2016 17:31:23 +0000
Subject: Fwd: [GHC] #11683: compiled files don't load in ghci
In-Reply-To: <045.58b9361ce402fcb7b2b8e776cc34f3ef@haskell.org>
References: <045.58b9361ce402fcb7b2b8e776cc34f3ef@haskell.org>
Message-ID: <CAB-d4A6S5A2CgQBPvLUgkmA+pwLuaXJF=-Mbq4Y3GPg+SHqfVA@mail.gmail.com>

---------- Forwarded message ---------
From: GHC <ghc-devs at haskell.org>
Date: Sun, Mar 6, 2016 at 1:23 PM
Subject: [GHC] #11683: compiled files don't load in ghci
To:
Cc: <ghc-tickets at haskell.org>


#11683: compiled files don't load in ghci
-------------------------------------+-------------------------------------
           Reporter:  George         |             Owner:
               Type:  bug            |            Status:  new
           Priority:  high           |         Milestone:
          Component:  Compiler       |           Version:  8.0.1-rc2
           Keywords:                 |  Operating System:  MacOS X
       Architecture:                 |   Type of failure:  Incorrect result
  Unknown/Multiple                   |  at runtime
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 compiled files don't load in ghci

 {{{
 ghc -DYNAMIC bug.hs
 [1 of 1] Compiling Main             ( bug.hs, bug.o )
 Linking bug ...
 bash-3.2$ ghci -ignore-dot-ghci

 GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/  :? for help
 Prelude> Prelude> :load bug
 [1 of 1] Compiling Main             ( bug.hs, interpreted )
 Ok, modules loaded: Main.
 *Main> :show modules
 Main             ( bug.hs, interpreted )
 *Main>
 }}}

 According to the doc,
 file:///usr/local/share/doc/ghc-8.0.0.20160204/html/users_guide/ghci.html
 #loading-compiled-code,  this should work:

 {{{
 Note the -dynamic flag to GHC: GHCi uses dynamically-linked object code
 (if you are on a platform that supports it), and so in order to use
 compiled code with GHCi it must be compiled for dynamic linking.
 }}}

 Similarly https://ghc.haskell.org/trac/ghc/ticket/8736#comment:4 says the
 same thing:

 {{{
 if you say :load Foo in GHCi

 Foo was compiled with -dynamic: loads Foo.o
 }}}

 Interestingly -fobject-code does work:

 {{{
  ghci -ignore-dot-ghci -fobject-code
 GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/  :? for help
 Prelude> :load bug
 [1 of 1] Compiling Main             ( bug.hs, bug.o )
 Ok, modules loaded: Main.
 Prelude Main>
 }}}

 Unfortunately when I do
 {{{
 ghci -v -ignore-dot-ghci -fobject-code
 }}}

 I don't see why it works. It doesn't seem to use just ghc to compile , it
 also uses gcc, see attached file.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11683>
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/20160306/9888a18a/attachment.html>

From conal at conal.net  Sun Mar  6 21:46:09 2016
From: conal at conal.net (Conal Elliott)
Date: Sun, 6 Mar 2016 13:46:09 -0800
Subject: "token is not a valid binary operator in a preprocessor
 subexpression" in GHC HEAD build
Message-ID: <CAD6SzRK2oT4F77QV3ZHPTdhhDMWTD8Eh6srVSYNtPDdSR9gewg@mail.gmail.com>

I'm trying to build GHC HEAD on Mac OS after a fresh git-pull, and I'm
getting the following:

    libraries/binary/src/Data/Binary/Put.hs:38:27:
         error: token is not a valid binary operator in a preprocessor
subexpression
    #if MIN_VERSION_bytestring(0,10,4)

Any insights/suggestions?

I don't need the very latest HEAD version; just a version with ticket 11651
fixed (https://ghc.haskell.org/trac/ghc/ticket/11651#comment:3), and even
for that item, I don't mind patching the source myself.

Thanks!  - Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160306/b56c0cb7/attachment.html>

From eir at cis.upenn.edu  Mon Mar  7 04:59:57 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 6 Mar 2016 23:59:57 -0500
Subject: Specialized type hints
In-Reply-To: <aa2d7e6cb57d4a07addce4e717091e07@DB4PR30MB030.064d.mgd.msft.net>
References: <CADnndOrpRRSALBTUZ6jcVZF3uVVwOHJhirRqrV+zd88GX51QzA@mail.gmail.com>
 <7c4121b67eae470485ef5477931c6714@DB4PR30MB030.064d.mgd.msft.net>
 <CADnndOozi-3eJotUDGevxBT_+jb8dO8zrE8=YNaEXSo9y9EWHQ@mail.gmail.com>
 <aa2d7e6cb57d4a07addce4e717091e07@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <0074D703-D360-4646-B210-771555CB25BF@cis.upenn.edu>

I, for one, would greatly welcome someone rewriting much of the TcErrors module. (Almost all type errors are generated in that one module, rather conveniently.) Even better would be to have some written-out theory behind the design of the error-reporting mechanism. What we have now is incredibly ad-hoc and, as frequently reported, rather suboptimal.

Richard

On Mar 4, 2016, at 11:36 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> indication that a more general type error improvement sweep would be welcome
>  
> Absolutely yes.  But it depends on someone saying ?I want to do that?; and of course on how hard or easy it turns out to be.
>  
> general UX improvements I would like to undertake.
>  
> Great!  Make Trac tickets proposing changes; debate them with others to form a consensus about what would be good; implement them? that would all be amazing.
>  
> Simon
>  
> From: Christopher Allen [mailto:cma at bitemyapp.com] 
> Sent: 04 March 2016 16:24
> To: Simon Peyton Jones <simonpj at microsoft.com>
> Cc: ghc-devs at haskell.org
> Subject: Re: Specialized type hints
>  
> I was looking for an indication that a more general type error improvement sweep would be welcome. I could pinpoint a particular type error if you liked (such as the one that prompted this email), but there are general UX improvements I would like to undertake.
> 
>  
> 
> On Fri, Mar 4, 2016 at 4:25 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> Christopher
>  
> Improving error message is an excellent goal, and one that I have spent more hours on than I care to tell you.
>  
> If you have a particular one in mind, could you open a Trac ticket with a particular reproducible test case, the error message you get, and the error message you?d like to get.
> 
> Thanks
>  
> Simon
>  
> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Christopher Allen
> Sent: 03 March 2016 07:55
> To: ghc-devs at haskell.org
> Subject: Specialized type hints
>  
> I'd like to see how warm people would be to catching GHC's type error quality up a bit.
> 
>  
> 
> I did a write-up on a confusion a reader of our book had:
> 
>  
> 
> https://gist.github.com/bitemyapp/c27c721b92dab0248433 
> 
>  
> 
> This is not new. A lot of people complain about this particular type error in particular when they say GHC has bad type errors. I don't think GHC's type errors are bad, but I do think they could be improved and this particular issue has an unfortunate source to sink distance.
> 
>  
> 
> I would rather type error improvements not be buried behind a "silly beginners only" flag and that they just be part of improving the UX for everyone. With that proviso, how likely would specialized type error hints and some general error message fix ups be regarded?
> 
>  
> 
> By specialized I mean, "detect that they tried to find an instance of Num for (-> something something) and suggest that they did the wrong thing, with possible fixes: X Y Z". Ideally before the "hey do you want FlexibleContexts?!" thing fires.
> 
>  
> 
> I do not think I am capable of doing this, but being able to zoom in, clang style, to the expression where they are (probably accidentally) using a function like a Num or a Num like a function would be pretty valuable so they don't have to guess-n-check parenthesize their code.
> 
>  
> 
>  
> 
> --
> 
> Chris Allen
> 
> 
> 
>  
> --
> 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/20160306/2406a06d/attachment-0001.html>

From simonpj at microsoft.com  Mon Mar  7 09:34:29 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 7 Mar 2016 09:34:29 +0000
Subject: Specialized type hints
In-Reply-To: <0074D703-D360-4646-B210-771555CB25BF@cis.upenn.edu>
References: <CADnndOrpRRSALBTUZ6jcVZF3uVVwOHJhirRqrV+zd88GX51QzA@mail.gmail.com>
 <7c4121b67eae470485ef5477931c6714@DB4PR30MB030.064d.mgd.msft.net>
 <CADnndOozi-3eJotUDGevxBT_+jb8dO8zrE8=YNaEXSo9y9EWHQ@mail.gmail.com>
 <aa2d7e6cb57d4a07addce4e717091e07@DB4PR30MB030.064d.mgd.msft.net>
 <0074D703-D360-4646-B210-771555CB25BF@cis.upenn.edu>
Message-ID: <f1cc45e97e0c494782d516573d094902@DB4PR30MB030.064d.mgd.msft.net>

But (in my defence) it?s pretty cool that error message generation can be left (a) to the end of type checking when all information is available and (b) localised on one module.  I can?t tell you how much better it is than it was before!

There is _plenty_ of scope for improvement though!

Simon

From: Richard Eisenberg [mailto:eir at cis.upenn.edu]
Sent: 07 March 2016 05:00
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Christopher Allen <cma at bitemyapp.com>; ghc-devs at haskell.org
Subject: Re: Specialized type hints

I, for one, would greatly welcome someone rewriting much of the TcErrors module. (Almost all type errors are generated in that one module, rather conveniently.) Even better would be to have some written-out theory behind the design of the error-reporting mechanism. What we have now is incredibly ad-hoc and, as frequently reported, rather suboptimal.

Richard

On Mar 4, 2016, at 11:36 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:


indication that a more general type error improvement sweep would be welcome

Absolutely yes.  But it depends on someone saying ?I want to do that?; and of course on how hard or easy it turns out to be.

general UX improvements I would like to undertake.

Great!  Make Trac tickets proposing changes; debate them with others to form a consensus about what would be good; implement them? that would all be amazing.

Simon

From: Christopher Allen [mailto:cma at bitemyapp.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fbitemyapp.com&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c6b9bd6971ab84198591108d346455a33%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Z16BZJdPbEVIqcEIcgF7jebu4vpu5xsuFOsjwNos2wc%3d>]
Sent: 04 March 2016 16:24
To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
Cc: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: Specialized type hints

I was looking for an indication that a more general type error improvement sweep would be welcome. I could pinpoint a particular type error if you liked (such as the one that prompted this email), but there are general UX improvements I would like to undertake.

On Fri, Mar 4, 2016 at 4:25 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Christopher

Improving error message is an excellent goal, and one that I have spent more hours on than I care to tell you.

If you have a particular one in mind, could you open a Trac ticket with a particular reproducible test case, the error message you get, and the error message you?d like to get.

Thanks

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>] On Behalf Of Christopher Allen
Sent: 03 March 2016 07:55
To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Specialized type hints

I'd like to see how warm people would be to catching GHC's type error quality up a bit.

I did a write-up on a confusion a reader of our book had:

https://gist.github.com/bitemyapp/c27c721b92dab0248433<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgist.github.com%2fbitemyapp%2fc27c721b92dab0248433&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c64d227da349847f85fe308d343391dbb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EtjujRikMvoUN%2fBq6RtOrotsPdXdvZggnMU3Cu2BypE%3d>

This is not new. A lot of people complain about this particular type error in particular when they say GHC has bad type errors. I don't think GHC's type errors are bad, but I do think they could be improved and this particular issue has an unfortunate source to sink distance.

I would rather type error improvements not be buried behind a "silly beginners only" flag and that they just be part of improving the UX for everyone. With that proviso, how likely would specialized type error hints and some general error message fix ups be regarded?

By specialized I mean, "detect that they tried to find an instance of Num for (-> something something) and suggest that they did the wrong thing, with possible fixes: X Y Z". Ideally before the "hey do you want FlexibleContexts?!" thing fires.

I do not think I am capable of doing this, but being able to zoom in, clang style, to the expression where they are (probably accidentally) using a function like a Num or a Num like a function would be pretty valuable so they don't have to guess-n-check parenthesize their code.


--
Chris Allen



--
Chris Allen
Currently working on http://haskellbook.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhaskellbook.com&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c757f72d364664cd81b8508d344497063%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EaRmV%2bS3%2f1vgr6klNmr0gM89ofO7CP2%2b7h12bJ%2bJwi8%3d>
_______________________________________________
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/20160307/2f669772/attachment-0001.html>

From facundo.dominguez at tweag.io  Mon Mar  7 20:54:49 2016
From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=)
Date: Mon, 7 Mar 2016 17:54:49 -0300
Subject: Local bindings in the static form
In-Reply-To: <5c2393791c9f4bbbb0aee62b16f30005@DB4PR30MB030.064d.mgd.msft.net>
References: <CA+Q==SDSA4gncXAAd9dGWvWT28Tre44DZshuMigF-xLX_MXhaQ@mail.gmail.com>
 <5c2393791c9f4bbbb0aee62b16f30005@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CA+Q==SDSHygPXUxh9kyO-apDtm8fsU9ReyWK5S6w4iX6vNO4eg@mail.gmail.com>

Hello Simon,

We considered tct_closed once. However, it only seems to indicate
whether the type of a binding is closed, instead of its right hand
side.

For instance,

\x -> let g = x :: Int in g

In this example, g would have a closed type Int, thus tct_closed ==
TopLevel. However, the right hand side of g has a free variable x
which is not bound at the top level, and therefore it couldn't be
floated out.

Corrections are welcome if I'm fooling myself in some aspect here.

Thanks,
Facundo


On Fri, Mar 4, 2016 at 7:47 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> Facundo
>
> Yes, that makes perfect sense.  Moreover, it is pretty much exactly what the tct_closed flag on `ATcId` does.
>
> The trick will be to guarantee that all those Ids do in fact end up being floated out.
>
> We could have a Skype chat about this, preferably after the March 16 ICFP deadline
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> |  Facundo Dom?nguez
> |  Sent: 03 March 2016 19:41
> |  To: ghc-devs at haskell.org
> |  Subject: Local bindings in the static form
> |
> |  Hello,
> |    At Tweag I/O we are considering relaxing a bit the constraints on the
> |  static form.
> |
> |  static <exp>
> |
> |    demands <exp> to be closed. That is, the free variables of <exp> must
> |  be bound at the top level.
> |
> |  However, it would be fine to allow local bindings too. For instance:
> |
> |  test :: StaticPtr ([[Int]] -> [[Int]])
> |  test x = static (filter hasZero)
> |    where
> |      hasZero = any isZero
> |      isZero  = (0 ==)
> |
> |  Where hasZero is local but its body can be considered kind of closed
> |  (all free variables refer to top-level bindings or other *closed* local
> |  bindings.).
> |
> |  We would need for this implementation a way to test closedness in this
> |  sense. Could there be any similar test implemented already in GHC?
> |
> |  Thanks,
> |  Facundo
> |
> |  [1] https://ghc.haskell.org/trac/ghc/ticket/11656
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
> |  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cead97b273efa41c1
> |  a49608d3439bd142%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Z1TbBcSgd
> |  YLZ%2bXrMJVMvqJIfwc4R2kLeRaPPwuQ5%2fLQ%3d

From conal at conal.net  Tue Mar  8 01:48:18 2016
From: conal at conal.net (Conal Elliott)
Date: Mon, 7 Mar 2016 17:48:18 -0800
Subject: "token is not a valid binary operator in a preprocessor
 subexpression" in GHC HEAD build
In-Reply-To: <CAD6SzRK2oT4F77QV3ZHPTdhhDMWTD8Eh6srVSYNtPDdSR9gewg@mail.gmail.com>
References: <CAD6SzRK2oT4F77QV3ZHPTdhhDMWTD8Eh6srVSYNtPDdSR9gewg@mail.gmail.com>
Message-ID: <CAD6SzRLRCFmEAsCxEUoT4oqBOJKYD6x767YHEFyTjm2WmBE9Xg@mail.gmail.com>

I installed a newer Xcode, and now GHC HEAD is building fine for me.  -
Conal

On Sun, Mar 6, 2016 at 1:46 PM, Conal Elliott <conal at conal.net> wrote:

> I'm trying to build GHC HEAD on Mac OS after a fresh git-pull, and I'm
> getting the following:
>
>     libraries/binary/src/Data/Binary/Put.hs:38:27:
>          error: token is not a valid binary operator in a preprocessor
> subexpression
>     #if MIN_VERSION_bytestring(0,10,4)
>
> Any insights/suggestions?
>
> I don't need the very latest HEAD version; just a version with ticket
> 11651 fixed (https://ghc.haskell.org/trac/ghc/ticket/11651#comment:3),
> and even for that item, I don't mind patching the source myself.
>
> Thanks!  - Conal
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160307/f24725f8/attachment.html>

From ben at well-typed.com  Tue Mar  8 13:38:31 2016
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 08 Mar 2016 14:38:31 +0100
Subject: Change in GHC release timing policy
Message-ID: <874mchxf6w.fsf@smart-cactus.org>

tl;dr. We'll be introducing a week-long gap between the tagging of the
       source release and the release announcement to allow providers of
       binary distributions to get their builds together.


Hello everyone!

While Austin and I try to produce binary distributions for as many of
the major platforms as we can, we are of course unable to support
everything. Thankfully, we are lucky to have a number of reliable
contributors who consistently provide builds for those platform that we
can't handle ourselves.

These include,

    Karel Gardas, who provides Solaris, OpenBSD, and Linux builds for a
                  variety of platforms
  
  
    P?li G?bor J?nos, who provides FreeBSD builds
  
    Jens Petersen, who ensures that GHC is well-represented on Redhat
                   distributions
  
    Gershom, Jason Dagit, who handle build of the Haskell Platform on
                          many platforms
  
    Randy Polen, who handles building of the Haskell Platform on Windows

    Herbert Valerio Riedel, who handles AIX builds

They all deserve our thanks.

However, our release process has until now not treated their efforts on
an equal footing with the binary distributions produced by GHC HQ. In an
attempt to fix this we're going to try changing the timing of GHC
releases,

  * The source release will be tagged and tarballs pushed to a staging
    area

  * We will soon thereafter notify the binary distribution builders and
    ghc-devs@

  * Everyone will go to work on their binary distributions

  * One week after the source release is tagged the release artifacts
    will be pushed to downloads.haskell.org and the release publicly
    announced.

We hope that this will remove some of the confusion from the current
process while ensuring that all platforms have the potential for support
on the day of the release. We'll be trying this for 8.0.1-rc3 and the final
release. If all goes well we'll continue this policy in future releases.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160308/a8531c6d/attachment.sig>

From e.c.austin at gmail.com  Wed Mar  9 00:17:40 2016
From: e.c.austin at gmail.com (Evan Austin)
Date: Tue, 8 Mar 2016 19:17:40 -0500
Subject: Constrained Type Families?
Message-ID: <6C5BEA85-CC87-4576-9CE7-80E356939D3C@gmail.com>

GHC Devs,


The wiki page for Phase I of Dependent Haskell describes an approach to constrained type families:
https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequationscanbeconstrained <https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequationscanbeconstrained>

Did that land in GHC 8.0 and, if so, is the updated syntax documented somewhere?

V/r,

-Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160308/90fd8161/attachment.html>

From eir at cis.upenn.edu  Wed Mar  9 01:21:44 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 8 Mar 2016 20:21:44 -0500
Subject: Constrained Type Families?
In-Reply-To: <6C5BEA85-CC87-4576-9CE7-80E356939D3C@gmail.com>
References: <6C5BEA85-CC87-4576-9CE7-80E356939D3C@gmail.com>
Message-ID: <12F756C8-D973-43BA-9E27-456067A0E7F0@cis.upenn.edu>


On Mar 8, 2016, at 7:17 PM, Evan Austin <e.c.austin at gmail.com> wrote:
> The wiki page for Phase I of Dependent Haskell describes an approach to constrained type families:
> https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequationscanbeconstrained
> 
> Did that land in GHC 8.0 and, if so, is the updated syntax documented somewhere?

No, it didn't make it. The motivating test case seemed contrived and so we punted on this one.

Do you have a use case that really needs this feature? That would help to motivate it for 8.2 or beyond.

Thanks!
Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160308/8e2ae716/attachment.html>

From ekmett at gmail.com  Wed Mar  9 01:24:15 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 8 Mar 2016 20:24:15 -0500
Subject: Constrained Type Families?
In-Reply-To: <12F756C8-D973-43BA-9E27-456067A0E7F0@cis.upenn.edu>
References: <6C5BEA85-CC87-4576-9CE7-80E356939D3C@gmail.com>
 <12F756C8-D973-43BA-9E27-456067A0E7F0@cis.upenn.edu>
Message-ID: <CAJumaK-ompHNrNb6ke=0zxbKtpWps2Y_Okxf-JLLXXpLMBdY8w@mail.gmail.com>

If and when that feature lands would it be possible to use it to bypass a
current limitation in class associated types?

Notably if a class associated type has a more general kind, we currently
can't give a default definition for it that has a tighter kind.

e.g. I have some classes which are technically polykinded but where 90% of
the instances instantiate that kind as *. The status quo prevents me from
putting in a type default that would only be valid when the kind argument
is *.

-Edward

On Tue, Mar 8, 2016 at 8:21 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:

>
> On Mar 8, 2016, at 7:17 PM, Evan Austin <e.c.austin at gmail.com> wrote:
>
> The wiki page for Phase I of Dependent Haskell describes an approach to
> constrained type families:
>
> https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequationscanbeconstrained
>
> Did that land in GHC 8.0 and, if so, is the updated syntax documented
> somewhere?
>
>
> No, it didn't make it. The motivating test case seemed contrived and so we
> punted on this one.
>
> Do you have a use case that really needs this feature? That would help to
> motivate it for 8.2 or beyond.
>
> Thanks!
> Richard
>
>
> _______________________________________________
> 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/20160308/83fd6090/attachment.html>

From ekmett at gmail.com  Wed Mar  9 01:28:00 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 8 Mar 2016 20:28:00 -0500
Subject: Constrained Type Families?
In-Reply-To: <CAJumaK-ompHNrNb6ke=0zxbKtpWps2Y_Okxf-JLLXXpLMBdY8w@mail.gmail.com>
References: <6C5BEA85-CC87-4576-9CE7-80E356939D3C@gmail.com>
 <12F756C8-D973-43BA-9E27-456067A0E7F0@cis.upenn.edu>
 <CAJumaK-ompHNrNb6ke=0zxbKtpWps2Y_Okxf-JLLXXpLMBdY8w@mail.gmail.com>
Message-ID: <CAJumaK-_X2v7hgWy8CbeRjvESMqZcAkHM8N0oSbUfk0_9MwGXw@mail.gmail.com>

An example would be something like:

class Foo (p :: k -> Type) where
  type Bar p :: k -> k
  type (k ~ Type) => Bar p = p

-Edward

On Tue, Mar 8, 2016 at 8:24 PM, Edward Kmett <ekmett at gmail.com> wrote:

> If and when that feature lands would it be possible to use it to bypass a
> current limitation in class associated types?
>
> Notably if a class associated type has a more general kind, we currently
> can't give a default definition for it that has a tighter kind.
>
> e.g. I have some classes which are technically polykinded but where 90% of
> the instances instantiate that kind as *. The status quo prevents me from
> putting in a type default that would only be valid when the kind argument
> is *.
>
> -Edward
>
> On Tue, Mar 8, 2016 at 8:21 PM, Richard Eisenberg <eir at cis.upenn.edu>
> wrote:
>
>>
>> On Mar 8, 2016, at 7:17 PM, Evan Austin <e.c.austin at gmail.com> wrote:
>>
>> The wiki page for Phase I of Dependent Haskell describes an approach to
>> constrained type families:
>>
>> https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequationscanbeconstrained
>>
>> Did that land in GHC 8.0 and, if so, is the updated syntax documented
>> somewhere?
>>
>>
>> No, it didn't make it. The motivating test case seemed contrived and so
>> we punted on this one.
>>
>> Do you have a use case that really needs this feature? That would help to
>> motivate it for 8.2 or beyond.
>>
>> Thanks!
>> Richard
>>
>>
>> _______________________________________________
>> 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/20160308/4319fa22/attachment.html>

From eir at cis.upenn.edu  Wed Mar  9 01:31:31 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 8 Mar 2016 20:31:31 -0500
Subject: Constrained Type Families?
In-Reply-To: <CAJumaK-ompHNrNb6ke=0zxbKtpWps2Y_Okxf-JLLXXpLMBdY8w@mail.gmail.com>
References: <6C5BEA85-CC87-4576-9CE7-80E356939D3C@gmail.com>
 <12F756C8-D973-43BA-9E27-456067A0E7F0@cis.upenn.edu>
 <CAJumaK-ompHNrNb6ke=0zxbKtpWps2Y_Okxf-JLLXXpLMBdY8w@mail.gmail.com>
Message-ID: <4844F2A4-5660-4250-9D63-2ECB7495D3C7@cis.upenn.edu>

I see no good reason for this restriction -- I think that we should just remove the restriction instead of cooking up a workaround. Have you brought this up before? Perhaps make a ticket.

Richard

On Mar 8, 2016, at 8:24 PM, Edward Kmett <ekmett at gmail.com> wrote:

> If and when that feature lands would it be possible to use it to bypass a current limitation in class associated types?
> 
> Notably if a class associated type has a more general kind, we currently can't give a default definition for it that has a tighter kind.
> 
> e.g. I have some classes which are technically polykinded but where 90% of the instances instantiate that kind as *. The status quo prevents me from putting in a type default that would only be valid when the kind argument is *.
> 
> -Edward
> 
> On Tue, Mar 8, 2016 at 8:21 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> 
> On Mar 8, 2016, at 7:17 PM, Evan Austin <e.c.austin at gmail.com> wrote:
>> The wiki page for Phase I of Dependent Haskell describes an approach to constrained type families:
>> https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequationscanbeconstrained
>> 
>> Did that land in GHC 8.0 and, if so, is the updated syntax documented somewhere?
> 
> No, it didn't make it. The motivating test case seemed contrived and so we punted on this one.
> 
> Do you have a use case that really needs this feature? That would help to motivate it for 8.2 or beyond.
> 
> Thanks!
> Richard
> 
> 
> _______________________________________________
> 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/20160308/744edaf3/attachment-0001.html>

From ekmett at gmail.com  Wed Mar  9 01:40:08 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 8 Mar 2016 20:40:08 -0500
Subject: Constrained Type Families?
In-Reply-To: <4844F2A4-5660-4250-9D63-2ECB7495D3C7@cis.upenn.edu>
References: <6C5BEA85-CC87-4576-9CE7-80E356939D3C@gmail.com>
 <12F756C8-D973-43BA-9E27-456067A0E7F0@cis.upenn.edu>
 <CAJumaK-ompHNrNb6ke=0zxbKtpWps2Y_Okxf-JLLXXpLMBdY8w@mail.gmail.com>
 <4844F2A4-5660-4250-9D63-2ECB7495D3C7@cis.upenn.edu>
Message-ID: <CAJumaK_0eMdBeLp0dirwD16V32nK8yNDyXJ34KTW4UQ_1a9s2w@mail.gmail.com>

It has only been a low level irritant. Until Evan mentioned the link above,
I'd mostly just pushed it aside and learned to live with it.

This is probably the first time I've mentioned it outside of IRC.

-Edward

On Tue, Mar 8, 2016 at 8:31 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> I see no good reason for this restriction -- I think that we should just
> remove the restriction instead of cooking up a workaround. Have you brought
> this up before? Perhaps make a ticket.
>
> Richard
>
> On Mar 8, 2016, at 8:24 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
> If and when that feature lands would it be possible to use it to bypass a
> current limitation in class associated types?
>
> Notably if a class associated type has a more general kind, we currently
> can't give a default definition for it that has a tighter kind.
>
> e.g. I have some classes which are technically polykinded but where 90% of
> the instances instantiate that kind as *. The status quo prevents me from
> putting in a type default that would only be valid when the kind argument
> is *.
>
> -Edward
>
> On Tue, Mar 8, 2016 at 8:21 PM, Richard Eisenberg <eir at cis.upenn.edu>
> wrote:
>
>>
>> On Mar 8, 2016, at 7:17 PM, Evan Austin <e.c.austin at gmail.com> wrote:
>>
>> The wiki page for Phase I of Dependent Haskell describes an approach to
>> constrained type families:
>>
>> https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequationscanbeconstrained
>>
>> Did that land in GHC 8.0 and, if so, is the updated syntax documented
>> somewhere?
>>
>>
>> No, it didn't make it. The motivating test case seemed contrived and so
>> we punted on this one.
>>
>> Do you have a use case that really needs this feature? That would help to
>> motivate it for 8.2 or beyond.
>>
>> Thanks!
>> Richard
>>
>>
>> _______________________________________________
>> 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/20160308/0a23108b/attachment.html>

From e.c.austin at gmail.com  Wed Mar  9 01:54:05 2016
From: e.c.austin at gmail.com (Evan Austin)
Date: Tue, 8 Mar 2016 20:54:05 -0500
Subject: Constrained Type Families?
In-Reply-To: <12F756C8-D973-43BA-9E27-456067A0E7F0@cis.upenn.edu>
References: <6C5BEA85-CC87-4576-9CE7-80E356939D3C@gmail.com>
 <12F756C8-D973-43BA-9E27-456067A0E7F0@cis.upenn.edu>
Message-ID: <66EBE347-B381-48D3-90DF-302D0FF00884@gmail.com>

I unfortunately don?t have the exact code I was working on in front of me, but I was playing around with the -XTypeInType extension to see if I could use it to implement some notion of sub-kinding to start doing ?Data Types a la Carte? style things at the type level.

Constrained type families seemed like the most natural way to ?promote? those concepts, but maybe there?s a more obvious way I?m missing.

I?d be happy to send you a follow up email tomorrow when I?m back at the office if you think this would be a good motivating use case for the feature.


V/r,

-Evan


> On Mar 8, 2016, at 8:21 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> 
> 
> On Mar 8, 2016, at 7:17 PM, Evan Austin <e.c.austin at gmail.com <mailto:e.c.austin at gmail.com>> wrote:
>> The wiki page for Phase I of Dependent Haskell describes an approach to constrained type families:
>> https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequationscanbeconstrained <https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequationscanbeconstrained>
>> 
>> Did that land in GHC 8.0 and, if so, is the updated syntax documented somewhere?
> 
> No, it didn't make it. The motivating test case seemed contrived and so we punted on this one.
> 
> Do you have a use case that really needs this feature? That would help to motivate it for 8.2 or beyond.
> 
> Thanks!
> Richard
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160308/602dd836/attachment.html>

From eir at cis.upenn.edu  Wed Mar  9 02:25:31 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 8 Mar 2016 21:25:31 -0500
Subject: necessary to build for all platforms?
Message-ID: <94B8FCAB-5ABC-4387-9EBE-1BE853250FFB@cis.upenn.edu>

Hi devs,

Watching the files being compiled slowly scrolling by, as I too often do, led me to this question: Is there a reason that my machine (an x86-based Mac) is building modules in the SPARC or PPC directory? These absolutely need to be compiled when validating on any machine, but if I'm on the devel2 build settings, I don't see the need.

Am I right that these aren't needed for debugging? If I am, is it reasonable to try to teach the build scripts how to avoid doing this?

Thanks!
Richard

From mle+hs at mega-nerd.com  Wed Mar  9 02:28:50 2016
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Wed, 9 Mar 2016 13:28:50 +1100
Subject: Loading GHC into GHCi (reprise)
Message-ID: <20160309132850.6f6a7dfe041020c8098e195f@mega-nerd.com>

Hi all,

Recently Richard showed us how to load GHC into CHCi which ended up
being documented here:

    https://ghc.haskell.org/trac/ghc/wiki/Debugging/Compiler

That very useful for some things, but doesn't give you access to
symbols and types that have not been exported.

Specifically, I'm interested in some of the inner workings of the
file `compiler/llvmGen/LlvmCodeGen.hs` and I've even managed to
load it into GHCi using the command line:

    inplace/bin/ghc-stage2 --interactive  -ignore-dot-ghci -fobject-code \
       -DSTAGE=1 -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen \
      -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn \
      -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen \
      -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename \
      -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn \
      -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils \
      -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen \
      -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/.  \
      -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -XHaskell2010 \
      compiler/llvmGen/LlvmCodeGen.hs

and it loads all the modules require, but then seems to mess up the symbol
table so that it can't even find top level functions in the module it has
just loaded. 

    Prelude LlvmCodeGen> :t LlvmCodeGen.cmmDataLlvmGens

    <interactive>:1:1: error:
        Not in scope: ?LlvmCodeGen.cmmDataLlvmGens?
        No module named ?LlvmCodeGen? is imported.

I even tied adding `-icompiler/llvmGen` to the above command line (from
hell) before I noticed that it was already present.

Anyone have any idea why this doesn't work?

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

From eir at cis.upenn.edu  Wed Mar  9 02:29:51 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 8 Mar 2016 21:29:51 -0500
Subject: Constrained Type Families?
In-Reply-To: <66EBE347-B381-48D3-90DF-302D0FF00884@gmail.com>
References: <6C5BEA85-CC87-4576-9CE7-80E356939D3C@gmail.com>
 <12F756C8-D973-43BA-9E27-456067A0E7F0@cis.upenn.edu>
 <66EBE347-B381-48D3-90DF-302D0FF00884@gmail.com>
Message-ID: <3308C2B2-E230-40D5-B363-7FBDA022EA82@cis.upenn.edu>


On Mar 8, 2016, at 8:54 PM, Evan Austin <e.c.austin at gmail.com> wrote:

> I?d be happy to send you a follow up email tomorrow when I?m back at the office if you think this would be a good motivating use case for the feature.

Up to you. That feature isn't high on my priority list, and there are enough things on that list that I'm not begging for something new. But if it's important to you, then please do push for it.

Thanks,
Richard


From mle+hs at mega-nerd.com  Wed Mar  9 02:43:46 2016
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Wed, 9 Mar 2016 13:43:46 +1100
Subject: necessary to build for all platforms?
In-Reply-To: <94B8FCAB-5ABC-4387-9EBE-1BE853250FFB@cis.upenn.edu>
References: <94B8FCAB-5ABC-4387-9EBE-1BE853250FFB@cis.upenn.edu>
Message-ID: <20160309134346.7f9dd8ff511a1beea3cee1ff@mega-nerd.com>

Richard Eisenberg wrote:

> Watching the files being compiled slowly scrolling by, as I too often do,
> led me to this question: Is there a reason that my machine (an x86-based Mac)
> is building modules in the SPARC or PPC directory?

They do need to be built at some point.

> These absolutely need
> to be compiled when validating on any machine,

If they aren't build during devel2 but are build during validation then
that would be sufficient.

> If I am, is it reasonable to try to teach the build scripts how to avoid doing
> this?

As someone who cares about PowerPC and some other arches, I agree that this
is a reasonable request on the face of it. I am a little concerned about
the difficulty of teaching the build system to do it and I'm not sure how
big the payoff is. These arch specific files are probably less than 1% of the
total file count.

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

From mle+hs at mega-nerd.com  Wed Mar  9 07:41:44 2016
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Wed, 9 Mar 2016 18:41:44 +1100
Subject: Loading GHC into GHCi (reprise)
In-Reply-To: <20160309132850.6f6a7dfe041020c8098e195f@mega-nerd.com>
References: <20160309132850.6f6a7dfe041020c8098e195f@mega-nerd.com>
Message-ID: <20160309184144.c82907e117d55d8c318edaa9@mega-nerd.com>

Erik de Castro Lopo wrote:

> I even tied adding `-icompiler/llvmGen` to the above command line (from
> hell) before I noticed that it was already present.

Well I have a solution, I modified the module export list as follows:

    -module LlvmCodeGen ( llvmCodeGen, llvmFixupAsm ) where
    +module LlvmCodeGen ( llvmFixupAsm, module LlvmCodeGen ) where
 
which gives me access to all top level functions in that module.

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

From ben at smart-cactus.org  Wed Mar  9 10:52:20 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 09 Mar 2016 11:52:20 +0100
Subject: necessary to build for all platforms?
In-Reply-To: <20160309134346.7f9dd8ff511a1beea3cee1ff@mega-nerd.com>
References: <94B8FCAB-5ABC-4387-9EBE-1BE853250FFB@cis.upenn.edu>
 <20160309134346.7f9dd8ff511a1beea3cee1ff@mega-nerd.com>
Message-ID: <87lh5rx6sb.fsf@smart-cactus.org>

Erik de Castro Lopo <mle+hs at mega-nerd.com> writes:

> Richard Eisenberg wrote:
>
snip
>> If I am, is it reasonable to try to teach the build scripts how to avoid doing
>> this?
>
> As someone who cares about PowerPC and some other arches, I agree that this
> is a reasonable request on the face of it. I am a little concerned about
> the difficulty of teaching the build system to do it and I'm not sure how
> big the payoff is. These arch specific files are probably less than 1% of the
> total file count.
>
Right; moreover I suspect we want to compile them during validation
anyways to ensure that they aren't inadvertently broken.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160309/0e1ffc75/attachment-0001.sig>

From simonpj at microsoft.com  Wed Mar  9 12:39:41 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 9 Mar 2016 12:39:41 +0000
Subject: Constrained Type Families?
In-Reply-To: <4844F2A4-5660-4250-9D63-2ECB7495D3C7@cis.upenn.edu>
References: <6C5BEA85-CC87-4576-9CE7-80E356939D3C@gmail.com>
 <12F756C8-D973-43BA-9E27-456067A0E7F0@cis.upenn.edu>
 <CAJumaK-ompHNrNb6ke=0zxbKtpWps2Y_Okxf-JLLXXpLMBdY8w@mail.gmail.com>
 <4844F2A4-5660-4250-9D63-2ECB7495D3C7@cis.upenn.edu>
Message-ID: <777e8f9e3f4e4c40999de37d84e9457d@DB4PR30MB030.064d.mgd.msft.net>

Notably if a class associated type has a more general kind, we currently can't give a default definition for it that has a tighter kind.

This is the same situation as holds for default class methods.

BUT for the latter we invented default method signatures ?XdefaultSignatures (user manual Section 9.8.1.4<http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#class-declarations>), which can be more restrictive than the signature implied by the method signature of the class.

Maybe we can do the same for default declarations for associated types?

Would someone like to open a ticket and tell the story?

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard Eisenberg
Sent: 09 March 2016 01:32
To: Edward Kmett <ekmett at gmail.com>
Cc: ghc-devs <ghc-devs at haskell.org>
Subject: Re: Constrained Type Families?

I see no good reason for this restriction -- I think that we should just remove the restriction instead of cooking up a workaround. Have you brought this up before? Perhaps make a ticket.

Richard

On Mar 8, 2016, at 8:24 PM, Edward Kmett <ekmett at gmail.com<mailto:ekmett at gmail.com>> wrote:


If and when that feature lands would it be possible to use it to bypass a current limitation in class associated types?

Notably if a class associated type has a more general kind, we currently can't give a default definition for it that has a tighter kind.

e.g. I have some classes which are technically polykinded but where 90% of the instances instantiate that kind as *. The status quo prevents me from putting in a type default that would only be valid when the kind argument is *.

-Edward

On Tue, Mar 8, 2016 at 8:21 PM, Richard Eisenberg <eir at cis.upenn.edu<mailto:eir at cis.upenn.edu>> wrote:

On Mar 8, 2016, at 7:17 PM, Evan Austin <e.c.austin at gmail.com<mailto:e.c.austin at gmail.com>> wrote:
The wiki page for Phase I of Dependent Haskell describes an approach to constrained type families:
https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequationscanbeconstrained

Did that land in GHC 8.0 and, if so, is the updated syntax documented somewhere?

No, it didn't make it. The motivating test case seemed contrived and so we punted on this one.

Do you have a use case that really needs this feature? That would help to motivate it for 8.2 or beyond.

Thanks!
Richard


_______________________________________________
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<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c548849e42ffa4b50f01208d347ba9228%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=QKme1PQXRrwAkxAODUaPscdFk7ovwwwxHAFhDxpBXb8%3d>


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

From ekmett at gmail.com  Wed Mar  9 15:45:17 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 9 Mar 2016 10:45:17 -0500
Subject: Constrained Type Families?
In-Reply-To: <777e8f9e3f4e4c40999de37d84e9457d@DB4PR30MB030.064d.mgd.msft.net>
References: <6C5BEA85-CC87-4576-9CE7-80E356939D3C@gmail.com>
 <12F756C8-D973-43BA-9E27-456067A0E7F0@cis.upenn.edu>
 <CAJumaK-ompHNrNb6ke=0zxbKtpWps2Y_Okxf-JLLXXpLMBdY8w@mail.gmail.com>
 <4844F2A4-5660-4250-9D63-2ECB7495D3C7@cis.upenn.edu>
 <777e8f9e3f4e4c40999de37d84e9457d@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAJumaK-8PHSRzbK4ETJ3iSOY08jtZTN7jpjxNGZzv+n0ozHQVQ@mail.gmail.com>

I'd pretty much just assumed that a class associated type with a default
definition was modeling the same thing as a default signature, just without
the 'default' keyword

-Edward

On Wed, Mar 9, 2016 at 7:39 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Notably if a class associated type has a more general kind, we currently
> can't give a default definition for it that has a tighter kind.
>
>
>
> This is the same situation as holds for default class methods.
>
>
>
> BUT for the latter we invented default method signatures
> ?XdefaultSignatures (user manual Section 9.8.1.4
> <http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#class-declarations>),
> which can be more restrictive than the signature implied by the method
> signature of the class.
>
>
>
> Maybe we can do the same for default declarations for associated types?
>
>
>
> Would someone like to open a ticket and tell the story?
>
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Richard
> Eisenberg
> *Sent:* 09 March 2016 01:32
> *To:* Edward Kmett <ekmett at gmail.com>
> *Cc:* ghc-devs <ghc-devs at haskell.org>
> *Subject:* Re: Constrained Type Families?
>
>
>
> I see no good reason for this restriction -- I think that we should just
> remove the restriction instead of cooking up a workaround. Have you brought
> this up before? Perhaps make a ticket.
>
>
>
> Richard
>
>
>
> On Mar 8, 2016, at 8:24 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
>
>
> If and when that feature lands would it be possible to use it to bypass a
> current limitation in class associated types?
>
>
>
> Notably if a class associated type has a more general kind, we currently
> can't give a default definition for it that has a tighter kind.
>
>
>
> e.g. I have some classes which are technically polykinded but where 90% of
> the instances instantiate that kind as *. The status quo prevents me from
> putting in a type default that would only be valid when the kind argument
> is *.
>
>
>
> -Edward
>
>
>
> On Tue, Mar 8, 2016 at 8:21 PM, Richard Eisenberg <eir at cis.upenn.edu>
> wrote:
>
>
>
> On Mar 8, 2016, at 7:17 PM, Evan Austin <e.c.austin at gmail.com> wrote:
>
> The wiki page for Phase I of Dependent Haskell describes an approach to
> constrained type families:
>
>
> https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Typefamilyequationscanbeconstrained
>
>
>
> Did that land in GHC 8.0 and, if so, is the updated syntax documented
> somewhere?
>
>
>
> No, it didn't make it. The motivating test case seemed contrived and so we
> punted on this one.
>
>
>
> Do you have a use case that really needs this feature? That would help to
> motivate it for 8.2 or beyond.
>
>
>
> Thanks!
>
> Richard
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c548849e42ffa4b50f01208d347ba9228%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=QKme1PQXRrwAkxAODUaPscdFk7ovwwwxHAFhDxpBXb8%3d>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160309/07e35aa5/attachment-0001.html>

From ryani.spam at gmail.com  Wed Mar  9 16:48:31 2016
From: ryani.spam at gmail.com (Ryan Ingram)
Date: Wed, 9 Mar 2016 08:48:31 -0800
Subject: Constrained Type Families?
In-Reply-To: <CAJumaK-8PHSRzbK4ETJ3iSOY08jtZTN7jpjxNGZzv+n0ozHQVQ@mail.gmail.com>
References: <6C5BEA85-CC87-4576-9CE7-80E356939D3C@gmail.com>
 <12F756C8-D973-43BA-9E27-456067A0E7F0@cis.upenn.edu>
 <CAJumaK-ompHNrNb6ke=0zxbKtpWps2Y_Okxf-JLLXXpLMBdY8w@mail.gmail.com>
 <4844F2A4-5660-4250-9D63-2ECB7495D3C7@cis.upenn.edu>
 <777e8f9e3f4e4c40999de37d84e9457d@DB4PR30MB030.064d.mgd.msft.net>
 <CAJumaK-8PHSRzbK4ETJ3iSOY08jtZTN7jpjxNGZzv+n0ozHQVQ@mail.gmail.com>
Message-ID: <CA+XKtKgMHvTjGS4HH-eGK2dOoAyszmNiTwNanu7ZZ_QH+Ntzjw@mail.gmail.com>

I think it's more like the non-keyworded default definitions of class
methods, for the same reasons; the default definition has to potentially be
valid for all instances of the class?.

It's the difference between

class Applicative m => Monad m where
    return :: a -> m a
    return = pure  -- always valid, but can be overridden in instance
declarations

and

class Fuctor f => Applicative f where
    (<*>) :: f (a -> b) -> f a -> f b
    default (<*>) :: Monad f => f (a -> b) -> f a -> f b
    (<*>) = ap -- only valid if matches the type signature above
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160309/e6db12e8/attachment.html>

From ben at well-typed.com  Wed Mar  9 18:33:03 2016
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 09 Mar 2016 19:33:03 +0100
Subject: Loading GHC into GHCi (reprise)
In-Reply-To: <20160309132850.6f6a7dfe041020c8098e195f@mega-nerd.com>
References: <20160309132850.6f6a7dfe041020c8098e195f@mega-nerd.com>
Message-ID: <87fuvzwlgg.fsf@smart-cactus.org>

Erik de Castro Lopo <mle+hs at mega-nerd.com> writes:

> Hi all,
>
> Recently Richard showed us how to load GHC into CHCi which ended up
> being documented here:
>
>     https://ghc.haskell.org/trac/ghc/wiki/Debugging/Compiler
>
> That very useful for some things, but doesn't give you access to
> symbols and types that have not been exported.
>
> Specifically, I'm interested in some of the inner workings of the
> file `compiler/llvmGen/LlvmCodeGen.hs` and I've even managed to
> load it into GHCi using the command line:
>
>     inplace/bin/ghc-stage2 --interactive  -ignore-dot-ghci -fobject-code \
>        -DSTAGE=1 -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen \
>       -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn \
>       -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen \
>       -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename \
>       -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn \
>       -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils \
>       -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen \
>       -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/.  \
>       -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -XHaskell2010 \
>       compiler/llvmGen/LlvmCodeGen.hs
>
> and it loads all the modules require, but then seems to mess up the symbol
> table so that it can't even find top level functions in the module it has
> just loaded. 
>
>     Prelude LlvmCodeGen> :t LlvmCodeGen.cmmDataLlvmGens
>
>     <interactive>:1:1: error:
>         Not in scope: ?LlvmCodeGen.cmmDataLlvmGens?
>         No module named ?LlvmCodeGen? is imported.
>
> I even tied adding `-icompiler/llvmGen` to the above command line (from
> hell) before I noticed that it was already present.
>
The issue here is that you used -fobject-code while loading the module
in question; this gives you only access to exported definitions.
Unfortunately -fobject-code is necessary when loading GHC in GHCi as the
bytecode interpreter doesn't support unboxed tuples, which various GHC
modules use.

I suspect it should be possible to convince GHCi to use object code for
those modules which require it. In fact, I think thomie was looking into
this at some point. I'm not sure what became of his effort.

Cheers,

- Ben


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160309/8aee0391/attachment.sig>

From ekmett at gmail.com  Wed Mar  9 21:07:53 2016
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 9 Mar 2016 16:07:53 -0500
Subject: Constrained Type Families?
In-Reply-To: <CA+XKtKgMHvTjGS4HH-eGK2dOoAyszmNiTwNanu7ZZ_QH+Ntzjw@mail.gmail.com>
References: <6C5BEA85-CC87-4576-9CE7-80E356939D3C@gmail.com>
 <12F756C8-D973-43BA-9E27-456067A0E7F0@cis.upenn.edu>
 <CAJumaK-ompHNrNb6ke=0zxbKtpWps2Y_Okxf-JLLXXpLMBdY8w@mail.gmail.com>
 <4844F2A4-5660-4250-9D63-2ECB7495D3C7@cis.upenn.edu>
 <777e8f9e3f4e4c40999de37d84e9457d@DB4PR30MB030.064d.mgd.msft.net>
 <CAJumaK-8PHSRzbK4ETJ3iSOY08jtZTN7jpjxNGZzv+n0ozHQVQ@mail.gmail.com>
 <CA+XKtKgMHvTjGS4HH-eGK2dOoAyszmNiTwNanu7ZZ_QH+Ntzjw@mail.gmail.com>
Message-ID: <CAJumaK96PS95ic2HJdTE9HpaHRNhZ99um3NcNn8oF61ZRNAn8w@mail.gmail.com>

Good point!

On Wed, Mar 9, 2016 at 11:48 AM, Ryan Ingram <ryani.spam at gmail.com> wrote:

> I think it's more like the non-keyworded default definitions of class
> methods, for the same reasons; the default definition has to potentially be
> valid for all instances of the class?.
>
> It's the difference between
>
> class Applicative m => Monad m where
>     return :: a -> m a
>     return = pure  -- always valid, but can be overridden in instance
> declarations
>
> and
>
> class Fuctor f => Applicative f where
>     (<*>) :: f (a -> b) -> f a -> f b
>     default (<*>) :: Monad f => f (a -> b) -> f a -> f b
>     (<*>) = ap -- only valid if matches the type signature above
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160309/d610b8e5/attachment.html>

From juhpetersen at gmail.com  Thu Mar 10 02:46:33 2016
From: juhpetersen at gmail.com (Jens Petersen)
Date: Thu, 10 Mar 2016 11:46:33 +0900
Subject: Change in GHC release timing policy
In-Reply-To: <874mchxf6w.fsf@smart-cactus.org>
References: <874mchxf6w.fsf@smart-cactus.org>
Message-ID: <CAEDGBqLHr81c97AHR6+YXCHGSDe5L_=8SF0axZwVehgR2y3Sgw@mail.gmail.com>

>   * The source release will be tagged and tarballs pushed to a staging
>     area
>   * We will soon thereafter notify the binary distribution builders and
>     ghc-devs@
>   * Everyone will go to work on their binary distributions
>   * One week after the source release is tagged the release artifacts
>     will be pushed to downloads.haskell.org and the release publicly
>     announced.
>
> We hope that this will remove some of the confusion from the current
> process while ensuring that all platforms have the potential for support
> on the day of the release. We'll be trying this for 8.0.1-rc3 and the final
> release. If all goes well we'll continue this policy in future releases.

Sounds great, thanks!!

Jens

From carter.schonwald at gmail.com  Thu Mar 10 03:27:52 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 9 Mar 2016 22:27:52 -0500
Subject: Loading GHC into GHCi (reprise)
In-Reply-To: <87fuvzwlgg.fsf@smart-cactus.org>
References: <20160309132850.6f6a7dfe041020c8098e195f@mega-nerd.com>
 <87fuvzwlgg.fsf@smart-cactus.org>
Message-ID: <CAHYVw0wQEUUptKyn0UUu1V4evJ++FGq0PkQXbCZqQSGGdf56Dw@mail.gmail.com>

Actually that raises a question: is it possible to set a top level ghci
option file pragma for having a module to fobject code ? That would be nice
for exactly this reason. Fobject code doesn't seem to work as of 7.10,
though it seems to be listed as dynamic as of 8.0 rc2, does that mean it'll
work for those of using ghc 8.0 ??

On Wednesday, March 9, 2016, Ben Gamari <ben at well-typed.com> wrote:

> Erik de Castro Lopo <mle+hs at mega-nerd.com <javascript:;>> writes:
>
> > Hi all,
> >
> > Recently Richard showed us how to load GHC into CHCi which ended up
> > being documented here:
> >
> >     https://ghc.haskell.org/trac/ghc/wiki/Debugging/Compiler
> >
> > That very useful for some things, but doesn't give you access to
> > symbols and types that have not been exported.
> >
> > Specifically, I'm interested in some of the inner workings of the
> > file `compiler/llvmGen/LlvmCodeGen.hs` and I've even managed to
> > load it into GHCi using the command line:
> >
> >     inplace/bin/ghc-stage2 --interactive  -ignore-dot-ghci -fobject-code
> \
> >        -DSTAGE=1 -i -icompiler/basicTypes -icompiler/cmm
> -icompiler/codeGen \
> >       -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci
> -icompiler/hsSyn \
> >       -icompiler/iface -icompiler/llvmGen -icompiler/main
> -icompiler/nativeGen \
> >       -icompiler/parser -icompiler/prelude -icompiler/profiling
> -icompiler/rename \
> >       -icompiler/simplCore -icompiler/simplStg -icompiler/specialise
> -icompiler/stgSyn \
> >       -icompiler/stranal -icompiler/typecheck -icompiler/types
> -icompiler/utils \
> >       -icompiler/vectorise -icompiler/stage1/build
> -icompiler/stage1/build/autogen \
> >       -Icompiler/stage1/build -Icompiler/stage1/build/autogen
> -Icompiler/.  \
> >       -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -XHaskell2010
> \
> >       compiler/llvmGen/LlvmCodeGen.hs
> >
> > and it loads all the modules require, but then seems to mess up the
> symbol
> > table so that it can't even find top level functions in the module it has
> > just loaded.
> >
> >     Prelude LlvmCodeGen> :t LlvmCodeGen.cmmDataLlvmGens
> >
> >     <interactive>:1:1: error:
> >         Not in scope: ?LlvmCodeGen.cmmDataLlvmGens?
> >         No module named ?LlvmCodeGen? is imported.
> >
> > I even tied adding `-icompiler/llvmGen` to the above command line (from
> > hell) before I noticed that it was already present.
> >
> The issue here is that you used -fobject-code while loading the module
> in question; this gives you only access to exported definitions.
> Unfortunately -fobject-code is necessary when loading GHC in GHCi as the
> bytecode interpreter doesn't support unboxed tuples, which various GHC
> modules use.
>
> I suspect it should be possible to convince GHCi to use object code for
> those modules which require it. In fact, I think thomie was looking into
> this at some point. I'm not sure what became of his effort.
>
> Cheers,
>
> - Ben
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160309/460eb411/attachment.html>

From hsyl20 at gmail.com  Thu Mar 10 14:53:47 2016
From: hsyl20 at gmail.com (Sylvain Henry)
Date: Thu, 10 Mar 2016 15:53:47 +0100
Subject: Fwd: Reducing boilerplate
In-Reply-To: <CAPmptcVd1qRaYMMb2VjzJ27CxB-KuOtNUz8Z-E5uXQi4O-b3Fg@mail.gmail.com>
References: <CAPmptcVd1qRaYMMb2VjzJ27CxB-KuOtNUz8Z-E5uXQi4O-b3Fg@mail.gmail.com>
Message-ID: <CAPmptcVqi5KtJL6gXP3W=sCLRcOuvw4CC0PdOxNnmHr0zj_zsA@mail.gmail.com>

Hi devs,

I would like to add the support for the following automatic
instance-deriving extension:

module M where

class G a where
    doG :: a -> Int

class P a where
  doP :: a -> Int
  doP _ = 10
  deriving instance G a where -- automatically derived instance
    doG = doP

data X = X
instance P X -- derive G X automatically

print (doG X) -- print 10

See the forwarded mail below for the real context. This extension has
been proposed by someone before as InstanceTemplates:
https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates

I have modified the parser and the renamer accordingly to get:

class M.G a_awb where
  M.doG :: a_awb -> Int
class M.P a_ap6 where
  M.doP :: a_ap6 -> Int
  M.doP _ = 10
  instance M.G a_ap6 where
    M.doG = M.doP

I am new to the compiler part of GHC, so I have a few questions before
I continue:
1a) does it make sense to store the renamed class instance declaration
in an interface file? (supposing it only uses exported methods/types;
we could check that)
1b) will it be possible to create a new instance declaration in
another module by just doing the substitution [a_ap6 -> X] in it?
(i.e. when we parse "instance P X", do we know that it means [a_ap6 ->
X] in class P (and not [a -> X])?)
2) maybe I should go a different way and store only the derived
instance methods as we store class default methods?

Any insight appreciated!

Thanks,
Sylvain


---------- Forwarded message ----------
From: Sylvain Henry <hsyl20 at gmail.com>
Date: 2016-03-05 14:56 GMT+01:00
Subject: Reducing boilerplate
To: Haskell Cafe <haskell-cafe at haskell.org>


Hi,

To write FFI bindings, I use c-storable-deriving [1] to automatically
derive CStorable instances for many data types (the only difference
between Storable and CStorable is that CStorable provides default
methods for types that have Generic instances):

{-# LANGUAGE DeriveGeneric #-}
{-# LANGUAGE DeriveAnyClass #-}
...
data X = X
   { fieldStatus           :: Vector 24 Word8
   , fieldPadding         :: Word8
   } deriving (Generic, CStorable)

However I also need a Storable instance, hence I have to write (the
"c*" methods are provided by CStorable):

instance Storable X where
   peek        = cPeek
   poke        = cPoke
   alignment = cAlignment
   sizeOf      = cSizeOf

Is there a way to automatically generate this instance for every data
that has an instance of CStorable? Ideally, I would like to say once
and for all:

instance CStorable a => Storable a where
   peek        = cPeek
   poke        = cPoke
   alignment = cAlignment
   sizeOf      = cSizeOf

As I don't think it is currently possible, would it be sensible to add
the support for automatically derived instances attached to classes
(as a GHC extension)?

Regards,
Sylvain

[1] https://hackage.haskell.org/package/c-storable-deriving

From ben at well-typed.com  Thu Mar 10 15:58:48 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 10 Mar 2016 16:58:48 +0100
Subject: Loading GHC into GHCi (reprise)
In-Reply-To: <CAHYVw0wQEUUptKyn0UUu1V4evJ++FGq0PkQXbCZqQSGGdf56Dw@mail.gmail.com>
References: <20160309132850.6f6a7dfe041020c8098e195f@mega-nerd.com>
 <87fuvzwlgg.fsf@smart-cactus.org>
 <CAHYVw0wQEUUptKyn0UUu1V4evJ++FGq0PkQXbCZqQSGGdf56Dw@mail.gmail.com>
Message-ID: <878u1qwchz.fsf@smart-cactus.org>

Ccing Edward, who may have some insight here.


Carter Schonwald <carter.schonwald at gmail.com> writes:

> Actually that raises a question: is it possible to set a top level ghci
> option file pragma for having a module to fobject code ? That would be nice
> for exactly this reason. Fobject code doesn't seem to work as of 7.10,
> though it seems to be listed as dynamic as of 8.0 rc2, does that mean it'll
> work for those of using ghc 8.0 ??
>
It does not work as far as I know. I don't believe the problem was ever
that -fobject-code wasn't a dynamic flag; I suspect the reason is that
by the time we see the pragma we've already committed to compiling the
module. That being said, I'm not as familiar with this part of the
compiler as I'd like to be.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160310/ddb58a84/attachment.sig>

From ben at well-typed.com  Thu Mar 10 16:05:46 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 10 Mar 2016 17:05:46 +0100
Subject: Loading GHC into GHCi (reprise)
In-Reply-To: <CAHYVw0wQEUUptKyn0UUu1V4evJ++FGq0PkQXbCZqQSGGdf56Dw@mail.gmail.com>
References: <20160309132850.6f6a7dfe041020c8098e195f@mega-nerd.com>
 <87fuvzwlgg.fsf@smart-cactus.org>
 <CAHYVw0wQEUUptKyn0UUu1V4evJ++FGq0PkQXbCZqQSGGdf56Dw@mail.gmail.com>
Message-ID: <8760wuwc6d.fsf@smart-cactus.org>

Carter Schonwald <carter.schonwald at gmail.com> writes:

> Actually that raises a question: is it possible to set a top level ghci
> option file pragma for having a module to fobject code ? That would be nice
> for exactly this reason. Fobject code doesn't seem to work as of 7.10,
> though it seems to be listed as dynamic as of 8.0 rc2, does that mean it'll
> work for those of using ghc 8.0 ??
>
For the record, I believe #1365 is a relevant ticket here.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160310/e24a497d/attachment.sig>

From simonpj at microsoft.com  Thu Mar 10 21:51:40 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 10 Mar 2016 21:51:40 +0000
Subject: Local bindings in the static form
In-Reply-To: <CA+Q==SDSHygPXUxh9kyO-apDtm8fsU9ReyWK5S6w4iX6vNO4eg@mail.gmail.com>
References: <CA+Q==SDSA4gncXAAd9dGWvWT28Tre44DZshuMigF-xLX_MXhaQ@mail.gmail.com>
 <5c2393791c9f4bbbb0aee62b16f30005@DB4PR30MB030.064d.mgd.msft.net>
 <CA+Q==SDSHygPXUxh9kyO-apDtm8fsU9ReyWK5S6w4iX6vNO4eg@mail.gmail.com>
Message-ID: <cf68dcd4fc3a49ba8d5cb6eb422a97e4@DB4PR30MB030.064d.mgd.msft.net>

Eeek. That looks wrong.  I've created https://ghc.haskell.org/trac/ghc/ticket/11698.

The fix isn't hard, but I'm busy writing papers.  I can explain what to do if you are minded to do it.  The good thing is that it would then do what you want too!

Simon

| -----Original Message-----
| From: facundominguez at gmail.com [mailto:facundominguez at gmail.com] On Behalf Of
| Facundo Dom?nguez
| Sent: 07 March 2016 20:55
| To: Simon Peyton Jones <simonpj at microsoft.com>
| Cc: ghc-devs at haskell.org
| Subject: Re: Local bindings in the static form
| 
| Hello Simon,
| 
| We considered tct_closed once. However, it only seems to indicate
| whether the type of a binding is closed, instead of its right hand
| side.
| 
| For instance,
| 
| \x -> let g = x :: Int in g
| 
| In this example, g would have a closed type Int, thus tct_closed ==
| TopLevel. However, the right hand side of g has a free variable x
| which is not bound at the top level, and therefore it couldn't be
| floated out.
| 
| Corrections are welcome if I'm fooling myself in some aspect here.
| 
| Thanks,
| Facundo
| 
| 
| On Fri, Mar 4, 2016 at 7:47 AM, Simon Peyton Jones
| <simonpj at microsoft.com> wrote:
| > Facundo
| >
| > Yes, that makes perfect sense.  Moreover, it is pretty much exactly what
| the tct_closed flag on `ATcId` does.
| >
| > The trick will be to guarantee that all those Ids do in fact end up being
| floated out.
| >
| > We could have a Skype chat about this, preferably after the March 16 ICFP
| deadline
| >
| > Simon
| >
| > |  -----Original Message-----
| > |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| > |  Facundo Dom?nguez
| > |  Sent: 03 March 2016 19:41
| > |  To: ghc-devs at haskell.org
| > |  Subject: Local bindings in the static form
| > |
| > |  Hello,
| > |    At Tweag I/O we are considering relaxing a bit the constraints on the
| > |  static form.
| > |
| > |  static <exp>
| > |
| > |    demands <exp> to be closed. That is, the free variables of <exp> must
| > |  be bound at the top level.
| > |
| > |  However, it would be fine to allow local bindings too. For instance:
| > |
| > |  test :: StaticPtr ([[Int]] -> [[Int]])
| > |  test x = static (filter hasZero)
| > |    where
| > |      hasZero = any isZero
| > |      isZero  = (0 ==)
| > |
| > |  Where hasZero is local but its body can be considered kind of closed
| > |  (all free variables refer to top-level bindings or other *closed* local
| > |  bindings.).
| > |
| > |  We would need for this implementation a way to test closedness in this
| > |  sense. Could there be any similar test implemented already in GHC?
| > |
| > |  Thanks,
| > |  Facundo
| > |
| > |  [1] https://ghc.haskell.org/trac/ghc/ticket/11656
| > |  _______________________________________________
| > |  ghc-devs mailing list
| > |  ghc-devs at haskell.org
| > |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
| > |  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| > |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cead97b273efa41c1
| > |  a49608d3439bd142%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Z1TbBcSgd
| > |  YLZ%2bXrMJVMvqJIfwc4R2kLeRaPPwuQ5%2fLQ%3d

From ben at well-typed.com  Fri Mar 11 15:51:32 2016
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 11 Mar 2016 16:51:32 +0100
Subject: Fwd: Reducing boilerplate
In-Reply-To: <CAPmptcVqi5KtJL6gXP3W=sCLRcOuvw4CC0PdOxNnmHr0zj_zsA@mail.gmail.com>
References: <CAPmptcVd1qRaYMMb2VjzJ27CxB-KuOtNUz8Z-E5uXQi4O-b3Fg@mail.gmail.com>
 <CAPmptcVqi5KtJL6gXP3W=sCLRcOuvw4CC0PdOxNnmHr0zj_zsA@mail.gmail.com>
Message-ID: <87twkdui63.fsf@smart-cactus.org>

Sylvain Henry <hsyl20 at gmail.com> writes:

> Hi devs,
>
> I would like to add the support for the following automatic
> instance-deriving extension:
>
Hi Sylvain,

I suspect the person most qualified to answer these questions will be
Simon who is currently in the middle of paper-writing season.
Consequently, it may be a while until he is able to answer. That being
said, I'm quite happy to hear that someone is thinking about these
proposals.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160311/e4fcb0b6/attachment.sig>

From eir at cis.upenn.edu  Fri Mar 11 16:11:53 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 11 Mar 2016 11:11:53 -0500
Subject: A performance predicament
Message-ID: <9DCA7D17-8B4E-4CE8-9391-1271C8D1C599@cis.upenn.edu>

Hi devs,

I'm working on some compiler performance bugs. I've implemented caching for coercion kinds at Phab:D1992. But tests show a net slowdown, which I'm currently investigating. I could abandon this work for 8.0, but it really should show an improvement, and so I'm looking deeper.

A little profiling has shown that the (>>=) operator of the FlatM monad is doing 13% of all allocations on a test program (T3064). The sad thing is that, if I understand correctly, this bind shouldn't do any allocation at all! Here are the relevant definitions:

> newtype FlatM a = FlatM { runFlatM :: FlattenEnv -> TcS a }
> newtype TcS a = TcS { unTcS :: TcSEnv -> TcM a }
> type TcM = TcRn
> type TcRn = TcRnIf TcGblEnv TcLclEnv
> type TcRnIf a b = IOEnv (Env a b)
> newtype IOEnv env a = IOEnv (env -> IO a)

As we can see here, FlatM a is equivalent to (Foo -> Bar -> Baz -> IO a). So working in this monad should just pass around the three parameters without doing any allocation, unless IO's bind operation does allocation. (I assume we use magic to prevent that last piece.) I've tried adding INLINE to the various pieces to no avail.

Am I misunderstanding something fundamental here? I feel like I must be.

Thanks,
Richard

PS: The allocation done by FlatM was around before my caching optimization. So I'm working slightly orthogonally to where I started. But if IOEnv is really doing something even slightly slowly, a small tweak here could net massive improvements in overall speed.

From simonpj at microsoft.com  Fri Mar 11 17:04:54 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 11 Mar 2016 17:04:54 +0000
Subject: A performance predicament
In-Reply-To: <9DCA7D17-8B4E-4CE8-9391-1271C8D1C599@cis.upenn.edu>
References: <9DCA7D17-8B4E-4CE8-9391-1271C8D1C599@cis.upenn.edu>
Message-ID: <3432055fb57540cea6bca1dccad82abc@DB4PR30MB030.064d.mgd.msft.net>

You don't say how you got those numbers, but if it's by -prof-auto-all it may be a red herring.  Profiling prevents optimisation!  

I built TcFlatten by touching it, make, grab command line, then execute that command line again with -ddump-simpl.

The defn of >>= for FlatM looks scary (below); but it's never called because it's already been inlined.  So I don?t think it'll allocate anything.

An alternative approach is to add manual SCCs and drill in gradually

Simon

TcFlatten.$fMonadFlatM1 =
  \ (@ a11_abat)
    (@ b_abau)
    (m_a7hJ :: FlatM a11_abat)
    (k_a7hK :: a11_abat -> FlatM b_abau)
    (env_a7hL :: FlattenEnv) ->
    let {
      m1_aegb [Dmd=<L,C(U)>] :: TcS a11_abat
      [LclId, Str=DmdType]
      m1_aegb = (m_a7hJ `cast` ...) env_a7hL } in
    (\ (ebs_aegd :: TcSMonad.TcSEnv) ->
       let {
         eta_aege [Dmd=<L,C(C(U(U,U)))>]
           :: IOEnv.IOEnv (Env TcGblEnv TcLclEnv) a11_abat
         [LclId, Str=DmdType]
         eta_aege = (m1_aegb `cast` ...) ebs_aegd } in
       (\ (eta2_aegf :: Env TcGblEnv TcLclEnv)
          (eta3_aegg [OS=OneShot]
             :: ghc-prim-0.4.0.0:GHC.Prim.State#
                  ghc-prim-0.4.0.0:GHC.Prim.RealWorld) ->
          case (((eta_aege `cast` ...) eta2_aegf) `cast` ...) eta3_aegg
          of _ [Occ=Dead] { (# ipv_aegj, ipv1_aegk #) ->
          ((((((((k_a7hK ipv1_aegk) `cast` ...) env_a7hL) `cast` ...)
                ebs_aegd)
             `cast` ...)
              eta2_aegf)
           `cast` ...)
            ipv_aegj
          })
       `cast` ...)
    `cast` ...

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Richard Eisenberg
|  Sent: 11 March 2016 16:12
|  To: ghc-devs at haskell.org developers <ghc-devs at haskell.org>
|  Subject: A performance predicament
|  
|  Hi devs,
|  
|  I'm working on some compiler performance bugs. I've implemented caching
|  for coercion kinds at Phab:D1992. But tests show a net slowdown, which
|  I'm currently investigating. I could abandon this work for 8.0, but it
|  really should show an improvement, and so I'm looking deeper.
|  
|  A little profiling has shown that the (>>=) operator of the FlatM monad
|  is doing 13% of all allocations on a test program (T3064). The sad
|  thing is that, if I understand correctly, this bind shouldn't do any
|  allocation at all! Here are the relevant definitions:
|  
|  > newtype FlatM a = FlatM { runFlatM :: FlattenEnv -> TcS a }
|  > newtype TcS a = TcS { unTcS :: TcSEnv -> TcM a }
|  > type TcM = TcRn
|  > type TcRn = TcRnIf TcGblEnv TcLclEnv
|  > type TcRnIf a b = IOEnv (Env a b)
|  > newtype IOEnv env a = IOEnv (env -> IO a)
|  
|  As we can see here, FlatM a is equivalent to (Foo -> Bar -> Baz -> IO
|  a). So working in this monad should just pass around the three
|  parameters without doing any allocation, unless IO's bind operation
|  does allocation. (I assume we use magic to prevent that last piece.)
|  I've tried adding INLINE to the various pieces to no avail.
|  
|  Am I misunderstanding something fundamental here? I feel like I must
|  be.
|  
|  Thanks,
|  Richard
|  
|  PS: The allocation done by FlatM was around before my caching
|  optimization. So I'm working slightly orthogonally to where I started.
|  But if IOEnv is really doing something even slightly slowly, a small
|  tweak here could net massive improvements in overall speed.
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c08f2a6ba49224e52
|  f77108d349c7e37e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tIy8Et5RN
|  MpnOmPbypf7ggBq6DgufBd%2bACe46nau%2b%2fk%3d

From eir at cis.upenn.edu  Fri Mar 11 18:53:32 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 11 Mar 2016 13:53:32 -0500
Subject: A performance predicament
In-Reply-To: <3432055fb57540cea6bca1dccad82abc@DB4PR30MB030.064d.mgd.msft.net>
References: <9DCA7D17-8B4E-4CE8-9391-1271C8D1C599@cis.upenn.edu>
 <3432055fb57540cea6bca1dccad82abc@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <3A7EABDA-FE48-41A2-89DE-4B2471E95095@cis.upenn.edu>


On Mar 11, 2016, at 12:04 PM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> Profiling prevents optimisation!  

I didn't know that. Why does it do this? It defeats the point of profiling a bit if we can't optimize. I just assumed the optimizer looks through the SCCs, preserving them, but that otherwise SCCs don't get in the way.

Anyway, helpful to know. Is this fact documented in the manual?

Thanks!
Richard

From hsyl20 at gmail.com  Fri Mar 11 20:59:10 2016
From: hsyl20 at gmail.com (Sylvain Henry)
Date: Fri, 11 Mar 2016 21:59:10 +0100
Subject: Fwd: Reducing boilerplate
In-Reply-To: <87twkdui63.fsf@smart-cactus.org>
References: <CAPmptcVd1qRaYMMb2VjzJ27CxB-KuOtNUz8Z-E5uXQi4O-b3Fg@mail.gmail.com>
 <CAPmptcVqi5KtJL6gXP3W=sCLRcOuvw4CC0PdOxNnmHr0zj_zsA@mail.gmail.com>
 <87twkdui63.fsf@smart-cactus.org>
Message-ID: <CAPmptcXYesZST1XiHEzwz5M91CbcMGDT7oniPgMrC1uetkDVLw@mail.gmail.com>

Hi Ben,

Thanks for your answer. No problem, I can wait.

With this proposal, we would have a really nice story about doing FFI
with GHC. I've been playing with DataKinds and other type-related
extensions for a few days (thanks to everyone involved in implementing
them!) and this extension would remove the last glitch:
https://github.com/hsyl20/ViperVM/blob/master/WritingBindings.md
Btw, the Vector part is inspired from what you did here:
https://github.com/expipiplus1/vulkan/pull/1 (thanks!)

Cheers,
Sylvain


2016-03-11 16:51 GMT+01:00 Ben Gamari <ben at well-typed.com>:
> Sylvain Henry <hsyl20 at gmail.com> writes:
>
>> Hi devs,
>>
>> I would like to add the support for the following automatic
>> instance-deriving extension:
>>
> Hi Sylvain,
>
> I suspect the person most qualified to answer these questions will be
> Simon who is currently in the middle of paper-writing season.
> Consequently, it may be a while until he is able to answer. That being
> said, I'm quite happy to hear that someone is thinking about these
> proposals.
>
> Cheers,
>
> - Ben
>

From conal at conal.net  Fri Mar 11 21:49:48 2016
From: conal at conal.net (Conal Elliott)
Date: Fri, 11 Mar 2016 13:49:48 -0800
Subject: Disappearing case alternative?
Message-ID: <CAD6SzRJarg6QdsWygcKkhLTqijg8FTGSc-Mp54u5yysbpcvxkg@mail.gmail.com>

I'm working on a GHC plugin, mainly in the form of a "builtin" rewrite
rule, and I'm seeing a strange disappearance of a case alternative. With
-ddump-rule-rewrites, I can see before & after the disappearance: Here's
one rule firing with the alternative present:

    Rule fired
        Rule: reify
        Before: reifyP
                  TyArg Pair Int -> Int
                  ValArg \ (ds :: Pair Int) ->
                           case ds of _ { :# a b -> $fNumInt_$c+ a b }
        After:  lamP
                  @ (Pair Int)
                  @ Int
                  "ds"#
                  (\ (ds :: EP (Pair Int)) ->
                     reifyP
                       @ Int
                       (case evalP @ (Pair Int) ds of _ { :# a b ->
$fNumInt_$c+ a b }))
        Cont:   StrictArg toE
                Stop[BoringCtxt] E Prim (Pair Int -> Int)

The next thing I see is the rule firing again on the residual reifyP
application, but with the case alternative gone:

    Rule fired
        Rule: reify
        Before: reifyP
                  TyArg Int ValArg case evalP @ (Pair Int) ds of wild { }
        After:  ...

Any ideas what's causing the disappearance?

Thanks.  - Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160311/1521b1c9/attachment-0001.html>

From omeragacan at gmail.com  Sat Mar 12 00:06:11 2016
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Fri, 11 Mar 2016 19:06:11 -0500
Subject: Disappearing case alternative?
In-Reply-To: <CAD6SzRJarg6QdsWygcKkhLTqijg8FTGSc-Mp54u5yysbpcvxkg@mail.gmail.com>
References: <CAD6SzRJarg6QdsWygcKkhLTqijg8FTGSc-Mp54u5yysbpcvxkg@mail.gmail.com>
Message-ID: <CAMQQO3kOwGXW3OMUfVxcyuErmWU0dybeNEz4cw+_Cnr+9yRXeg@mail.gmail.com>

Empty case expressions like `case evalP @ (Pair Int) ds of wild { }` are only
valid if the scrutinee is bottom, see CoreLint.hs for how exprIsBottom is used
and CoreUtils.hs for how it's defined. So it seems like the simplifier somehow
figured that `evalP @ (Pair Int) ds` is bottom, and generated an empty case.

Is the linter complaining about this case expression? (you can try it using
CoreLint.lintExpr)

2016-03-11 16:49 GMT-05:00 Conal Elliott <conal at conal.net>:
>
> I'm working on a GHC plugin, mainly in the form of a "builtin" rewrite rule,
> and I'm seeing a strange disappearance of a case alternative. With
> -ddump-rule-rewrites, I can see before & after the disappearance: Here's one
> rule firing with the alternative present:
>
>     Rule fired
>         Rule: reify
>         Before: reifyP
>                   TyArg Pair Int -> Int
>                   ValArg \ (ds :: Pair Int) ->
>                            case ds of _ { :# a b -> $fNumInt_$c+ a b }
>         After:  lamP
>                   @ (Pair Int)
>                   @ Int
>                   "ds"#
>                   (\ (ds :: EP (Pair Int)) ->
>                      reifyP
>                        @ Int
>                        (case evalP @ (Pair Int) ds of _ { :# a b ->
> $fNumInt_$c+ a b }))
>         Cont:   StrictArg toE
>                 Stop[BoringCtxt] E Prim (Pair Int -> Int)
>
> The next thing I see is the rule firing again on the residual reifyP
> application, but with the case alternative gone:
>
>     Rule fired
>         Rule: reify
>         Before: reifyP
>                   TyArg Int ValArg case evalP @ (Pair Int) ds of wild { }
>         After:  ...
>
> Any ideas what's causing the disappearance?
>
> Thanks.  - Conal
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From conal at conal.net  Sun Mar 13 03:55:53 2016
From: conal at conal.net (Conal Elliott)
Date: Sat, 12 Mar 2016 19:55:53 -0800
Subject: Disappearing case alternative?
In-Reply-To: <CAMQQO3kOwGXW3OMUfVxcyuErmWU0dybeNEz4cw+_Cnr+9yRXeg@mail.gmail.com>
References: <CAD6SzRJarg6QdsWygcKkhLTqijg8FTGSc-Mp54u5yysbpcvxkg@mail.gmail.com>
 <CAMQQO3kOwGXW3OMUfVxcyuErmWU0dybeNEz4cw+_Cnr+9yRXeg@mail.gmail.com>
Message-ID: <CAD6SzRJR+T2Y1YE-8m3dFc=-6mJ7xXfw9TenL1K0EakoJY3nSw@mail.gmail.com>

I think you put your finger on the problem here. That `evalP` is a
placeholder to get transformed away later. I thought that my `NOINLINE`
annotation would prevent GHC from noticing that `evalP` evaluates to
bottom. I'll do a better job.

Thank you!

-- Conal


On Fri, Mar 11, 2016 at 4:06 PM, ?mer Sinan A?acan <omeragacan at gmail.com>
wrote:

> Empty case expressions like `case evalP @ (Pair Int) ds of wild { }` are
> only
> valid if the scrutinee is bottom, see CoreLint.hs for how exprIsBottom is
> used
> and CoreUtils.hs for how it's defined. So it seems like the simplifier
> somehow
> figured that `evalP @ (Pair Int) ds` is bottom, and generated an empty
> case.
>
> Is the linter complaining about this case expression? (you can try it using
> CoreLint.lintExpr)
>
> 2016-03-11 16:49 GMT-05:00 Conal Elliott <conal at conal.net>:
> >
> > I'm working on a GHC plugin, mainly in the form of a "builtin" rewrite
> rule,
> > and I'm seeing a strange disappearance of a case alternative. With
> > -ddump-rule-rewrites, I can see before & after the disappearance: Here's
> one
> > rule firing with the alternative present:
> >
> >     Rule fired
> >         Rule: reify
> >         Before: reifyP
> >                   TyArg Pair Int -> Int
> >                   ValArg \ (ds :: Pair Int) ->
> >                            case ds of _ { :# a b -> $fNumInt_$c+ a b }
> >         After:  lamP
> >                   @ (Pair Int)
> >                   @ Int
> >                   "ds"#
> >                   (\ (ds :: EP (Pair Int)) ->
> >                      reifyP
> >                        @ Int
> >                        (case evalP @ (Pair Int) ds of _ { :# a b ->
> > $fNumInt_$c+ a b }))
> >         Cont:   StrictArg toE
> >                 Stop[BoringCtxt] E Prim (Pair Int -> Int)
> >
> > The next thing I see is the rule firing again on the residual reifyP
> > application, but with the case alternative gone:
> >
> >     Rule fired
> >         Rule: reify
> >         Before: reifyP
> >                   TyArg Int ValArg case evalP @ (Pair Int) ds of wild { }
> >         After:  ...
> >
> > Any ideas what's causing the disappearance?
> >
> > Thanks.  - Conal
> >
> >
> > _______________________________________________
> > 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/20160312/8c53e3b4/attachment.html>

From simonpj at microsoft.com  Mon Mar 14 09:06:58 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 14 Mar 2016 09:06:58 +0000
Subject: Semantics of IORefs in GHC
In-Reply-To: <BN1PR0301MB0756AE9F8459A3ABEA897E04CBB50@BN1PR0301MB0756.namprd03.prod.outlook.com>
References: <BN1PR0301MB0756AE9F8459A3ABEA897E04CBB50@BN1PR0301MB0756.namprd03.prod.outlook.com>
Message-ID: <8754ad5e7ad645959a369df12954cd1e@DB4PR30MB030.064d.mgd.msft.net>

Maclan

I?m glad you enjoyed the awkward squad paper.

I urge you to write to the Haskell Caf? mailing list and/or ghc-devs.  Lots of smart people there.  Ryan Newton is working on this kind of stuff; I?ve cc?d him.

But my rough answer would be: IORefs are really only meant for single-threaded work.  Use STM for concurrent communication.

That?s not to say that we are done!  The Haskell community doesn?t have many people like you, who care about the detail of the memory model.  So please do help us :).   For example, perhaps we could guarantee a simple sequential memory model without much additional cost?

Simon

From: Madan Musuvathi
Sent: 11 March 2016 19:35
To: Simon Peyton Jones <simonpj at microsoft.com>
Subject: Semantics of IORefs in GHC

Dear Simon,
I really enjoyed reading your awkward squad paper<http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/mark.pdf>. Thank you for writing such an accessible paper.

My current understanding is that the implementation of IORefs in GHC breaks the simple semantics you develop in this paper. In particular, by not inserting sufficient fences around reads and writes of IORefs, a Haskell program is exposed to the weak-memory-consistency effects of the underlying hardware and possibly the backend C compiler. As a result, the monadic bind operator no longer has the simple semantics of sequential composition. Is my understanding correct?

This is very troublesome as this weaker semantics can lead to unforeseen consequences even in pure functional parts of a program. For example, when a reference to an object is passed through an IORef to another thread, the latter thread is not guaranteed to see the updates of the first thread. So, it is quite possible for some (pure functional) code to be processing objects with broken invariants or partially-constructed objects. In the extreme, this could lead to type-unsafety unless the GHC compiler is taking careful precautions to avoid this. (Many of these problems are unlikely to show up on x86 machines, but will be common on ARM.)

I am sure the GHC community is addressing these problems one way or the other. But, my question is WHY?  Why can?t GHC tighten the semantics of IORefs so that the bind operation simply means sequential composition? Given that Haskell has a clean separation between pure functional parts and ?awkward? parts of the program, the overheads of these fenced IORefs should be acceptable.

My coauthors and I wrote a recent SNAPL article<http://research.microsoft.com/apps/pubs/default.aspx?id=252150> about this problem for other (?less-beautiful? :)) imperative languages like C# and Java. I really believe we should support sequential composition in our programming languages.

madan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160314/773f593e/attachment.html>

From simonpj at microsoft.com  Mon Mar 14 09:10:28 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 14 Mar 2016 09:10:28 +0000
Subject: Fwd: Reducing boilerplate
In-Reply-To: <CAPmptcXYesZST1XiHEzwz5M91CbcMGDT7oniPgMrC1uetkDVLw@mail.gmail.com>
References: <CAPmptcVd1qRaYMMb2VjzJ27CxB-KuOtNUz8Z-E5uXQi4O-b3Fg@mail.gmail.com>
 <CAPmptcVqi5KtJL6gXP3W=sCLRcOuvw4CC0PdOxNnmHr0zj_zsA@mail.gmail.com>
 <87twkdui63.fsf@smart-cactus.org>
 <CAPmptcXYesZST1XiHEzwz5M91CbcMGDT7oniPgMrC1uetkDVLw@mail.gmail.com>
Message-ID: <74bf1aae690a456081d883444083ed3f@DB4PR30MB030.064d.mgd.msft.net>

Great.  Is there a clearly-articulated design on a wiki page?

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Sylvain Henry
|  Sent: 11 March 2016 20:59
|  To: Ben Gamari <ben at well-typed.com>
|  Cc: ghc-devs at haskell.org
|  Subject: Re: Fwd: Reducing boilerplate
|  
|  Hi Ben,
|  
|  Thanks for your answer. No problem, I can wait.
|  
|  With this proposal, we would have a really nice story about doing FFI
|  with GHC. I've been playing with DataKinds and other type-related
|  extensions for a few days (thanks to everyone involved in implementing
|  them!) and this extension would remove the last glitch:
|  https://github.com/hsyl20/ViperVM/blob/master/WritingBindings.md
|  Btw, the Vector part is inspired from what you did here:
|  https://github.com/expipiplus1/vulkan/pull/1 (thanks!)
|  
|  Cheers,
|  Sylvain
|  
|  
|  2016-03-11 16:51 GMT+01:00 Ben Gamari <ben at well-typed.com>:
|  > Sylvain Henry <hsyl20 at gmail.com> writes:
|  >
|  >> Hi devs,
|  >>
|  >> I would like to add the support for the following automatic
|  >> instance-deriving extension:
|  >>
|  > Hi Sylvain,
|  >
|  > I suspect the person most qualified to answer these questions will be
|  > Simon who is currently in the middle of paper-writing season.
|  > Consequently, it may be a while until he is able to answer. That
|  being
|  > said, I'm quite happy to hear that someone is thinking about these
|  > proposals.
|  >
|  > Cheers,
|  >
|  > - Ben
|  >
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c8bc41138302f4cc4
|  696e08d349efffd6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=hSoMQAHQ8
|  E5aWPa%2fK8FXsKcKoUUn7Xv6%2ftpaEX0%2b01M%3d

From ben at well-typed.com  Mon Mar 14 09:50:58 2016
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 14 Mar 2016 10:50:58 +0100
Subject: Fwd: Reducing boilerplate
In-Reply-To: <74bf1aae690a456081d883444083ed3f@DB4PR30MB030.064d.mgd.msft.net>
References: <CAPmptcVd1qRaYMMb2VjzJ27CxB-KuOtNUz8Z-E5uXQi4O-b3Fg@mail.gmail.com>
 <CAPmptcVqi5KtJL6gXP3W=sCLRcOuvw4CC0PdOxNnmHr0zj_zsA@mail.gmail.com>
 <87twkdui63.fsf@smart-cactus.org>
 <CAPmptcXYesZST1XiHEzwz5M91CbcMGDT7oniPgMrC1uetkDVLw@mail.gmail.com>
 <74bf1aae690a456081d883444083ed3f@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87oaahv14t.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> Great.  Is there a clearly-articulated design on a wiki page?
>
The design for the relevant GHC extension is here [1].

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160314/9abcb164/attachment.sig>

From thomasmiedema at gmail.com  Mon Mar 14 11:08:37 2016
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Mon, 14 Mar 2016 12:08:37 +0100
Subject: Loading GHC into GHCi (reprise)
In-Reply-To: <87fuvzwlgg.fsf@smart-cactus.org>
References: <20160309132850.6f6a7dfe041020c8098e195f@mega-nerd.com>
 <87fuvzwlgg.fsf@smart-cactus.org>
Message-ID: <CAD3WKghd5xi6A-OKGUUCUFN8xJBqisg0A3Diu-4SyzTfyj2ZaQ@mail.gmail.com>

On Wed, Mar 9, 2016 at 7:33 PM, Ben Gamari <ben at well-typed.com> wrote:
>
> Unfortunately -fobject-code is necessary when loading GHC in GHCi as the
> bytecode interpreter doesn't support unboxed tuples, which various GHC
> modules use.
>

There's a ticket for that: https://ghc.haskell.org/trac/ghc/ticket/1257
("Bytecode generator can't handle unboxed tuples"). Fixing that would make
it much easier to use GHCi to load the compiler, and allow setting
breakpoints, make a change and use `:r` to reload etc. The ticket is closed
as wontfix however.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160314/5d51b222/attachment.html>

From rrnewton at gmail.com  Mon Mar 14 13:37:21 2016
From: rrnewton at gmail.com (Ryan Newton)
Date: Mon, 14 Mar 2016 14:37:21 +0100
Subject: Semantics of IORefs in GHC
In-Reply-To: <8754ad5e7ad645959a369df12954cd1e@DB4PR30MB030.064d.mgd.msft.net>
References: <BN1PR0301MB0756AE9F8459A3ABEA897E04CBB50@BN1PR0301MB0756.namprd03.prod.outlook.com>
 <8754ad5e7ad645959a369df12954cd1e@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CACYs5AZWFj+kiH_=u1_KW4kCF2tFx=wFg+piK8fYDk0w8QQDpw@mail.gmail.com>

Hi Madan,

Yes, GHC, like Java, is an "unsafe language" currently ;-).  It does not
protect its abstractions against buggy programs.  Namely both Haskell and
Java do not protect semi-colon/(>>).

Really, we should probably have some additional monad to distinguish
data-race-free (DRF) IO programs from other IO programs that may have data
races.

Or we could just make sequential consistency the law of the land for IO, as
you propose.  One thing I'd really like to work on -- if someone were
interested in collaborating -- is testing the overhead of making sequential
composition the norm in this way.

I had a nice conversation with your SNAPL co-author Satish about this
recently.  It seems like we could survey a broad swath of Haskell code to
see if fine-grained use of "writeIORef" and "readIORef" are at all common.
My hunch is that IORefs used in concurrent apps (web servers, etc), all use
atomicModifyIORef anyway.

Thus like you I think we could fence read/writeIORef with acceptable perf
for most real apps.  You can still have "reallyUnsafeReadIORef" for
specific purposes like implementing concurrent data structures.

Best,
 -Ryan



On Mon, Mar 14, 2016 at 10:06 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Maclan
>
>
>
> I?m glad you enjoyed the awkward squad paper.
>
>
>
> I urge you to write to the Haskell Caf? mailing list and/or ghc-devs.
> Lots of smart people there.  Ryan Newton is working on this kind of stuff;
> I?ve cc?d him.
>
>
>
> But my rough answer would be: IORefs are really only meant for
> single-threaded work.  Use STM for concurrent communication.
>
>
>
> That?s not to say that we are done!  The Haskell community doesn?t have
> many people like you, who care about the detail of the memory model.  So
> please do help us J.   For example, perhaps we could guarantee a simple
> sequential memory model without much additional cost?
>
>
>
> Simon
>
>
>
> *From:* Madan Musuvathi
> *Sent:* 11 March 2016 19:35
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Subject:* Semantics of IORefs in GHC
>
>
>
> Dear Simon,
>
> I really enjoyed reading your awkward squad paper
> <http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/mark.pdf>.
> Thank you for writing such an accessible paper.
>
>
>
> My current understanding is that the implementation of IORefs in GHC
> breaks the simple semantics you develop in this paper. In particular, by
> not inserting sufficient fences around reads and writes of IORefs, a
> Haskell program is exposed to the weak-memory-consistency effects of the
> underlying hardware and possibly the backend C compiler. As a result, the
> monadic bind operator no longer has the simple semantics of sequential
> composition. Is my understanding correct?
>
>
>
> This is very troublesome as this weaker semantics can lead to unforeseen
> consequences even in pure functional parts of a program. For example, when
> a reference to an object is passed through an IORef to another thread, the
> latter thread is not guaranteed to see the updates of the first thread. So,
> it is quite possible for some (pure functional) code to be processing
> objects with broken invariants or partially-constructed objects. In the
> extreme, this could lead to type-unsafety unless the GHC compiler is taking
> careful precautions to avoid this. (Many of these problems are unlikely to
> show up on x86 machines, but will be common on ARM.)
>
>
>
> I am sure the GHC community is addressing these problems one way or the
> other. But, my question is WHY?  Why can?t GHC tighten the semantics of
> IORefs so that the bind operation simply means sequential composition?
> Given that Haskell has a clean separation between pure functional parts and
> ?awkward? parts of the program, the overheads of these fenced IORefs should
> be acceptable.
>
>
>
> My coauthors and I wrote a recent SNAPL article
> <http://research.microsoft.com/apps/pubs/default.aspx?id=252150> about
> this problem for other (?less-beautiful? J) imperative languages like C#
> and Java. I really believe we should support sequential composition in our
> programming languages.
>
>
>
> madan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160314/a2c407b3/attachment.html>

From benl at ouroborus.net  Mon Mar 14 13:38:47 2016
From: benl at ouroborus.net (Ben Lippmeier)
Date: Tue, 15 Mar 2016 00:38:47 +1100
Subject: Semantics of IORefs in GHC
In-Reply-To: <8754ad5e7ad645959a369df12954cd1e@DB4PR30MB030.064d.mgd.msft.net>
References: <BN1PR0301MB0756AE9F8459A3ABEA897E04CBB50@BN1PR0301MB0756.namprd03.prod.outlook.com>
 <8754ad5e7ad645959a369df12954cd1e@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <3F6D0BDD-CD1D-419A-9521-CFA4C85DAC6F@ouroborus.net>


> On 14 Mar 2016, at 8:06 pm, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> But my rough answer would be: IORefs are really only meant for single-threaded work.  Use STM for concurrent communication.

You can also use atomicModifyIORef for simple things. 


> Why can?t GHC tighten the semantics of IORefs so that the bind operation simply means sequential composition?

Part of the problem is that IO encomposes all sorts of computational effects, including ones that don?t have a well defined notion of time. File and network effects are also a problem, not just IORefs. The IO instance of bind composes two IO computations, but the computations themselves could do anything.

A first step is to split the IO type into more fine grained effects, perhaps ones that can be properly sequentialized and those which can?t (or should not be). Many people have done work on more expressive effect systems, though no system so far has been good enough to want to refactor the GHC base libraries using it.

On a more philosophical level, Haskell types are statements in a simple predicate logic which does not natively know anything about time. Functions don?t know about time either, so it?s a bit odd to ask a functional operator to do something sequential (at least relative to the real world). In the ?awkward squad? paper note that the functional encoding of the bind operator *passes* the world from one place to another -- it is not part of the world, and does not act upon the world itself.

In recent work on effect systems there are a lot of embeddings of modal logics into the ambient Haskell/predicate logic, and the embeddings then suffer an encoding overhead. AFAIK the future lies in type systems that natively express temporal concepts, rather than needing tricky encodings of them, but we?re not there yet.

Ben.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160315/7c56919f/attachment.html>

From andrew.thaddeus at gmail.com  Mon Mar 14 18:40:28 2016
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Mon, 14 Mar 2016 14:40:28 -0400
Subject: VisibleTypeApplication and AllowAmbiguousTypes
Message-ID: <CABNC7eNwd8oxicWKooD0hVmTmXcEg53sbQh46UFbPomOHdB=cg@mail.gmail.com>

I'm posting this because Richard said it would be the best place to raise
this issue. I know it's a little bit late in the GHC8 development process,
but I would like to get the idea out there.

To my knowledge, in GHC8, turning on VisibleTypeApplication will also turn
on AllowAmbiguousTypes. I think that a better behavior for most end users
would be to not have this happen.

I need AllowAmbiguousTypes turned on in modules where I want to declare
functions that are presently uncalled. At a call site though, I only need
VisibleTypeApplication, not both extensions. The only reason I bring this
up is because having AllowAmbiguousTypes on is usually bad. It makes it
possible to write functions that don't work, but you don't learn that until
you get to the call site. If I write libraries that require
VisibleTypeAppliaction to call certain functions, I don't want users
accidentally ending up turning on AllowAmbiguousTypes in their own code.

-- 
-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160314/a77f352a/attachment.html>

From ben at smart-cactus.org  Tue Mar 15 13:16:39 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 15 Mar 2016 14:16:39 +0100
Subject: VisibleTypeApplication and AllowAmbiguousTypes
In-Reply-To: <CABNC7eNwd8oxicWKooD0hVmTmXcEg53sbQh46UFbPomOHdB=cg@mail.gmail.com>
References: <CABNC7eNwd8oxicWKooD0hVmTmXcEg53sbQh46UFbPomOHdB=cg@mail.gmail.com>
Message-ID: <87h9g7vq2w.fsf@smart-cactus.org>

Andrew Martin <andrew.thaddeus at gmail.com> writes:

> I'm posting this because Richard said it would be the best place to raise
> this issue. I know it's a little bit late in the GHC8 development process,
> but I would like to get the idea out there.
>
> To my knowledge, in GHC8, turning on VisibleTypeApplication will also turn
> on AllowAmbiguousTypes. I think that a better behavior for most end users
> would be to not have this happen.
>
> I need AllowAmbiguousTypes turned on in modules where I want to declare
> functions that are presently uncalled. At a call site though, I only need
> VisibleTypeApplication, not both extensions. The only reason I bring this
> up is because having AllowAmbiguousTypes on is usually bad. It makes it
> possible to write functions that don't work, but you don't learn that until
> you get to the call site. If I write libraries that require
> VisibleTypeAppliaction to call certain functions, I don't want users
> accidentally ending up turning on AllowAmbiguousTypes in their own code.
>
It sounds reasonable to me to require that those defining
functions to be used with type application enable AllowAmbiguousTypes.
In my opinion we should avoid adding extension implications unless
the extensions in question are essentially always used together and this
doesn't appear to be true in the case of TypeApplications and
AllowAmbiguousTypes.

Cheers,
- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160315/7d1573bc/attachment.sig>

From eir at cis.upenn.edu  Tue Mar 15 14:53:53 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 15 Mar 2016 10:53:53 -0400
Subject: VisibleTypeApplication and AllowAmbiguousTypes
In-Reply-To: <87h9g7vq2w.fsf@smart-cactus.org>
References: <CABNC7eNwd8oxicWKooD0hVmTmXcEg53sbQh46UFbPomOHdB=cg@mail.gmail.com>
 <87h9g7vq2w.fsf@smart-cactus.org>
Message-ID: <684912C1-5971-474C-8CBA-8E4611892305@cis.upenn.edu>

I'm happy to change the setting, but my logic was this: With -XTypeApplications, there are no ambiguous types. Of course, there may be types that are unambiguous locally but might be ambiguous in downstream modules that don't use -XTypeApplications, and this is what Andrew is (quite validly) getting at.

Richard

On Mar 15, 2016, at 9:16 AM, Ben Gamari <ben at smart-cactus.org> wrote:

> Andrew Martin <andrew.thaddeus at gmail.com> writes:
> 
>> I'm posting this because Richard said it would be the best place to raise
>> this issue. I know it's a little bit late in the GHC8 development process,
>> but I would like to get the idea out there.
>> 
>> To my knowledge, in GHC8, turning on VisibleTypeApplication will also turn
>> on AllowAmbiguousTypes. I think that a better behavior for most end users
>> would be to not have this happen.
>> 
>> I need AllowAmbiguousTypes turned on in modules where I want to declare
>> functions that are presently uncalled. At a call site though, I only need
>> VisibleTypeApplication, not both extensions. The only reason I bring this
>> up is because having AllowAmbiguousTypes on is usually bad. It makes it
>> possible to write functions that don't work, but you don't learn that until
>> you get to the call site. If I write libraries that require
>> VisibleTypeAppliaction to call certain functions, I don't want users
>> accidentally ending up turning on AllowAmbiguousTypes in their own code.
>> 
> It sounds reasonable to me to require that those defining
> functions to be used with type application enable AllowAmbiguousTypes.
> In my opinion we should avoid adding extension implications unless
> the extensions in question are essentially always used together and this
> doesn't appear to be true in the case of TypeApplications and
> AllowAmbiguousTypes.
> 
> Cheers,
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From adam at well-typed.com  Tue Mar 15 20:11:15 2016
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 15 Mar 2016 20:11:15 +0000
Subject: VisibleTypeApplication and AllowAmbiguousTypes
In-Reply-To: <684912C1-5971-474C-8CBA-8E4611892305@cis.upenn.edu>
References: <CABNC7eNwd8oxicWKooD0hVmTmXcEg53sbQh46UFbPomOHdB=cg@mail.gmail.com>
 <87h9g7vq2w.fsf@smart-cactus.org>
 <684912C1-5971-474C-8CBA-8E4611892305@cis.upenn.edu>
Message-ID: <56E86C63.6070605@well-typed.com>

On 15/03/16 14:53, Richard Eisenberg wrote:
> I'm happy to change the setting, but my logic was this: With
> -XTypeApplications, there are no ambiguous types. Of course, there
> may be types that are unambiguous locally but might be ambiguous in
> downstream modules that don't use -XTypeApplications, and this is
> what Andrew is (quite validly) getting at.

Yes. I think the key point here is that TypeApplications is typically
required at use sites, whereas AllowAmbiguousTypes is needed at
definition sites.

AllowAmbiguousTypes is a heuristic: ambiguity can arise without it, and
even before TypeApplications there were cases in which
AllowAmbiguousTypes was necessary to permit polymorphic definitions that
could be used unambiguously in some contexts. With TypeApplications, any
definition can be used given a suitable context, but ambiguity is still
a useful rule for deciding whether a definition is likely to lead to
type inference trouble.

TL;DR I agree that we should drop the implication.

All the best,

Adam


> Richard
> 
> On Mar 15, 2016, at 9:16 AM, Ben Gamari <ben at smart-cactus.org>
> wrote:
> 
>> Andrew Martin <andrew.thaddeus at gmail.com> writes:
>> 
>>> I'm posting this because Richard said it would be the best place
>>> to raise this issue. I know it's a little bit late in the GHC8
>>> development process, but I would like to get the idea out there.
>>> 
>>> To my knowledge, in GHC8, turning on VisibleTypeApplication will
>>> also turn on AllowAmbiguousTypes. I think that a better behavior
>>> for most end users would be to not have this happen.
>>> 
>>> I need AllowAmbiguousTypes turned on in modules where I want to
>>> declare functions that are presently uncalled. At a call site
>>> though, I only need VisibleTypeApplication, not both extensions.
>>> The only reason I bring this up is because having
>>> AllowAmbiguousTypes on is usually bad. It makes it possible to
>>> write functions that don't work, but you don't learn that until 
>>> you get to the call site. If I write libraries that require 
>>> VisibleTypeAppliaction to call certain functions, I don't want
>>> users accidentally ending up turning on AllowAmbiguousTypes in
>>> their own code.
>>> 
>> It sounds reasonable to me to require that those defining functions
>> to be used with type application enable AllowAmbiguousTypes. In my
>> opinion we should avoid adding extension implications unless the
>> extensions in question are essentially always used together and
>> this doesn't appear to be true in the case of TypeApplications and 
>> AllowAmbiguousTypes.
>> 
>> Cheers, - Ben



-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From matthewtpickering at gmail.com  Tue Mar 15 21:13:11 2016
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Tue, 15 Mar 2016 21:13:11 +0000
Subject: Syntax changes due to TypeInType
Message-ID: <CALuQ0m-bvU=JKHu2psiWfh=hn4D=T2z3o=iSVXxCDo_dV82DjA@mail.gmail.com>

Hello,

I'm trying to update the haskell-src-exts parser for the syntax
changes in GHC 8 but I'm struggling to find information about what
exactly the kind equalities patch has changed. Could someone please
give me a brief overview about what changes were made to the parser?

I was waiting for the manual entry (D1995) but whilst it is
illuminating about the semantic changes, the syntactic changes are a
bit less clear to me.

A very high-level overview would be helpful so I can then look at the
diff to find the finer details.

Matt

From eir at cis.upenn.edu  Wed Mar 16 01:16:46 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 15 Mar 2016 21:16:46 -0400
Subject: Syntax changes due to TypeInType
In-Reply-To: <CALuQ0m-bvU=JKHu2psiWfh=hn4D=T2z3o=iSVXxCDo_dV82DjA@mail.gmail.com>
References: <CALuQ0m-bvU=JKHu2psiWfh=hn4D=T2z3o=iSVXxCDo_dV82DjA@mail.gmail.com>
Message-ID: <5602576A-5D75-462C-9E7F-7E454A21EE78@cis.upenn.edu>

The TypeInType patch did relatively little to the abstract syntax. HsImplicitBndrs no longer separates type variables and kind variables. And there was some major surgery to the type/kind parser (discussed below). It's that last bit that you probably want to know about. But check out https://phabricator.haskell.org/rGHC6746549772c5cc0ac66c0fce562f297f4d4b80a2 and you'll see that not much changed.

The "major surgery" to the parser is concerned solely with parsing *. Because the kind * is parsed like an alphanumeric identifier and the type * is parsed like an infix operator, and because types and kinds have to share a parser, we can't use the old HsOpTy story. Instead, we essentially parse a bunch of space-separated tokens in a type as a list, stored in HsAppsTy. Then, in the renamer, once we know which * we're dealing with, we can get rid of HsAppsTy and go on with HsOpTy, etc., as usual. That's really it. There may be improvements possible to this scheme -- I'm far from wedded to it.

The bigger change in the syntax since GHC 7.10 is Simon's wildcard refactor, https://phabricator.haskell.org/rGHC1e041b7382b6aa329e4ad9625439f811e0f27232   The new story is quite well explained in a Note, starting at https://github.com/ghc/ghc/blob/master/compiler/hsSyn/HsTypes.hs#L137

There is also the addition of visible type application, but that's just two new constructor in HsExpr, HsAppType/HsAppTypeOut. I believe it's straightforward.

Are there other particular points giving you challenge?

Richard

On Mar 15, 2016, at 5:13 PM, Matthew Pickering <matthewtpickering at gmail.com> wrote:

> Hello,
> 
> I'm trying to update the haskell-src-exts parser for the syntax
> changes in GHC 8 but I'm struggling to find information about what
> exactly the kind equalities patch has changed. Could someone please
> give me a brief overview about what changes were made to the parser?
> 
> I was waiting for the manual entry (D1995) but whilst it is
> illuminating about the semantic changes, the syntactic changes are a
> bit less clear to me.
> 
> A very high-level overview would be helpful so I can then look at the
> diff to find the finer details.
> 
> Matt
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From mail at joachim-breitner.de  Thu Mar 17 12:16:19 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 17 Mar 2016 13:16:19 +0100
Subject: Updatable, single entry, one-short thunks and lambda
Message-ID: <1458216979.5080.46.camel@joachim-breitner.de>

Dear list,

in the literature, the code and the comments, I often find these
notions:
?* updatable
?* single-entry
?* one-shot
applied to thunks, functions, closures and lambda expressions on
various levels

I have the impression that these are indeed plain synonyms (resp.
antinyms) when it comes to thunks and other closures, and indicate
whether a dynamic instance of this closure is going to be entered once
or more than once, while "one-shot", when applied to a lambda
expression (or, by extension function argument), indicates that this
lambda expression is _called_ at most once for every _evaluation_ of
it.

Is that about right, or are there more pitfalls around?

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-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/20160317/11f310e5/attachment.sig>

From mail at joachim-breitner.de  Thu Mar 17 13:54:26 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 17 Mar 2016 14:54:26 +0100
Subject: Updatable, single entry, one-short thunks and lambda
In-Reply-To: <1458216979.5080.46.camel@joachim-breitner.de>
References: <1458216979.5080.46.camel@joachim-breitner.de>
Message-ID: <1458222866.5080.57.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 17.03.2016, 13:16 +0100 schrieb Joachim Breitner:
> in the literature, the code and the comments, I often find these
> notions:
> ?* updatable
> ?* single-entry
> ?* one-shot
> applied to thunks, functions, closures and lambda expressions on
> various levels
> 
> I have the impression that these are indeed plain synonyms (resp.
> antinyms) when it comes to thunks and other closures, and indicate
> whether a dynamic instance of this closure is going to be entered once
> or more than once.

More code reading? indicates that updatable and single-entry are
antinyms for Thunks, but other closures are always "not updatable" and
"not (necessarily) single entry".

Greetings,
Joachim

??closureUpdReqd and closureSingleEntry in?StgCmmClosure.


-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-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/20160317/2655f52f/attachment.sig>

From simonpj at microsoft.com  Thu Mar 17 17:41:22 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 17 Mar 2016 17:41:22 +0000
Subject: Updatable, single entry, one-short thunks and lambda
In-Reply-To: <1458216979.5080.46.camel@joachim-breitner.de>
References: <1458216979.5080.46.camel@joachim-breitner.de>
Message-ID: <6f240766ba704e73b94d9bc366c6732b@DB4PR30MB030.064d.mgd.msft.net>

Updatable
- is it updated after its value has been computed?
- thunks only
- a non-updatable thunk will effectively be call-by-name,
  so it should either be cheap or single-entry
  

Single-entry
- is it entered (called) once or zero times?
- thunks or functions

One-shot: same as single-entry


|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Joachim Breitner
|  Sent: 17 March 2016 12:16
|  To: GHC developers <ghc-devs at haskell.org>
|  Subject: Updatable, single entry, one-short thunks and lambda
|  
|  Dear list,
|  
|  in the literature, the code and the comments, I often find these
|  notions:
|  ?* updatable
|  ?* single-entry
|  ?* one-shot
|  applied to thunks, functions, closures and lambda expressions on
|  various levels
|  
|  I have the impression that these are indeed plain synonyms (resp.
|  antinyms) when it comes to thunks and other closures, and indicate
|  whether a dynamic instance of this closure is going to be entered once
|  or more than once, while "one-shot", when applied to a lambda
|  expression (or, by extension function argument), indicates that this
|  lambda expression is _called_ at most once for every _evaluation_ of
|  it.
|  
|  Is that about right, or are there more pitfalls around?
|  
|  Greetings,
|  Joachim
|  
|  
|  --
|  Joachim ?nomeata? Breitner
|  ? mail at joachim-breitner.de ?
|  https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.jo
|  achim-
|  breitner.de%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd7df37
|  ec4e6f406c455808d34e5df68b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata
|  =pigxxB7cDKt7AZbAUOHHK17%2bqcvJAXtmErf6HJPHCFs%3d
|  ? XMPP: nomeata at joachim-breitner.de?? OpenPGP-Key: 0xF0FBF51F
|  ? Debian Developer: nomeata at debian.org


From david.feuer at gmail.com  Fri Mar 18 21:25:46 2016
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 18 Mar 2016 17:25:46 -0400
Subject: Could we promote unlifted tuples?
Message-ID: <CAMgWh9tXer3Z3B4SS2vCXaC-=+6dPH5ANi2grPQ7C_asFMHnaw@mail.gmail.com>

At present, currying and uncurrying at the type level doesn't seem to
work terribly well. In particular, the kinds

(a, b) -> c

and

a -> b -> c

aren't really isomorphic, because (a, b) can be stuck. This makes some
things (like expressing Atkey-style indexed functors in terms of
McBride-style ones) rather awkward, and difficult or impossible to
really get quite right. The thought came to me that maybe we could
allow unlifted tuples to be promoted. Then something of the kind (# a,
b #) would unconditionally unify with '(# a, b #). The restrictions on
how values of unlifted tuple types can be used would presumably
translate directly to restrictions on how types of unlifted tuple kind
can be used.

David Feuer

From asr at eafit.edu.co  Sun Mar 20 02:16:34 2016
From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Sat, 19 Mar 2016 21:16:34 -0500
Subject: Issue using StrictData
Message-ID: <CAOUWSGA_QR+cPYJdngiKiNiPAx1KFFH5uW+qhLsXVibA=fT4Xw@mail.gmail.com>

Hi,

I know this isn't a convenient issue report because the "test case"
isn't easily reproducible. Since I don't understand the issue, I don't
know how to create a smaller test case, sorry.

My OS is Ubuntu 12-04 (64 bits) and I'm using the following programs:

Agda master branch on commit

  https://github.com/agda/agda/commit/181a954a40b137c8deb1df801a8ee55fdbc19116

GHC ghc-8.0 branch on commit

  https://git.haskell.org/ghc.git/commit/a96933017470d03a1c9414c9c90dfd5c0f0903ed

  $ cabal --version
  cabal-install version 1.23.0.0
  compiled using version 1.23.1.0 of the Cabal library

(compiled with GHC 7.10.3)

  $ alex --version
  Alex version 3.1.7, (c) 2003 Chris Dornan and Simon Marlow

  $ happy --version
  Happy Version 1.19.5 Copyright (c) 1993-1996 Andy Gill, Simon Marlow
(c) 1997-2005 Simon Marlow

After adding `extensions: StrictData` to Agda.cabal, I'm getting the
following errors:

  $ cabal install
  ...
  Installing library in
  /home/asr/.cabal/lib/x86_64-linux-ghc-8.0.0.20160316/Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU
  Installing executable(s) in /home/asr/.cabal/bin
  Generating Agda library interface files...
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Primitive!
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Builtin.Bool!
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Builtin.Char!
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Builtin.Coinduction!
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Builtin.Equality!
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Builtin.Float!
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Builtin.FromNat!
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Builtin.FromNeg!
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Builtin.FromString!
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Builtin.IO!
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Builtin.Int!
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Builtin.List!
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Builtin.Nat!
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Builtin.Reflection!
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Builtin.Size!
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Builtin.Strict!
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Builtin.String!
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Builtin.TrustMe!
  agda: Internal Happy error

  CallStack (from HasCallStack):
    error, called at templates/GenericTemplate.hs:288:17 in
Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
  WARNING: Failed to typecheck Agda.Builtin.Unit!
  Registering Agda-2.5.0...
  cabal: Leaving directory '.'
  Installed Agda-2.5.0

Best,

-- 
Andr?s

From rwbarton at gmail.com  Sun Mar 20 02:46:13 2016
From: rwbarton at gmail.com (Reid Barton)
Date: Sat, 19 Mar 2016 22:46:13 -0400
Subject: Issue using StrictData
In-Reply-To: <CAOUWSGA_QR+cPYJdngiKiNiPAx1KFFH5uW+qhLsXVibA=fT4Xw@mail.gmail.com>
References: <CAOUWSGA_QR+cPYJdngiKiNiPAx1KFFH5uW+qhLsXVibA=fT4Xw@mail.gmail.com>
Message-ID: <CADmwj45GRNg=aR5idk0K9qjt-kTNF7F5K=hnQuYJoz7YZTniaQ@mail.gmail.com>

Hi,

`extensions: StrictData` turns on the StrictData extension for all modules
in the program. So every field of every data type defined in every module
is made strict. Is that really what you wanted? For a large, complicated
program like Agda, It seems about as likely to work as just passing the
program into an ML compiler unmodified. Your errors are a typical example:
note they are runtime errors from a generated happy parser, which probably
does something like initializing a record with (error "Internal Happy
error") and then trying to update it with record update syntax.

I'm guessing you meant `other-extensions: StrictData`.

Regards,
Reid Barton

On Sat, Mar 19, 2016 at 10:16 PM, Andr?s Sicard-Ram?rez <asr at eafit.edu.co>
wrote:

> Hi,
>
> I know this isn't a convenient issue report because the "test case"
> isn't easily reproducible. Since I don't understand the issue, I don't
> know how to create a smaller test case, sorry.
>
> My OS is Ubuntu 12-04 (64 bits) and I'm using the following programs:
>
> Agda master branch on commit
>
>
> https://github.com/agda/agda/commit/181a954a40b137c8deb1df801a8ee55fdbc19116
>
> GHC ghc-8.0 branch on commit
>
>
> https://git.haskell.org/ghc.git/commit/a96933017470d03a1c9414c9c90dfd5c0f0903ed
>
>   $ cabal --version
>   cabal-install version 1.23.0.0
>   compiled using version 1.23.1.0 of the Cabal library
>
> (compiled with GHC 7.10.3)
>
>   $ alex --version
>   Alex version 3.1.7, (c) 2003 Chris Dornan and Simon Marlow
>
>   $ happy --version
>   Happy Version 1.19.5 Copyright (c) 1993-1996 Andy Gill, Simon Marlow
> (c) 1997-2005 Simon Marlow
>
> After adding `extensions: StrictData` to Agda.cabal, I'm getting the
> following errors:
>
>   $ cabal install
>   ...
>   Installing library in
>
> /home/asr/.cabal/lib/x86_64-linux-ghc-8.0.0.20160316/Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU
>   Installing executable(s) in /home/asr/.cabal/bin
>   Generating Agda library interface files...
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Primitive!
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Builtin.Bool!
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Builtin.Char!
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Builtin.Coinduction!
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Builtin.Equality!
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Builtin.Float!
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Builtin.FromNat!
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Builtin.FromNeg!
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Builtin.FromString!
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Builtin.IO!
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Builtin.Int!
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Builtin.List!
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Builtin.Nat!
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Builtin.Reflection!
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Builtin.Size!
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Builtin.Strict!
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Builtin.String!
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Builtin.TrustMe!
>   agda: Internal Happy error
>
>   CallStack (from HasCallStack):
>     error, called at templates/GenericTemplate.hs:288:17 in
> Agda-2.5.0-8eDdWzYvIFd4CKBTUUP6kU:Agda.Syntax.Parser.Parser
>   WARNING: Failed to typecheck Agda.Builtin.Unit!
>   Registering Agda-2.5.0...
>   cabal: Leaving directory '.'
>   Installed Agda-2.5.0
>
> Best,
>
> --
> Andr?s
> _______________________________________________
> 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/20160319/b280f99f/attachment.html>

From asr at eafit.edu.co  Sun Mar 20 02:52:20 2016
From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Sat, 19 Mar 2016 21:52:20 -0500
Subject: Issue using StrictData
In-Reply-To: <CADmwj45GRNg=aR5idk0K9qjt-kTNF7F5K=hnQuYJoz7YZTniaQ@mail.gmail.com>
References: <CAOUWSGA_QR+cPYJdngiKiNiPAx1KFFH5uW+qhLsXVibA=fT4Xw@mail.gmail.com>
 <CADmwj45GRNg=aR5idk0K9qjt-kTNF7F5K=hnQuYJoz7YZTniaQ@mail.gmail.com>
Message-ID: <CAOUWSGCic+XAKJ98OaJy=GRYAFf1kExiZCKD3w9Kw0xj=dq5Nw@mail.gmail.com>

Hi,

On 19 March 2016 at 21:46, Reid Barton <rwbarton at gmail.com> wrote:
> `extensions: StrictData` turns on the StrictData extension for all modules
> in the program. So every field of every data type defined in every module is
> made strict.

I was aware of it.

> Is that really what you wanted?

No really. I added the extension just out curiosity.

> For a large, complicated
> program like Agda, It seems about as likely to work as just passing the
> program into an ML compiler unmodified. Your errors are a typical example:
> note they are runtime errors from a generated happy parser, which probably
> does something like initializing a record with (error "Internal Happy
> error") and then trying to update it with record update syntax.

Thanks you for the explanation.

Best,

-- 
Andr?s

From mail at joachim-breitner.de  Mon Mar 21 13:23:35 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 21 Mar 2016 14:23:35 +0100
Subject: Harbormaster MIA?
Message-ID: <1458566615.1606.33.camel@joachim-breitner.de>

[Re-ending to the list, sorry Austin for the unnecessary private mail.]

Hi,

I?m looking forward to see what Harbormaster thinks of
https://phabricator.haskell.org/D2014
but it seems that no build has been scheduled. What is wrong?

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-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/20160321/80bfb9a0/attachment.sig>

From eir at cis.upenn.edu  Mon Mar 21 20:53:59 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 21 Mar 2016 16:53:59 -0400
Subject: Could we promote unlifted tuples?
In-Reply-To: <CAMgWh9tXer3Z3B4SS2vCXaC-=+6dPH5ANi2grPQ7C_asFMHnaw@mail.gmail.com>
References: <CAMgWh9tXer3Z3B4SS2vCXaC-=+6dPH5ANi2grPQ7C_asFMHnaw@mail.gmail.com>
Message-ID: <42ABDF62-D9D0-4B2F-A73A-372886AABCFF@cis.upenn.edu>

You have made an invalid assumption that there exists a semantics for type-level reduction in Haskell. There doesn't. Without such a well-defined evaluation order, it's hard to talk about lifted kinds vs. unlifted kinds.

Perhaps another way of slicing this exists, though. Does #7259 (https://ghc.haskell.org/trac/ghc/ticket/7259) solve your problem? I think so. Unfortunately, I've listed that as "Rocket Science" on my list of tickets that I'm interested in.

Richard

On Mar 18, 2016, at 5:25 PM, David Feuer <david.feuer at gmail.com> wrote:

> At present, currying and uncurrying at the type level doesn't seem to
> work terribly well. In particular, the kinds
> 
> (a, b) -> c
> 
> and
> 
> a -> b -> c
> 
> aren't really isomorphic, because (a, b) can be stuck. This makes some
> things (like expressing Atkey-style indexed functors in terms of
> McBride-style ones) rather awkward, and difficult or impossible to
> really get quite right. The thought came to me that maybe we could
> allow unlifted tuples to be promoted. Then something of the kind (# a,
> b #) would unconditionally unify with '(# a, b #). The restrictions on
> how values of unlifted tuple types can be used would presumably
> translate directly to restrictions on how types of unlifted tuple kind
> can be used.
> 
> David Feuer
> _______________________________________________
> 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  Mon Mar 21 21:23:45 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 21 Mar 2016 17:23:45 -0400
Subject: VisibleTypeApplication and AllowAmbiguousTypes
In-Reply-To: <56E86C63.6070605@well-typed.com>
References: <CABNC7eNwd8oxicWKooD0hVmTmXcEg53sbQh46UFbPomOHdB=cg@mail.gmail.com>
 <87h9g7vq2w.fsf@smart-cactus.org>
 <684912C1-5971-474C-8CBA-8E4611892305@cis.upenn.edu>
 <56E86C63.6070605@well-typed.com>
Message-ID: <D1715766-3438-4E90-9B69-20A5F4CBC7E1@cis.upenn.edu>

Just to close the loop on this: I have made this change in GHC, and the implication will be dropped in time for 8.0.

Thanks,
Richard

On Mar 15, 2016, at 4:11 PM, Adam Gundry <adam at well-typed.com> wrote:

> On 15/03/16 14:53, Richard Eisenberg wrote:
>> I'm happy to change the setting, but my logic was this: With
>> -XTypeApplications, there are no ambiguous types. Of course, there
>> may be types that are unambiguous locally but might be ambiguous in
>> downstream modules that don't use -XTypeApplications, and this is
>> what Andrew is (quite validly) getting at.
> 
> Yes. I think the key point here is that TypeApplications is typically
> required at use sites, whereas AllowAmbiguousTypes is needed at
> definition sites.
> 
> AllowAmbiguousTypes is a heuristic: ambiguity can arise without it, and
> even before TypeApplications there were cases in which
> AllowAmbiguousTypes was necessary to permit polymorphic definitions that
> could be used unambiguously in some contexts. With TypeApplications, any
> definition can be used given a suitable context, but ambiguity is still
> a useful rule for deciding whether a definition is likely to lead to
> type inference trouble.
> 
> TL;DR I agree that we should drop the implication.
> 
> All the best,
> 
> Adam
> 
> 
>> Richard
>> 
>> On Mar 15, 2016, at 9:16 AM, Ben Gamari <ben at smart-cactus.org>
>> wrote:
>> 
>>> Andrew Martin <andrew.thaddeus at gmail.com> writes:
>>> 
>>>> I'm posting this because Richard said it would be the best place
>>>> to raise this issue. I know it's a little bit late in the GHC8
>>>> development process, but I would like to get the idea out there.
>>>> 
>>>> To my knowledge, in GHC8, turning on VisibleTypeApplication will
>>>> also turn on AllowAmbiguousTypes. I think that a better behavior
>>>> for most end users would be to not have this happen.
>>>> 
>>>> I need AllowAmbiguousTypes turned on in modules where I want to
>>>> declare functions that are presently uncalled. At a call site
>>>> though, I only need VisibleTypeApplication, not both extensions.
>>>> The only reason I bring this up is because having
>>>> AllowAmbiguousTypes on is usually bad. It makes it possible to
>>>> write functions that don't work, but you don't learn that until 
>>>> you get to the call site. If I write libraries that require 
>>>> VisibleTypeAppliaction to call certain functions, I don't want
>>>> users accidentally ending up turning on AllowAmbiguousTypes in
>>>> their own code.
>>>> 
>>> It sounds reasonable to me to require that those defining functions
>>> to be used with type application enable AllowAmbiguousTypes. In my
>>> opinion we should avoid adding extension implications unless the
>>> extensions in question are essentially always used together and
>>> this doesn't appear to be true in the case of TypeApplications and 
>>> AllowAmbiguousTypes.
>>> 
>>> Cheers, - Ben
> 
> 
> 
> -- 
> Adam Gundry, 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


From mail at joachim-breitner.de  Mon Mar 21 23:05:20 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 22 Mar 2016 00:05:20 +0100
Subject: VisibleTypeApplication and AllowAmbiguousTypes
In-Reply-To: <D1715766-3438-4E90-9B69-20A5F4CBC7E1@cis.upenn.edu>
References: <CABNC7eNwd8oxicWKooD0hVmTmXcEg53sbQh46UFbPomOHdB=cg@mail.gmail.com>
 <87h9g7vq2w.fsf@smart-cactus.org>
 <684912C1-5971-474C-8CBA-8E4611892305@cis.upenn.edu>
 <56E86C63.6070605@well-typed.com>
 <D1715766-3438-4E90-9B69-20A5F4CBC7E1@cis.upenn.edu>
Message-ID: <1458601520.1606.58.camel@joachim-breitner.de>

Hi Richard,

along with this or some other change it seems you broke the test suite
when run with DEBUG:

T2478.hs:1:41: warning:
????-XDatatypeContexts is deprecated: It was widely considered a misfeature, and has been removed from the Haskell language.
ghc-stage2: panic! (the 'impossible' happened)
? (GHC version 8.1.20160321 for x86_64-unknown-linux):
	ASSERT failed!
? CallStack (from HasCallStack):
? assertPprPanic, called at compiler/typecheck/TcType.hs:931:47 in ghc:TcType
? t_ap0

Please report this as a GHC bug:??http://www.haskell.org/ghc/reportabug


*** unexpected failure for T2478(normal)

at least according to travis:
https://s3.amazonaws.com/archive.travis-ci.org/jobs/117548750/log.txt

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-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/20160322/b2d6a49c/attachment.sig>

From eir at cis.upenn.edu  Tue Mar 22 02:45:19 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 21 Mar 2016 22:45:19 -0400
Subject: VisibleTypeApplication and AllowAmbiguousTypes
In-Reply-To: <1458601520.1606.58.camel@joachim-breitner.de>
References: <CABNC7eNwd8oxicWKooD0hVmTmXcEg53sbQh46UFbPomOHdB=cg@mail.gmail.com>
 <87h9g7vq2w.fsf@smart-cactus.org>
 <684912C1-5971-474C-8CBA-8E4611892305@cis.upenn.edu>
 <56E86C63.6070605@well-typed.com>
 <D1715766-3438-4E90-9B69-20A5F4CBC7E1@cis.upenn.edu>
 <1458601520.1606.58.camel@joachim-breitner.de>
Message-ID: <8697ABAA-EA3C-47F8-A05C-77C57F4D37E1@cis.upenn.edu>

Thanks for the heads up. I've pushed my fix to wip/rae and am waiting for Travis to give me the OK.

Richard

On Mar 21, 2016, at 7:05 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:

> Hi Richard,
> 
> along with this or some other change it seems you broke the test suite
> when run with DEBUG:
> 
> T2478.hs:1:41: warning:
>     -XDatatypeContexts is deprecated: It was widely considered a misfeature, and has been removed from the Haskell language.
> ghc-stage2: panic! (the 'impossible' happened)
>   (GHC version 8.1.20160321 for x86_64-unknown-linux):
> 	ASSERT failed!
>   CallStack (from HasCallStack):
>   assertPprPanic, called at compiler/typecheck/TcType.hs:931:47 in ghc:TcType
>   t_ap0
> 
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
> 
> 
> *** unexpected failure for T2478(normal)
> 
> at least according to travis:
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/117548750/log.txt
> 
> Greetings,
> Joachim
> 
> -- 
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? https://www.joachim-breitner.de/
>   XMPP: nomeata at joachim-breitner.de ? OpenPGP-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


From conal at conal.net  Wed Mar 23 00:09:29 2016
From: conal at conal.net (Conal Elliott)
Date: Tue, 22 Mar 2016 17:09:29 -0700
Subject: lookupRdrNameInModuleForPlugins with constructors
Message-ID: <CAD6SzRLJsO3UrsK2wUgCnyMgk1ZCe7Nq9ongF5k8Y0ahgyG5=Q@mail.gmail.com>

I'm trying to construct a dictionary in a GHC plugin. I'm stuck on finding
the constructor for the dictionary. When I use `-ddump-simpl` on the module
that defines the class, I see "Circat.Rep.C:HasRep". To try finding that
constructor, I say

> lookupRdrNameInModuleForPlugins hsc_env
>   (mkModuleName "Circat.Rep") (mkVarUnqual "C:HasRep")

However, I keep getting `Nothing` as a result. (Same without the "C:".)
I've also had this same difficulty when looking up constructors for
algebraic data types and when looking up TyCons. For regular value Ids,
lookup succeeds.

What am I missing?

Thanks, - Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160322/90341fb2/attachment.html>

From xichekolas at gmail.com  Wed Mar 23 00:24:01 2016
From: xichekolas at gmail.com (Andrew Farmer)
Date: Tue, 22 Mar 2016 17:24:01 -0700
Subject: lookupRdrNameInModuleForPlugins with constructors
In-Reply-To: <CAD6SzRLJsO3UrsK2wUgCnyMgk1ZCe7Nq9ongF5k8Y0ahgyG5=Q@mail.gmail.com>
References: <CAD6SzRLJsO3UrsK2wUgCnyMgk1ZCe7Nq9ongF5k8Y0ahgyG5=Q@mail.gmail.com>
Message-ID: <CAJ14jR-eQxcpAYkMW+EDjsDaMGCgENhNPLnD=2bYSaH77Y1UsA@mail.gmail.com>

mkVarUnqual calls mkVarOccFS, which constructs an OccName in the
varName namespace. You need to construct your RdrName via mkTyVarOcc,
which picks the Type/Class namespace.

On Tue, Mar 22, 2016 at 5:09 PM, Conal Elliott <conal at conal.net> wrote:
> I'm trying to construct a dictionary in a GHC plugin. I'm stuck on finding
> the constructor for the dictionary. When I use `-ddump-simpl` on the module
> that defines the class, I see "Circat.Rep.C:HasRep". To try finding that
> constructor, I say
>
>> lookupRdrNameInModuleForPlugins hsc_env
>>   (mkModuleName "Circat.Rep") (mkVarUnqual "C:HasRep")
>
> However, I keep getting `Nothing` as a result. (Same without the "C:".) I've
> also had this same difficulty when looking up constructors for algebraic
> data types and when looking up TyCons. For regular value Ids, lookup
> succeeds.
>
> What am I missing?
>
> Thanks, - Conal
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From xichekolas at gmail.com  Wed Mar 23 00:25:06 2016
From: xichekolas at gmail.com (Andrew Farmer)
Date: Tue, 22 Mar 2016 17:25:06 -0700
Subject: lookupRdrNameInModuleForPlugins with constructors
In-Reply-To: <CAJ14jR-eQxcpAYkMW+EDjsDaMGCgENhNPLnD=2bYSaH77Y1UsA@mail.gmail.com>
References: <CAD6SzRLJsO3UrsK2wUgCnyMgk1ZCe7Nq9ongF5k8Y0ahgyG5=Q@mail.gmail.com>
 <CAJ14jR-eQxcpAYkMW+EDjsDaMGCgENhNPLnD=2bYSaH77Y1UsA@mail.gmail.com>
Message-ID: <CAJ14jR9UUY0uTstP8rLHBUOQ9v3AcH5vGio62_du=3x9vJ=qow@mail.gmail.com>

Er, dictionary... sorry, mkDataOccFS

On Tue, Mar 22, 2016 at 5:24 PM, Andrew Farmer <xichekolas at gmail.com> wrote:
> mkVarUnqual calls mkVarOccFS, which constructs an OccName in the
> varName namespace. You need to construct your RdrName via mkTyVarOcc,
> which picks the Type/Class namespace.
>
> On Tue, Mar 22, 2016 at 5:09 PM, Conal Elliott <conal at conal.net> wrote:
>> I'm trying to construct a dictionary in a GHC plugin. I'm stuck on finding
>> the constructor for the dictionary. When I use `-ddump-simpl` on the module
>> that defines the class, I see "Circat.Rep.C:HasRep". To try finding that
>> constructor, I say
>>
>>> lookupRdrNameInModuleForPlugins hsc_env
>>>   (mkModuleName "Circat.Rep") (mkVarUnqual "C:HasRep")
>>
>> However, I keep getting `Nothing` as a result. (Same without the "C:".) I've
>> also had this same difficulty when looking up constructors for algebraic
>> data types and when looking up TyCons. For regular value Ids, lookup
>> succeeds.
>>
>> What am I missing?
>>
>> Thanks, - Conal
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>

From conal at conal.net  Wed Mar 23 00:40:53 2016
From: conal at conal.net (Conal Elliott)
Date: Tue, 22 Mar 2016 17:40:53 -0700
Subject: lookupRdrNameInModuleForPlugins with constructors
In-Reply-To: <CAJ14jR9UUY0uTstP8rLHBUOQ9v3AcH5vGio62_du=3x9vJ=qow@mail.gmail.com>
References: <CAD6SzRLJsO3UrsK2wUgCnyMgk1ZCe7Nq9ongF5k8Y0ahgyG5=Q@mail.gmail.com>
 <CAJ14jR-eQxcpAYkMW+EDjsDaMGCgENhNPLnD=2bYSaH77Y1UsA@mail.gmail.com>
 <CAJ14jR9UUY0uTstP8rLHBUOQ9v3AcH5vGio62_du=3x9vJ=qow@mail.gmail.com>
Message-ID: <CAD6SzRLAPH6Evmpxy0OKEtytPzb3Cp9Yqs-p+p6ykbOw=P5tSA@mail.gmail.com>

Got it. Silly me. Thanks!!  - Conal

On Tue, Mar 22, 2016 at 5:25 PM, Andrew Farmer <xichekolas at gmail.com> wrote:

> Er, dictionary... sorry, mkDataOccFS
>
> On Tue, Mar 22, 2016 at 5:24 PM, Andrew Farmer <xichekolas at gmail.com>
> wrote:
> > mkVarUnqual calls mkVarOccFS, which constructs an OccName in the
> > varName namespace. You need to construct your RdrName via mkTyVarOcc,
> > which picks the Type/Class namespace.
> >
> > On Tue, Mar 22, 2016 at 5:09 PM, Conal Elliott <conal at conal.net> wrote:
> >> I'm trying to construct a dictionary in a GHC plugin. I'm stuck on
> finding
> >> the constructor for the dictionary. When I use `-ddump-simpl` on the
> module
> >> that defines the class, I see "Circat.Rep.C:HasRep". To try finding that
> >> constructor, I say
> >>
> >>> lookupRdrNameInModuleForPlugins hsc_env
> >>>   (mkModuleName "Circat.Rep") (mkVarUnqual "C:HasRep")
> >>
> >> However, I keep getting `Nothing` as a result. (Same without the "C:".)
> I've
> >> also had this same difficulty when looking up constructors for algebraic
> >> data types and when looking up TyCons. For regular value Ids, lookup
> >> succeeds.
> >>
> >> What am I missing?
> >>
> >> Thanks, - Conal
> >>
> >> _______________________________________________
> >> 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/20160322/d34327a0/attachment.html>

From conal at conal.net  Wed Mar 23 01:55:20 2016
From: conal at conal.net (Conal Elliott)
Date: Tue, 22 Mar 2016 18:55:20 -0700
Subject: lookupRdrNameInModuleForPlugins with constructors
In-Reply-To: <CAD6SzRLAPH6Evmpxy0OKEtytPzb3Cp9Yqs-p+p6ykbOw=P5tSA@mail.gmail.com>
References: <CAD6SzRLJsO3UrsK2wUgCnyMgk1ZCe7Nq9ongF5k8Y0ahgyG5=Q@mail.gmail.com>
 <CAJ14jR-eQxcpAYkMW+EDjsDaMGCgENhNPLnD=2bYSaH77Y1UsA@mail.gmail.com>
 <CAJ14jR9UUY0uTstP8rLHBUOQ9v3AcH5vGio62_du=3x9vJ=qow@mail.gmail.com>
 <CAD6SzRLAPH6Evmpxy0OKEtytPzb3Cp9Yqs-p+p6ykbOw=P5tSA@mail.gmail.com>
Message-ID: <CAD6SzRKTUr_t9whZ9WX8arWb5-5suNGdsXoqO-3w_yGPtKEYRw@mail.gmail.com>

I'm now able to look up value identifiers, type constructors (including
classes), and regular data constructors, but not dictionary constructors.
Here's my failing effort to look up a dictionary constructor (in CoreM):

    hasRepThing <-
      maybe (panic "HasRep lookup failure") lookupThing =<<
        (liftIO $
          lookupRdrNameInModuleForPlugins hsc_env (mkModuleName
"Circat.Rep")
             (Unqual (mkDataOcc "C:HasRep")))
    pprTrace "mkReifyEnv HasRep thing:" (ppr hasRepThing) (return ())

Result:

    ghc-stage2: panic! (the 'impossible' happened)
      (GHC version 8.1.20160307 for x86_64-apple-darwin):
            HasRep lookup failure

Same failure when I use the name string "HasRep" in place of "C:HasRep".

Any idea what I'm doing wrong here?

-- Conal

On Tue, Mar 22, 2016 at 5:40 PM, Conal Elliott <conal at conal.net> wrote:

> Got it. Silly me. Thanks!!  - Conal
>
> On Tue, Mar 22, 2016 at 5:25 PM, Andrew Farmer <xichekolas at gmail.com>
> wrote:
>
>> Er, dictionary... sorry, mkDataOccFS
>>
>> On Tue, Mar 22, 2016 at 5:24 PM, Andrew Farmer <xichekolas at gmail.com>
>> wrote:
>> > mkVarUnqual calls mkVarOccFS, which constructs an OccName in the
>> > varName namespace. You need to construct your RdrName via mkTyVarOcc,
>> > which picks the Type/Class namespace.
>> >
>> > On Tue, Mar 22, 2016 at 5:09 PM, Conal Elliott <conal at conal.net> wrote:
>> >> I'm trying to construct a dictionary in a GHC plugin. I'm stuck on
>> finding
>> >> the constructor for the dictionary. When I use `-ddump-simpl` on the
>> module
>> >> that defines the class, I see "Circat.Rep.C:HasRep". To try finding
>> that
>> >> constructor, I say
>> >>
>> >>> lookupRdrNameInModuleForPlugins hsc_env
>> >>>   (mkModuleName "Circat.Rep") (mkVarUnqual "C:HasRep")
>> >>
>> >> However, I keep getting `Nothing` as a result. (Same without the
>> "C:".) I've
>> >> also had this same difficulty when looking up constructors for
>> algebraic
>> >> data types and when looking up TyCons. For regular value Ids, lookup
>> >> succeeds.
>> >>
>> >> What am I missing?
>> >>
>> >> Thanks, - Conal
>> >>
>> >> _______________________________________________
>> >> 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/20160322/9cb50261/attachment.html>

From simonpj at microsoft.com  Wed Mar 23 08:32:29 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 23 Mar 2016 08:32:29 +0000
Subject: lookupRdrNameInModuleForPlugins with constructors
In-Reply-To: <CAD6SzRLJsO3UrsK2wUgCnyMgk1ZCe7Nq9ongF5k8Y0ahgyG5=Q@mail.gmail.com>
References: <CAD6SzRLJsO3UrsK2wUgCnyMgk1ZCe7Nq9ongF5k8Y0ahgyG5=Q@mail.gmail.com>
Message-ID: <b76ac3c11fb34940b5d7b23940e01f9c@DB4PR30MB030.064d.mgd.msft.net>

Start with the Class.  Use classTyCon to get the TyCon.  Use tyConDataCons to get the data constructor.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal Elliott
Sent: 23 March 2016 00:09
To: ghc-devs at haskell.org
Subject: lookupRdrNameInModuleForPlugins with constructors

I'm trying to construct a dictionary in a GHC plugin. I'm stuck on finding the constructor for the dictionary. When I use `-ddump-simpl` on the module that defines the class, I see "Circat.Rep.C:HasRep". To try finding that constructor, I say

> lookupRdrNameInModuleForPlugins hsc_env
>   (mkModuleName "Circat.Rep") (mkVarUnqual "C:HasRep")

However, I keep getting `Nothing` as a result. (Same without the "C:".) I've also had this same difficulty when looking up constructors for algebraic data types and when looking up TyCons. For regular value Ids, lookup succeeds.

What am I missing?
Thanks, - Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160323/61583add/attachment-0001.html>

From empthynickname at gmail.com  Wed Mar 23 12:47:15 2016
From: empthynickname at gmail.com (=?UTF-8?B?0J3QuNC60LjRgtCwINCd0LXQttC10LLRgdC60LjQuQ==?=)
Date: Wed, 23 Mar 2016 12:47:15 +0000
Subject: Support for colors in ghci
Message-ID: <CAAf7KER9Fqa848necReLnuhqZgPJN-LdqiaLFNvWaO4LmTNYoQ@mail.gmail.com>

Hello

I'm newcomer in GHC. I'd like to realize native support for colors in ghci
(this feature was described in https://ghc.haskell.org/trac/ghc/ticket/10073
).
Is it possible to realize inside ghci? If possible i'd like to understand
how to start implementation and how it might look in ghci?

Best regards, Nikita Nezhevskii.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160323/f6751b02/attachment.html>

From conal at conal.net  Wed Mar 23 16:48:57 2016
From: conal at conal.net (Conal Elliott)
Date: Wed, 23 Mar 2016 09:48:57 -0700
Subject: lookupRdrNameInModuleForPlugins with constructors
In-Reply-To: <b76ac3c11fb34940b5d7b23940e01f9c@DB4PR30MB030.064d.mgd.msft.net>
References: <CAD6SzRLJsO3UrsK2wUgCnyMgk1ZCe7Nq9ongF5k8Y0ahgyG5=Q@mail.gmail.com>
 <b76ac3c11fb34940b5d7b23940e01f9c@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAD6SzRLAhmu2F9Jfnh3tLBLE0HK7zam8WGpdDfNwy=LSGoQ5=w@mail.gmail.com>

Indeed, tyConDataCons does the trick. I don't know how to start with the
Class (given a name string), but I'm able to use 'mkClsOcc . Unqual' with
lookupRdrNameInModuleForPlugins and then lookupTyCon on the resulting name,
followed by 'head . tyConDataCons' to get the constructor.

Thanks, Simon!

-- Conal

On Wed, Mar 23, 2016 at 1:32 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Start with the Class.  Use classTyCon to get the TyCon.  Use tyConDataCons
> to get the data constructor.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Conal
> Elliott
> *Sent:* 23 March 2016 00:09
> *To:* ghc-devs at haskell.org
> *Subject:* lookupRdrNameInModuleForPlugins with constructors
>
>
>
> I'm trying to construct a dictionary in a GHC plugin. I'm stuck on finding
> the constructor for the dictionary. When I use `-ddump-simpl` on the module
> that defines the class, I see "Circat.Rep.C:HasRep". To try finding that
> constructor, I say
>
> > lookupRdrNameInModuleForPlugins hsc_env
> >   (mkModuleName "Circat.Rep") (mkVarUnqual "C:HasRep")
>
> However, I keep getting `Nothing` as a result. (Same without the "C:".)
> I've also had this same difficulty when looking up constructors for
> algebraic data types and when looking up TyCons. For regular value Ids,
> lookup succeeds.
>
> What am I missing?
>
> Thanks, - Conal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160323/8c4c03c5/attachment.html>

From ben at well-typed.com  Wed Mar 23 19:36:19 2016
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 23 Mar 2016 20:36:19 +0100
Subject: Support for colors in ghci
In-Reply-To: <CAAf7KER9Fqa848necReLnuhqZgPJN-LdqiaLFNvWaO4LmTNYoQ@mail.gmail.com>
References: <CAAf7KER9Fqa848necReLnuhqZgPJN-LdqiaLFNvWaO4LmTNYoQ@mail.gmail.com>
Message-ID: <878u19t2a4.fsf@smart-cactus.org>

?????? ????????? <empthynickname at gmail.com> writes:

> Hello
>
> I'm newcomer in GHC. I'd like to realize native support for colors in ghci
> (this feature was described in https://ghc.haskell.org/trac/ghc/ticket/10073
> ).
Great! I've been hoping someone would come along to look at this problem.

> Is it possible to realize inside ghci? If possible i'd like to understand
> how to start implementation and how it might look in ghci?
>
Really, I believe that the problem that you are describing reduces to
the problem of making GHC's error messages (or, more precisely, it's
pretty-printer) more semantic. The Idris community has done a great job
in making their pretty-printer documents descriptive, so familiarizing
yourself with the approach they take would be a good place to start (see
David Christiansen's writings and talk on this matter[1,2]).

There are some thoughts on how this can be done in GHC in #8809. In
comment 3 I lay out what I believe is the smoothest road to achieving
this. Namely we turn the pretty-printer into a free monad, allowing
values of a particular type to be embedded within SDoc. In most of GHC
this type would be a sum type which would accomodate expressions, types,
source locations, etc. This change would allow us to defer the
pretty-printing of this known set of primitive objects, allowing the
interpreter to perform more sophisticated printing (e.g. coloring).

This approach has the advantage of being relatively unintrusive while
being useful for users outside of GHC (e.g. IDEs). Some time ago I
started playing with an implementation of this idea in the typechecker
and it seemed to work out fairly well in practice.

Richard has proposed that perhaps instead of indexing the pretty-printer we
should merely allow the injection of dynamically typed data. I'm not
convinced that this is necessary and suspect that it would ultimately
become quite brittle. The whole point here is that we only want to allow
a small, closed universe of atoms into our errors; IMHO allowing a
dynamically typed open universe is a road which will ultimately lead to
pain. The cost of defining a small sum-type per compiler component a
small price to pay, especially relative to the safety and clarity that
it brings.

You'll also want to familiarize yourself with the relevant parts of GHC.
Namely, you'll want to read GHC's Outputable module as well as some of
its common users (TcErrors is a good place to start).

Let us know on the list if you have questions about procedure or general
questions about GHC. For questions and proposals pertaining to the
pretty-errors problem itself it would be best if we stayed on the
appropriate tickets (#8809 is probably best).

Cheers,

- Ben


[1] http://www.davidchristiansen.dk/2014/09/06/pretty-printing-idris/
[2] https://www.youtube.com/watch?v=m7BBCcIDXSg&list=PLnqUlCo055hVfNkQHP7z43r10yNo-mc7B&index=10
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160323/ceab89f5/attachment.sig>

From simonpj at microsoft.com  Thu Mar 24 09:53:54 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 24 Mar 2016 09:53:54 +0000
Subject: [Diffusion] [Build Failed] rGHC7e7407977243: Comment fix
In-Reply-To: <20160324095123.45814.10566.07CC9D12@phabricator.haskell.org>
References: <diffusion-audit-PHID-CMIT-moq6g2caaolyqszjcc63@phabricator.haskell.org>
 <20160324095123.45814.10566.07CC9D12@phabricator.haskell.org>
Message-ID: <80770846399d47b8863789ca2ff23dab@DB4PR30MB030.064d.mgd.msft.net>

Phab seems to be failing immediately

Simon

|  -----Original Message-----
|  From: noreply at phabricator.haskell.org
|  [mailto:noreply at phabricator.haskell.org]
|  Sent: 24 March 2016 09:51
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Subject: [Diffusion] [Build Failed] rGHC7e7407977243: Comment fix
|  
|  Harbormaster failed to build B8834: rGHC7e7407977243: Comment fix!
|  
|  BRANCHES
|    master
|  
|  USERS
|    simonpj (Author)
|    GHC - Type checker/inferencer (Auditor)
|  
|  COMMIT
|    https://phabricator.haskell.org/rGHC7e7407977243
|  
|  EMAIL PREFERENCES
|    https://phabricator.haskell.org/settings/panel/emailpreferences/
|  
|  To: simonpj, GHC - Type checker/inferencer, Harbormaster

From ben at well-typed.com  Thu Mar 24 11:52:06 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 24 Mar 2016 12:52:06 +0100
Subject: [Diffusion] [Build Failed] rGHC7e7407977243: Comment fix
In-Reply-To: <80770846399d47b8863789ca2ff23dab@DB4PR30MB030.064d.mgd.msft.net>
References: <diffusion-audit-PHID-CMIT-moq6g2caaolyqszjcc63@phabricator.haskell.org>
 <20160324095123.45814.10566.07CC9D12@phabricator.haskell.org>
 <80770846399d47b8863789ca2ff23dab@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87y498rt3t.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> Phab seems to be failing immediately
>
I've fixed this particular issue; it appears that the build command was
incorrect. However, all is still not well. I'll investigate.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160324/5f2f13f4/attachment-0001.sig>

From ben at well-typed.com  Thu Mar 24 13:13:23 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 24 Mar 2016 14:13:23 +0100
Subject: Harbormaster MIA?
In-Reply-To: <1458566615.1606.33.camel@joachim-breitner.de>
References: <1458566615.1606.33.camel@joachim-breitner.de>
Message-ID: <87vb4crpcc.fsf@smart-cactus.org>

Joachim Breitner <mail at joachim-breitner.de> writes:

> [Re-ending to the list, sorry Austin for the unnecessary private mail.]
>
> Hi,
>
> I?m looking forward to see what Harbormaster thinks of
> https://phabricator.haskell.org/D2014
> but it seems that no build has been scheduled. What is wrong?
>
Indeed Harbormaster isn't currently building differentials; I'm afraid I
can't recall the reason for this.

Austin, what will need to happen to get Harbormaster building
Differentials again?

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160324/0033d5c5/attachment.sig>

From christiaan.baaij at gmail.com  Thu Mar 24 13:39:27 2016
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Thu, 24 Mar 2016 14:39:27 +0100
Subject: How to prevent GHC (API) from breaking large constants into multiple
 top-level bindings
Message-ID: <56F3EE0F.8000109@gmail.com>

My situation is the following, given the code:

 > {-# LANGUAGE GADTs, DataKinds, TypeOperators, KindSignatures #-}
 > module GConst where
 >
 > import GHC.TypeLits
 >
 > data Vec :: Nat -> * -> *
 >   where
 >     Nil  :: Vec 0 a
 >     Cons :: a -> Vec n a -> Vec (n+1) a
 >
 > infixr `Cons`
 >
 > c :: Vec 5 Int
 > c = 1 `Cons` 2 `Cons` 3 `Cons` 4 `Cons` 5 `Cons` Nil

The output of the desugarer, 'ghc -O -fforce-recomp -fno-full-laziness 
-ddump-ds -dsuppress-all GConst.hs', is:

 > c =
 >   ($WCons
 >      (I# 1)
 >      (($WCons
 >          (I# 2)
 >          (($WCons
 >              (I# 3)
 >              (($WCons (I# 4) (($WCons (I# 5) ($WNil)) `cast` ...)) 
`cast` ...))
 >           `cast` ...))
 >       `cast` ...))
 >   `cast` ...

Where the constant 'c' is a single large constant. However, when I look 
at the output of the simplifier, 'ghc -O -fforce-recomp 
-fno-full-laziness -ddump-simpl -dsuppress-all GConst.hs', I see this:

 > c10
 > c10 = I# 1
 >
 > c9
 > c9 = I# 2
 >
 > c8
 > c8 = I# 3
 >
 > c7
 > c7 = I# 4
 >
 > c6
 > c6 = I# 5
 >
 > c5
 > c5 = Cons @~ <0 + 1>_N c6 ($WNil)
 >
 > c4
 > c4 = Cons @~ <1 + 1>_N c7 (c5 `cast` ...)
 >
 > c3
 > c3 = Cons @~ <2 + 1>_N c8 (c4 `cast` ...)
 >
 > c2
 > c2 = Cons @~ <3 + 1>_N c9 (c3 `cast` ...)
 >
 > c1
 > c1 = Cons @~ <4 + 1>_N c10 (c2 `cast` ...)
 >
 > c
 > c = c1 `cast` ...

The single constant is completely taken apart into multiple top-level 
bindings.

I haven't given it too much thought, but I assume there are good reasons 
to take large constants aparts, and break them into individual top-level 
bindings. At least when your target is a normal CPU.

Now, I'm a GHC API user, and I convert Haskell programs to digital 
circuits. For my use case, breaking up constants into smaller top-level 
bindings has completely no performance benefits at all. Actually, my 
compiler _inlines_ all those top-level bindings again to create a single 
large constant.
When working with large constants, my compiler is actually taking an 
disproportionately large amount of time of doing the inverse of what the 
GHC simplifier did.
I want to keep using the GHC simplifier, because it contains many 
optimisations that are usefull for my specific use-case.

So my question is: how can I stop the GHC simplifier from breaking up 
large constants into smaller top-level bindings?
As you could see from the example, this "breaking-apart-constants" is 
not due to the FullLaziness transform, as I explicitly disabled it.
If this "breaking-apart-constants" part is not (currently) controllable 
by a flag, would it be possible to add such a flag? I'm happy to work on 
a patch myself if someone could tell where about in the simplifier I 
would have to make some changes.

Thanks,

Christiaan

From simonpj at microsoft.com  Thu Mar 24 15:49:10 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 24 Mar 2016 15:49:10 +0000
Subject: How to prevent GHC (API) from breaking large constants into
 multiple top-level bindings
In-Reply-To: <56F3EE0F.8000109@gmail.com>
References: <56F3EE0F.8000109@gmail.com>
Message-ID: <efe4984214c54d71b97f36b74c8e343a@DB4PR30MB030.064d.mgd.msft.net>

There's a pretty strong reason for flattening data structures, whether nested or at top level.  Consider

let x = a : (b : (c : [])))
in
....(case x of (p:q) -> e1)...(case x or (r:s) -> e2) ....

We want to cancel out those case expressions.  In the nested form we'd be stuck with 

let x = a : (b : (c : [])))
in
....(let { p = a; q = b:c:[] } in e1) ....
    (let {r = a; s = b:c:[] } in e2)...

But now we have wastefully duplicated that (b:c:[]).

Instead GHC flattens thus:

let x2 = c : []
    x1 = b : x2
    x = a : x1
in
....(case x of (p:q) -> e1)...(case x or (r:s) -> e2) ....

And now we can do nice simple case-cancellation:

let x2 = c : []
    x1 = b : x2
    x = a : x1
in
....(let { p = a; q = x1 } in e1) ....
    (let {r = a; s = x2 } in e2)...


Bottom line: no, there is no flag to stop this happening.

But surely it should be a linear-time substitution to undo it?

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Christiaan Baaij
|  Sent: 24 March 2016 13:39
|  To: ghc-devs at haskell.org
|  Subject: How to prevent GHC (API) from breaking large constants into
|  multiple top-level bindings
|  
|  My situation is the following, given the code:
|  
|   > {-# LANGUAGE GADTs, DataKinds, TypeOperators, KindSignatures #-}  >
|  module GConst where  >  > import GHC.TypeLits  >  > data Vec :: Nat ->
|  * -> *
|   >   where
|   >     Nil  :: Vec 0 a
|   >     Cons :: a -> Vec n a -> Vec (n+1) a
|   >
|   > infixr `Cons`
|   >
|   > c :: Vec 5 Int
|   > c = 1 `Cons` 2 `Cons` 3 `Cons` 4 `Cons` 5 `Cons` Nil
|  
|  The output of the desugarer, 'ghc -O -fforce-recomp -fno-full-laziness
|  -ddump-ds -dsuppress-all GConst.hs', is:
|  
|   > c =
|   >   ($WCons
|   >      (I# 1)
|   >      (($WCons
|   >          (I# 2)
|   >          (($WCons
|   >              (I# 3)
|   >              (($WCons (I# 4) (($WCons (I# 5) ($WNil)) `cast` ...))
|  `cast` ...))
|   >           `cast` ...))
|   >       `cast` ...))
|   >   `cast` ...
|  
|  Where the constant 'c' is a single large constant. However, when I look
|  at the output of the simplifier, 'ghc -O -fforce-recomp -fno-full-
|  laziness -ddump-simpl -dsuppress-all GConst.hs', I see this:
|  
|   > c10
|   > c10 = I# 1
|   >
|   > c9
|   > c9 = I# 2
|   >
|   > c8
|   > c8 = I# 3
|   >
|   > c7
|   > c7 = I# 4
|   >
|   > c6
|   > c6 = I# 5
|   >
|   > c5
|   > c5 = Cons @~ <0 + 1>_N c6 ($WNil)
|   >
|   > c4
|   > c4 = Cons @~ <1 + 1>_N c7 (c5 `cast` ...)  >  > c3  > c3 = Cons @~
|  <2 + 1>_N c8 (c4 `cast` ...)  >  > c2  > c2 = Cons @~ <3 + 1>_N c9 (c3
|  `cast` ...)  >  > c1  > c1 = Cons @~ <4 + 1>_N c10 (c2 `cast` ...)  >
|  > c  > c = c1 `cast` ...
|  
|  The single constant is completely taken apart into multiple top-level
|  bindings.
|  
|  I haven't given it too much thought, but I assume there are good
|  reasons to take large constants aparts, and break them into individual
|  top-level bindings. At least when your target is a normal CPU.
|  
|  Now, I'm a GHC API user, and I convert Haskell programs to digital
|  circuits. For my use case, breaking up constants into smaller top-level
|  bindings has completely no performance benefits at all. Actually, my
|  compiler _inlines_ all those top-level bindings again to create a
|  single large constant.
|  When working with large constants, my compiler is actually taking an
|  disproportionately large amount of time of doing the inverse of what
|  the GHC simplifier did.
|  I want to keep using the GHC simplifier, because it contains many
|  optimisations that are usefull for my specific use-case.
|  
|  So my question is: how can I stop the GHC simplifier from breaking up
|  large constants into smaller top-level bindings?
|  As you could see from the example, this "breaking-apart-constants" is
|  not due to the FullLaziness transform, as I explicitly disabled it.
|  If this "breaking-apart-constants" part is not (currently) controllable
|  by a flag, would it be possible to add such a flag? I'm happy to work
|  on a patch myself if someone could tell where about in the simplifier I
|  would have to make some changes.
|  
|  Thanks,
|  
|  Christiaan
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cf244fbbdf6d946ae
|  2b9408d353e9946c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=v1daJzyAp
|  Slqrw8MUAy57Z%2bIDpNGO1wT50X54%2fmTx38%3d

From christiaan.baaij at gmail.com  Thu Mar 24 16:13:23 2016
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Thu, 24 Mar 2016 17:13:23 +0100
Subject: How to prevent GHC (API) from breaking large constants into
 multiple top-level bindings
In-Reply-To: <efe4984214c54d71b97f36b74c8e343a@DB4PR30MB030.064d.mgd.msft.net>
References: <56F3EE0F.8000109@gmail.com>
 <efe4984214c54d71b97f36b74c8e343a@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <56F41223.20703@gmail.com>

Ok, that makes sense, indeed, we don't want to duplicate that (b:c:[]).
Thank you for explaining the reason behind the flattening.

And yes, the asymptotic complexity of undoing the flattening is linear.
It is just, due to the internal structure of my compiler pipeline, the 
constants of doing that are high, because I perform the substitution 
during my normal inlining-pass, which does a lot of extra checks.

Now that I know why GHC does the things it does, I'll figure out a 
different way to make sure that my compiler doesn't slow down on large 
constants.

Christiaan

On 03/24/2016 04:49 PM, Simon Peyton Jones wrote:
> There's a pretty strong reason for flattening data structures, whether nested or at top level.  Consider
>
> let x = a : (b : (c : [])))
> in
> ....(case x of (p:q) -> e1)...(case x or (r:s) -> e2) ....
>
> We want to cancel out those case expressions.  In the nested form we'd be stuck with
>
> let x = a : (b : (c : [])))
> in
> ....(let { p = a; q = b:c:[] } in e1) ....
>      (let {r = a; s = b:c:[] } in e2)...
>
> But now we have wastefully duplicated that (b:c:[]).
>
> Instead GHC flattens thus:
>
> let x2 = c : []
>      x1 = b : x2
>      x = a : x1
> in
> ....(case x of (p:q) -> e1)...(case x or (r:s) -> e2) ....
>
> And now we can do nice simple case-cancellation:
>
> let x2 = c : []
>      x1 = b : x2
>      x = a : x1
> in
> ....(let { p = a; q = x1 } in e1) ....
>      (let {r = a; s = x2 } in e2)...
>
>
> Bottom line: no, there is no flag to stop this happening.
>
> But surely it should be a linear-time substitution to undo it?
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> |  Christiaan Baaij
> |  Sent: 24 March 2016 13:39
> |  To: ghc-devs at haskell.org
> |  Subject: How to prevent GHC (API) from breaking large constants into
> |  multiple top-level bindings
> |
> |  My situation is the following, given the code:
> |
> |   > {-# LANGUAGE GADTs, DataKinds, TypeOperators, KindSignatures #-}  >
> |  module GConst where  >  > import GHC.TypeLits  >  > data Vec :: Nat ->
> |  * -> *
> |   >   where
> |   >     Nil  :: Vec 0 a
> |   >     Cons :: a -> Vec n a -> Vec (n+1) a
> |   >
> |   > infixr `Cons`
> |   >
> |   > c :: Vec 5 Int
> |   > c = 1 `Cons` 2 `Cons` 3 `Cons` 4 `Cons` 5 `Cons` Nil
> |
> |  The output of the desugarer, 'ghc -O -fforce-recomp -fno-full-laziness
> |  -ddump-ds -dsuppress-all GConst.hs', is:
> |
> |   > c =
> |   >   ($WCons
> |   >      (I# 1)
> |   >      (($WCons
> |   >          (I# 2)
> |   >          (($WCons
> |   >              (I# 3)
> |   >              (($WCons (I# 4) (($WCons (I# 5) ($WNil)) `cast` ...))
> |  `cast` ...))
> |   >           `cast` ...))
> |   >       `cast` ...))
> |   >   `cast` ...
> |
> |  Where the constant 'c' is a single large constant. However, when I look
> |  at the output of the simplifier, 'ghc -O -fforce-recomp -fno-full-
> |  laziness -ddump-simpl -dsuppress-all GConst.hs', I see this:
> |
> |   > c10
> |   > c10 = I# 1
> |   >
> |   > c9
> |   > c9 = I# 2
> |   >
> |   > c8
> |   > c8 = I# 3
> |   >
> |   > c7
> |   > c7 = I# 4
> |   >
> |   > c6
> |   > c6 = I# 5
> |   >
> |   > c5
> |   > c5 = Cons @~ <0 + 1>_N c6 ($WNil)
> |   >
> |   > c4
> |   > c4 = Cons @~ <1 + 1>_N c7 (c5 `cast` ...)  >  > c3  > c3 = Cons @~
> |  <2 + 1>_N c8 (c4 `cast` ...)  >  > c2  > c2 = Cons @~ <3 + 1>_N c9 (c3
> |  `cast` ...)  >  > c1  > c1 = Cons @~ <4 + 1>_N c10 (c2 `cast` ...)  >
> |  > c  > c = c1 `cast` ...
> |
> |  The single constant is completely taken apart into multiple top-level
> |  bindings.
> |
> |  I haven't given it too much thought, but I assume there are good
> |  reasons to take large constants aparts, and break them into individual
> |  top-level bindings. At least when your target is a normal CPU.
> |
> |  Now, I'm a GHC API user, and I convert Haskell programs to digital
> |  circuits. For my use case, breaking up constants into smaller top-level
> |  bindings has completely no performance benefits at all. Actually, my
> |  compiler _inlines_ all those top-level bindings again to create a
> |  single large constant.
> |  When working with large constants, my compiler is actually taking an
> |  disproportionately large amount of time of doing the inverse of what
> |  the GHC simplifier did.
> |  I want to keep using the GHC simplifier, because it contains many
> |  optimisations that are usefull for my specific use-case.
> |
> |  So my question is: how can I stop the GHC simplifier from breaking up
> |  large constants into smaller top-level bindings?
> |  As you could see from the example, this "breaking-apart-constants" is
> |  not due to the FullLaziness transform, as I explicitly disabled it.
> |  If this "breaking-apart-constants" part is not (currently) controllable
> |  by a flag, would it be possible to add such a flag? I'm happy to work
> |  on a patch myself if someone could tell where about in the simplifier I
> |  would have to make some changes.
> |
> |  Thanks,
> |
> |  Christiaan
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
> |  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cf244fbbdf6d946ae
> |  2b9408d353e9946c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=v1daJzyAp
> |  Slqrw8MUAy57Z%2bIDpNGO1wT50X54%2fmTx38%3d
>

From simonpj at microsoft.com  Fri Mar 25 10:30:58 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 25 Mar 2016 10:30:58 +0000
Subject: Table of contents
Message-ID: <f97a5e84037543beb55cf3c36e525753@DB4PR30MB030.064d.mgd.msft.net>

Could the table of contents for the GHC user manual have one more level showing?  Or just all levels?
http://downloads.haskell.org/~ghc/master/users-guide/
I often search for things I can?t find
Thanks
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160325/83157f19/attachment.html>

From ben at smart-cactus.org  Sat Mar 26 01:13:20 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Sat, 26 Mar 2016 02:13:20 +0100
Subject: Table of contents
In-Reply-To: <f97a5e84037543beb55cf3c36e525753@DB4PR30MB030.064d.mgd.msft.net>
References: <f97a5e84037543beb55cf3c36e525753@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87d1qirqhb.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> Could the table of contents for the GHC user manual have one more level showing?  Or just all levels?
>
Indeed we could show another level. However, I worry that by showing
even more headings than we already do we will make things harder to
navigate, not easier.

Note that Sphinx does offer search functionality (note the search box in
the right pane) although I'll admit that it leaves much to be desired. I
would really like for this to be improved but in the meantime I wouldn't
be opposed to adding another level of hierarchy to the TOC.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160326/43e644bc/attachment.sig>

From chak at justtesting.org  Sat Mar 26 09:35:14 2016
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Sat, 26 Mar 2016 20:35:14 +1100
Subject: 7.10.3 fails to build with Xcode 7.3
Message-ID: <8CB8A4E2-32AD-4730-9A1D-0BF3CD3319B0@justtesting.org>

I just noticed that GHC 7.10.3 (latest release version) fails to build with version 7.3 of Xcode (which just came out of beta). Maybe this is due to

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

The problem manifests in the form of a SEGV when dll-split is invoked for the first time ? specifically lldb has the following to say,

Process 17348 launched: '../lib/bin/dll-split' (x86_64)
Process 17348 stopped
* thread #1: tid = 0x4a821e, 0x0000000100e26357 libHSrts-ghc7.10.3.dylib`stg_returnToStackTop + 7, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1e)
    frame #0: 0x0000000100e26357 libHSrts-ghc7.10.3.dylib`stg_returnToStackTop + 7
libHSrts-ghc7.10.3.dylib`stg_returnToStackTop:
->  0x100e26357 <+7>:  movq   0x1e(%rax), %rbx
    0x100e2635b <+11>: movq   0x10(%rbx), %rbp
    0x100e2635f <+15>: leaq   0x126(%rbx), %r15
    0x100e26366 <+22>: movq   $0x0, 0x904(%r13)

Interestingly, the GHC 8.0.1-rc2 build does not exhibit that same failure. It does, however, fail to build due to an undefined symbol:

Undefined symbols for architecture x86_64:
  "_stg_sel_18_upd_info", referenced from:
      _sc9J_info in Monad.dyn_o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
`gcc' failed in phase `Linker'. (Exit code: 1)
make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1
make: *** [all] Error 2

(This may be unrelated to Xcode 7.3 and a known problem on OS X with that RC. I didn?t follow the 8.0.1-rc2 tickets in detail.)

As I assume that there will be no further 7.10 release, I am posting this here just to save others the time to track the problem down.

Manuel

PS: I wish I had the time to check GHC builds with Xcode beta releases, but alas, I usually don?t.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160326/1284dc2f/attachment.html>

From mle+hs at mega-nerd.com  Sat Mar 26 09:53:27 2016
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Sat, 26 Mar 2016 20:53:27 +1100
Subject: 7.10.3 fails to build with Xcode 7.3
In-Reply-To: <8CB8A4E2-32AD-4730-9A1D-0BF3CD3319B0@justtesting.org>
References: <8CB8A4E2-32AD-4730-9A1D-0BF3CD3319B0@justtesting.org>
Message-ID: <20160326205327.46d0e05462f12ed61a3584a0@mega-nerd.com>

Manuel M T Chakravarty wrote:

> I just noticed that GHC 7.10.3 (latest release version) fails to build
> with version 7.3 of Xcode (which just came out of beta). Maybe this is due to
> 
>   https://ghc.haskell.org/trac/ghc/ticket/11744

Yes, pretty sure that is the problem. I believe Carter (and maybe Luite)
are working on it.

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

From chak at justtesting.org  Sat Mar 26 13:36:57 2016
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Sun, 27 Mar 2016 00:36:57 +1100
Subject: 7.10.3 fails to build with Xcode 7.3
In-Reply-To: <20160326205327.46d0e05462f12ed61a3584a0@mega-nerd.com>
References: <8CB8A4E2-32AD-4730-9A1D-0BF3CD3319B0@justtesting.org>
 <20160326205327.46d0e05462f12ed61a3584a0@mega-nerd.com>
Message-ID: <56A5A8C0-0832-43DF-BB99-D59FDD23F709@justtesting.org>

At HVR?s suggestion, I tried passing ?with-nm=?/nm-classic to configure and that indeed fixes the problem, confirming that this is #11744.

A fix is simple in this case, check whether

  `xcode-select -p`/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic

or

  `xcode-select -p`/usr/bin/nm-classic

exists. If yes, use that instead of ?nm?; otherwise, use ?nm? as usual. (You need to check for both, because the former is what comes with Xcode and the latter is what comes with the standalone command line tool package.)

Thanks,
Manuel

> Am 26 Mar 2016 um 20:53  schrieb Erik de Castro Lopo <mle+hs at mega-nerd.com>:
> 
> Manuel M T Chakravarty wrote:
> 
>> I just noticed that GHC 7.10.3 (latest release version) fails to build
>> with version 7.3 of Xcode (which just came out of beta). Maybe this is due to
>> 
>>  https://ghc.haskell.org/trac/ghc/ticket/11744
> 
> Yes, pretty sure that is the problem. I believe Carter (and maybe Luite)
> are working on it.
> 
> Erik
> -- 
> ----------------------------------------------------------------------
> Erik de Castro Lopo
> http://www.mega-nerd.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From george.colpitts at gmail.com  Sat Mar 26 17:50:32 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Sat, 26 Mar 2016 17:50:32 +0000
Subject: possible tuple elimination optimization?
Message-ID: <CAB-d4A5PtZ5cLyNdkHh_7Z3yg8Okgmm1fBUWmiC68ikpAiqEBQ@mail.gmail.com>

The following higher order function, sumh, seems to be 3 to 14 times slower
than the equivalent recursive function, sumr:

sumh :: Double -> Double
sumh n =
    snd $ until ((>= n) . fst) as' (1, 0)
    where
      as' (i,s) =
          (i + 2, s + (-1) / i + 1 / (i + 1))

sumr :: Double -> Double
sumr n =
    as' 1 0
    where
      as' i  s
          | i >= n    = s
          | otherwise = as' (i + 2) (s + (-1) / i + 1 / (i + 1))

This is true in 7.10.3 as well as 8.0.1 so this is not a regression. From
the size usage my guess is that this is due to the allocation of tuples in
sumh. Maybe there is a straightforward way to optimize sumh but I couldn't
find it. Adding a Strict pragma didn't help nor did use
of -funbox-strict-fields -flate-dmd-anal. Have I missed something or should
I file a bug?

Timings from 8.0.1 rc2:

ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160204
bash-3.2$ ghc -O2 -dynamic sum.hs
ghc -O2 -dynamic sum.hs
[1 of 1] Compiling Main             ( sum.hs, sum.o )
Linking sum ...
bash-3.2$ ghci
Prelude> :load sum
Ok, modules loaded: Main.
(0.05 secs,)
Prelude Main> *sumh* (10^6)
-0.6931466805602525
it :: Double
(*0.14 secs, 40,708,016 bytes*)
Prelude Main> sumr (10^6)
-0.6931466805602525
it :: Double
(*0.01 secs, 92,000 bytes)*

Thanks
George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160326/7b1490a7/attachment.html>

From dan.doel at gmail.com  Sat Mar 26 20:11:20 2016
From: dan.doel at gmail.com (Dan Doel)
Date: Sat, 26 Mar 2016 16:11:20 -0400
Subject: possible tuple elimination optimization?
In-Reply-To: <CAB-d4A5PtZ5cLyNdkHh_7Z3yg8Okgmm1fBUWmiC68ikpAiqEBQ@mail.gmail.com>
References: <CAB-d4A5PtZ5cLyNdkHh_7Z3yg8Okgmm1fBUWmiC68ikpAiqEBQ@mail.gmail.com>
Message-ID: <CAHEA9tPb8RzuX-hMuOpQxHpah4HfphR9EEYODgNP3qzu8=Jn-Q@mail.gmail.com>

The extra allocation/time isn't caused by allocating pairs (neither
version does this). It is caused by allocating Doubles, because GHC
doesn't figure out that the second part of your pairs is always
demanded (I think), so the corresponding argument is left boxed. sumh
essentially turns into:

    sumh (D# d#) = sumh1 d#
    sumh1 d# = case loop1 1# 0# of
      (# _, ans #) -> ans
     where
     loop1 :: Double# -> Double# -> (# Double, Double #)
     loop1 i# s#
       | i# >= d# = (# D# i#, D# s# #)
       | otherwise = loop2 (i# + 2#) (D# ...)
     loop2 :: Double# -> Double -> (# Double, Double #)
     loop2 i# s
       | i# >= d# = (# D# i#, s #)
       | otherwise = loop2 (i# + 2#) (...)

So, it starts as a loop on unboxed arguments for one step, but then
switches over to boxing the second argument after the first iteration.
If you consider loop2 in isolation (and the hypothetical loop that
both of these came from), it is not strict in s. So there is no reason
to keep s evaluated except by considering the calling context, which I
guess GHC is not doing.

One way to fix this is by modifying the predicate to make is stricter.
Instead of `((>=n) . fst)` you can use:

    p (i, s) = s `seq` (i >= n)

Then it will be obvious to GHC that it shouldn't delay computing `s`
at each step.

This may be a similar failure to the old 'constructed product result
inside unboxed tuples' bug, where a function with an `ST s Int` result
could internally be optimized to return an unboxed integer, but it
isn't. Your example isn't exactly the same, but it has a similar
flavor. A call site is strict in part of the result of a function, and
generating code for that strict case would enable better optimization
of the callee, but the optimization would have to act on individual
parts of an unboxed tuple (which in your case comes from optimizing a
tuple), and that isn't done.

-- Dan

On Sat, Mar 26, 2016 at 1:50 PM, George Colpitts
<george.colpitts at gmail.com> wrote:
> The following higher order function, sumh, seems to be 3 to 14 times slower
> than the equivalent recursive function, sumr:
>
> sumh :: Double -> Double
> sumh n =
>     snd $ until ((>= n) . fst) as' (1, 0)
>     where
>       as' (i,s) =
>           (i + 2, s + (-1) / i + 1 / (i + 1))
>
> sumr :: Double -> Double
> sumr n =
>     as' 1 0
>     where
>       as' i  s
>           | i >= n    = s
>           | otherwise = as' (i + 2) (s + (-1) / i + 1 / (i + 1))
>
> This is true in 7.10.3 as well as 8.0.1 so this is not a regression. From
> the size usage my guess is that this is due to the allocation of tuples in
> sumh. Maybe there is a straightforward way to optimize sumh but I couldn't
> find it. Adding a Strict pragma didn't help nor did use of
> -funbox-strict-fields -flate-dmd-anal. Have I missed something or should I
> file a bug?
>
> Timings from 8.0.1 rc2:
>
> ghc --version
> The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160204
> bash-3.2$ ghc -O2 -dynamic sum.hs
> ghc -O2 -dynamic sum.hs
> [1 of 1] Compiling Main             ( sum.hs, sum.o )
> Linking sum ...
> bash-3.2$ ghci
> Prelude> :load sum
> Ok, modules loaded: Main.
> (0.05 secs,)
> Prelude Main> sumh (10^6)
> -0.6931466805602525
> it :: Double
> (0.14 secs, 40,708,016 bytes)
> Prelude Main> sumr (10^6)
> -0.6931466805602525
> it :: Double
> (0.01 secs, 92,000 bytes)
>
> Thanks
> George
>
> _______________________________________________
> 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  Sat Mar 26 20:40:50 2016
From: dan.doel at gmail.com (Dan Doel)
Date: Sat, 26 Mar 2016 16:40:50 -0400
Subject: possible tuple elimination optimization?
In-Reply-To: <CAB-d4A5PtZ5cLyNdkHh_7Z3yg8Okgmm1fBUWmiC68ikpAiqEBQ@mail.gmail.com>
References: <CAB-d4A5PtZ5cLyNdkHh_7Z3yg8Okgmm1fBUWmiC68ikpAiqEBQ@mail.gmail.com>
Message-ID: <CAHEA9tNY2mh_C-17L+U6R+ewjrxsHgOZN3W286Y0mJPeL1kz5Q@mail.gmail.com>

By the way, in case this helps your mental model, if you modify sumr to be:

    sumr n = snd $ as' 1 0
      where
      as' i s
        | i >= n = (i, s)
        | otherwise = ...

Then it has the same problem as sumh. Your original as' for sumr is
strict in s, but this modified one isn't.

This shows another way to fix sumh, too. Create a version of until
that separates out the part of the state that is only for testing.
Then the until loop will be strict in the result part of the state,
and the desired optimizations will happen (in this case):

    until' p step = go
     where
     go t r
       | p t = r
       | otherwise = uncurry go $ step (t, r)

-- Dan

On Sat, Mar 26, 2016 at 1:50 PM, George Colpitts
<george.colpitts at gmail.com> wrote:
> The following higher order function, sumh, seems to be 3 to 14 times slower
> than the equivalent recursive function, sumr:
>
> sumh :: Double -> Double
> sumh n =
>     snd $ until ((>= n) . fst) as' (1, 0)
>     where
>       as' (i,s) =
>           (i + 2, s + (-1) / i + 1 / (i + 1))
>
> sumr :: Double -> Double
> sumr n =
>     as' 1 0
>     where
>       as' i  s
>           | i >= n    = s
>           | otherwise = as' (i + 2) (s + (-1) / i + 1 / (i + 1))
>
> This is true in 7.10.3 as well as 8.0.1 so this is not a regression. From
> the size usage my guess is that this is due to the allocation of tuples in
> sumh. Maybe there is a straightforward way to optimize sumh but I couldn't
> find it. Adding a Strict pragma didn't help nor did use of
> -funbox-strict-fields -flate-dmd-anal. Have I missed something or should I
> file a bug?
>
> Timings from 8.0.1 rc2:
>
> ghc --version
> The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160204
> bash-3.2$ ghc -O2 -dynamic sum.hs
> ghc -O2 -dynamic sum.hs
> [1 of 1] Compiling Main             ( sum.hs, sum.o )
> Linking sum ...
> bash-3.2$ ghci
> Prelude> :load sum
> Ok, modules loaded: Main.
> (0.05 secs,)
> Prelude Main> sumh (10^6)
> -0.6931466805602525
> it :: Double
> (0.14 secs, 40,708,016 bytes)
> Prelude Main> sumr (10^6)
> -0.6931466805602525
> it :: Double
> (0.01 secs, 92,000 bytes)
>
> Thanks
> George
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From _deepfire at feelingofgreen.ru  Sun Mar 27 13:36:02 2016
From: _deepfire at feelingofgreen.ru (Kosyrev Serge)
Date: Sun, 27 Mar 2016 16:36:02 +0300
Subject: GHC 8 superclass chain constraint regression
Message-ID: <87a8lkavr1.fsf@feelingofgreen.ru>

Good day!

It seems that GHC 8 regresses with regard to GHC 7.10, when it tries to
satisfy the constraints, implied by instance context.

The following does not build on GHC 8.0.1 RC2, but does on 7.10.3:

> {-# LANGUAGE FlexibleInstances #-}
> {-# LANGUAGE UndecidableInstances #-}
> --{-# LANGUAGE UndecidableSuperClasses #-} -- this doesn't matter
> {-# LANGUAGE UnicodeSyntax #-}
>
> module Foo where
>
> class Super a
> class Super a ? Left a
> class Super a ? Right a
> instance (Left a) ? Right a

the error being:

> ? Could not deduce (Super a)
>     arising from the superclasses of an instance declaration
>   from the context: Left a
>     bound by the instance declaration
>     at repro.hs:9:10-27
>   Possible fix:
>     add (Super a) to the context of the instance declaration
> ? In the instance declaration for ?Right a?

A look through the GHC 8 status page, produced no bugs that seemed
related to my uneducated guess.

It also /roughly/ seems that https://phabricator.haskell.org/D1594
could possibly be related.

Thanks to lyxia on #haskell for pointing that this actually works on 7.10..

-- 
? ???????e? / respectfully,
??????? ??????

From george.colpitts at gmail.com  Sun Mar 27 20:42:55 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Sun, 27 Mar 2016 17:42:55 -0300
Subject: until, laziness, and performance
Message-ID: <CAB-d4A7YNvuXxuy9o1pQjshToDn1jxyfxXTXPg+ocmYv4pZrDA@mail.gmail.com>

Dan, I really appreciate that you responded so quickly and  took the time
to explain this. Unfortunately I still don't understand.

I did think of laziness as a potential source of bad performance but to me
both internal functions were lazy in the second argument. Since I couldn't
explain why both weren't equally slow due to laziness, I dismissed laziness
as a possible source of the problem instead of questioning my understanding
of laziness.

I still don't understand why

as'
? ?
i s
     | i >= n    = s
     | otherwise = as' (i + 2) (s + (-1) / i + 1 / (i + 1))


is not lazy in its second arg as it only has to evaluate it if i >= n. This
seems exactly analogous to or, ||, which only needs to evaluate its second
arg if its first arg is False. || is definitely lazy in its second
argument. Can you explain why as' is strict in its second arg, s? Is it due
to the following from,
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Demand ?

For functions, it is assumed, that the result of the function is used
strictly.


I guess  I should have checked my intuition against the compiler strictness
analysis. I modified sum.hs to only have a definition of sumr, commenting
out sumh and tried the various tools.

The user's guide,
https://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/users_guide/sooner.html#faster-producing-a-program-that-runs-quicker,
recommends:

Look for your function in the interface file, then for the third field in
the pragma; it should say Strictness: ?string?. The ?string? gives the
strictness of the function?s arguments: see the GHC Commentary for a
description of the strictness notation.


It doesn't mention that the interface file is binary and that you need to
use ghc --show-iface, e.g.

ghc --show-iface sum.hi > sum.hir


Doing this seems to give the wrong answer, i.e. the second arg is lazy.

                     $was' :: Double# -> Double# -> Double#
          {- Arity: 2, Strictness: <S,U><*L*,U>, Inline: [0] -}

Is this a bug?

ghc -ddump-stranal -O sum.hs gives the right answer:

as'_s25G [Occ=LoopBreaker] :: Double -> Double -> Double
      [LclId,
       Arity=2,
       CallArity=2,
       Str=DmdType <S(S),1*U(U)><*S*,1*U(U)>m {avM-><S(S),U(U)>},
       Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True,
       WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 20] 108 0}]


Unfortunately the simplest way to find out doesn't give information on
internal functions. I will file an ER for this:

 ghc -ddump-strsigs -O sum.hs
[1 of 1] Compiling Main             ( sum.hs, sum.o )
==================== Strictness signatures ====================
:Main.main:
Main.$trModule: m
Main.main: x
Main.sumr: <S(S),U(U)>m


I really like your definition of until' as the solution to this. To me it
seems analogous to foldl', in that it provides a way to avoid an
optimization problem that may be subtle to many. I guess it is not general
enough to be added to a library. The following world be general enough but
it would probably be overkill:

until' :: NFData a => (a -> Bool) -> (a -> a) -> a -> a
until' p f = go
  where
    go x | p $!! x   = x
         | otherwise = go (f x)



Thanks again for all your help
George


On Sat, Mar 26, 2016 at 5:40 PM Dan Doel <dan.doel at gmail.com> wrote:

> By the way, in case this helps your mental model, if you modify sumr to be:
>
>     sumr n = snd $ as' 1 0
>       where
>       as' i s
>         | i >= n = (i, s)
>         | otherwise = ...
>
> Then it has the same problem as sumh. Your original as' for sumr is
> strict in s, but this modified one isn't.
>
> This shows another way to fix sumh, too. Create a version of until
> that separates out the part of the state that is only for testing.
> Then the until loop will be strict in the result part of the state,
> and the desired optimizations will happen (in this case):
>
>     until' p step = go
>      where
>      go t r
>        | p t = r
>        | otherwise = uncurry go $ step (t, r)
>
> -- Dan
>
> On Sat, Mar 26, 2016 at 1:50 PM, George Colpitts
> <george.colpitts at gmail.com> wrote:
> > The following higher order function, sumh, seems to be 3 to 14 times
> slower
> > than the equivalent recursive function, sumr:
> >
> > sumh :: Double -> Double
> > sumh n =
> >     snd $ until ((>= n) . fst) as' (1, 0)
> >     where
> >       as' (i,s) =
> >           (i + 2, s + (-1) / i + 1 / (i + 1))
> >
> > sumr :: Double -> Double
> > sumr n =
> >     as' 1 0
> >     where
> >       as' i  s
> >           | i >= n    = s
> >           | otherwise = as' (i + 2) (s + (-1) / i + 1 / (i + 1))
> >
> > This is true in 7.10.3 as well as 8.0.1 so this is not a regression. From
> > the size usage my guess is that this is due to the allocation of tuples
> in
> > sumh. Maybe there is a straightforward way to optimize sumh but I
> couldn't
> > find it. Adding a Strict pragma didn't help nor did use of
> > -funbox-strict-fields -flate-dmd-anal. Have I missed something or should
> I
> > file a bug?
> >
> > Timings from 8.0.1 rc2:
> >
> > ghc --version
> > The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160204
> > bash-3.2$ ghc -O2 -dynamic sum.hs
> > ghc -O2 -dynamic sum.hs
> > [1 of 1] Compiling Main             ( sum.hs, sum.o )
> > Linking sum ...
> > bash-3.2$ ghci
> > Prelude> :load sum
> > Ok, modules loaded: Main.
> > (0.05 secs,)
> > Prelude Main> sumh (10^6)
> > -0.6931466805602525
> > it :: Double
> > (0.14 secs, 40,708,016 bytes)
> > Prelude Main> sumr (10^6)
> > -0.6931466805602525
> > it :: Double
> > (0.01 secs, 92,000 bytes)
> >
> > Thanks
> > George
> >
> > _______________________________________________
> > 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/20160327/6c848335/attachment.html>

From dan.doel at gmail.com  Sun Mar 27 22:44:45 2016
From: dan.doel at gmail.com (Dan Doel)
Date: Sun, 27 Mar 2016 18:44:45 -0400
Subject: until, laziness, and performance
In-Reply-To: <CAB-d4A7YNvuXxuy9o1pQjshToDn1jxyfxXTXPg+ocmYv4pZrDA@mail.gmail.com>
References: <CAB-d4A7YNvuXxuy9o1pQjshToDn1jxyfxXTXPg+ocmYv4pZrDA@mail.gmail.com>
Message-ID: <CAHEA9tMkeYKRBXonUPqLB__JKXXZvZR=tC_jBMXqLq2b=Zr36w@mail.gmail.com>

On Sun, Mar 27, 2016 at 4:42 PM, George Colpitts
<george.colpitts at gmail.com> wrote:
> I still don't understand why
>
> as' i s
>      | i >= n    = s
>      | otherwise = as' (i + 2) (s + (-1) / i + 1 / (i + 1))
>
>
> is not lazy in its second arg as it only has to evaluate it if i >= n. This
> seems exactly analogous to or, ||, which only needs to evaluate its second
> arg if its first arg is False. || is definitely lazy in its second argument.
> Can you explain why as' is strict in its second arg, s? Is it due to the
> following from,
> https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Demand ?

The simplest way to see why as' is strict in s is to use the actual
definition of strictness, and not think about operational semantics.
The definition is that a function f is strict if `f undefined =
undefined`. So, what is `as' i undefined`?

If `i >= n` then `as' i undefined = undefined`
if not `i >= n` then `as' i undefined = as' (i+2) undefined`

The second case holds because Double arithmetic is strict, so the
complex expression will be undefined because s is.

>From these cases we can reason that the result will always be
undefined. Either the value of i will grow such that the first case
succeeds, or if that will never happen (if n is NaN for instance), the
loop will continue forever, in which case the result is equivalent to
undefined semantically.

Because of this denotational analysis, we are at liberty to make the
operation of as' such that it always evaluates s immediately, because
it won't change the answer. And that is the optimization that saves
time/space.

By contrast, my alternate function:

    as' i s
      | i >= n = (i, s)
      | otherwise = as' (i+2) (...)

is easily not strict in s, because:

    as' i undefined = (i, undefined)

when `i >= n` is True, and (i, undefined) is not undefined. So it is
invalid to perform the same optimization, because it would change the
answer on some inputs. We happen to know that all the places the
function is used, those two answers would be equivalent (because we
just project out the second item), but that's somewhat difficult,
non-local reasoning.

Note that GHC does do some optimization. The loop in until is (in this
case) a loop on a pair, and it figures out that the loop is strict in
the pair, and eliminates the construction of the pair (by passing two
separate arguments, and returning an unboxed pair from the loop).
Optimizing the pieces of the pair would have to be a sort of
speculative operation (without doing a global analysis), where 2^k
different versions of the loop are generated (where k is the number of
non-strict pieces), and the call sites are optimized to call the best
of those versions for them. But 2^k isn't a good looking number for
this sort of thing.

-- Dan

From george.colpitts at gmail.com  Sun Mar 27 22:52:27 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Sun, 27 Mar 2016 22:52:27 +0000
Subject: until, laziness, and performance
In-Reply-To: <CAHEA9tMkeYKRBXonUPqLB__JKXXZvZR=tC_jBMXqLq2b=Zr36w@mail.gmail.com>
References: <CAB-d4A7YNvuXxuy9o1pQjshToDn1jxyfxXTXPg+ocmYv4pZrDA@mail.gmail.com>
 <CAHEA9tMkeYKRBXonUPqLB__JKXXZvZR=tC_jBMXqLq2b=Zr36w@mail.gmail.com>
Message-ID: <CAB-d4A6NOLimpwSxC7cC6Pqhfmjg=xrV+vNSXDVcWyvDZR8Rbw@mail.gmail.com>

Got it! Thanks!!

On Sun, Mar 27, 2016 at 7:44 PM Dan Doel <dan.doel at gmail.com> wrote:

> On Sun, Mar 27, 2016 at 4:42 PM, George Colpitts
> <george.colpitts at gmail.com> wrote:
> > I still don't understand why
> >
> > as' i s
> >      | i >= n    = s
> >      | otherwise = as' (i + 2) (s + (-1) / i + 1 / (i + 1))
> >
> >
> > is not lazy in its second arg as it only has to evaluate it if i >= n.
> This
> > seems exactly analogous to or, ||, which only needs to evaluate its
> second
> > arg if its first arg is False. || is definitely lazy in its second
> argument.
> > Can you explain why as' is strict in its second arg, s? Is it due to the
> > following from,
> > https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Demand ?
>
> The simplest way to see why as' is strict in s is to use the actual
> definition of strictness, and not think about operational semantics.
> The definition is that a function f is strict if `f undefined =
> undefined`. So, what is `as' i undefined`?
>
> If `i >= n` then `as' i undefined = undefined`
> if not `i >= n` then `as' i undefined = as' (i+2) undefined`
>
> The second case holds because Double arithmetic is strict, so the
> complex expression will be undefined because s is.
>
> From these cases we can reason that the result will always be
> undefined. Either the value of i will grow such that the first case
> succeeds, or if that will never happen (if n is NaN for instance), the
> loop will continue forever, in which case the result is equivalent to
> undefined semantically.
>
> Because of this denotational analysis, we are at liberty to make the
> operation of as' such that it always evaluates s immediately, because
> it won't change the answer. And that is the optimization that saves
> time/space.
>
> By contrast, my alternate function:
>
>     as' i s
>       | i >= n = (i, s)
>       | otherwise = as' (i+2) (...)
>
> is easily not strict in s, because:
>
>     as' i undefined = (i, undefined)
>
> when `i >= n` is True, and (i, undefined) is not undefined. So it is
> invalid to perform the same optimization, because it would change the
> answer on some inputs. We happen to know that all the places the
> function is used, those two answers would be equivalent (because we
> just project out the second item), but that's somewhat difficult,
> non-local reasoning.
>
> Note that GHC does do some optimization. The loop in until is (in this
> case) a loop on a pair, and it figures out that the loop is strict in
> the pair, and eliminates the construction of the pair (by passing two
> separate arguments, and returning an unboxed pair from the loop).
> Optimizing the pieces of the pair would have to be a sort of
> speculative operation (without doing a global analysis), where 2^k
> different versions of the loop are generated (where k is the number of
> non-strict pieces), and the call sites are optimized to call the best
> of those versions for them. But 2^k isn't a good looking number for
> this sort of thing.
>
> -- Dan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160327/204f7f06/attachment-0001.html>

From ben at smart-cactus.org  Mon Mar 28 09:45:39 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 28 Mar 2016 11:45:39 +0200
Subject: GHC 8 superclass chain constraint regression
In-Reply-To: <87a8lkavr1.fsf@feelingofgreen.ru>
References: <87a8lkavr1.fsf@feelingofgreen.ru>
Message-ID: <87mvpj6im4.fsf@smart-cactus.org>

Kosyrev Serge <_deepfire at feelingofgreen.ru> writes:

> Good day!
>
Hi Kosyrev!

Thanks for reporting this. Have you opened a Trac ticket for this issue?
If not could you do so?

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160328/20a875ba/attachment.sig>

From eir at cis.upenn.edu  Mon Mar 28 12:55:16 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 28 Mar 2016 14:55:16 +0200
Subject: instantiating visible parameters in when deriving instances
Message-ID: <8CCBACDE-89F4-4058-BF17-199ADDBE7379@cis.upenn.edu>

Hi devs,

Consider the following:

> data Proxy k (a :: k) = P
>   deriving Functor

What should happen when this is compiled?
 1. Issue an error saying that `deriving` cannot instantiate visible parameters.
 2. Type error: cannot match `k` with `*`.
 3. Successfully produce `instance (Proxy *)`.

Currently, GHC does #3. But this ends up choosing a value for a visible (i.e. explicit) parameter to Proxy. Is this a good idea? I myself have flip-flopped on this issue; see https://ghc.haskell.org/trac/ghc/ticket/11732, comments 4 and 9.

I'd love to get feedback on this point.

Thanks!
Richard

From george.colpitts at gmail.com  Mon Mar 28 13:22:59 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Mon, 28 Mar 2016 10:22:59 -0300
Subject: New type of ($) operator in GHC 8.0 is problematic
In-Reply-To: <CA+Vhx4T3B1b+JidNzNU0vJnL=NTcdU_ewycOoctCfdw6dC7TtQ@mail.gmail.com>
References: <CADdQpRDFNhDE79D37DZAw2Z2fpY73=2hts9W4-DVZx5iK13pCQ@mail.gmail.com>
 <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com>
 <DE67E064-0CD4-42A3-82D8-DBDBECDB36C5@cis.upenn.edu>
 <CAJ0eudoPdQ23SniL7NE2dMFvJOCzG0rv9uh+MkbRFkVghuT2Sw@mail.gmail.com>
 <87si0u6y9h.fsf@smart-cactus.org>
 <CAJ0eudpmejY8Tefr98jNSzRH4qJ4-d6FHX3=D9a0GSywEO337Q@mail.gmail.com>
 <8737st6iyg.fsf@smart-cactus.org>
 <98EE8A62-8397-4D21-ABB4-63D4604D7062@cis.upenn.edu>
 <9723F5A2-8FA7-4389-AE55-B46481748216@justtesting.org>
 <CADnndOrb_CACoOG4nphk+NF4HPfknT14ibSTav=d3c0gZDVHtw@mail.gmail.com>
 <1455764544.2889103.524482378.1C9DA511@webmail.messagingengine.com>
 <C90C0188-2850-4262-B40E-0CF192AA48CF@justtesting.org>
 <CA+Vhx4T3B1b+JidNzNU0vJnL=NTcdU_ewycOoctCfdw6dC7TtQ@mail.gmail.com>
Message-ID: <CAB-d4A6HN5YKEKEeki9tp6ksJc3miJzD_cJF9-HuF8LV3RnDXw@mail.gmail.com>

Was there any consensus on how to move forward on this? I just found
another example of
??
8.0 type which is not beginner friendly:

bash-3.2$ ghci
GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/  :? for help
Prelude> True
True
it :: Bool
Prelude> True || undefined
True
*it :: ?callStack::GHC.Stack.Types.CallStack => Bool*



On Wed, Mar 2, 2016 at 1:56 PM Ericson, John <john_ericson at brown.edu> wrote:

> I dispute your second point a bit: I consider any Prelude changes a
> standard library change than a language change, not withstanding the fact
> the Prelude is imported by default. Any beginner-language library can still
> be imported from normal code. Likewise a "hygienic copy paste" would simply
> import the beginner prelude qualified and mangle identifiers as necessary.
>
> I'm inclined to think the Racket way is the only true solution here.
>
> John
>
>
> On Wed, Feb 24, 2016 at 6:07 PM, Manuel M T Chakravarty <
> chak at justtesting.org> wrote:
>
>> Two notable differences between Racket and the situation in Haskell is
>> that (1) Racket has a full blown IDE to support the staged languages and
>> (2) AFIK any Racket program in a simpler language is still a valid Racket
>> program in a more advanced language. (The latter wouldn?t be the case with,
>> e.g., a Prelude omitting type classes as you need to introduce new names
>> ?to avoid overloading? that are no longer valid in the full Prelude.)
>>
>> Manuel
>>
>> > Eric Seidel <eric at seidel.io>:
>> >
>> > On Wed, Feb 17, 2016, at 08:09, Christopher Allen wrote:
>> >> I have tried a beginner's Prelude with people. I don't have a lot of
>> data
>> >> because it was clearly a failure early on so I bailed them out into the
>> >> usual thing. It's just not worth it and it deprives them of the
>> >> preparedness to go write real Haskell code. That's not something I'm
>> >> willing to give up just so I can teach _less_.
>> >
>> > Chris, have you written about your experiences teaching with a
>> > beginner's Prelude? I'd be quite interested to read about it, as (1) it
>> > seems like a natural thing to do and (2) the Racket folks seem to have
>> > had good success with their staged teaching languages.
>> >
>> > In particular, I'm curious if your experience is in the context of
>> > teaching people with no experience programming at all, vs programming
>> > experience but no Haskell (or generally FP) experience. The Racket "How
>> > to Design Programs" curriculum seems very much geared towards absolute
>> > beginners, and that could be a relevant distinction.
>> >
>> > Thanks!
>> > Eric
>> > _______________________________________________
>> > 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/20160328/948a0555/attachment.html>

From eric at seidel.io  Mon Mar 28 13:42:38 2016
From: eric at seidel.io (Eric Seidel)
Date: Mon, 28 Mar 2016 06:42:38 -0700
Subject: instantiating visible parameters in when deriving instances
In-Reply-To: <8CCBACDE-89F4-4058-BF17-199ADDBE7379@cis.upenn.edu>
References: <8CCBACDE-89F4-4058-BF17-199ADDBE7379@cis.upenn.edu>
Message-ID: <1459172558.1689167.561411050.5A51C88F@webmail.messagingengine.com>

I'm inclined to go with option 3 as `Functor (Proxy *)` is the only
instance that would typecheck. 

Perhaps with a warning to let the user know the instance is less general
than they might expect? I think this is the most user-friendly route:
the user can suppress the warning if they don't care, or make it an
error if they do care. 

On Mon, Mar 28, 2016, at 05:55, Richard Eisenberg wrote:
> Hi devs,
> 
> Consider the following:
> 
> > data Proxy k (a :: k) = P
> >   deriving Functor
> 
> What should happen when this is compiled?
>  1. Issue an error saying that `deriving` cannot instantiate visible
>  parameters.
>  2. Type error: cannot match `k` with `*`.
>  3. Successfully produce `instance (Proxy *)`.
> 
> Currently, GHC does #3. But this ends up choosing a value for a visible
> (i.e. explicit) parameter to Proxy. Is this a good idea? I myself have
> flip-flopped on this issue; see
> https://ghc.haskell.org/trac/ghc/ticket/11732, comments 4 and 9.
> 
> I'd love to get feedback on this point.
> 
> Thanks!
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From eric at seidel.io  Mon Mar 28 13:45:28 2016
From: eric at seidel.io (Eric Seidel)
Date: Mon, 28 Mar 2016 06:45:28 -0700
Subject: New type of ($) operator in GHC 8.0 is problematic
In-Reply-To: <CAB-d4A6HN5YKEKEeki9tp6ksJc3miJzD_cJF9-HuF8LV3RnDXw@mail.gmail.com>
References: <CADdQpRDFNhDE79D37DZAw2Z2fpY73=2hts9W4-DVZx5iK13pCQ@mail.gmail.com>
 <87egcg93zn.fsf@smart-cactus.org> <1455381609.2134.16.camel@gmail.com>
 <DE67E064-0CD4-42A3-82D8-DBDBECDB36C5@cis.upenn.edu>
 <CAJ0eudoPdQ23SniL7NE2dMFvJOCzG0rv9uh+MkbRFkVghuT2Sw@mail.gmail.com>
 <87si0u6y9h.fsf@smart-cactus.org>
 <CAJ0eudpmejY8Tefr98jNSzRH4qJ4-d6FHX3=D9a0GSywEO337Q@mail.gmail.com>
 <8737st6iyg.fsf@smart-cactus.org>
 <98EE8A62-8397-4D21-ABB4-63D4604D7062@cis.upenn.edu>
 <9723F5A2-8FA7-4389-AE55-B46481748216@justtesting.org>
 <CADnndOrb_CACoOG4nphk+NF4HPfknT14ibSTav=d3c0gZDVHtw@mail.gmail.com>
 <1455764544.2889103.524482378.1C9DA511@webmail.messagingengine.com>
 <C90C0188-2850-4262-B40E-0CF192AA48CF@justtesting.org>
 <CA+Vhx4T3B1b+JidNzNU0vJnL=NTcdU_ewycOoctCfdw6dC7TtQ@mail.gmail.com>
 <CAB-d4A6HN5YKEKEeki9tp6ksJc3miJzD_cJF9-HuF8LV3RnDXw@mail.gmail.com>
Message-ID: <1459172728.1689431.561417794.059E367E@webmail.messagingengine.com>

Yes, the inference of call-stacks is being removed. I'm just waiting for
the patch to be reviewed. 

On Mon, Mar 28, 2016, at 06:22, George Colpitts wrote:
> Was there any consensus on how to move forward on this? I just found
> another example of
> ??
> 8.0 type which is not beginner friendly:
> 
> bash-3.2$ ghci
> GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/  :? for help
> Prelude> True
> True
> it :: Bool
> Prelude> True || undefined
> True
> *it :: ?callStack::GHC.Stack.Types.CallStack => Bool*
> 
> 
> 
> On Wed, Mar 2, 2016 at 1:56 PM Ericson, John <john_ericson at brown.edu>
> wrote:
> 
> > I dispute your second point a bit: I consider any Prelude changes a
> > standard library change than a language change, not withstanding the fact
> > the Prelude is imported by default. Any beginner-language library can still
> > be imported from normal code. Likewise a "hygienic copy paste" would simply
> > import the beginner prelude qualified and mangle identifiers as necessary.
> >
> > I'm inclined to think the Racket way is the only true solution here.
> >
> > John
> >
> >
> > On Wed, Feb 24, 2016 at 6:07 PM, Manuel M T Chakravarty <
> > chak at justtesting.org> wrote:
> >
> >> Two notable differences between Racket and the situation in Haskell is
> >> that (1) Racket has a full blown IDE to support the staged languages and
> >> (2) AFIK any Racket program in a simpler language is still a valid Racket
> >> program in a more advanced language. (The latter wouldn?t be the case with,
> >> e.g., a Prelude omitting type classes as you need to introduce new names
> >> ?to avoid overloading? that are no longer valid in the full Prelude.)
> >>
> >> Manuel
> >>
> >> > Eric Seidel <eric at seidel.io>:
> >> >
> >> > On Wed, Feb 17, 2016, at 08:09, Christopher Allen wrote:
> >> >> I have tried a beginner's Prelude with people. I don't have a lot of
> >> data
> >> >> because it was clearly a failure early on so I bailed them out into the
> >> >> usual thing. It's just not worth it and it deprives them of the
> >> >> preparedness to go write real Haskell code. That's not something I'm
> >> >> willing to give up just so I can teach _less_.
> >> >
> >> > Chris, have you written about your experiences teaching with a
> >> > beginner's Prelude? I'd be quite interested to read about it, as (1) it
> >> > seems like a natural thing to do and (2) the Racket folks seem to have
> >> > had good success with their staged teaching languages.
> >> >
> >> > In particular, I'm curious if your experience is in the context of
> >> > teaching people with no experience programming at all, vs programming
> >> > experience but no Haskell (or generally FP) experience. The Racket "How
> >> > to Design Programs" curriculum seems very much geared towards absolute
> >> > beginners, and that could be a relevant distinction.
> >> >
> >> > Thanks!
> >> > Eric
> >> > _______________________________________________
> >> > 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
> >
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From _deepfire at feelingofgreen.ru  Mon Mar 28 14:17:06 2016
From: _deepfire at feelingofgreen.ru (Kosyrev Serge)
Date: Mon, 28 Mar 2016 17:17:06 +0300
Subject: GHC 8 superclass chain constraint regression
In-Reply-To: <87mvpj6im4.fsf@smart-cactus.org>
 (sfid-20160328_141408_952655_2C70CF7D) (Ben Gamari's message of "Mon,
 28 Mar 2016 11:45:39 +0200")
References: <87a8lkavr1.fsf@feelingofgreen.ru>
 <87mvpj6im4.fsf@smart-cactus.org>
Message-ID: <87vb46d6vx.fsf@feelingofgreen.ru>

Ben Gamari <ben at smart-cactus.org> writes:
> Kosyrev Serge <_deepfire at feelingofgreen.ru> writes:
>
> Thanks for reporting this. Have you opened a Trac ticket for this issue?
> If not could you do so?

Just done so:

  https://ghc.haskell.org/trac/ghc/ticket/11762#ticket

-- 
? ???????e?,
??????? ??????

From andrew.thaddeus at gmail.com  Mon Mar 28 14:54:22 2016
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Mon, 28 Mar 2016 10:54:22 -0400
Subject: instantiating visible parameters in when deriving instances
In-Reply-To: <8CCBACDE-89F4-4058-BF17-199ADDBE7379@cis.upenn.edu>
References: <8CCBACDE-89F4-4058-BF17-199ADDBE7379@cis.upenn.edu>
Message-ID: <CABNC7eMjKXwWPs2DnejdqUgtn8O0o-xCXOzNy7tjbewS8dqS7A@mail.gmail.com>

I like number option number two. I don't really expect any of the
TypeInType stuff to work with the deriving machinery. I think that, at the
moment, for a normal deriving clause, GHC never adds in constraints (I
might be wrong on this). Whenever constraints, I feel like
StandaloneDeriving is the right choice. I don't know if StandaloneDeriving
works with DeriveFunctor or not, but if it does, then this is what I would
expect:

    REJECTED
    data Proxy k (a :: k) = P
      deriving Functor

    ACCEPTED
    data Proxy k (a :: k) = P
    deriving instance (k ~ *) => Functor Proxy k

But if the second code snippet involving StandaloneDeriving can't be made
to work, I would still prefer for the first snippet to be rejected as well.
Just my two cents.

-Andrew Thaddeus Martin

On Mon, Mar 28, 2016 at 8:55 AM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

> Hi devs,
>
> Consider the following:
>
> > data Proxy k (a :: k) = P
> >   deriving Functor
>
> What should happen when this is compiled?
>  1. Issue an error saying that `deriving` cannot instantiate visible
> parameters.
>  2. Type error: cannot match `k` with `*`.
>  3. Successfully produce `instance (Proxy *)`.
>
> Currently, GHC does #3. But this ends up choosing a value for a visible
> (i.e. explicit) parameter to Proxy. Is this a good idea? I myself have
> flip-flopped on this issue; see
> https://ghc.haskell.org/trac/ghc/ticket/11732, comments 4 and 9.
>
> I'd love to get feedback on this point.
>
> Thanks!
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160328/52d810a8/attachment-0001.html>

From ryan.gl.scott at gmail.com  Mon Mar 28 15:12:21 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Mon, 28 Mar 2016 11:12:21 -0400
Subject: instantiating visible parameters in when deriving instances
Message-ID: <CADdQpRBEDrTiKLgKQu3fjv6pBdua_nXjNTNe4kzVpezD+5eJtQ@mail.gmail.com>

> I don't really expect any of the TypeInType stuff to work with the deriving machinery.

I do! And we can make -XDeriveFunctor work well with -XTypeInType
regardless of which option is picked, so keep that in mind.

> I think that, at the moment, for a normal deriving clause, GHC never adds in constraints (I might be wrong on this).

GHC does add constraints in some cases. Here's a less dangerous-looking example:

    data T (a :: k) = T deriving Functor
    =>
    instance Functor T

The generated instance very subtly constraints k to be *. The
difference in this example, however, is that k is not visible, so it
feels less harmful to constrain it.

> I don't know if StandaloneDeriving works with DeriveFunctor or not

It does. -XStandaloneDeriving works with any flavor of deriving out
there, and it's a great backdoor to get around sticky deriving issues
like this (e.g., if a derived instance context would require
undecidable typechecking, we bail out and tell the user to try again
with -XStandaloneDeriving).

I don't have a strong opinion on whether option 1, 2, or 3 is best,
but if we pick option 1 or 2, I request that the error message tell
the user to try -XStandaloneDeriving.

Ryan S.

From andrew.thaddeus at gmail.com  Mon Mar 28 18:08:12 2016
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Mon, 28 Mar 2016 14:08:12 -0400
Subject: More Higher-Kinded Typeclass Instances
Message-ID: <CABNC7eMPAB7fFGOP7JgQG9MUteJTB7N8WgrEVyvhkmZrs626dA@mail.gmail.com>

Earlier today, I wrote Proxy's instances for Eq1, Ord1, Show1, and Read1
and they were accepted for base-4.9.0.0. All in all, the process went way
more smoothly than I expected, and so I started thinking about what other
types from base are currently missing these instances, and this is what
I've come up with:

    - Down (from Data.Ord)
    - Complex (from Data.Complex)
    - Ratio (from Data.Ratio)
    - First, Last (from Data.Monoid)
    - ZipList (from Control.Applicative)
    - Ptr, FunPtr (from Foreign.Ptr, only Eq1 and Ord1)
    - StablePtr (from Foreign.StablePtr, only Eq1)
    - K1, U1, Par1, Rec1, etc. (from GHC.Generics)
    - StableName (from System.Mem.StableName, only Eq1, requested here:
http://hub.darcs.net/ross/transformers/issue/17)

Since most of these are trivial to implement, I'd like to try to get them
in for GHC-8.0. Does anyone have in mind any other data types that would
benefit from these?

-- 
-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160328/abdad713/attachment.html>

From eir at cis.upenn.edu  Mon Mar 28 19:05:28 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 28 Mar 2016 21:05:28 +0200
Subject: instantiating visible parameters in when deriving instances
In-Reply-To: <CADdQpRBEDrTiKLgKQu3fjv6pBdua_nXjNTNe4kzVpezD+5eJtQ@mail.gmail.com>
References: <CADdQpRBEDrTiKLgKQu3fjv6pBdua_nXjNTNe4kzVpezD+5eJtQ@mail.gmail.com>
Message-ID: <CEF90857-4F96-4FA2-818E-DED5E756A81D@cis.upenn.edu>

I started this thread feeling uncomfortable about a `deriving` clause instantiating `k` to `*`. But `deriving` *does* infer constraints. Perhaps it's just inferring a `(k ~ *)` constraint. Thinking of it this way makes me prefer (3).

Richard

On Mar 28, 2016, at 5:12 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:

>> I don't really expect any of the TypeInType stuff to work with the deriving machinery.
> 
> I do! And we can make -XDeriveFunctor work well with -XTypeInType
> regardless of which option is picked, so keep that in mind.
> 
>> I think that, at the moment, for a normal deriving clause, GHC never adds in constraints (I might be wrong on this).
> 
> GHC does add constraints in some cases. Here's a less dangerous-looking example:
> 
>    data T (a :: k) = T deriving Functor
>    =>
>    instance Functor T
> 
> The generated instance very subtly constraints k to be *. The
> difference in this example, however, is that k is not visible, so it
> feels less harmful to constrain it.
> 
>> I don't know if StandaloneDeriving works with DeriveFunctor or not
> 
> It does. -XStandaloneDeriving works with any flavor of deriving out
> there, and it's a great backdoor to get around sticky deriving issues
> like this (e.g., if a derived instance context would require
> undecidable typechecking, we bail out and tell the user to try again
> with -XStandaloneDeriving).
> 
> I don't have a strong opinion on whether option 1, 2, or 3 is best,
> but if we pick option 1 or 2, I request that the error message tell
> the user to try -XStandaloneDeriving.
> 
> Ryan S.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From ben at well-typed.com  Mon Mar 28 19:12:48 2016
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 28 Mar 2016 21:12:48 +0200
Subject: GHC 8.0.1 release plan
Message-ID: <87io0676xb.fsf@smart-cactus.org>

Hello GHCers,

After numerous delays, I think we may finally be converging on a
(hopefully final) 8.0.1 release candidate. Thanks to the tireless
efforts of Richard Eisenberg, Simon PJ, and many others almost all of
the release blocking tickets [1] have now been resolved. There are a few
patches currently waiting for review that should hopefully be mergeable
within the next few days.

After these last patches have been merged I'll proceed in cutting
the source distribution for GHC 8.0.1 release candidate 3. This release
candidate will be made available immediately, although, in accordance
with our new release policy [2], binary distributions won't be available
until seven days later.

Release candidate 3 will hopefully be the final release candidate for
8.0.1; the final 8.0.1 release will, with luck, be released in
mid-April.

This has indeed been a rather peculiar release and we hope that we'll
be able to stick to a more consistent schedule for future releases.
After the 8.0.1 release we'll need to discuss how we'd like to set the
timeline for 8.2, our next major release.

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1#Ticketsslatedfor8.0.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160328/748c4215/attachment.sig>

From ben at well-typed.com  Mon Mar 28 19:16:19 2016
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 28 Mar 2016 21:16:19 +0200
Subject: GHC 8.0.1 release plan
In-Reply-To: <87io0676xb.fsf@smart-cactus.org>
References: <87io0676xb.fsf@smart-cactus.org>
Message-ID: <87fuva76rg.fsf@smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> Hello GHCers,
>
> After numerous delays, I think we may finally be converging on a
> (hopefully final) 8.0.1 release candidate. Thanks to the tireless
> efforts of Richard Eisenberg, Simon PJ, and many others almost all of
> the release blocking tickets [1] have now been resolved. There are a few
> patches currently waiting for review that should hopefully be mergeable
> within the next few days.
>
> After these last patches have been merged I'll proceed in cutting
> the source distribution for GHC 8.0.1 release candidate 3. This release
> candidate will be made available immediately, although, in accordance
> with our new release policy [2], binary distributions won't be available
> until seven days later.
>
Oops, forgot the reference here. The new release timing policy was
described here,

[2] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160328/1be74851/attachment.sig>

From simonpj at microsoft.com  Tue Mar 29 10:24:49 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 29 Mar 2016 10:24:49 +0000
Subject: possible tuple elimination optimization?
In-Reply-To: <CAHEA9tNY2mh_C-17L+U6R+ewjrxsHgOZN3W286Y0mJPeL1kz5Q@mail.gmail.com>
References: <CAB-d4A5PtZ5cLyNdkHh_7Z3yg8Okgmm1fBUWmiC68ikpAiqEBQ@mail.gmail.com>
 <CAHEA9tNY2mh_C-17L+U6R+ewjrxsHgOZN3W286Y0mJPeL1kz5Q@mail.gmail.com>
Message-ID: <09f3c0d4bc874115a1b4a6512fabd1cb@DB4PR30MB030.064d.mgd.msft.net>

Yes: see https://ghc.haskell.org/trac/ghc/wiki/NestedCPR

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Dan Doel
| Sent: 26 March 2016 20:41
| To: George Colpitts <george.colpitts at gmail.com>
| Cc: ghc-devs at haskell.org
| Subject: Re: possible tuple elimination optimization?
| 
| By the way, in case this helps your mental model, if you modify sumr to be:
| 
|     sumr n = snd $ as' 1 0
|       where
|       as' i s
|         | i >= n = (i, s)
|         | otherwise = ...
| 
| Then it has the same problem as sumh. Your original as' for sumr is
| strict in s, but this modified one isn't.
| 
| This shows another way to fix sumh, too. Create a version of until
| that separates out the part of the state that is only for testing.
| Then the until loop will be strict in the result part of the state,
| and the desired optimizations will happen (in this case):
| 
|     until' p step = go
|      where
|      go t r
|        | p t = r
|        | otherwise = uncurry go $ step (t, r)
| 
| -- Dan
| 
| On Sat, Mar 26, 2016 at 1:50 PM, George Colpitts
| <george.colpitts at gmail.com> wrote:
| > The following higher order function, sumh, seems to be 3 to 14 times slower
| > than the equivalent recursive function, sumr:
| >
| > sumh :: Double -> Double
| > sumh n =
| >     snd $ until ((>= n) . fst) as' (1, 0)
| >     where
| >       as' (i,s) =
| >           (i + 2, s + (-1) / i + 1 / (i + 1))
| >
| > sumr :: Double -> Double
| > sumr n =
| >     as' 1 0
| >     where
| >       as' i  s
| >           | i >= n    = s
| >           | otherwise = as' (i + 2) (s + (-1) / i + 1 / (i + 1))
| >
| > This is true in 7.10.3 as well as 8.0.1 so this is not a regression. From
| > the size usage my guess is that this is due to the allocation of tuples in
| > sumh. Maybe there is a straightforward way to optimize sumh but I couldn't
| > find it. Adding a Strict pragma didn't help nor did use of
| > -funbox-strict-fields -flate-dmd-anal. Have I missed something or should I
| > file a bug?
| >
| > Timings from 8.0.1 rc2:
| >
| > ghc --version
| > The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160204
| > bash-3.2$ ghc -O2 -dynamic sum.hs
| > ghc -O2 -dynamic sum.hs
| > [1 of 1] Compiling Main             ( sum.hs, sum.o )
| > Linking sum ...
| > bash-3.2$ ghci
| > Prelude> :load sum
| > Ok, modules loaded: Main.
| > (0.05 secs,)
| > Prelude Main> sumh (10^6)
| > -0.6931466805602525
| > it :: Double
| > (0.14 secs, 40,708,016 bytes)
| > Prelude Main> sumr (10^6)
| > -0.6931466805602525
| > it :: Double
| > (0.01 secs, 92,000 bytes)
| >
| > Thanks
| > George
| >
| > _______________________________________________
| > ghc-devs mailing list
| > ghc-devs at haskell.org
| >
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cec78251e0f564b23014708
| d355b6ed56%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7u50FvyHKPpAXiweli%2b
| 0CP1pup15X8Kh9rN8JrIXP78%3d
| >
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cec78251e0f564b23014708
| d355b6ed56%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7u50FvyHKPpAXiweli%2b
| 0CP1pup15X8Kh9rN8JrIXP78%3d

From simonpj at microsoft.com  Tue Mar 29 11:45:02 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 29 Mar 2016 11:45:02 +0000
Subject: instantiating visible parameters in when deriving instances
In-Reply-To: <8CCBACDE-89F4-4058-BF17-199ADDBE7379@cis.upenn.edu>
References: <8CCBACDE-89F4-4058-BF17-199ADDBE7379@cis.upenn.edu>
Message-ID: <3c8720d4241d4a5ca2948edbddea944f@DB4PR30MB030.064d.mgd.msft.net>

Just to be clear to everyone else, we are discussing

   data P1   (a :: k) = MkP1 deriving Functor
   data P2 k (a :: k) = MkP2 deriving Functor

Here P2 has an explicit kind arg, which must appear in any use of P2; thus
   f :: P2 * Int -> Bool

Now the question is: what derived instances do we get?  We could get

  instance Functor (P1 (a :: *))
  instance Functor (P2 * (a ::*))

The question before the house is whether to reject either or both 'deriving' clauses, on the grounds that both instantiate 'k'; and ask for a stand-alone deriving declaration instead.  In principle we could say Yes/Yes, Yes/No, or No/No to the two cases.

As Richard points out, a 'deriving' clause attached to a 'data' decl infers some instance context.  That context must be written explicitly in a standalone deriving declaration. For example:

  data Maybe a = Nothing | Just a deriving( Eq )

we get the derived instance

  instance Eq a => Eq (Maybe a ) where
    (==) x y = ...blah...

The "Eq a" context in this instance declaration is magically inferred from the form of the data type declaration.  This inference process gets pretty tricky for Functor and Traversable. To use the instance declarations you have to understand what the inferred instance context is; GHC should really provide a way to tell you.

Richard points out (later in the thread) that "instantiating k" is like adding a constraint `k ~ *` to the instance, thus
{{{
  instance (k ~ *) => Functor (P1 (a :: k))
}}}
That's not quite true, because this instance will match for any k, and hence overlaps with putative instances for k's other than `*`; whereas
{{{
  instance Functor P1 (a :: *)
}}}
matches only for the `*` case.  And that is a subtle distinction indeed!

Humph.  I am rather persuaded by Richard's argument. Proposal: just regard the kind constraints as extra inferred constraints, and hence generate
{{{
  instance (k ~ *) => Functor (P1 (a :: k))
}}}
Now the derived instance always has type variables in the head; but those type variables may be constrained by the context.  I like that.

It's not quite what happens now, so there would be a little implementation work to do.  It might quite possibly actually be simpler.

I'm going to dump this email into the ticket.

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Richard Eisenberg
|  Sent: 28 March 2016 13:55
|  To: GHC developers <ghc-devs at haskell.org>
|  Subject: instantiating visible parameters in when deriving instances
|  
|  Hi devs,
|  
|  Consider the following:
|  
|  > data Proxy k (a :: k) = P
|  >   deriving Functor
|  
|  What should happen when this is compiled?
|   1. Issue an error saying that `deriving` cannot instantiate visible
|  parameters.
|   2. Type error: cannot match `k` with `*`.
|   3. Successfully produce `instance (Proxy *)`.
|  
|  Currently, GHC does #3. But this ends up choosing a value for a visible
|  (i.e. explicit) parameter to Proxy. Is this a good idea? I myself have
|  flip-flopped on this issue; see
|  https://ghc.haskell.org/trac/ghc/ticket/11732, comments 4 and 9.
|  
|  I'd love to get feedback on this point.
|  
|  Thanks!
|  Richard
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c175b7c5afb594993
|  14e708d357083e9e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=d6dNjZWCi
|  IeqDBNFVSL13b6ZUG0QREf9UcqrVrqbpEA%3d

From ryan.gl.scott at gmail.com  Tue Mar 29 13:10:22 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Tue, 29 Mar 2016 09:10:22 -0400
Subject: More Higher-Kinded Typeclass Instances
Message-ID: <CADdQpRCqR1tsjfg-iqv0qwNXoGS6CZDrary4PBoEpCNttg6PQQ@mail.gmail.com>

Well, if we're going to be thorough, we need to also get:

* Tuple types
* All (* -> *)-kinded datatypes in Data.Monoid
* Data.Type.Equality.(:~:) and Data.Type.Coercion.Coercion
* Fixed
* ST, STRef
* Chan
* MVar, IORef, TVar

A lot of these types' existing Eq/Ord/Read/Show instances are
currently derived, however, and you might find it incredibly tedious
to type all them out by hand (not to discourage you from going for it
if you need them now, but we warned). Given that the window for new
8.0 features is almost closed, perhaps it would be better to wait
until I've implemented an extension which derives these classes
automatically?

(I wanted to get such an extension implemented sooner, but time ran
out. I'll try to find some time to write a wiki page proposing a
design so that we can get the ball rolling soon after the 8.0 final
release.)

Ryan S.

From ryan.gl.scott at gmail.com  Tue Mar 29 13:58:05 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Tue, 29 Mar 2016 09:58:05 -0400
Subject: instantiating visible parameters in when deriving instances
Message-ID: <CADdQpRCnsJFKQXNoYF4zW+h0yMOH5J547vkYn_+0CmCVPu12Bg@mail.gmail.com>

Simon, did you meant P2? (Since you can't write instance (k ~ *) =>
Functor (P1 (a :: k)), as that's ill-kinded). Something like this?

    data P2 k (a :: k) = MkP2
    instance (k ~ *) => Functor (P2 k)

That's an interesting idea. Be aware that you actually can't compile
that code at the moment, since GHC complains:

    * Expected kind ?* -> *?, but ?P2 k? has kind ?k -> *?
    * In the first argument of ?Functor?, namely ?P2 k?
      In the instance declaration for ?Functor (P2 k)?

I hope this is a bug and not a fundamental limitation.

There's another wrinkle in the design we must consider. Not only can
datatypes have dependent type parameters, but so can typeclasses
themselves. Consider:

    {-# LANGUAGE FlexibleInstances #-}
    {-# LANGUAGE GeneralizedNewtypeDeriving #-}
    {-# LANGUAGE MultiParamTypeClasses #-}
    {-# LANGUAGE TypeInType #-}
    module Cat where

    import Data.Kind

    class Cat k (cat :: k -> k -> *) where
      catId   :: cat a a
      catComp :: cat b c -> cat a b -> cat a c

    instance Cat * (->) where
      catId   = id
      catComp = (.)

    newtype Fun a b = Fun (a -> b) deriving (Cat k)

I was surprised to find out that this code currently compiles without
issue on GHC 8.0, even though we're deriving (Cat k) instead of (Cat
*). This is an effect of the way GHC currently handles deriving
clauses, since it unifies the kind of the datatype and typeclass
beforehand (therefore, it silently gets unified to Cat * before
generating the instance). [1]

Is this correct? It definitely feels a bit off. We currently allow
this (see Trac #8865 [2]):

    newtype T a b = MkT (Either a b) deriving ( Category )

Even though Category :: k -> k -> * (i.e., we silently unify k with
*). The difference here, as is the difference between P1 and P2 in
Simon's email, is that k is not visible, so it's out-of-sight and
out-of-mind. When k is visible, as in Cat, when now must be conscious
of how it's used in a deriving clause.

The Cat code is lying in the sense that we aren't deriving an instance
that begins with (Cat k), but rather:

    instance Cat * Fun where ...

Using Simon's advice, we could just as well generate:

    instance (k ~ *) => Cat k Fun where ...

(Again, this doesn't currently compile on 8.0. I really hope that's just a bug.)

So I'm starting to lean towards Simon's proposal. That is, we freely
unify non-visible type parameters when deriving, but if a type
parameter is visible, then we generate equality constraints instead of
unifying it.

Ryan S.
-----
[1] http://git.haskell.org/ghc.git/blob/b0ab8db61568305f50947058fc5573e2382c84eb:/compiler/typecheck/TcDeriv.hs#l653
[2] https://ghc.haskell.org/trac/ghc/ticket/8865

From andrew.thaddeus at gmail.com  Tue Mar 29 14:13:30 2016
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Tue, 29 Mar 2016 10:13:30 -0400
Subject: More Higher-Kinded Typeclass Instances
In-Reply-To: <CADdQpRCqR1tsjfg-iqv0qwNXoGS6CZDrary4PBoEpCNttg6PQQ@mail.gmail.com>
References: <CADdQpRCqR1tsjfg-iqv0qwNXoGS6CZDrary4PBoEpCNttg6PQQ@mail.gmail.com>
Message-ID: <CABNC7ePX64P8nZMgjNHNKbPZGR-8=JE2NTpjHeR9Sp5USC91KQ@mail.gmail.com>

Yeah, that is a lot of instances (especially all 62 types of tuples). I
think you're right that it makes more sense to do this with an extension to
the deriving mechanism, especially since even if I wrote them now, it would
probably make sense to redo them with a deriving clause later. At the
moment, I don't really need any of them but Proxy, which is already done,
some I'm happy to wait this one out. Thanks.

-Andrew Martin

On Tue, Mar 29, 2016 at 9:10 AM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:

> Well, if we're going to be thorough, we need to also get:
>
> * Tuple types
> * All (* -> *)-kinded datatypes in Data.Monoid
> * Data.Type.Equality.(:~:) and Data.Type.Coercion.Coercion
> * Fixed
> * ST, STRef
> * Chan
> * MVar, IORef, TVar
>
> A lot of these types' existing Eq/Ord/Read/Show instances are
> currently derived, however, and you might find it incredibly tedious
> to type all them out by hand (not to discourage you from going for it
> if you need them now, but we warned). Given that the window for new
> 8.0 features is almost closed, perhaps it would be better to wait
> until I've implemented an extension which derives these classes
> automatically?
>
> (I wanted to get such an extension implemented sooner, but time ran
> out. I'll try to find some time to write a wiki page proposing a
> design so that we can get the ball rolling soon after the 8.0 final
> release.)
>
> Ryan S.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160329/d706a61e/attachment.html>

From simonpj at microsoft.com  Tue Mar 29 14:47:57 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 29 Mar 2016 14:47:57 +0000
Subject: instantiating visible parameters in when deriving instances
In-Reply-To: <CADdQpRCnsJFKQXNoYF4zW+h0yMOH5J547vkYn_+0CmCVPu12Bg@mail.gmail.com>
References: <CADdQpRCnsJFKQXNoYF4zW+h0yMOH5J547vkYn_+0CmCVPu12Bg@mail.gmail.com>
Message-ID: <274a0fee370241cebaad1dbc8b33b5dd@DB4PR30MB030.064d.mgd.msft.net>

|  So I'm starting to lean towards Simon's proposal. That is, we freely
|  unify non-visible type parameters when deriving, but if a type
|  parameter is visible, then we generate equality constraints instead of
|  unifying it.

Why should it make a difference whether it's visible or not.  Can't we behave the same for both?

Simon


|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ryan
|  Scott
|  Sent: 29 March 2016 14:58
|  To: ghc-devs at haskell.org
|  Subject: Re: instantiating visible parameters in when deriving
|  instances
|  
|  Simon, did you meant P2? (Since you can't write instance (k ~ *) =>
|  Functor (P1 (a :: k)), as that's ill-kinded). Something like this?
|  
|      data P2 k (a :: k) = MkP2
|      instance (k ~ *) => Functor (P2 k)
|  
|  That's an interesting idea. Be aware that you actually can't compile
|  that code at the moment, since GHC complains:
|  
|      * Expected kind ?* -> *?, but ?P2 k? has kind ?k -> *?
|      * In the first argument of ?Functor?, namely ?P2 k?
|        In the instance declaration for ?Functor (P2 k)?
|  
|  I hope this is a bug and not a fundamental limitation.
|  
|  There's another wrinkle in the design we must consider. Not only can
|  datatypes have dependent type parameters, but so can typeclasses
|  themselves. Consider:
|  
|      {-# LANGUAGE FlexibleInstances #-}
|      {-# LANGUAGE GeneralizedNewtypeDeriving #-}
|      {-# LANGUAGE MultiParamTypeClasses #-}
|      {-# LANGUAGE TypeInType #-}
|      module Cat where
|  
|      import Data.Kind
|  
|      class Cat k (cat :: k -> k -> *) where
|        catId   :: cat a a
|        catComp :: cat b c -> cat a b -> cat a c
|  
|      instance Cat * (->) where
|        catId   = id
|        catComp = (.)
|  
|      newtype Fun a b = Fun (a -> b) deriving (Cat k)
|  
|  I was surprised to find out that this code currently compiles without
|  issue on GHC 8.0, even though we're deriving (Cat k) instead of (Cat
|  *). This is an effect of the way GHC currently handles deriving
|  clauses, since it unifies the kind of the datatype and typeclass
|  beforehand (therefore, it silently gets unified to Cat * before
|  generating the instance). [1]
|  
|  Is this correct? It definitely feels a bit off. We currently allow this
|  (see Trac #8865 [2]):
|  
|      newtype T a b = MkT (Either a b) deriving ( Category )
|  
|  Even though Category :: k -> k -> * (i.e., we silently unify k with *).
|  The difference here, as is the difference between P1 and P2 in Simon's
|  email, is that k is not visible, so it's out-of-sight and out-of-mind.
|  When k is visible, as in Cat, when now must be conscious of how it's
|  used in a deriving clause.
|  
|  The Cat code is lying in the sense that we aren't deriving an instance
|  that begins with (Cat k), but rather:
|  
|      instance Cat * Fun where ...
|  
|  Using Simon's advice, we could just as well generate:
|  
|      instance (k ~ *) => Cat k Fun where ...
|  
|  (Again, this doesn't currently compile on 8.0. I really hope that's
|  just a bug.)
|  
|  So I'm starting to lean towards Simon's proposal. That is, we freely
|  unify non-visible type parameters when deriving, but if a type
|  parameter is visible, then we generate equality constraints instead of
|  unifying it.
|  
|  Ryan S.
|  -----
|  [1]
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fgit.has
|  kell.org%2fghc.git%2fblob%2fb0ab8db61568305f50947058fc5573e2382c84eb%3a
|  %2fcompiler%2ftypecheck%2fTcDeriv.hs%23l653&data=01%7c01%7csimonpj%4006
|  4d.mgd.microsoft.com%7cdd343f6279d74b40a30b08d357da348e%7c72f988bf86f14
|  1af91ab2d7cd011db47%7c1&sdata=I2YgFKCYkZtpSJlN7UzOyawgK2LncTQIlE2PpOAwP
|  2c%3d
|  [2] https://ghc.haskell.org/trac/ghc/ticket/8865
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cdd343f6279d74
|  b40a30b08d357da348e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=19EhLy
|  AsemDkPIdmK08C0XBbLufiKEsEwYuLqWhCH3s%3d

From ryan.gl.scott at gmail.com  Tue Mar 29 14:52:09 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Tue, 29 Mar 2016 10:52:09 -0400
Subject: instantiating visible parameters in when deriving instances
In-Reply-To: <274a0fee370241cebaad1dbc8b33b5dd@DB4PR30MB030.064d.mgd.msft.net>
References: <CADdQpRCnsJFKQXNoYF4zW+h0yMOH5J547vkYn_+0CmCVPu12Bg@mail.gmail.com>
 <274a0fee370241cebaad1dbc8b33b5dd@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CADdQpRCAYEg9HPELS5yyFdjYjZqxYAZpWLzGxuANdDWineWCEQ@mail.gmail.com>

> Why should it make a difference whether it's visible or not.  Can't we behave the same for both?

Oops, I made the wrong distinction. I should have said: we freely
unify eta-reduced type parameters when deriving, but if a type
parameter isn't eta-reduced, then we generate equality constraints
instead of unifying it.

That is, the distinction between

    instance Functor P1
    -- with -fprint-explicit-kinds, this would be instance Functor * P1

and

    instance (k ~ *) => Functor (P2 k)

We can't generate equality constraints for eta-reduced type variables
since there's literally no way to refer to them in an instance.

Ryan S.

On Tue, Mar 29, 2016 at 10:47 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> |  So I'm starting to lean towards Simon's proposal. That is, we freely
> |  unify non-visible type parameters when deriving, but if a type
> |  parameter is visible, then we generate equality constraints instead of
> |  unifying it.
>
> Why should it make a difference whether it's visible or not.  Can't we behave the same for both?
>
> Simon
>
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ryan
> |  Scott
> |  Sent: 29 March 2016 14:58
> |  To: ghc-devs at haskell.org
> |  Subject: Re: instantiating visible parameters in when deriving
> |  instances
> |
> |  Simon, did you meant P2? (Since you can't write instance (k ~ *) =>
> |  Functor (P1 (a :: k)), as that's ill-kinded). Something like this?
> |
> |      data P2 k (a :: k) = MkP2
> |      instance (k ~ *) => Functor (P2 k)
> |
> |  That's an interesting idea. Be aware that you actually can't compile
> |  that code at the moment, since GHC complains:
> |
> |      * Expected kind ?* -> *?, but ?P2 k? has kind ?k -> *?
> |      * In the first argument of ?Functor?, namely ?P2 k?
> |        In the instance declaration for ?Functor (P2 k)?
> |
> |  I hope this is a bug and not a fundamental limitation.
> |
> |  There's another wrinkle in the design we must consider. Not only can
> |  datatypes have dependent type parameters, but so can typeclasses
> |  themselves. Consider:
> |
> |      {-# LANGUAGE FlexibleInstances #-}
> |      {-# LANGUAGE GeneralizedNewtypeDeriving #-}
> |      {-# LANGUAGE MultiParamTypeClasses #-}
> |      {-# LANGUAGE TypeInType #-}
> |      module Cat where
> |
> |      import Data.Kind
> |
> |      class Cat k (cat :: k -> k -> *) where
> |        catId   :: cat a a
> |        catComp :: cat b c -> cat a b -> cat a c
> |
> |      instance Cat * (->) where
> |        catId   = id
> |        catComp = (.)
> |
> |      newtype Fun a b = Fun (a -> b) deriving (Cat k)
> |
> |  I was surprised to find out that this code currently compiles without
> |  issue on GHC 8.0, even though we're deriving (Cat k) instead of (Cat
> |  *). This is an effect of the way GHC currently handles deriving
> |  clauses, since it unifies the kind of the datatype and typeclass
> |  beforehand (therefore, it silently gets unified to Cat * before
> |  generating the instance). [1]
> |
> |  Is this correct? It definitely feels a bit off. We currently allow this
> |  (see Trac #8865 [2]):
> |
> |      newtype T a b = MkT (Either a b) deriving ( Category )
> |
> |  Even though Category :: k -> k -> * (i.e., we silently unify k with *).
> |  The difference here, as is the difference between P1 and P2 in Simon's
> |  email, is that k is not visible, so it's out-of-sight and out-of-mind.
> |  When k is visible, as in Cat, when now must be conscious of how it's
> |  used in a deriving clause.
> |
> |  The Cat code is lying in the sense that we aren't deriving an instance
> |  that begins with (Cat k), but rather:
> |
> |      instance Cat * Fun where ...
> |
> |  Using Simon's advice, we could just as well generate:
> |
> |      instance (k ~ *) => Cat k Fun where ...
> |
> |  (Again, this doesn't currently compile on 8.0. I really hope that's
> |  just a bug.)
> |
> |  So I'm starting to lean towards Simon's proposal. That is, we freely
> |  unify non-visible type parameters when deriving, but if a type
> |  parameter is visible, then we generate equality constraints instead of
> |  unifying it.
> |
> |  Ryan S.
> |  -----
> |  [1]
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fgit.has
> |  kell.org%2fghc.git%2fblob%2fb0ab8db61568305f50947058fc5573e2382c84eb%3a
> |  %2fcompiler%2ftypecheck%2fTcDeriv.hs%23l653&data=01%7c01%7csimonpj%4006
> |  4d.mgd.microsoft.com%7cdd343f6279d74b40a30b08d357da348e%7c72f988bf86f14
> |  1af91ab2d7cd011db47%7c1&sdata=I2YgFKCYkZtpSJlN7UzOyawgK2LncTQIlE2PpOAwP
> |  2c%3d
> |  [2] https://ghc.haskell.org/trac/ghc/ticket/8865
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
> |  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  devs%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cdd343f6279d74
> |  b40a30b08d357da348e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=19EhLy
> |  AsemDkPIdmK08C0XBbLufiKEsEwYuLqWhCH3s%3d

From austin at well-typed.com  Tue Mar 29 16:13:35 2016
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 29 Mar 2016 11:13:35 -0500
Subject: GHC 8.0.1 release plan
In-Reply-To: <87fuva76rg.fsf@smart-cactus.org>
References: <87io0676xb.fsf@smart-cactus.org> <87fuva76rg.fsf@smart-cactus.org>
Message-ID: <CAEs96n2fLb1NNp71Fz3ZxSRsUyKNJAE3OWCR-qBEnkLyW4zd6g@mail.gmail.com>

Hello all,

I just wanted to follow up on this. Yesterday, Ben and I spent some
time and went over the current bug list[1]. If you saw that email
yesterday - please refresh that page, we've trimmed the hedges a
little bit. Please note that, barring any huge bugs in 8.0.1-rc3, we
really aren't intending on putting anything else into the queue.

So, if you're a developer: Please take a look at the tickets! Try to
fix something. If you're a user: if you want something done for 8.0.1
that isn't done already, you better make a *really* good case for it,
email us ASAP, and help us fix it!

Realistically, we're going to be spending most of our time on the
high/highest priority bugs. The remaining 'normal' bugs would be 'nice
to have', and some may even be promoted - so if you can, maybe take a
look. Otherwise we're going to be working on getting the remaining
critical bugs fixed and out of the way and move forward.

Thanks!

[1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1#Ticketsslatedfor8.0.1

On Mon, Mar 28, 2016 at 2:16 PM, Ben Gamari <ben at well-typed.com> wrote:
> Ben Gamari <ben at well-typed.com> writes:
>
>> Hello GHCers,
>>
>> After numerous delays, I think we may finally be converging on a
>> (hopefully final) 8.0.1 release candidate. Thanks to the tireless
>> efforts of Richard Eisenberg, Simon PJ, and many others almost all of
>> the release blocking tickets [1] have now been resolved. There are a few
>> patches currently waiting for review that should hopefully be mergeable
>> within the next few days.
>>
>> After these last patches have been merged I'll proceed in cutting
>> the source distribution for GHC 8.0.1 release candidate 3. This release
>> candidate will be made available immediately, although, in accordance
>> with our new release policy [2], binary distributions won't be available
>> until seven days later.
>>
> Oops, forgot the reference here. The new release timing policy was
> described here,
>
> [2] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.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 eir at cis.upenn.edu  Tue Mar 29 17:56:18 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 29 Mar 2016 19:56:18 +0200
Subject: instantiating visible parameters in when deriving instances
In-Reply-To: <CADdQpRCnsJFKQXNoYF4zW+h0yMOH5J547vkYn_+0CmCVPu12Bg@mail.gmail.com>
References: <CADdQpRCnsJFKQXNoYF4zW+h0yMOH5J547vkYn_+0CmCVPu12Bg@mail.gmail.com>
Message-ID: <AABEC36B-B14F-4EC6-9085-503790D863FC@cis.upenn.edu>


On Mar 29, 2016, at 3:58 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:

> I hope this is a bug and not a fundamental limitation.

As I posted in the ticket, this is a somewhat fundamental limitation. I qualify by "somewhat" because it's a consequence of a design choice, but reversing the design choice would be rather difficult and lead to several more tough design choices. It's my hope and belief that this restriction will one day be lifted. That day will not be soon. The wiki (https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Internal#Liftedvs.Unliftedequality) has some thoughts on the issue, but those notes may be out of date and/or wrong. YMMV.

As for Simon's question about the difference between visible and invisible: when the user says `deriving (Cat k)`, the user has written k and presumably means k to be universally quantified. When the user days `deriving Category`, then no `k` has been written and unification seems appropriate. Of course, if we consider that in the `deriving (Cat k)` case, we're just inferring a `k ~ *` constraint, perhaps this is OK. But it's certainly a bit odd.

Richard

From omeragacan at gmail.com  Tue Mar 29 21:00:24 2016
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Tue, 29 Mar 2016 17:00:24 -0400
Subject: Initial compile time benchmarks
Message-ID: <CAMQQO3kVEpBPbTrywo6KN1XPxQqwd2AHRsseuiNvvSh8bp382Q@mail.gmail.com>

Hi all,

Using Ben's timing patch [^1], Cabal, and a Haskell program to parse generated
logs [^2], I generated some tables that show compile times of modules in hxt,
haskell-src-exts, lens, and all of their dependencies:

https://gist.githubusercontent.com/osa1/fd82335181a584679c9f3200b7b0a8a5/raw/5d46b0e7006c7ef9fae913f7d6932b74c83835f1/gistfile1.txt

Some notes:

- Modules and passes in modules are sorted.

- At the end of the file you can see the cumulative numbers for the passes. In
  fact, that's a small table so I'm just going to paste it here:

    ======================Total======================
    CodeGen                                    41.32%
    Simplifier                                 34.83%
    Renamer/typechecker                        12.22%
    Desugar                                     2.11%
    CorePrep                                    1.90%
    Demand analysis                             1.44%
    CoreTidy                                    1.35%
    Called arity analysis                       1.10%
    Float inwards                               0.96%
    Common sub-expression                       0.87%
    Parser                                      0.75%
    SpecConstr                                  0.57%
    Specialise                                  0.30%
    Worker Wrapper binds                        0.17%
    Liberate case                               0.12%
    ByteCodeGen                                 0.00%
    Simplify                                    0.00%

I don't know how to make use of this yet, but I thought ghc-devs may find it
useful.

As a next thing I'm hoping to add some more `withTiming` calls. The analyze
program can handle nested `withTiming` calls and renders passes as a tree (GHC
HEAD doesn't have nested `withTiming`s so we don't see it in the file above),
so we can benchmark things in more details. I also want to experiment a little
bit with different `force` parameters to `withTiming`. If anyone has any other
ideas I can also try those.

---

[^1]: https://phabricator.haskell.org/D1959
[^2]: https://github.com/osa1/analyze-ghc-timings

From eric at seidel.io  Tue Mar 29 21:24:29 2016
From: eric at seidel.io (Eric Seidel)
Date: Tue, 29 Mar 2016 14:24:29 -0700
Subject: Initial compile time benchmarks
In-Reply-To: <CAMQQO3kVEpBPbTrywo6KN1XPxQqwd2AHRsseuiNvvSh8bp382Q@mail.gmail.com>
References: <CAMQQO3kVEpBPbTrywo6KN1XPxQqwd2AHRsseuiNvvSh8bp382Q@mail.gmail.com>
Message-ID: <1459286669.3035728.562951706.0BD009AE@webmail.messagingengine.com>

Very cool!

It would be nice to add build flags to the table (or at least
optimization levels) as these probably differ across packages, and will
certainly impact the numbers. 

I'd also be really interested to see a comparison of the timing data for
-O0 and -O. I think the biggest impact for performance improvements will
probably come from working on -O0, since that's what people will use for
development.

Thanks!
Eric

On Tue, Mar 29, 2016, at 14:00, ?mer Sinan A?acan wrote:
> Hi all,
> 
> Using Ben's timing patch [^1], Cabal, and a Haskell program to parse
> generated
> logs [^2], I generated some tables that show compile times of modules in
> hxt,
> haskell-src-exts, lens, and all of their dependencies:
> 
> https://gist.githubusercontent.com/osa1/fd82335181a584679c9f3200b7b0a8a5/raw/5d46b0e7006c7ef9fae913f7d6932b74c83835f1/gistfile1.txt
> 
> Some notes:
> 
> - Modules and passes in modules are sorted.
> 
> - At the end of the file you can see the cumulative numbers for the
> passes. In
>   fact, that's a small table so I'm just going to paste it here:
> 
>     ======================Total======================
>     CodeGen                                    41.32%
>     Simplifier                                 34.83%
>     Renamer/typechecker                        12.22%
>     Desugar                                     2.11%
>     CorePrep                                    1.90%
>     Demand analysis                             1.44%
>     CoreTidy                                    1.35%
>     Called arity analysis                       1.10%
>     Float inwards                               0.96%
>     Common sub-expression                       0.87%
>     Parser                                      0.75%
>     SpecConstr                                  0.57%
>     Specialise                                  0.30%
>     Worker Wrapper binds                        0.17%
>     Liberate case                               0.12%
>     ByteCodeGen                                 0.00%
>     Simplify                                    0.00%
> 
> I don't know how to make use of this yet, but I thought ghc-devs may find
> it
> useful.
> 
> As a next thing I'm hoping to add some more `withTiming` calls. The
> analyze
> program can handle nested `withTiming` calls and renders passes as a tree
> (GHC
> HEAD doesn't have nested `withTiming`s so we don't see it in the file
> above),
> so we can benchmark things in more details. I also want to experiment a
> little
> bit with different `force` parameters to `withTiming`. If anyone has any
> other
> ideas I can also try those.
> 
> ---
> 
> [^1]: https://phabricator.haskell.org/D1959
> [^2]: https://github.com/osa1/analyze-ghc-timings
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From mgsloan at gmail.com  Tue Mar 29 22:23:50 2016
From: mgsloan at gmail.com (Michael Sloan)
Date: Tue, 29 Mar 2016 15:23:50 -0700
Subject: Initial compile time benchmarks
In-Reply-To: <CAMQQO3kVEpBPbTrywo6KN1XPxQqwd2AHRsseuiNvvSh8bp382Q@mail.gmail.com>
References: <CAMQQO3kVEpBPbTrywo6KN1XPxQqwd2AHRsseuiNvvSh8bp382Q@mail.gmail.com>
Message-ID: <CAEDDsWeAYF4M36Lzrb_V0dn_Gx+uXkky_taz-sXGw1PtUN8Tpg@mail.gmail.com>

Great! Thanks for y'all putting effort towards performance. It really is
crucial
for developer productivity.

In the particular case of haskell-src-exts, I found that removing many of
the
more complicated typeclasses from deriving (Data, Generics, etc) brought the
compilation time way down. IIRC it was pretty drastic, like 40 seconds vs 10
seconds (that could be just the timing for that one types module though, I
don't recall).  Could be valuable to investigate exactly what's going on
there.

-Michael

On Tue, Mar 29, 2016 at 2:00 PM, ?mer Sinan A?acan <omeragacan at gmail.com>
wrote:

> Hi all,
>
> Using Ben's timing patch [^1], Cabal, and a Haskell program to parse
> generated
> logs [^2], I generated some tables that show compile times of modules in
> hxt,
> haskell-src-exts, lens, and all of their dependencies:
>
>
> https://gist.githubusercontent.com/osa1/fd82335181a584679c9f3200b7b0a8a5/raw/5d46b0e7006c7ef9fae913f7d6932b74c83835f1/gistfile1.txt
>
> Some notes:
>
> - Modules and passes in modules are sorted.
>
> - At the end of the file you can see the cumulative numbers for the
> passes. In
>   fact, that's a small table so I'm just going to paste it here:
>
>     ======================Total======================
>     CodeGen                                    41.32%
>     Simplifier                                 34.83%
>     Renamer/typechecker                        12.22%
>     Desugar                                     2.11%
>     CorePrep                                    1.90%
>     Demand analysis                             1.44%
>     CoreTidy                                    1.35%
>     Called arity analysis                       1.10%
>     Float inwards                               0.96%
>     Common sub-expression                       0.87%
>     Parser                                      0.75%
>     SpecConstr                                  0.57%
>     Specialise                                  0.30%
>     Worker Wrapper binds                        0.17%
>     Liberate case                               0.12%
>     ByteCodeGen                                 0.00%
>     Simplify                                    0.00%
>
> I don't know how to make use of this yet, but I thought ghc-devs may find
> it
> useful.
>
> As a next thing I'm hoping to add some more `withTiming` calls. The analyze
> program can handle nested `withTiming` calls and renders passes as a tree
> (GHC
> HEAD doesn't have nested `withTiming`s so we don't see it in the file
> above),
> so we can benchmark things in more details. I also want to experiment a
> little
> bit with different `force` parameters to `withTiming`. If anyone has any
> other
> ideas I can also try those.
>
> ---
>
> [^1]: https://phabricator.haskell.org/D1959
> [^2]: https://github.com/osa1/analyze-ghc-timings
> _______________________________________________
> 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/20160329/b5191c41/attachment-0001.html>

From ezyang at mit.edu  Tue Mar 29 22:29:43 2016
From: ezyang at mit.edu (Edward Z. Yang)
Date: Tue, 29 Mar 2016 15:29:43 -0700
Subject: Initial compile time benchmarks
In-Reply-To: <CAEDDsWeAYF4M36Lzrb_V0dn_Gx+uXkky_taz-sXGw1PtUN8Tpg@mail.gmail.com>
References: <CAMQQO3kVEpBPbTrywo6KN1XPxQqwd2AHRsseuiNvvSh8bp382Q@mail.gmail.com>
 <CAEDDsWeAYF4M36Lzrb_V0dn_Gx+uXkky_taz-sXGw1PtUN8Tpg@mail.gmail.com>
Message-ID: <1459290491-sup-6288@sabre>

This ticket may be of interest:

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

Deriving costs a lot and we just need someone to figure out what's
going on.

Edward

Excerpts from Michael Sloan's message of 2016-03-29 15:23:50 -0700:
> Great! Thanks for y'all putting effort towards performance. It really is
> crucial
> for developer productivity.
> 
> In the particular case of haskell-src-exts, I found that removing many of
> the
> more complicated typeclasses from deriving (Data, Generics, etc) brought the
> compilation time way down. IIRC it was pretty drastic, like 40 seconds vs 10
> seconds (that could be just the timing for that one types module though, I
> don't recall).  Could be valuable to investigate exactly what's going on
> there.
> 
> -Michael
> 
> On Tue, Mar 29, 2016 at 2:00 PM, ?mer Sinan A?acan <omeragacan at gmail.com>
> wrote:
> 
> > Hi all,
> >
> > Using Ben's timing patch [^1], Cabal, and a Haskell program to parse
> > generated
> > logs [^2], I generated some tables that show compile times of modules in
> > hxt,
> > haskell-src-exts, lens, and all of their dependencies:
> >
> >
> > https://gist.githubusercontent.com/osa1/fd82335181a584679c9f3200b7b0a8a5/raw/5d46b0e7006c7ef9fae913f7d6932b74c83835f1/gistfile1.txt
> >
> > Some notes:
> >
> > - Modules and passes in modules are sorted.
> >
> > - At the end of the file you can see the cumulative numbers for the
> > passes. In
> >   fact, that's a small table so I'm just going to paste it here:
> >
> >     ======================Total======================
> >     CodeGen                                    41.32%
> >     Simplifier                                 34.83%
> >     Renamer/typechecker                        12.22%
> >     Desugar                                     2.11%
> >     CorePrep                                    1.90%
> >     Demand analysis                             1.44%
> >     CoreTidy                                    1.35%
> >     Called arity analysis                       1.10%
> >     Float inwards                               0.96%
> >     Common sub-expression                       0.87%
> >     Parser                                      0.75%
> >     SpecConstr                                  0.57%
> >     Specialise                                  0.30%
> >     Worker Wrapper binds                        0.17%
> >     Liberate case                               0.12%
> >     ByteCodeGen                                 0.00%
> >     Simplify                                    0.00%
> >
> > I don't know how to make use of this yet, but I thought ghc-devs may find
> > it
> > useful.
> >
> > As a next thing I'm hoping to add some more `withTiming` calls. The analyze
> > program can handle nested `withTiming` calls and renders passes as a tree
> > (GHC
> > HEAD doesn't have nested `withTiming`s so we don't see it in the file
> > above),
> > so we can benchmark things in more details. I also want to experiment a
> > little
> > bit with different `force` parameters to `withTiming`. If anyone has any
> > other
> > ideas I can also try those.
> >
> > ---
> >
> > [^1]: https://phabricator.haskell.org/D1959
> > [^2]: https://github.com/osa1/analyze-ghc-timings
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >

From chak at justtesting.org  Wed Mar 30 02:26:13 2016
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Wed, 30 Mar 2016 13:26:13 +1100
Subject: Unicode, strings, and Show
Message-ID: <9FCF91F7-B3E4-46A5-979E-9C24AFF8D51F@justtesting.org>

Why are we doing this?

  GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help
  Prelude> "??"
  "\25991\23383"
  Prelude> 

After all, we don?t print ?a? as ?\97?.

Manuel


From targen at gmail.com  Wed Mar 30 03:01:14 2016
From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=)
Date: Tue, 29 Mar 2016 22:31:14 -0430
Subject: Unicode, strings, and Show
In-Reply-To: <9FCF91F7-B3E4-46A5-979E-9C24AFF8D51F@justtesting.org>
References: <9FCF91F7-B3E4-46A5-979E-9C24AFF8D51F@justtesting.org>
Message-ID: <CAJWnFaMVa8yib6VWb9k2LjyZjQbrC8sg72vFGkb+qmQbjzezWQ@mail.gmail.com>

On Tue, Mar 29, 2016 at 9:56 PM, Manuel M T Chakravarty
<chak at justtesting.org> wrote:
> Why are we doing this?
>
>   GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help
>   Prelude> "??"
>   "\25991\23383"
>   Prelude>
>
> After all, we don?t print ?a? as ?\97?.
>
> Manuel

Indeed:

? 2016: https://mail.haskell.org/pipermail/haskell-cafe/2016-February/122874.html
? 2012: http://stackoverflow.com/questions/14039726/how-to-make-haskell-or-ghci-able-to-show-chinese-characters-and-run-chinese-char
? 2012 again: https://mail.haskell.org/pipermail/haskell-cafe/2012-July/102569.html
? 2011: http://stackoverflow.com/questions/5535512/how-to-hack-ghci-or-hugs-so-that-it-prints-unicode-chars-unescaped
? 2010: https://mail.haskell.org/pipermail/haskell-cafe/2010-August/082823.html

This is a constant source of pain and should be relatively easy to fix.

Manuel

From qdunkan at gmail.com  Wed Mar 30 03:05:33 2016
From: qdunkan at gmail.com (Evan Laforge)
Date: Tue, 29 Mar 2016 20:05:33 -0700
Subject: Unicode, strings, and Show
In-Reply-To: <9FCF91F7-B3E4-46A5-979E-9C24AFF8D51F@justtesting.org>
References: <9FCF91F7-B3E4-46A5-979E-9C24AFF8D51F@justtesting.org>
Message-ID: <CACbaDy4VtQrXmiS8QJLzEfvxNfKrpZeBS69AP1fg6ghNJ5EiXw@mail.gmail.com>

There was recently a discussion about it, search for subject "Can we
improve Show instance for non-ascii charcters?"

You can read for yourself but my impression was that people were
generally favorable, but had some backward compatibility worries, and
came up with some workarounds, but no one committed to following up on
a ghci patch.

On Tue, Mar 29, 2016 at 7:26 PM, Manuel M T Chakravarty
<chak at justtesting.org> wrote:
> Why are we doing this?
>
>   GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help
>   Prelude> "??"
>   "\25991\23383"
>   Prelude>
>
> After all, we don?t print ?a? as ?\97?.
>
> Manuel
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From mail at joachim-breitner.de  Wed Mar 30 07:11:08 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 30 Mar 2016 09:11:08 +0200
Subject: Initial compile time benchmarks
In-Reply-To: <1459290491-sup-6288@sabre>
References: <CAMQQO3kVEpBPbTrywo6KN1XPxQqwd2AHRsseuiNvvSh8bp382Q@mail.gmail.com>
 <CAEDDsWeAYF4M36Lzrb_V0dn_Gx+uXkky_taz-sXGw1PtUN8Tpg@mail.gmail.com>
 <1459290491-sup-6288@sabre>
Message-ID: <1459321868.1851.2.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 29.03.2016, 15:29 -0700 schrieb Edward Z. Yang:
> This ticket may be of interest:
> 
> https://ghc.haskell.org/trac/ghc/ticket/9630
> 
> Deriving costs a lot and we just need someone to figure out what's
> going on.

are you sure that deriving itself costs a lot? I would expect that
deriving itself is reasonably cheap, but results in a lot of
complicated (e.g. recursive) code that later analyzes have to go
through...

http://ghc.haskell.org/trac/ghc/ticket/9557?and tickets linked from
there are also relevant. In fact, there is even a keyword for this
meta-issue:
https://ghc.haskell.org/trac/ghc/query?status=!closed&keywords=~deriving-perf

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-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/20160330/29953ed4/attachment.sig>

From simonpj at microsoft.com  Wed Mar 30 07:43:00 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 30 Mar 2016 07:43:00 +0000
Subject: Initial compile time benchmarks
In-Reply-To: <1459321868.1851.2.camel@joachim-breitner.de>
References: <CAMQQO3kVEpBPbTrywo6KN1XPxQqwd2AHRsseuiNvvSh8bp382Q@mail.gmail.com>
 <CAEDDsWeAYF4M36Lzrb_V0dn_Gx+uXkky_taz-sXGw1PtUN8Tpg@mail.gmail.com>
 <1459290491-sup-6288@sabre> <1459321868.1851.2.camel@joachim-breitner.de>
Message-ID: <65bf36a4df9b4463ad56b2829648f2d8@DB4PR30MB030.064d.mgd.msft.net>

|  > Deriving costs a lot and we just need someone to figure out what's
|  > going on.
|  
|  are you sure that deriving itself costs a lot? I would expect that
|  deriving itself is reasonably cheap, but results in a lot of
|  complicated (e.g. recursive) code that later analyzes have to go
|  through...

I think that's right. But somehow the code generated by 'deriving' tickles some non-linearity (I guess) in the rest of the compiler.  It would be great to know what it was.

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Joachim Breitner
|  Sent: 30 March 2016 08:11
|  To: ghc-devs at haskell.org
|  Subject: Re: Initial compile time benchmarks
|  
|  Hi,
|  
|  Am Dienstag, den 29.03.2016, 15:29 -0700 schrieb Edward Z. Yang:
|  > This ticket may be of interest:
|  >
|  > https://ghc.haskell.org/trac/ghc/ticket/9630
|  >
|  > Deriving costs a lot and we just need someone to figure out what's
|  > going on.
|  
|  are you sure that deriving itself costs a lot? I would expect that
|  deriving itself is reasonably cheap, but results in a lot of
|  complicated (e.g. recursive) code that later analyzes have to go
|  through...
|  
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.has
|  kell.org%2ftrac%2fghc%2fticket%2f9557&data=01%7c01%7csimonpj%40064d.mgd
|  .microsoft.com%7c209ce28b44644d1603d408d3586a7ea2%7c72f988bf86f141af91a
|  b2d7cd011db47%7c1&sdata=7NJ%2fd7z98HtnTvPqQvR5o%2bGr5U6RewWBNlRudH4xZvY
|  %3d?and tickets linked from there are also relevant. In fact, there is
|  even a keyword for this
|  meta-issue:
|  https://ghc.haskell.org/trac/ghc/query?status=!closed&keywords=~derivin
|  g-perf
|  
|  Greetings,
|  Joachim
|  
|  
|  --
|  Joachim ?nomeata? Breitner
|  ? mail at joachim-breitner.de ?
|  https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.jo
|  achim-
|  breitner.de%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c209ce2
|  8b44644d1603d408d3586a7ea2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata
|  =bIiW5fIZ9Wnv2IWkDGjTU3PMuA6nmitgcHmBdY5q31Q%3d
|  ? XMPP: nomeata at joachim-breitner.de?? OpenPGP-Key: 0xF0FBF51F
|  ? Debian Developer: nomeata at debian.org


From ben at smart-cactus.org  Wed Mar 30 08:51:22 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 30 Mar 2016 10:51:22 +0200
Subject: Unicode, strings, and Show
In-Reply-To: <CACbaDy4VtQrXmiS8QJLzEfvxNfKrpZeBS69AP1fg6ghNJ5EiXw@mail.gmail.com>
References: <9FCF91F7-B3E4-46A5-979E-9C24AFF8D51F@justtesting.org>
 <CACbaDy4VtQrXmiS8QJLzEfvxNfKrpZeBS69AP1fg6ghNJ5EiXw@mail.gmail.com>
Message-ID: <87wpok5oxh.fsf@smart-cactus.org>

Evan Laforge <qdunkan at gmail.com> writes:

> There was recently a discussion about it, search for subject "Can we
> improve Show instance for non-ascii charcters?"
>
> You can read for yourself but my impression was that people were
> generally favorable, but had some backward compatibility worries, and
> came up with some workarounds, but no one committed to following up on
> a ghci patch.
>
It would be great if someone could create a Trac ticket so we had
someplace persistent to track this discussion. Manuel, perhaps you could
handle this?

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160330/cf9decb3/attachment.sig>

From thomasmiedema at gmail.com  Wed Mar 30 09:06:11 2016
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Wed, 30 Mar 2016 11:06:11 +0200
Subject: Unicode, strings, and Show
In-Reply-To: <87wpok5oxh.fsf@smart-cactus.org>
References: <9FCF91F7-B3E4-46A5-979E-9C24AFF8D51F@justtesting.org>
 <CACbaDy4VtQrXmiS8QJLzEfvxNfKrpZeBS69AP1fg6ghNJ5EiXw@mail.gmail.com>
 <87wpok5oxh.fsf@smart-cactus.org>
Message-ID: <CAD3WKghX5sQwdePxK35Mazys7-Vcp36TjyQd2nmWFWUqTxcgCg@mail.gmail.com>

> It would be great if someone could create a Trac ticket


Existing ticket: https://ghc.haskell.org/trac/ghc/ticket/11529 ("Show
instance of Char should print literals for non-ascii printable charcters")
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160330/770d45cb/attachment.html>

From ben at smart-cactus.org  Wed Mar 30 09:36:19 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 30 Mar 2016 11:36:19 +0200
Subject: Unicode, strings, and Show
In-Reply-To: <CAD3WKghX5sQwdePxK35Mazys7-Vcp36TjyQd2nmWFWUqTxcgCg@mail.gmail.com>
References: <9FCF91F7-B3E4-46A5-979E-9C24AFF8D51F@justtesting.org>
 <CACbaDy4VtQrXmiS8QJLzEfvxNfKrpZeBS69AP1fg6ghNJ5EiXw@mail.gmail.com>
 <87wpok5oxh.fsf@smart-cactus.org>
 <CAD3WKghX5sQwdePxK35Mazys7-Vcp36TjyQd2nmWFWUqTxcgCg@mail.gmail.com>
Message-ID: <87twjo5muk.fsf@smart-cactus.org>

Thomas Miedema <thomasmiedema at gmail.com> writes:

>> It would be great if someone could create a Trac ticket
>
>
> Existing ticket: https://ghc.haskell.org/trac/ghc/ticket/11529 ("Show
> instance of Char should print literals for non-ascii printable charcters")

Thanks Thomas! I've added a reference to this thread on the ticket.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160330/a90f1e46/attachment.sig>

From conal at conal.net  Wed Mar 30 17:02:20 2016
From: conal at conal.net (Conal Elliott)
Date: Wed, 30 Mar 2016 10:02:20 -0700
Subject: GHC HEAD compile failure at ghctags: "missing: Cabal >=1.25 && <1.27"
Message-ID: <CAD6SzR+zExieHy7W0LQRuMjnJ3ONHLOK9gWmUJuE8BzOO1oY5A@mail.gmail.com>

I'm trying to recompile GHC (via GHC 7.10.3) from freshly git-pulled HEAD,
and "make" keeps dying at ghctags:

    Configuring ghctags-0.1...
    ghc-cabal: At least the following dependencies are missing:
    Cabal >=1.25 && <1.27

According to ghc-pkg I have Cabal 1.25.0.0 (compiled from a freshly
git-pulled git clone).

Any ideas what's going on and how I can fix it?

Thanks.  - Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160330/1d271fa7/attachment.html>

From ezyang at mit.edu  Wed Mar 30 17:54:19 2016
From: ezyang at mit.edu (Edward Z. Yang)
Date: Wed, 30 Mar 2016 10:54:19 -0700
Subject: GHC HEAD compile failure at ghctags: "missing: Cabal >=1.25 &&
 <1.27"
In-Reply-To: <CAD6SzR+zExieHy7W0LQRuMjnJ3ONHLOK9gWmUJuE8BzOO1oY5A@mail.gmail.com>
References: <CAD6SzR+zExieHy7W0LQRuMjnJ3ONHLOK9gWmUJuE8BzOO1oY5A@mail.gmail.com>
Message-ID: <1459360439-sup-1038@sabre>

Don't forget to "git submodule update"

Edward

Excerpts from Conal Elliott's message of 2016-03-30 10:02:20 -0700:
> I'm trying to recompile GHC (via GHC 7.10.3) from freshly git-pulled HEAD,
> and "make" keeps dying at ghctags:
> 
>     Configuring ghctags-0.1...
>     ghc-cabal: At least the following dependencies are missing:
>     Cabal >=1.25 && <1.27
> 
> According to ghc-pkg I have Cabal 1.25.0.0 (compiled from a freshly
> git-pulled git clone).
> 
> Any ideas what's going on and how I can fix it?
> 
> Thanks.  - Conal

From carter.schonwald at gmail.com  Wed Mar 30 19:40:05 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 30 Mar 2016 15:40:05 -0400
Subject: singletons stuff in GHC.Generics?
Message-ID: <CAHYVw0y3xfOOHu15sBzBAm8HGwbrkamZV43f3eTM5eMfFAKuHg@mail.gmail.com>

Hey All, i just noticed that theres some Singletons code in the
GHC.Generics module thats defined but not exported, whats the context on
that?

https://ghc.haskell.org/trac/ghc/ticket/11775#ticket is the ticket i
created to track / ask for clarificaiton:)
_Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160330/2f52bcd8/attachment.html>

From ben at well-typed.com  Wed Mar 30 19:46:22 2016
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 30 Mar 2016 21:46:22 +0200
Subject: singletons stuff in GHC.Generics?
In-Reply-To: <CAHYVw0y3xfOOHu15sBzBAm8HGwbrkamZV43f3eTM5eMfFAKuHg@mail.gmail.com>
References: <CAHYVw0y3xfOOHu15sBzBAm8HGwbrkamZV43f3eTM5eMfFAKuHg@mail.gmail.com>
Message-ID: <87k2kj6969.fsf@smart-cactus.org>

Carter Schonwald <carter.schonwald at gmail.com> writes:

> Hey All, i just noticed that theres some Singletons code in the
> GHC.Generics module thats defined but not exported, whats the context on
> that?
>
It's used strictly internally in instances defined in GHC.Generics. For
instance,

    instance (KnownSymbol n, SingI f, SingI r)
        => Constructor ('MetaCons n f r) where
      conName     _ = symbolVal (Proxy :: Proxy n)
      conFixity   _ = fromSing  (sing  :: Sing f)
      conIsRecord _ = fromSing  (sing  :: Sing r)

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160330/3ef373ea/attachment.sig>

From carter.schonwald at gmail.com  Wed Mar 30 19:47:05 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 30 Mar 2016 15:47:05 -0400
Subject: singletons stuff in GHC.Generics?
In-Reply-To: <87k2kj6969.fsf@smart-cactus.org>
References: <CAHYVw0y3xfOOHu15sBzBAm8HGwbrkamZV43f3eTM5eMfFAKuHg@mail.gmail.com>
 <87k2kj6969.fsf@smart-cactus.org>
Message-ID: <CAHYVw0wqD4tMHJitgEcnn+Xo48dfm=xcdC3ou195pHEVoEje+A@mail.gmail.com>

GOTCHA,
thanks, i was being a bit myopic in looking around, :)

On Wed, Mar 30, 2016 at 3:46 PM, Ben Gamari <ben at well-typed.com> wrote:

> Carter Schonwald <carter.schonwald at gmail.com> writes:
>
> > Hey All, i just noticed that theres some Singletons code in the
> > GHC.Generics module thats defined but not exported, whats the context on
> > that?
> >
> It's used strictly internally in instances defined in GHC.Generics. For
> instance,
>
>     instance (KnownSymbol n, SingI f, SingI r)
>         => Constructor ('MetaCons n f r) where
>       conName     _ = symbolVal (Proxy :: Proxy n)
>       conFixity   _ = fromSing  (sing  :: Sing f)
>       conIsRecord _ = fromSing  (sing  :: Sing r)
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160330/56102b30/attachment.html>

From conal at conal.net  Wed Mar 30 20:37:01 2016
From: conal at conal.net (Conal Elliott)
Date: Wed, 30 Mar 2016 13:37:01 -0700
Subject: GHC HEAD compile failure at ghctags: "missing: Cabal >=1.25 &&
 <1.27"
In-Reply-To: <1459360439-sup-1038@sabre>
References: <CAD6SzR+zExieHy7W0LQRuMjnJ3ONHLOK9gWmUJuE8BzOO1oY5A@mail.gmail.com>
 <1459360439-sup-1038@sabre>
Message-ID: <CAD6SzRLWzXbXsSGOjOiTA6sOE4p6Drz=JcqgdNZ_f7BMPrayJA@mail.gmail.com>

Oh, yeah. Thanks!  - Conal

On Wed, Mar 30, 2016 at 10:54 AM, Edward Z. Yang <ezyang at mit.edu> wrote:

> Don't forget to "git submodule update"
>
> Edward
>
> Excerpts from Conal Elliott's message of 2016-03-30 10:02:20 -0700:
> > I'm trying to recompile GHC (via GHC 7.10.3) from freshly git-pulled
> HEAD,
> > and "make" keeps dying at ghctags:
> >
> >     Configuring ghctags-0.1...
> >     ghc-cabal: At least the following dependencies are missing:
> >     Cabal >=1.25 && <1.27
> >
> > According to ghc-pkg I have Cabal 1.25.0.0 (compiled from a freshly
> > git-pulled git clone).
> >
> > Any ideas what's going on and how I can fix it?
> >
> > Thanks.  - Conal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160330/33934253/attachment.html>

From chak at justtesting.org  Thu Mar 31 01:16:35 2016
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Thu, 31 Mar 2016 12:16:35 +1100
Subject: Unicode, strings, and Show
In-Reply-To: <CAD3WKghX5sQwdePxK35Mazys7-Vcp36TjyQd2nmWFWUqTxcgCg@mail.gmail.com>
References: <9FCF91F7-B3E4-46A5-979E-9C24AFF8D51F@justtesting.org>
 <CACbaDy4VtQrXmiS8QJLzEfvxNfKrpZeBS69AP1fg6ghNJ5EiXw@mail.gmail.com>
 <87wpok5oxh.fsf@smart-cactus.org>
 <CAD3WKghX5sQwdePxK35Mazys7-Vcp36TjyQd2nmWFWUqTxcgCg@mail.gmail.com>
Message-ID: <9E234A5C-DADF-4B31-8D2D-10AD2686F3E7@justtesting.org>

Thank you for all the replies and especially pointing to this ticket.

I think, the discussion on this ticket is actually misleading and there is a simple solution, which I added as a comment.

Manuel

> Thomas Miedema <thomasmiedema at gmail.com>:
> 
> 
> It would be great if someone could create a Trac ticket
> 
> Existing ticket: https://ghc.haskell.org/trac/ghc/ticket/11529 <https://ghc.haskell.org/trac/ghc/ticket/11529> ("Show instance of Char should print literals for non-ascii printable charcters")

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

From allbery.b at gmail.com  Thu Mar 31 01:21:31 2016
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 30 Mar 2016 21:21:31 -0400
Subject: Unicode, strings, and Show
In-Reply-To: <9E234A5C-DADF-4B31-8D2D-10AD2686F3E7@justtesting.org>
References: <9FCF91F7-B3E4-46A5-979E-9C24AFF8D51F@justtesting.org>
 <CACbaDy4VtQrXmiS8QJLzEfvxNfKrpZeBS69AP1fg6ghNJ5EiXw@mail.gmail.com>
 <87wpok5oxh.fsf@smart-cactus.org>
 <CAD3WKghX5sQwdePxK35Mazys7-Vcp36TjyQd2nmWFWUqTxcgCg@mail.gmail.com>
 <9E234A5C-DADF-4B31-8D2D-10AD2686F3E7@justtesting.org>
Message-ID: <CAKFCL4Xh07yQ3hSD6ZK2iv0Pk6nrcJFVCm44ivo3uwK09hSTTQ@mail.gmail.com>

On Wed, Mar 30, 2016 at 9:16 PM, Manuel M T Chakravarty <
chak at justtesting.org> wrote:

> Thank you for all the replies and especially pointing to this ticket.
>
> I think, the discussion on this ticket is actually misleading and there is
> a simple solution, which I added as a comment.
>

That is in fact not simple at all: with that, the ostensibly pure `show`
now depends on the user's locale and therefore should be in IO (and you
cannot reliably feed it to `read` in a program running in a different
locale)! This is why the ticket was concentrating on ghci, where it's at
least somewhat reasonable to assume a UTF8 environment.

-- 
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/20160330/d10dc48a/attachment-0001.html>

From chak at justtesting.org  Thu Mar 31 01:50:45 2016
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Thu, 31 Mar 2016 12:50:45 +1100
Subject: Unicode, strings, and Show
In-Reply-To: <CAKFCL4Xh07yQ3hSD6ZK2iv0Pk6nrcJFVCm44ivo3uwK09hSTTQ@mail.gmail.com>
References: <9FCF91F7-B3E4-46A5-979E-9C24AFF8D51F@justtesting.org>
 <CACbaDy4VtQrXmiS8QJLzEfvxNfKrpZeBS69AP1fg6ghNJ5EiXw@mail.gmail.com>
 <87wpok5oxh.fsf@smart-cactus.org>
 <CAD3WKghX5sQwdePxK35Mazys7-Vcp36TjyQd2nmWFWUqTxcgCg@mail.gmail.com>
 <9E234A5C-DADF-4B31-8D2D-10AD2686F3E7@justtesting.org>
 <CAKFCL4Xh07yQ3hSD6ZK2iv0Pk6nrcJFVCm44ivo3uwK09hSTTQ@mail.gmail.com>
Message-ID: <17264046-C6FF-42E2-AECE-F7988A1C17DE@justtesting.org>

Firstly, we have

  isPrint :: Char -> Bool

Are you saying that this type is wrong?

Secondly, how often do you feed the output of ?show? to ?read? in another locale versus how often is everybody whose whole life is outside of ASCII (i.e., not anglo-centric people) bothered by this shortcoming? (*)

Moreover, the argument on the ticket was that changing the current implementation would go against the standard. Now that I am saying, the current implementation is not conforming to the standard, the standard suddenly doesn?t seem to matter. Personally, I would say, when we wrote that standard, we knew what we were doing.

Manuel

(*) BTW, (read . show) is a pretty bad serialisation story anyway.

> Brandon Allbery <allbery.b at gmail.com>:
> 
> On Wed, Mar 30, 2016 at 9:16 PM, Manuel M T Chakravarty <chak at justtesting.org <mailto:chak at justtesting.org>> wrote:
> Thank you for all the replies and especially pointing to this ticket.
> 
> I think, the discussion on this ticket is actually misleading and there is a simple solution, which I added as a comment.
> 
> That is in fact not simple at all: with that, the ostensibly pure `show` now depends on the user's locale and therefore should be in IO (and you cannot reliably feed it to `read` in a program running in a different locale)! This is why the ticket was concentrating on ghci, where it's at least somewhat reasonable to assume a UTF8 environment.
> 
> -- 
> brandon s allbery kf8nh                               sine nomine associates
> allbery.b at gmail.com <mailto:allbery.b at gmail.com>                                  ballbery at sinenomine.net <mailto:ballbery at sinenomine.net>
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net <http://sinenomine.net/>_______________________________________________
> 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/20160331/f7bc57b1/attachment.html>

From allbery.b at gmail.com  Thu Mar 31 01:58:34 2016
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 30 Mar 2016 21:58:34 -0400
Subject: Unicode, strings, and Show
In-Reply-To: <17264046-C6FF-42E2-AECE-F7988A1C17DE@justtesting.org>
References: <9FCF91F7-B3E4-46A5-979E-9C24AFF8D51F@justtesting.org>
 <CACbaDy4VtQrXmiS8QJLzEfvxNfKrpZeBS69AP1fg6ghNJ5EiXw@mail.gmail.com>
 <87wpok5oxh.fsf@smart-cactus.org>
 <CAD3WKghX5sQwdePxK35Mazys7-Vcp36TjyQd2nmWFWUqTxcgCg@mail.gmail.com>
 <9E234A5C-DADF-4B31-8D2D-10AD2686F3E7@justtesting.org>
 <CAKFCL4Xh07yQ3hSD6ZK2iv0Pk6nrcJFVCm44ivo3uwK09hSTTQ@mail.gmail.com>
 <17264046-C6FF-42E2-AECE-F7988A1C17DE@justtesting.org>
Message-ID: <CAKFCL4XGM6H3mUGH0Yan9Dob+cifvsJDJGLq0P9DVnPb6Q7_ZQ@mail.gmail.com>

On Wed, Mar 30, 2016 at 9:50 PM, Manuel M T Chakravarty <
chak at justtesting.org> wrote:

> Firstly, we have
>
>   isPrint :: Char -> Bool
>
> Are you saying that this type is wrong?
>
> Secondly, how often do you feed the output of ?show? to ?read? in another
> locale versus how often is everybody whose whole life is outside of ASCII
> (i.e., not anglo-centric people) bothered by this shortcoming? (*)
>
> Moreover, the argument on the ticket was that changing the current
> implementation would go against the standard. Now that I am saying, the
> current implementation is not conforming to the standard, the standard
> suddenly doesn?t seem to matter. Personally, I would say, when we wrote
> that standard, we knew what we were doing.
>

The standard I am aware of is the Report, which deliberately limited the
output to the subset which is guaranteed to be usable in all locales. show
conforms to this; apparently people want it to *not* conform, and in a way
which requires some locale to become the One True Locale.

isPrint is, as per the language Report, based on what Char is --- which is
Unicode codepoints. Using it for output --- or for input, for that matter
--- gets you into locale issues because nobody anywhere guarantees that
Unicode codepoints that pass isPrint are representable in every locale.
isPrint is not the place to verify that a character can actually be
displayed in the current locale.

Or have you decided that ghc should require Unicode locales and nothing but
Unicode locales from now on? If so, what do you do when the next issue
comes up, where Unix is UTF8 and Windows is UTF16?

-- 
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/20160330/1363324c/attachment.html>

From carter.schonwald at gmail.com  Thu Mar 31 03:03:37 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 30 Mar 2016 23:03:37 -0400
Subject: Unicode, strings, and Show
In-Reply-To: <CAKFCL4XGM6H3mUGH0Yan9Dob+cifvsJDJGLq0P9DVnPb6Q7_ZQ@mail.gmail.com>
References: <9FCF91F7-B3E4-46A5-979E-9C24AFF8D51F@justtesting.org>
 <CACbaDy4VtQrXmiS8QJLzEfvxNfKrpZeBS69AP1fg6ghNJ5EiXw@mail.gmail.com>
 <87wpok5oxh.fsf@smart-cactus.org>
 <CAD3WKghX5sQwdePxK35Mazys7-Vcp36TjyQd2nmWFWUqTxcgCg@mail.gmail.com>
 <9E234A5C-DADF-4B31-8D2D-10AD2686F3E7@justtesting.org>
 <CAKFCL4Xh07yQ3hSD6ZK2iv0Pk6nrcJFVCm44ivo3uwK09hSTTQ@mail.gmail.com>
 <17264046-C6FF-42E2-AECE-F7988A1C17DE@justtesting.org>
 <CAKFCL4XGM6H3mUGH0Yan9Dob+cifvsJDJGLq0P9DVnPb6Q7_ZQ@mail.gmail.com>
Message-ID: <CAHYVw0ynycUDUNWZvLpYbM54KR+Kmgs01iP7CrWLTSfFCeGvWw@mail.gmail.com>

One point in the design space that the swift language does, which seems
intersting at least to me, is to have the notion of a character be backed
by a Unicode grapheme cluster, which is a character like sequence of
Unicode code points.  Would library support for this at all help this
discussion or problem?

On Wednesday, March 30, 2016, Brandon Allbery <allbery.b at gmail.com> wrote:

> On Wed, Mar 30, 2016 at 9:50 PM, Manuel M T Chakravarty <
> chak at justtesting.org
> <javascript:_e(%7B%7D,'cvml','chak at justtesting.org');>> wrote:
>
>> Firstly, we have
>>
>>   isPrint :: Char -> Bool
>>
>> Are you saying that this type is wrong?
>>
>> Secondly, how often do you feed the output of ?show? to ?read? in another
>> locale versus how often is everybody whose whole life is outside of ASCII
>> (i.e., not anglo-centric people) bothered by this shortcoming? (*)
>>
>> Moreover, the argument on the ticket was that changing the current
>> implementation would go against the standard. Now that I am saying, the
>> current implementation is not conforming to the standard, the standard
>> suddenly doesn?t seem to matter. Personally, I would say, when we wrote
>> that standard, we knew what we were doing.
>>
>
> The standard I am aware of is the Report, which deliberately limited the
> output to the subset which is guaranteed to be usable in all locales. show
> conforms to this; apparently people want it to *not* conform, and in a way
> which requires some locale to become the One True Locale.
>
> isPrint is, as per the language Report, based on what Char is --- which is
> Unicode codepoints. Using it for output --- or for input, for that matter
> --- gets you into locale issues because nobody anywhere guarantees that
> Unicode codepoints that pass isPrint are representable in every locale.
> isPrint is not the place to verify that a character can actually be
> displayed in the current locale.
>
> Or have you decided that ghc should require Unicode locales and nothing
> but Unicode locales from now on? If so, what do you do when the next issue
> comes up, where Unix is UTF8 and Windows is UTF16?
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com <javascript:_e(%7B%7D,'cvml','allbery.b at gmail.com');>
>                                  ballbery at sinenomine.net
> <javascript:_e(%7B%7D,'cvml','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/20160330/b3135b25/attachment.html>

From allbery.b at gmail.com  Thu Mar 31 03:08:28 2016
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 30 Mar 2016 23:08:28 -0400
Subject: Unicode, strings, and Show
In-Reply-To: <CAHYVw0ynycUDUNWZvLpYbM54KR+Kmgs01iP7CrWLTSfFCeGvWw@mail.gmail.com>
References: <9FCF91F7-B3E4-46A5-979E-9C24AFF8D51F@justtesting.org>
 <CACbaDy4VtQrXmiS8QJLzEfvxNfKrpZeBS69AP1fg6ghNJ5EiXw@mail.gmail.com>
 <87wpok5oxh.fsf@smart-cactus.org>
 <CAD3WKghX5sQwdePxK35Mazys7-Vcp36TjyQd2nmWFWUqTxcgCg@mail.gmail.com>
 <9E234A5C-DADF-4B31-8D2D-10AD2686F3E7@justtesting.org>
 <CAKFCL4Xh07yQ3hSD6ZK2iv0Pk6nrcJFVCm44ivo3uwK09hSTTQ@mail.gmail.com>
 <17264046-C6FF-42E2-AECE-F7988A1C17DE@justtesting.org>
 <CAKFCL4XGM6H3mUGH0Yan9Dob+cifvsJDJGLq0P9DVnPb6Q7_ZQ@mail.gmail.com>
 <CAHYVw0ynycUDUNWZvLpYbM54KR+Kmgs01iP7CrWLTSfFCeGvWw@mail.gmail.com>
Message-ID: <CAKFCL4Umbzu6gS1XhO0-vtSRzPeS5kUf8ChAXSSnq7w4SDKYCw@mail.gmail.com>

On Wed, Mar 30, 2016 at 11:03 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> One point in the design space that the swift language does, which seems
> intersting at least to me, is to have the notion of a character be backed
> by a Unicode grapheme cluster, which is a character like sequence of
> Unicode code points.  Would library support for this at all help this
> discussion or problem?


That's also Perl 6's solution. But in this case it would not help because
it's still living in Unicode space and not the I/O locale that is the
destination for the character.

-- 
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/20160330/11e7e3d9/attachment-0001.html>

From rahulmutt at gmail.com  Thu Mar 31 06:32:47 2016
From: rahulmutt at gmail.com (Rahul Muttineni)
Date: Thu, 31 Mar 2016 12:02:47 +0530
Subject: nix build haskell.compiler.ghcHEAD
Message-ID: <CANij+eRfGmhANLFzSvk+xk6UbW9DOcoCx7Ld1c3WRD1XU4_2=g@mail.gmail.com>

Hi GHC Devs,

Refer https://github.com/NixOS/nixpkgs/issues/14333 for a problem I was
having when building with nix. The interesting part is that if I add an
extra flag -optl-lpthread manually, the error goes away and the build
succeeds. My question is why the build system didn't add the -optl-lpthread
flag when libpthread was a requirement for that particular build?

Thanks,
Rahul Muttineni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160331/bd07aa77/attachment.html>

From chak at justtesting.org  Thu Mar 31 06:38:25 2016
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Thu, 31 Mar 2016 17:38:25 +1100
Subject: Unicode, strings, and Show
In-Reply-To: <CAKFCL4XGM6H3mUGH0Yan9Dob+cifvsJDJGLq0P9DVnPb6Q7_ZQ@mail.gmail.com>
References: <9FCF91F7-B3E4-46A5-979E-9C24AFF8D51F@justtesting.org>
 <CACbaDy4VtQrXmiS8QJLzEfvxNfKrpZeBS69AP1fg6ghNJ5EiXw@mail.gmail.com>
 <87wpok5oxh.fsf@smart-cactus.org>
 <CAD3WKghX5sQwdePxK35Mazys7-Vcp36TjyQd2nmWFWUqTxcgCg@mail.gmail.com>
 <9E234A5C-DADF-4B31-8D2D-10AD2686F3E7@justtesting.org>
 <CAKFCL4Xh07yQ3hSD6ZK2iv0Pk6nrcJFVCm44ivo3uwK09hSTTQ@mail.gmail.com>
 <17264046-C6FF-42E2-AECE-F7988A1C17DE@justtesting.org>
 <CAKFCL4XGM6H3mUGH0Yan9Dob+cifvsJDJGLq0P9DVnPb6Q7_ZQ@mail.gmail.com>
Message-ID: <73971A5E-E949-429F-8D2F-1A73FCBC2C9A@justtesting.org>

> Brandon Allbery <allbery.b at gmail.com>:
> 
> On Wed, Mar 30, 2016 at 9:50 PM, Manuel M T Chakravarty <chak at justtesting.org <mailto:chak at justtesting.org>> wrote:
> Firstly, we have
> 
>   isPrint :: Char -> Bool
> 
> Are you saying that this type is wrong?
> 
> Secondly, how often do you feed the output of ?show? to ?read? in another locale versus how often is everybody whose whole life is outside of ASCII (i.e., not anglo-centric people) bothered by this shortcoming? (*)
> 
> Moreover, the argument on the ticket was that changing the current implementation would go against the standard. Now that I am saying, the current implementation is not conforming to the standard, the standard suddenly doesn?t seem to matter. Personally, I would say, when we wrote that standard, we knew what we were doing.
> 
> The standard I am aware of is the Report, which deliberately limited the output to the subset which is guaranteed to be usable in all locales. show conforms to this; apparently people want it to *not* conform, and in a way which requires some locale to become the One True Locale.

Where does it say that in the Report?

> isPrint is, as per the language Report, based on what Char is --- which is Unicode codepoints. Using it for output ? or for input, for that matter --- gets you into locale issues because nobody anywhere guarantees that Unicode codepoints that pass isPrint are representable in every locale. isPrint is not the place to verify that a character can actually be displayed in the current locale.

Yet, this is apparently what the report requires.

IMHO, it also makes sense. We have seen that either set up (the current or using ?isPrint?) has imperfections. However, getting \<number> is rarely helpful, whereas using ?isPrint? is going to be helpful most of the time.

Manuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160331/24f1e6f8/attachment.html>

From rahulmutt at gmail.com  Thu Mar 31 07:06:01 2016
From: rahulmutt at gmail.com (Rahul Muttineni)
Date: Thu, 31 Mar 2016 12:36:01 +0530
Subject: nix build haskell.compiler.ghcHEAD
In-Reply-To: <CANij+eRfGmhANLFzSvk+xk6UbW9DOcoCx7Ld1c3WRD1XU4_2=g@mail.gmail.com>
References: <CANij+eRfGmhANLFzSvk+xk6UbW9DOcoCx7Ld1c3WRD1XU4_2=g@mail.gmail.com>
Message-ID: <CANij+eTaX5Up735s+Y9=JdFqJMODpX+fEKTXrL0AxDe54gbrYg@mail.gmail.com>

It seems to keep failing on all sub-directories of utils/. I manually
changed

utils/*_dist-install_DEP_EXTRA_LIBS = rt util dl gmp m rt dl pthread

and the stage2 compiler built successfully after that. Has anyone else
faced this problem building the utils/* in commit 1757dd8? If so, I'll
submit a patch that adds on the 'pthread' to DEP_EXTRA_LIBS in the utils/
directory.


On Thu, Mar 31, 2016 at 12:02 PM, Rahul Muttineni <rahulmutt at gmail.com>
wrote:

> Hi GHC Devs,
>
> Refer https://github.com/NixOS/nixpkgs/issues/14333 for a problem I was
> having when building with nix. The interesting part is that if I add an
> extra flag -optl-lpthread manually, the error goes away and the build
> succeeds. My question is why the build system didn't add the -optl-lpthread
> flag when libpthread was a requirement for that particular build?
>
> Thanks,
> Rahul Muttineni
>



-- 
Rahul Muttineni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160331/add3657a/attachment.html>

From simonpj at microsoft.com  Thu Mar 31 07:26:37 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 31 Mar 2016 07:26:37 +0000
Subject: [commit: ghc] master: Refactor in TcMatches (bdd9042)
In-Reply-To: <20160331070154.844B53A300@ghc.haskell.org>
References: <20160331070154.844B53A300@ghc.haskell.org>
Message-ID: <964bfe8b07764b7bb580e66115276da4@DB4PR30MB030.064d.mgd.msft.net>

Ben, Austin

The group of around six refactoring patches I have just committed are inessential for 8.0, but I think they are solid enough to merge if some other later patch depends on them.

Simon

|  -----Original Message-----
|  From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
|  git at git.haskell.org
|  Sent: 31 March 2016 08:02
|  To: ghc-commits at haskell.org
|  Subject: [commit: ghc] master: Refactor in TcMatches (bdd9042)
|  
|  Repository : ssh://git at git.haskell.org/ghc
|  
|  On branch  : master
|  Link       :
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.has
|  kell.org%2ftrac%2fghc%2fchangeset%2fbdd90426a7f88d57bedf15411fa00f62aeb
|  22172%2fghc&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c23c66899d
|  70e4e74cd8608d35932b916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Lw
|  9ByEHKPpKZb%2fsgZQc1dpCjTm8yNAh5%2b1izy9PdgX0%3d
|  
|  >---------------------------------------------------------------
|  
|  commit bdd90426a7f88d57bedf15411fa00f62aeb22172
|  Author: Simon Peyton Jones <simonpj at microsoft.com>
|  Date:   Wed Mar 30 17:14:11 2016 +0100
|  
|      Refactor in TcMatches
|  
|      * Move the several calls of tauifyMultipleMatches into tcMatches,
|        so that it can be called only once, and the invariants are
|        clearer
|  
|      * I discovered in doing this that HsLamCase had a redundant and
|        tiresome argument, so I removed it. That in turn allowed some
|        modest but nice code simplification
|  
|  
|  >---------------------------------------------------------------
|  
|  bdd90426a7f88d57bedf15411fa00f62aeb22172
|   compiler/deSugar/Coverage.hs    |  2 +-
|   compiler/deSugar/DsExpr.hs      |  7 +++----
|   compiler/deSugar/DsMeta.hs      |  2 +-
|   compiler/hsSyn/Convert.hs       |  3 +--
|   compiler/hsSyn/HsExpr.hs        | 16 +++++++++-------
|   compiler/parser/Parser.y        |  2 +-
|   compiler/rename/RnExpr.hs       |  5 ++---
|   compiler/typecheck/TcExpr.hs    | 17 +++++++++--------
|   compiler/typecheck/TcHsSyn.hs   |  7 +++----
|   compiler/typecheck/TcMatches.hs | 24 ++++++++----------------
|  compiler/typecheck/TcRnTypes.hs |  2 +-
|   11 files changed, 39 insertions(+), 48 deletions(-)
|  
|  Diff suppressed because of size. To see it, use:
|  
|      git diff-tree --root --patch-with-stat --no-color --find-copies-
|  harder --ignore-space-at-eol --cc
|  bdd90426a7f88d57bedf15411fa00f62aeb22172
|  _______________________________________________
|  ghc-commits mailing list
|  ghc-commits at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c23c66899d70e4
|  e74cd8608d35932b916%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8kgpTH
|  G1JUjyHegki%2bBXMZ6gdSlUReHDY5pQIdaUqMg%3d

From mail at joachim-breitner.de  Thu Mar 31 08:49:04 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 31 Mar 2016 10:49:04 +0200
Subject: Initial compile time benchmarks
In-Reply-To: <CAMQQO3kVEpBPbTrywo6KN1XPxQqwd2AHRsseuiNvvSh8bp382Q@mail.gmail.com>
References: <CAMQQO3kVEpBPbTrywo6KN1XPxQqwd2AHRsseuiNvvSh8bp382Q@mail.gmail.com>
Message-ID: <1459414144.1628.6.camel@joachim-breitner.de>

Hi ?mer,

thanks for the log. This is roughly GHC HEAD, right?

I wanted to check for low-hanging fruit in ?my? code, so I compiled
Data.Reflection, where your tool reports 12% time spent in Call Arity.?

But if I run it with profiling, it says 3.5% of time is spent in that
pass, and if I run your tool on the timing output produced by a
profiled GHC, I get 8.3%, and on the output of a a development build, I
get 3.8%.


So what is your setup: How did you compile GHC, and with what options
are you running it?

Greetings,
Joachim



-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-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/20160331/7c53a499/attachment.sig>

From simonpj at microsoft.com  Thu Mar 31 14:56:56 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 31 Mar 2016 14:56:56 +0000
Subject: Perf
Message-ID: <f1cd22f99e184c67b22a6a7c0df2a931@DB4PR30MB030.064d.mgd.msft.net>

Joachim
Harbormaster seems to be saying that GHC?s perf got a lot worse
https://phabricator.haskell.org/harbormaster/
after Buildable 9015, which omitted the oneshot info.  The typechecker seems to allocate a lot more.
That is not good.  Revert and investigate?
Simon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160331/5363e0fb/attachment.html>

From omeragacan at gmail.com  Thu Mar 31 16:00:42 2016
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Thu, 31 Mar 2016 12:00:42 -0400
Subject: Initial compile time benchmarks
In-Reply-To: <1459414144.1628.6.camel@joachim-breitner.de>
References: <CAMQQO3kVEpBPbTrywo6KN1XPxQqwd2AHRsseuiNvvSh8bp382Q@mail.gmail.com>
 <1459414144.1628.6.camel@joachim-breitner.de>
Message-ID: <CAMQQO3mpEbGcP5AohUK4+FtBoDt0J+tJ1WTqZQWc=a5BByVPeg@mail.gmail.com>

Hi Joachim,

That's GHC HEAD at the time with -O1 for stage 2 + libs.

The way I generate the logs is:

- I create a cabal sandbox and run `cabal exec zsh` to set up the env
  variables.

- I install packages in that shell.

- $ (cat  .cabal-sandbox/logs/*.log | analyze-ghc-timings) > output

I don't know why there would be that much difference. Note that my setup was
not perfect, I run some other (although lightweight) processes on the side.

2016-03-31 4:49 GMT-04:00 Joachim Breitner <mail at joachim-breitner.de>:
> Hi ?mer,
>
> thanks for the log. This is roughly GHC HEAD, right?
>
> I wanted to check for low-hanging fruit in ?my? code, so I compiled
> Data.Reflection, where your tool reports 12% time spent in Call Arity.
>
> But if I run it with profiling, it says 3.5% of time is spent in that
> pass, and if I run your tool on the timing output produced by a
> profiled GHC, I get 8.3%, and on the output of a a development build, I
> get 3.8%.
>
>
> So what is your setup: How did you compile GHC, and with what options
> are you running it?
>
> Greetings,
> Joachim
>
>
>
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? https://www.joachim-breitner.de/
>   XMPP: nomeata at joachim-breitner.de ? OpenPGP-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
>

From omeragacan at gmail.com  Thu Mar 31 16:01:39 2016
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Thu, 31 Mar 2016 12:01:39 -0400
Subject: Initial compile time benchmarks
In-Reply-To: <CAMQQO3mpEbGcP5AohUK4+FtBoDt0J+tJ1WTqZQWc=a5BByVPeg@mail.gmail.com>
References: <CAMQQO3kVEpBPbTrywo6KN1XPxQqwd2AHRsseuiNvvSh8bp382Q@mail.gmail.com>
 <1459414144.1628.6.camel@joachim-breitner.de>
 <CAMQQO3mpEbGcP5AohUK4+FtBoDt0J+tJ1WTqZQWc=a5BByVPeg@mail.gmail.com>
Message-ID: <CAMQQO3m3K5Ms-LgGex3UpUo_Q4foLs+tkSg=6Rwr4_f+aC0F5Q@mail.gmail.com>

Forgot to mention that I use `cabal install <package name>
--ghc-options="-v3" -v3` to install the packages.

2016-03-31 12:00 GMT-04:00 ?mer Sinan A?acan <omeragacan at gmail.com>:
> Hi Joachim,
>
> That's GHC HEAD at the time with -O1 for stage 2 + libs.
>
> The way I generate the logs is:
>
> - I create a cabal sandbox and run `cabal exec zsh` to set up the env
>   variables.
>
> - I install packages in that shell.
>
> - $ (cat  .cabal-sandbox/logs/*.log | analyze-ghc-timings) > output
>
> I don't know why there would be that much difference. Note that my setup was
> not perfect, I run some other (although lightweight) processes on the side.
>
> 2016-03-31 4:49 GMT-04:00 Joachim Breitner <mail at joachim-breitner.de>:
>> Hi ?mer,
>>
>> thanks for the log. This is roughly GHC HEAD, right?
>>
>> I wanted to check for low-hanging fruit in ?my? code, so I compiled
>> Data.Reflection, where your tool reports 12% time spent in Call Arity.
>>
>> But if I run it with profiling, it says 3.5% of time is spent in that
>> pass, and if I run your tool on the timing output produced by a
>> profiled GHC, I get 8.3%, and on the output of a a development build, I
>> get 3.8%.
>>
>>
>> So what is your setup: How did you compile GHC, and with what options
>> are you running it?
>>
>> Greetings,
>> Joachim
>>
>>
>>
>> --
>> Joachim ?nomeata? Breitner
>>   mail at joachim-breitner.de ? https://www.joachim-breitner.de/
>>   XMPP: nomeata at joachim-breitner.de ? OpenPGP-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
>>

From mail at joachim-breitner.de  Thu Mar 31 16:33:35 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 31 Mar 2016 18:33:35 +0200
Subject: Perf
In-Reply-To: <f1cd22f99e184c67b22a6a7c0df2a931@DB4PR30MB030.064d.mgd.msft.net>
References: <f1cd22f99e184c67b22a6a7c0df2a931@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <1459442015.1628.15.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 31.03.2016, 14:56 +0000 schrieb Simon Peyton Jones:
> Joachim
> 
> Harbormaster seems to be saying that GHC?s perf got a lot worse
> 
> https://phabricator.haskell.org/harbormaster/
> 
> after Buildable 9015, which omitted the oneshot info.? The
> typechecker seems to allocate a lot more.
> 
> That is not good.? Revert and investigate?

yes, I noticed as well, and perf.haskell.org has now also confirmed
this. Just pushed a reversal. But I wonder what went wrong when I ran
./validate --slow
locally.

Can we please have harbormaster builds of DRs back? I felt just so much
more secure about pushing when the commits were checked by a more
reliable party than me.

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-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/20160331/ddffca21/attachment.sig>

From omeragacan at gmail.com  Thu Mar 31 19:28:25 2016
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Thu, 31 Mar 2016 15:28:25 -0400
Subject: Initial compile time benchmarks
In-Reply-To: <CAMQQO3m3K5Ms-LgGex3UpUo_Q4foLs+tkSg=6Rwr4_f+aC0F5Q@mail.gmail.com>
References: <CAMQQO3kVEpBPbTrywo6KN1XPxQqwd2AHRsseuiNvvSh8bp382Q@mail.gmail.com>
 <1459414144.1628.6.camel@joachim-breitner.de>
 <CAMQQO3mpEbGcP5AohUK4+FtBoDt0J+tJ1WTqZQWc=a5BByVPeg@mail.gmail.com>
 <CAMQQO3m3K5Ms-LgGex3UpUo_Q4foLs+tkSg=6Rwr4_f+aC0F5Q@mail.gmail.com>
Message-ID: <CAMQQO3m3pb+Kzu-A107WhzHObpABzkus96mNetwvtQ1RKi=QeQ@mail.gmail.com>

I just benchmarked another set of packages, this time using -O2 optimized libs
+ stage 2 (6ea42c7):

https://gist.githubusercontent.com/osa1/b483216953e3b02c0c79f9e4c8f8f931/raw/64001a1bfb71c0c4441c07f9f195bf5629095a6f/gistfile1.txt

For me the most surprising part is that CodeGen is sometimes taking 86% of the
time. It seems like we can start looking for improvements there. (I'll do that
myself but I'm too busy for a few more days)


Joachim, I think the difference is because of how thunk evaluation and cost
centers work. If you generate a thunk with cost-center "X", you attribute the
evaluation costs of that thunk to the cost-center "X". This is unlike how GHC
currently printing the timing information: We essentially measure the time of
thunk creation, not normalization of thunks. So the numbers you get from the
profiling output may be more correct.

We should try actually forcing the values in `withTiming` and see how it'll
effect the timings. I feel like some of the costs attributed to CodeGen step
is because of thunks we generate in previous steps. It's probably not possible
to completely evaluate the values (because of cycles), but we can still do a
better job probably.

One last thing is that profiling can prevent some optimizations and cause
different runtime behavior. Problems with instrumentation ...

2016-03-31 12:01 GMT-04:00 ?mer Sinan A?acan <omeragacan at gmail.com>:
> Forgot to mention that I use `cabal install <package name>
> --ghc-options="-v3" -v3` to install the packages.
>
> 2016-03-31 12:00 GMT-04:00 ?mer Sinan A?acan <omeragacan at gmail.com>:
>> Hi Joachim,
>>
>> That's GHC HEAD at the time with -O1 for stage 2 + libs.
>>
>> The way I generate the logs is:
>>
>> - I create a cabal sandbox and run `cabal exec zsh` to set up the env
>>   variables.
>>
>> - I install packages in that shell.
>>
>> - $ (cat  .cabal-sandbox/logs/*.log | analyze-ghc-timings) > output
>>
>> I don't know why there would be that much difference. Note that my setup was
>> not perfect, I run some other (although lightweight) processes on the side.
>>
>> 2016-03-31 4:49 GMT-04:00 Joachim Breitner <mail at joachim-breitner.de>:
>>> Hi ?mer,
>>>
>>> thanks for the log. This is roughly GHC HEAD, right?
>>>
>>> I wanted to check for low-hanging fruit in ?my? code, so I compiled
>>> Data.Reflection, where your tool reports 12% time spent in Call Arity.
>>>
>>> But if I run it with profiling, it says 3.5% of time is spent in that
>>> pass, and if I run your tool on the timing output produced by a
>>> profiled GHC, I get 8.3%, and on the output of a a development build, I
>>> get 3.8%.
>>>
>>>
>>> So what is your setup: How did you compile GHC, and with what options
>>> are you running it?
>>>
>>> Greetings,
>>> Joachim
>>>
>>>
>>>
>>> --
>>> Joachim ?nomeata? Breitner
>>>   mail at joachim-breitner.de ? https://www.joachim-breitner.de/
>>>   XMPP: nomeata at joachim-breitner.de ? OpenPGP-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
>>>

From mail at joachim-breitner.de  Thu Mar 31 20:53:36 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 31 Mar 2016 22:53:36 +0200
Subject: cryptarithm1 performance discontinuity (Was: Perf)
In-Reply-To: <1459442015.1628.15.camel@joachim-breitner.de>
References: <f1cd22f99e184c67b22a6a7c0df2a931@DB4PR30MB030.064d.mgd.msft.net>
 <1459442015.1628.15.camel@joachim-breitner.de>
Message-ID: <1459457616.24184.2.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 31.03.2016, 18:33 +0200 schrieb Joachim Breitner:
> yes, I noticed as well, and perf.haskell.org has now also confirmed
> this. Just pushed a reversal. But I wonder what went wrong when I ran
> ./validate --slow
> locally.

interesting, my patch, as bad as it was for compiler performance,
improved the runtime of cryptarithm1 by the amount it regressed due to?

commit d1179c4bff6d05cc9e86eee3e2d2cee707983c90
Author: Ben Gamari <ben at smart-cactus.org>
Date:???Wed Mar 30 10:09:36 2016 +0200

? ? ghc-prim: Delay inlining of {gt,ge,lt,le}Int to phase 1

as you can nicely see in this graph:
https://perf.haskell.org/ghc/#graph/nofib/time/cryptarithm1;hl=d1179c4bff6d05cc9e86eee3e2d2cee707983c90
(sorry, the relevant bits will move out of the window as more commits
come in. This is something I need to improve in gipeda).

There seems to be a performance non-continuity triggered by very small
changes. *shrug*, for now. But if anyone feels like investigating, I?d
be eager to hear you find.

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-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/20160331/acf6c3f6/attachment.sig>