<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.Code, li.Code, div.Code
{mso-style-name:Code;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:9.0pt;
font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal" style="margin-left:36.0pt">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.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">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)?<o:p></o:p></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Simon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> David Feuer [mailto:david@well-typed.com]
<br>
<b>Sent:</b> 26 May 2017 01:11<br>
<b>To:</b> Simon Peyton Jones <simonpj@microsoft.com>; Alan & Kim Zimmerman <alan.zimm@gmail.com>; ghc-devs@haskell.org<br>
<b>Subject:</b> RE: Trees that Grow in the hsSyn AST<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">I haven't looked in detail yet, but there seem to be good ideas. I have two questions:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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)?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div id="composer_signature">
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;color:#575757">David Feuer<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;color:#575757">Well-Typed, LLP<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:black">-------- Original message --------<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">From: Simon Peyton Jones via ghc-devs <<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>>
<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Date: 5/25/17 6:48 PM (GMT-05:00) <o:p>
</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">To: Alan & Kim Zimmerman <<a href="mailto:alan.zimm@gmail.com">alan.zimm@gmail.com</a>>,
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black">Subject: RE: Trees that Grow in the hsSyn AST
<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:black"><o:p> </o:p></span></p>
</div>
</div>
<p class="MsoNormal">Folks<br>
<br>
Do take a look at this:<br>
<br>
<br>
· We propose to re-engineer HsSyn itself. This will touch a lot of code.<br>
<br>
· But it’s very neat, and will bring big long-term advantages<br>
<br>
· And we can do it a bit at a time<br>
<br>
The wiki page <a href="https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow">
https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow</a> has the details.<br>
<br>
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.<br>
<br>
Alan has done a prototype first step, which worked out rather well. Rather than having<br>
HsExpr Id<br>
(which we all know means “HsExpr after the typechecker” but tha’s a bit inexplicit, we have<br>
HsExpr GhcTc<br>
meaning “HsExpr after GHC’s Tc pass”. In some ways this is quite superficial, but it unlocks the Trees That Grow machiney.<br>
<br>
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.<br>
<br>
Simon<br>
<br>
From: ghc-devs [<a href="mailto:ghc-devs-bounces@haskell.org">mailto:ghc-devs-bounces@haskell.org</a>] On Behalf Of Alan & Kim Zimmerman<br>
Sent: 24 May 2017 22:52<br>
To: <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
Subject: Trees that Grow in the hsSyn AST<br>
<br>
Hi all<br>
<br>
You may be aware that Shayan Najd presented the paper "Trees that Grow"[1] at HIW last year.<br>
Based on the following mandate<br>
> As in my previous email to Shayan (attached). Wiki page, describe goals, design,<br>
> approach. Point to prototype implementation. Seek comments. You can say that<br>
>I am supportive!<br>
><br>
> Simon<br>
<br>
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].<br>
Please take a look and provide feedback.<br>
Regards<br>
Alan<br>
<br>
<br>
[1] <a href="http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf%3chttps:/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">
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</a>><br>
[2] <a href="https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow">https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow</a><br>
[3] <a href="https://phabricator.haskell.org/D3609">https://phabricator.haskell.org/D3609</a><o:p></o:p></p>
</div>
</div>
</body>
</html>