<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:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
code
{mso-style-priority:99;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
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:11.0pt;
font-family:"Calibri",sans-serif;}
p.Code, li.Code, div.Code
{mso-style-name:Code;
mso-style-link:"Code Char";
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:9.0pt;
font-family:"Courier New";}
span.CodeChar
{mso-style-name:"Code Char";
mso-style-link:Code;
font-family:"Courier New";}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@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="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">This sounds fine. But I still don’t understand<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">There would still be a single parser definition in
<code><span style="font-size:10.0pt">Parser.y</span></code>, which would make use of functions to add the additional info to the generated source tree, which would be NOPs if the information was not being kept. This is similar to what happens at present with
the Api Annotations.<o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">What is the type of the parser? Does it produce<o:p></o:p></span></p>
<p class="Code"><b><span style="mso-fareast-language:EN-US">parser :: String -> HsSyn (GhcPass (Parsed WithApiAnnotation)<o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">or<o:p></o:p></span></p>
<p class="Code"><b><span style="mso-fareast-language:EN-US">parser :: </span><span class="CodeChar">String</span></b><b><span style="mso-fareast-language:EN-US"> -> HsSyn (GhcPass (Parsed WithoutApiAnnotation)<o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">We can’t make the result type depend on DynFlags! (Yet)(<o:p></o:p></span></p>
<p class="Code" style="margin-left:0cm"><b><span style="mso-fareast-language:EN-US"> parser :: DynFlags -> String
<o:p></o:p></span></b></p>
<p class="Code"><b><span style="mso-fareast-language:EN-US"> -> HsSyn (GhcPass (Parsed (if …
<o:p></o:p></span></b></p>
<p class="Code"><b><span style="mso-fareast-language:EN-US"> then WithApiAnnotations<o:p></o:p></span></b></p>
<p class="Code"><b><span style="mso-fareast-language:EN-US"> else WihoutsApiAnnotations)<o:p></o:p></span></b></p>
<p class="MsoNormal" style="text-indent:36.0pt"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">So I’m puzzled.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Nomenclature. I’d say “NoApiAnnotations” rather than “WithoutApiAnnotations”.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Also: do we have data to show that it’s not OK to
<b>always</b> keep API annotations. That would be simpler, wouldn’t it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Incidentally the Haddock stuff, decorations of type (Maybe LHsDocString) somehow belong in this world too, don’t they?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">SImon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><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">From:</span></b><span lang="EN-US"> Alan & Kim Zimmerman <alan.zimm@gmail.com>
<br>
<b>Sent:</b> 10 May 2018 22:35<br>
<b>To:</b> Simon Peyton Jones <simonpj@microsoft.com><br>
<b>Cc:</b> ghc-devs <ghc-devs@haskell.org><br>
<b>Subject:</b> Re: TTG hsSyn for Batch and Interactive Parsing<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">I have updated the Wiki with the clearer names, and noted that a single parser definition would still be used, as at present, but would only keep the extra info if it was requested to.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The naming around interactive and batch is to anticipate a further step I would like to take, to make the parser fully incremental, in the sense that it would process as input the prior parse tree and a list of changes to the source, and
then generate a fresh parse tree, with the changed nodes marked. This mode would be tightly coupled to an external too like haskell-ide-engine, to manage the bookkeeping around this.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">My thinking for this is to use the approach presented in the paper "Efficient and Flexible Incremental Parsing" by Wagner and Graham[1].<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">The plan is to modify `happy`, so that we can reuse the existing GHC Parser.y with minor modifications. This is the same approach as used in the library tree-sitter[2], which is a very active project on github.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">WIP is at [3], but it is very early stage.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Regards<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> Alan<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
[1] <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpdfs.semanticscholar.org%2F4d22%2Ffab95c78b3c23fa9dff88fb82976edc213c2.pdf&data=02%7C01%7Csimonpj%40microsoft.com%7C186cfaf7a10a4663ce2f08d5b6bdf0f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636615849263176553&sdata=itxDiaFAuZY4MH1oZDKOudKLNcsqrm7cywA9vt4Y1DI%3D&reserved=0" target="_blank">
https://pdfs.semanticscholar.org/4d22/fab95c78b3c23fa9dff88fb82976edc213c2.pdf</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[2] <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftree-sitter%2Ftree-sitter&data=02%7C01%7Csimonpj%40microsoft.com%7C186cfaf7a10a4663ce2f08d5b6bdf0f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636615849263176553&sdata=HmYE2FMO97ouuAR1vQHPfaEooI1oxtcU4aNWNg3E9T8%3D&reserved=0" target="_blank">
https://github.com/tree-sitter/tree-sitter</a><o:p></o:p></p>
<div>
<p class="MsoNormal">[3] <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Falanz%2Fhappy%2Ftree%2Fincremental&data=02%7C01%7Csimonpj%40microsoft.com%7C186cfaf7a10a4663ce2f08d5b6bdf0f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636615849263332819&sdata=3RcrS%2FMH53aENrS%2FFmdKt%2Fc9JUjIeEq6h5xugF7HmhU%3D&reserved=0" target="_blank">
https://github.com/alanz/happy/tree/incremental</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>