GHC release timing and future build infrastructure

[Ben Gamari]

Hello everyone,

I just posted a pair of posts on the GHC blog [1,2] laying out some
thoughts on the GHC release cycle timing [1] and how this relates to the
in-progress Jenkins build infrastructure [2]. When you have a some time
feel free to give them a read and comment (either here or on the Reddit
thread [3]).

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule
[2] https://ghc.haskell.org/trac/ghc/blog/jenkins-ci
[3] 
https://www.reddit.com/r/haskell/comments/6qt0iv/ghc_blog_reflections_on_ghcs_release_schedule/


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

RE: Operating on HsSyn

[Simon Peyton Jones via ghc-devs]

Am I far off?
I don’t think you are far off.  All I’m after is the debug-printer use-case: I 
want to be able to see the contents of the tree, including the PostRn 
annotations.  I don’t care about round-tripping it.

Simon

From: Shayan Najd [mailto:sh.n...@gmail.com]
Sent: 28 July 2017 15:32
To: Simon Peyton Jones 
Cc: ghc-devs@haskell.org; Alan & Kim Zimmerman ; Jacques 
Carette 
Subject: Re: Operating on HsSyn

On the contrary, inside GHC I /do/ want to print them. Otherwise how can I see 
what the renamer has done?

Right. So if I understand correctly, with this semantics, `Outputable` is 
somewhere between pretty printing as often used in program manipulation 
libraries (like Haskell-Src-Exts (HSE)) which is closer to syntax, and `Show` 
which is closer to Haskell representation.
(There are also "exact printers" (as in HSE) that are even closer to syntax in 
some sense.)
Often, pretty printers generate only grammatically valid terms, not the ones 
polluted with extra annotations (hence grammatically invalid), e.g., what is 
the grammatically valid form of `OpApp` printed via `Outputable` that includes 
the fixity annotation.

If I recall correctly, we have briefly studied these in the past summer, we 
came up with some roundtrip correctness criteria, like the following (bar error 
handling; assume valid input):

 (parser . prettyPrint . parser) = id

[paging in Jacques]

The reason I am trying to flesh out the semantics is the /big/ gains on code 
reuse later on in the process: one does not need to define a separate pretty 
printing library for Haskell syntax, and can reuse the well-tested and 
well-maintained one in GHC.

Reformulating part of your concern, based on my understanding (if I may), the 
questions is: what is the proper design of an "outputer" (debug-printer?) where 
/annotated/ terms can be pretty-printed including any printable 
(pretty?showable?) annotations.
In particular, we may want to take advantage of extensibility of data types for 
this.
Am I far off?

Note: with proper design, an extensible debug-printer can still subsume 
corresponding pretty-printers.


On Fri, Jul 28, 2017 at 2:36 PM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
I have been under the impression that we don't even want to print those.
On the contrary, inside GHC I /do/ want to print them. Otherwise how can I see 
what the renamer has done?

Simon

From: Shayan Najd [mailto:sh.n...@gmail.com]
Sent: 28 July 2017 12:20
To: Simon Peyton Jones mailto:simo...@microsoft.com>>
Cc: ghc-devs@haskell.org; Alan & Kim Zimmerman 
mailto:alan.z...@gmail.com>>
Subject: Re: Operating on HsSyn

Before all this, we may need to discuss a bit about the intended semantics of
`Outputable`: does it need to print `PostRn`, or `PostTc` fields; or `Out`
suffixed constructors?  If not, then we only need to write a set of instances
for the base growable AST, once and for all.  Such instances will be polymorphic
on the extension descriptor `p`, and do not need to mention the constraints like
`(PostRn p (IdP p)`, since these are just extensions and not part of the base
growable AST.  Or, am I missing something about the intended semantics of
`Outputable`?

You write

So today we never print these annotations, to avoid bloating the instance 
contexts, which can be painful.

I have been under the impression that we don't even want to print those.

Of course, there are scenarios (like `Show` instances) where we do want to write
compositional / generic functions that take into account the extensions.
Here is my abstract overview of the scenario, that may help the discussion.
Consider data types `A`, `B`, and `C` (say, one AST datatype per compiler 
phase) that
 are defined as extensions to a base datatype `T`:

> A = T XA
> B = T XB
> C = T XC

where `X*`s are extension descriptors.
Now, say we want to a define functions `f_A`, `f_B`, and `f_C` over `A`, `B`, 
and `C`.
We have two main alternatives:
(a) either we write these  (manually or using the deriving mechanism) separately
(b) or we write a generic / parametric function `g` over `T`, and reuse that to 
define `f_*`s

Of course, (b) is preferable in theory , but not always possible or preferable 
in practice.
In which case, we can always resort to (a).
The more varying are the definitions of `f_A`, `f_B`, and `f_C` the more 
parametric should
`g` get, as this is the case for any generic function.

With a correct design, I believe, these are all independent of Trees that Grow 
story itself:
we are now not only trying to reuse data types, and functions agnostic towards 
extensions
(pretty printers in my view of their semantics), but also reuse functions with 
parametric /
varying behaviour with respect to extensions.

/Shayan



On Fri, Jul 28, 2017 at 10:18 AM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
Devs,

Shayan is working away on “Trees that grow”… do keep it on your radar:

To: ghc-devs
Sent: 25 May