<div dir="ltr"><div><div><div>The problem is round-tripping cases like this, which are valid<br><br> ( /// ) :: Int -> Int -> Int<br> a /// b = 3<br><br> baz :: Int -> Int -> Int<br> a ` baz ` b = 4<br><br></div>There can be arbitrary spaces between the surrounding parens and the operator name, and between the backquotes and the identifier in the infix version.<br><br></div>In each case we simply get a RdrName, which in turn is wrapped in HsVar or whatever.<br><br></div>The D538 productions are of the form<br><br><div> var :: { Located RdrName }<br> : varid { $1 }<br> | '(' varsym ')' {% ams (sLL $1 $> (unLoc $2))<br> [mo $1,mj AnnVal $2,mc $3] }<br><br></div><div>and<br> <br><div> tyvarop :: { Located RdrName }<br> tyvarop : '`' tyvarid '`' {% ams (sLL $1 $> (unLoc $2))<br> [mj AnnBackquote $1,mj AnnVal $2<br> ,mj AnnBackquote $3] }<br><br></div><div>So the location tracks the entire span, but we need annotations for the three individual parts.<br><br></div><div>Note: I did not check how far close to the limit the performance was prior to this change, it may have been the last 1% to take it over.<br><br></div><div>Alan<br><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 12, 2014 at 11:03 PM, Simon Peyton Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="#0563C1" vlink="#954F72" lang="EN-GB">
<div><span class="">
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
I am now adding an `AnnVal` to every RdrName, to be able to separate it out from any decoration, such as surrounding backticks or parens.<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
</span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">That seems like overkill to me. (a `op` b) is an HsOpApp, and must of course have backticks unless op is an operator like (a + b),
in which case it doesn’t.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The corner case is something like ((`op`) a b), which will parse as (HsApp (HsApp (HsVar op) (HsVar a)) (HsVar b)). But it would
be silly for us to get bent out of shape because of such a vanishingly rare corner case. Instead, if you really want to reflect it faithfully, add a new constructor for “parens around backticks”).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Let’s only take these overheads when there is real reason to do so.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Simon<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></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 style="font-size:11.0pt;font-family:"Calibri","sans-serif"" lang="EN-US">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"" lang="EN-US"> ghc-devs [mailto:<a href="mailto:ghc-devs-bounces@haskell.org" target="_blank">ghc-devs-bounces@haskell.org</a>]
<b>On Behalf Of </b>Alan & Kim Zimmerman<br>
<b>Sent:</b> 12 December 2014 14:22<br>
<b>To:</b> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<b>Subject:</b> D538 and compiler performance spec<u></u><u></u></span></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
For API annotations I am working in the details of RdrNames, which come in a bewildering variety of syntactic forms.<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
My latest change causes perf/compiler to fail, with<br>
<br>
bytes allocated value is too high:<br>
Expected parsing001(normal) bytes allocated: 587079016 +/-5%<br>
Lower bound parsing001(normal) bytes allocated: 557725065 <br>
Upper bound parsing001(normal) bytes allocated: 616432967 <br>
Actual parsing001(normal) bytes allocated: 704940512 <br>
Deviation parsing001(normal) bytes allocated: 20.1 %<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
I am now adding an `AnnVal` to every RdrName, to be able to separate it out from any decoration, such as surrounding backticks or parens.<u></u><u></u></p>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
Is this a problem? The alternative would be to add a SourceText field to RdrName.<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Alan<u></u><u></u></p>
</div>
</div></div></div>
</div>
</div>
</blockquote></div></div>