<div dir="ltr"><div><div><div><div>Well, in GHC as it stands now (from 8.2.1), the original formulation is correct.<br><br></div>The current pretty printer does not reproduce layout, but reparsing a pretty printed ParsedSource will faithfully reproduce the original ParsedSource (except for the Locations).<br><br></div>This is useful for constructing hsSyn fragments programmatically and generating usable source from them.<br><br></div>I am hoping (intending) that a future version will allow the other formulation too.<br><br></div>Alan <br></div><div class="gmail_extra"><br><div class="gmail_quote">On 28 July 2017 at 19:38, Shayan Najd <span dir="ltr"><<a href="mailto:sh.najd@gmail.com" target="_blank">sh.najd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><font face="arial, helvetica, sans-serif">by</font><div><span class=""><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> (parser . prettyPrint . parser) = id </blockquote><div><br></div></span><div><font face="arial, helvetica, sans-serif">I meant </font></div><div><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif"><br></span></div><div><span style="font-size:12.8px;font-family:arial,helvetica,sans-serif"> </span><font style="font-size:12.8px" face="monospace, monospace">(prettyPrint . parser . prettyPrint) = id </font><br></div></div><div><font style="font-size:12.8px" face="monospace, monospace"><br></font></div><div><font style="font-size:12.8px" face="arial, helvetica, sans-serif">for a valid input. </font></div><div><font style="font-size:12.8px" face="monospace, monospace"><br></font></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 28, 2017 at 4:32 PM, Shayan Najd <span dir="ltr"><<a href="mailto:sh.najd@gmail.com" target="_blank">sh.najd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On the contrary, inside GHC I /do/ want to print them. Otherwise how can I see what the renamer has done?</blockquote><div><br></div></span><div><font face="arial, helvetica, sans-serif">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.</font></div><div><font face="arial, helvetica, sans-serif">(There are also "exact printers" (as in HSE) that are even closer to syntax in some sense.) </font></div><div><font face="arial, helvetica, sans-serif">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 `<span style="font-size:12px">OpApp` printed via `Outputable` that includes the fixity annotation. </span></font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">If I recall correctly, we have </font><span style="font-family:arial,helvetica,sans-serif">briefly </span><span style="font-family:arial,helvetica,sans-serif">studied these in the past summer, we came up with some roundtrip correctness criteria, like the following (bar error handling; assume valid input):</span></div><div><span style="font-family:arial,helvetica,sans-serif"><br></span></div><div><span style="font-family:arial,helvetica,sans-serif"> </span><font face="monospace, monospace">(parser . prettyPrint . parser) = id </font></div><div><font face="arial, helvetica, sans-serif"> </font></div><div><font face="arial, helvetica, sans-serif">[paging in Jacques]</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">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.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">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 </font><span style="font-family:arial,helvetica,sans-serif">(pretty?showable?)</span><span style="font-family:arial,helvetica,sans-serif"> a<wbr>nnotations.</span></div><div><span style="font-family:arial,helvetica,sans-serif">In particular, we may want to take advantage of extensibility of data types for this.</span></div><div><span style="font-family:arial,helvetica,sans-serif">Am I far off?</span><span style="font-family:arial,helvetica,sans-serif"> </span></div><div><span style="font-family:arial,helvetica,sans-serif"><br></span></div><div><font face="arial, helvetica, sans-serif">Note: with proper design, an extensible debug-printer can still subsume corresponding pretty-printers.</font></div><div><span style="font-family:arial,helvetica,sans-serif"><br></span></div></div><div class="m_-482551673552819728HOEnZb"><div class="m_-482551673552819728h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 28, 2017 at 2:36 PM, Simon Peyton Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-GB">
<div class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125WordSection1"><span>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:36.0pt">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">I have been under the impression that we don't even want to print those.</span><u></u><u></u></p>
</span><p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">On the contrary, inside GHC I /do/ want to print them. Otherwise how can I see what the renamer has done?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Simon<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"><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"> Shayan Najd [mailto:<a href="mailto:sh.najd@gmail.com" target="_blank">sh.najd@gmail.com</a>]
<br>
<b>Sent:</b> 28 July 2017 12:20<br>
<b>To:</b> Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><br>
<b>Cc:</b> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>; Alan & Kim Zimmerman <<a href="mailto:alan.zimm@gmail.com" target="_blank">alan.zimm@gmail.com</a>><br>
<b>Subject:</b> Re: Operating on HsSyn<u></u><u></u></span></p>
</div>
</div><div><div class="m_-482551673552819728m_3487327383462145931h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-family:"Arial",sans-serif">Before all this, we may need to discuss a bit about the intended semantics of<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-family:"Arial",sans-serif">`Outputable`: does it need to print `PostRn`, or `PostTc` fields; or `Out`<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-family:"Arial",sans-serif">suffixed constructors? If not, then we only need to write a set of instances<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-family:"Arial",sans-serif">for the base growable AST, once and for all. Such instances will be polymorphic<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-family:"Arial",sans-serif">on the extension descriptor `p`, and do not need to mention the constraints like<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-family:"Arial",sans-serif">`(PostRn p (IdP p)`, since these are just extensions and not part of the base<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-family:"Arial",sans-serif">growable AST. Or, am I missing something about the intended semantics of<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-family:"Arial",sans-serif">`Outputable`?<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif"><u></u> <u></u></span></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-family:"Arial",sans-serif">You write</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
So today we never print these annotations, to avoid bloating the instance contexts, which can be painful. <u></u><u></u></p>
</blockquote>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">I have been under the impression that we don't even want to print those.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">Of course, there are scenarios (like `Show` instances) where we do want to write </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">compositional / generic functions that take into account the extensions.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">Here is my abstract overview of the scenario, that may help the discussion.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">Consider data types `A`, `B`, and `C` (say, one AST datatype per compiler phase) that</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif"> are defined as extensions to a base datatype `T`:</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Courier New"">> A = T XA</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Courier New"">> B = T XB</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Courier New"">> C = T XC</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">where `</span><span style="font-size:9.0pt;font-family:"Courier New"">X*</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">`s are extension descriptors.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">Now, say we want to a define functions `</span><span style="font-size:9.0pt;font-family:"Courier New"">f_A</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">`, `</span><span style="font-size:9.0pt;font-family:"Courier New"">f_B</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">`,
and `</span><span style="font-size:9.0pt;font-family:"Courier New"">f_C</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">` over `</span><span style="font-size:9.0pt;font-family:"Courier New"">A</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">`,
`</span><span style="font-size:9.0pt;font-family:"Courier New"">B</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">`, and `</span><span style="font-size:9.0pt;font-family:"Courier New"">C</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">`.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">We have two main alternatives: </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">(a) either we write these (manually or using the deriving mechanism) separately</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">(b) or we write a generic / parametric function `</span><span style="font-size:9.0pt;font-family:"Courier New"">g</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">` over `</span><span style="font-size:9.0pt;font-family:"Courier New"">T</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">`,
and reuse that to define `</span><span style="font-size:9.0pt;font-family:"Courier New"">f_*</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">`s</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">Of course, (b) is preferable in theory , but not always possible or preferable in practice.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">In which case, we can always resort to (a).</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">The more varying are the definitions of `f_A`, `f_B`, and `f_C` the more parametric should </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">`g` get, as this is the case for any generic function.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">With a correct design, I believe, these are all independent of Trees that Grow story itself: </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">we are now not only trying to reuse data types, and functions agnostic towards extensions</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">(pretty printers in my view of their semantics), but also reuse functions with parametric / </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-size:9.0pt;font-family:"Arial",sans-serif">varying behaviour with respect to extensions. </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
/Shayan<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On Fri, Jul 28, 2017 at 10:18 AM, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Devs,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Shayan is working away on “Trees that grow”… do keep it on your radar:</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:12.0pt;margin-left:36.0pt">
<b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif" lang="EN-US">To:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif" lang="EN-US"> ghc-devs
<br>
<b>Sent:</b> 25 May 2017 23:49</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36.0pt">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Do take a look at this:</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36.0pt">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755msolistparagraph" style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:Symbol">·</span><span style="font-size:7.0pt">
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">We propose to re-engineer HsSyn itself. This will touch a
<b>lot</b> of code.</span><u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755msolistparagraph" style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:Symbol">·</span><span style="font-size:7.0pt">
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">But it’s very neat, and will bring big long-term advantages</span><u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755msolistparagraph" style="margin-left:72.0pt"><span style="font-size:11.0pt;font-family:Symbol">·</span><span style="font-size:7.0pt">
</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">And we can do it a bit at a time</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36.0pt">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:36.0pt">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif">The wiki page </span>
<a href="https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow" target="_blank">https://ghc.haskell.org/trac/g<wbr>hc/wiki/ImplementingTreesThatG<wbr>row</a>
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif">has the details.</span>
<a name="m_-482551673552819728_m_3487327383462145931_m_-5964656783010018125_m_-525007982728833755__MailEndCompose">I</a><span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">t’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</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Meanwhile I have a question. When pretty-printing HsSyn we often have a situation like this:</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> data Pass = Parsed | Renamed | Typechecked<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> <u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> data HsExpr (p :: Pass) = HsVar (IdP p) | ....<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> <u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> type famliy IdP p where<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> IdP Parsed = RdrName<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> IdP Renamed = Name<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> IdP Typechecked = Id<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> <u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> instance (Outputable (IdP p)) => Outputable (HsExpr p) where<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> ppr (HsVar v) = ppr v<u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">The (ppr v) requires (Outputable (IdP p)), hence the context.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Moreover, and more seriously, there are things we just can't pretty-print</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">right now. For example, HsExpr has this data constructor:</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> data HsExpr p = ...<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> | OpApp (LHsExpr p)<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> (LHsExpr p)<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> (PostRn p Fixity)<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> (LHsExpr p)<u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">To pretty-print the third argument, we'd need to add</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> instance (Outputable (IdP p),<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> Outputable (PostRn p Fixity)) -- New<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> => Outputable (HsExpr p) where<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> ppr (HsVar v) = ppr v<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> <u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">and that gets onerous.
<i>So today we never print these annotations</i>, to avoid bloating the instance contexts, which can be painful. It bit me yesterday.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">We have bitten that bullet for the Data class: look at HsExtension.DataId, which abbreviates the long list of dictionaries:</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> type DataId p =<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> ( Data p<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> , ForallX Data p<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> , Data (NameOrRdrName (IdP p))<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> , Data (IdP p)<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> , Data (PostRn p (IdP p))<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> , Data (PostRn p (Located Name))<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> , Data (PostRn p Bool)<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> , Data (PostRn p Fixity)<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> ,..and nine more... )<u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Let me note in passing that [<a href="https://ghc.haskell.org/trac/ghc/wiki/QuantifiedContexts" target="_blank">wiki:QuantifiedContexts</a>]
would make this somewhat shorter</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> type DataId p =<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> ( Data p<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> , ForallX Data p<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> , Data (NameOrRdrName (IdP p))<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> , Data (IdP p)<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> , forall t. Data t => Data (PostRn p t))<u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">But we still need one item in this list for each type function,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">and I am worried about how this scales to the</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">[<a href="https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow" target="_blank">wiki:ImplementingTreesThatGro<wbr>w</a>] story,
when we have a type</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">function for each data constructor -- and there are a
<b>lot</b> of data</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">constructors.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-family:"Calibri",sans-serif">So I have four questions</span></b><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<ol start="1" type="1">
<li class="MsoNormal" style="margin-left:0cm">
<span style="font-family:"Calibri",sans-serif">I think we should probably use a superclass instead of a type synonym</span><u></u><u></u></li></ol>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code">class (Data p, ForallX Data p, ....) => DataId p where {}<u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755msolistparagraph"><span style="font-family:"Calibri",sans-serif">Why? Only one argument to pass, and to pass on to successive calls. I see no downside.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<ol start="2" type="1">
<li class="MsoNormal" style="margin-bottom:12.0pt;margin-left:0cm">
<span style="font-family:"Calibri",sans-serif">Shall we treat Outputable like Data? (I.e. make an abbreviation for a long list of Outputable instances and use it everywhere)</span><u></u><u></u></li><li class="MsoNormal" style="margin-left:0cm">
<span style="font-family:"Calibri",sans-serif">I thought of another way to do it (pass a token); see below</span><u></u><u></u></li></ol>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<ol start="4" type="1">
<li class="MsoNormal" style="margin-left:0cm">
<span style="font-family:"Calibri",sans-serif">Are there any other ways?</span><u></u><u></u></li></ol>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><b><span style="font-family:"Calibri",sans-serif">Token passing idea.</span></b><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Perhaps instead of passing lots of functions, we pass a singleton token</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">that encodes the pass, like this:</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> instance (PassC p) => Outputable (HsExpr p) where<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> ppr (HsVar v) = case getPass :: IsPass p of<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> IsParsed -> ppr v<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> IsRenamed<wbr> -> ppr v<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> IsTypechecked -> ppr v<u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">The three ppr's are at different types, of course; that's the point.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">The infrastructure is something like</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> class PassC p where<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> getPass :: IsPass p<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> <u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> data IsPass p where<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> IsParsed :: IsPass Parsed<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> IsRenamed :: IsParsed Renamed<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> IsTypechecked :: IsParsed Typechecked<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> <u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> instance PassC Parsed where getPass = IsParsed<u></u><u></u></p>
<p class="m_-482551673552819728m_3487327383462145931m_-5964656783010018125m-525007982728833755code"> ...etc...<u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">Now we could sweep away all those OutputableX classes,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">replacing them with dynamic tests on the singletons IsParsed etc.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">This would have advantages:</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">- Probably faster: there's a dynamic test, but many fewer dictionary</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> arguments and higher-order function dispatch</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">- Only one dictionary to pass; programming is easier.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">The big downside is that it's not extensible: it works only because</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">we know the three cases. But the "Trees that Grow" story really doesn't</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif">scale well to pretty-printing: so maybe we should just give up on that?</span><u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>
</div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>