Trees that Grow in the hsSyn AST

Fri May 26 02:00:10 UTC 2017

Hi David,

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.

- Why not making Core growable as well?
We just have not considered making Core AST growable so far, though it is
entirely doable if needed.
Specially, if you have some motivating examples that a growable Core AST
"could be very helpful" like for "making zapping more reliable and ensuring
its efficiency", let us know; we can consider making Core growable as well
(possibly as an independent project).

- Why not making Core growable first?
Here the idea is to make HsSyn AST growable for the long-term goals stated
on the wiki page, like getting rid of the multiple representations of
Haskell syntax (i.e., HsSyn, Template Haskell, and Haskell-Src-Exts).
I imagine making Core AST growable does not get us closer to our current
long-term goals (except maybe as an experiment to study the impact of such
AST changes on GHC, like we did in D3609)

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)?

- While we are at it, can we consider improving some bits of the AST?
For the first few steps, I really hope to keep the changes to
representations as little as possible, at least to ease the reviewing
process and to avoid introducing bugs (provided the large scale of the
changes).
For the next steps, we can indeed consider such improvements. (We do so for
source locations, at least)

Do you have some specific changes in mind? Specially the ones that may
overlap with our work?

Thanks.

/Shayan

On Fri, May 26, 2017 at 2:11 AM, David Feuer <david at well-typed.com> wrote:

> 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 <ghc-devs at haskell.org>
> Date: 5/25/17 6:48 PM (GMT-05:00)
> To: Alan & Kim Zimmerman <alan.zimm at gmail.com>, ghc-devs at 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-bounces at haskell.org] On Behalf Of Alan &
> Kim Zimmerman
> Sent: 24 May 2017 22:52
> To: ghc-devs at 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<https://na01.safelinks.protection.
> outlook.com/?url=http%3A%2F%2Fwww.jucs.org%2Fjucs_23_1%
> 2Ftrees_that_grow%2Fjucs_23_01_0042_0062_najd.pdf&data=02%
> 7C01%7Csimonpj%40microsoft.com%7C5faccc0d2d534c42c23e08d4a2ef36d8%
> 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636312595690311243&sdata=
> fbLJdJqSyXgacCEJwVH880aLsHDgDY46hrc%2FtDXv4VQ%3D&reserved=0>
> [2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow
> [3] https://phabricator.haskell.org/D3609
>
> _______________________________________________
> 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/20170526/da928257/attachment.html>