HsParTy

2017-05-26 Thread Simon Peyton Jones via ghc-devs 
Alan
Do you know why HsTypes.ppr_mono_ty contains any uses of 'maybeParen'?  
Shouldn't the parens all be put in by HsParTy?
I tripped over this when I mistakenly added what I thought were missing 
maybeParen calls for HsAppTy and HsAppTys, but that was flagged as an error by 
a test in tests/printer.
So why are there /any/ maybeParen calls?
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Trees that Grow in the hsSyn AST

2017-05-26 Thread Simon Peyton Jones via ghc-devs 
1. Which is better to start with: HsSyn or Core? Intuition suggests this sort 
of thing could be very helpful for making zapping more reliable and ensuring 
its efficiency, but there may be better reasons to start with HsSyn.

Definitely HsSyn.  It’s big, riddled with extra info, and has many purposes for 
different people.  Core is small, tight, nailed down.  I don’t want to mess 
with it.

2. If we're making intrusive changes to representations, would now be a 
sensible era to consider switching to a different variable representation 
(unbound, bound, abt, etc)?

I don’t think so.  The issues are quite orthogonal, and no one (to my 
knowledge) has proposed any vaguely plausible change to variable bindings that 
would scale to what GHC does.   In contrast, this stuff is “just” 
re-engineering.

Simon

From: David Feuer [mailto:da...@well-typed.com]
Sent: 26 May 2017 01:11
To: Simon Peyton Jones ; Alan & Kim Zimmerman 
; ghc-devs@haskell.org
Subject: RE: Trees that Grow in the hsSyn AST

I haven't looked in detail yet, but there seem to be good ideas. I have two 
questions:

1. Which is better to start with: HsSyn or Core? Intuition suggests this sort 
of thing could be very helpful for making zapping more reliable and ensuring 
its efficiency, but there may be better reasons to start with HsSyn.

2. If we're making intrusive changes to representations, would now be a 
sensible era to consider switching to a different variable representation 
(unbound, bound, abt, etc)?


David Feuer
Well-Typed, LLP

 Original message 
From: Simon Peyton Jones via ghc-devs 
mailto:ghc-devs@haskell.org>>
Date: 5/25/17 6:48 PM (GMT-05:00)
To: Alan & Kim Zimmerman mailto:alan.z...@gmail.com>>, 
ghc-devs@haskell.org
Subject: RE: Trees that Grow in the hsSyn AST

Folks

Do take a look at this:


·We propose to re-engineer HsSyn itself.  This will touch a lot of code.

·But it’s very neat, and will bring big long-term advantages

·And we can do it a bit at a time

The wiki page https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow 
has the details.

It’s entirely an internal change, not a change to GHC’s specification, so it’s 
independent of the GHC proposals process.  But I’d value the opinion of other 
GHC devs.

Alan has done a prototype first step, which worked out rather well.  Rather 
than having
   HsExpr Id
(which we all know means “HsExpr after the typechecker” but tha’s a bit 
inexplicit, we have
   HsExpr GhcTc
meaning “HsExpr after GHC’s Tc pass”.   In some ways this is quite superficial, 
but it unlocks the Trees That Grow machiney.

Please ask questions etc.  Alan and Shayan can record the answers in the wiki.  
I’m inclined to go ahead with this, so yell soon if you disagree.

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan & Kim 
Zimmerman
Sent: 24 May 2017 22:52
To: ghc-devs@haskell.org
Subject: Trees that Grow in the hsSyn AST

Hi all

You may be aware that Shayan Najd presented the paper  "Trees that Grow"[1] at 
HIW last year.
Based on the following mandate
> As in my previous email to Shayan (attached).  Wiki page, describe goals, 
> design,
> approach.  Point to prototype implementation.  Seek comments.   You can say 
> that
>I am supportive!
>
> Simon

We have set up a Wiki page at [2] describing a prototype implementation of the 
first stage of this for the hsSyn AST, which is to change the polymorphic 
variable from one of RdrName / Name / Id to an index type. This is presented as 
a fabricator diff at [3].
Please take a look and provide feedback.
Regards
  Alan


[1] 
http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf>
[2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow
[3] https://phabricator.haskell.org/D3609
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.2.1 release candidate 2

2017-05-26 Thread Alberto Valverde 
Hi Ryan,

Some preogress... The cabal issues I reported seem more of a nix issue but
I'm not sure what is causing them. FWIW, nix does not use cabal-install at
all but instead compiles the Setup.hs script and runs that.

The weird thing is that i'm trying to reproduce what the nix
haskell-package builder [1] does and the problem I described (no Main.hs
could be found) does not occur but instead the Main.hs module fails to
compile due to an unrelated error. So it seems that, somehow, the unrelated
compile error is being mistaken by a lack of module.

Even weirder is that the snap-server.cabal says that the failing
executables should only be built when flags are enabled (which are disabled
by default) but they are being built anyway when nix calls Setup, even when
I explicitly disable them via nix. The nix build log [2] even says that the
flags (build-pong and build-testserver) are disabled! However, If I
manually execute Setup the configure flags are honored.

I'll continue to investigate to try and make some sense of this but I think
it's not cabal's fault so feel free to ignore me for the meantime. I'll
chime back if/when I find it is an issue with the new Cabal.

Thanks,
Alberto

[1]
https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/generic-builder.nix
[2]
https://gist.github.com/albertov/eee8af04eeca9f946ab107d416256a05#file-gistfile1-txt-L21

On Tue, May 23, 2017 at 6:28 PM, Ryan Scott  wrote:

> Alberto,
>
> > I've manage to reproduce the CK bug without any external dependencies and
> > opened a ticket with an attached module that fails to compile with
> > 8.2.1-rc2 (w/o explicit KindSignature) but compiles fine with 8.0.2.
>
> Thanks for doing this!
>
> > Will hopefully follow up soon with the Cabal issues I'm experiencing
>
> One thing that might be useful to do is to invoke Cabal with high
> verbosity (e.g., -v3) and post the logs somewhere. I wouldn't be surprised
> if Nix was passing some uncommonly used flags that have regressed in recent
> versions of Cabal.
>
> Ryan S.
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: HsParTy

2017-05-26 Thread Alan & Kim Zimmerman 
When I was working through the ppr to use HsParTy everywhere it was not
clear whether there were any usages that required maybeParen, so I left it
in.

I can try to strip then all out and see what happens.

Alan


On 26 May 2017 at 10:54, Simon Peyton Jones  wrote:

> Alan
>
> Do you know why HsTypes.ppr_mono_ty contains any uses of ‘maybeParen’?
> Shouldn’t the parens all be put in by HsParTy?
>
> I tripped over this when I mistakenly added what I thought were missing
> maybeParen calls for HsAppTy and HsAppTys, but that was flagged as an error
> by a test in tests/printer.
>
> So why are there /any/ maybeParen calls?
>
> Simon
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: HsParTy

2017-05-26 Thread Simon Peyton Jones via ghc-devs 
I can try to strip then all out and see what happens.
That’d be good!  With a Note to explain why…

We still need ctxt_prec, I think, to pass to the ordinary type pretty-printer, 
when we have HsCoreTy.

Simon

From: Alan & Kim Zimmerman [mailto:alan.z...@gmail.com]
Sent: 26 May 2017 12:14
To: Simon Peyton Jones 
Cc: ghc-devs@haskell.org
Subject: Re: HsParTy

When I was working through the ppr to use HsParTy everywhere it was not clear 
whether there were any usages that required maybeParen, so I left it in.
I can try to strip then all out and see what happens.
Alan

On 26 May 2017 at 10:54, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
Alan
Do you know why HsTypes.ppr_mono_ty contains any uses of ‘maybeParen’?  
Shouldn’t the parens all be put in by HsParTy?
I tripped over this when I mistakenly added what I thought were missing 
maybeParen calls for HsAppTy and HsAppTys, but that was flagged as an error by 
a test in tests/printer.
So why are there /any/ maybeParen calls?
Simon

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.2.1 release candidate 2

2017-05-26 Thread Alberto Valverde 
It's most certainly not a Cabal issue. The problem only manifests itself on
packages which I have applied Nix's "doJailbreak", which mangles the .cabal
file in order to remove bounds. Maybe the format of the .cabal has changed
slightly and the parser it uses trips up? Anyway, sorry for the noise

On Fri, May 26, 2017 at 11:11 AM, Alberto Valverde 
wrote:

> Hi Ryan,
>
> Some preogress... The cabal issues I reported seem more of a nix issue but
> I'm not sure what is causing them. FWIW, nix does not use cabal-install at
> all but instead compiles the Setup.hs script and runs that.
>
> The weird thing is that i'm trying to reproduce what the nix
> haskell-package builder [1] does and the problem I described (no Main.hs
> could be found) does not occur but instead the Main.hs module fails to
> compile due to an unrelated error. So it seems that, somehow, the unrelated
> compile error is being mistaken by a lack of module.
>
> Even weirder is that the snap-server.cabal says that the failing
> executables should only be built when flags are enabled (which are disabled
> by default) but they are being built anyway when nix calls Setup, even when
> I explicitly disable them via nix. The nix build log [2] even says that the
> flags (build-pong and build-testserver) are disabled! However, If I
> manually execute Setup the configure flags are honored.
>
> I'll continue to investigate to try and make some sense of this but I
> think it's not cabal's fault so feel free to ignore me for the meantime.
> I'll chime back if/when I find it is an issue with the new Cabal.
>
> Thanks,
> Alberto
>
> [1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/
> development/haskell-modules/generic-builder.nix
> [2] https://gist.github.com/albertov/eee8af04eeca9f946ab107d416256a
> 05#file-gistfile1-txt-L21
>
> On Tue, May 23, 2017 at 6:28 PM, Ryan Scott 
> wrote:
>
>> Alberto,
>>
>> > I've manage to reproduce the CK bug without any external dependencies
>> and
>> > opened a ticket with an attached module that fails to compile with
>> > 8.2.1-rc2 (w/o explicit KindSignature) but compiles fine with 8.0.2.
>>
>> Thanks for doing this!
>>
>> > Will hopefully follow up soon with the Cabal issues I'm experiencing
>>
>> One thing that might be useful to do is to invoke Cabal with high
>> verbosity (e.g., -v3) and post the logs somewhere. I wouldn't be surprised
>> if Nix was passing some uncommonly used flags that have regressed in recent
>> versions of Cabal.
>>
>> Ryan S.
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs