<div dir="ltr"><div><div><div><div>Having written the MonadicBang plugin somewhat recently, where I don't care about the exact-print annotations, I do have some snippets in my code that look like this:<br><br>    AsPat xa name tok pat -> do<br>      tellName name<br>      AsPat xa name tok <$> traverse (liftMaybeT . evacPats) pat<br><br></div>where the `tok` variable only exists to pass along the exact-print annotations unchanged. So in that context, I would have a slight preference for the exact-print annotations being hidden away in the extension points.<br></div>However, I think this also illustrates that the cost to clients is quite manageable. Adding this one variable doesn't make the code unreadable - of course, that's assuming exact-print annotations remain special and not just the first in a long list of properties to eventually be added to each node.<br><br></div>Of course, the cost *is* multiplied by the number of pattern matches on AST nodes you have, which could be a lot given the amount of constructors the types have. In my case, it was very few, because I was able to handle the vast majority of constructors generically via the Data.Data instance.<br><br></div>Jakob<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 13, 2023 at 1:23 PM Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com">simon.peytonjones@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Dear GHC developers</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Could you please look at <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/23447" target="_blank">#23447 Where should "tokens" live</a>?</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">In brief, the question is whether we want to have:</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px"><span style="font-family:monospace">data HsExpr p = ....</span></div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px"><span style="font-family:monospace">   | HsLet (XLet p) (HsLocalBinds p) (LHsExpr p)</span></div><div class="gmail_default" style="font-family:tahoma,sans-serif"></div><div class="gmail_default" style="font-family:tahoma,sans-serif">or</div><div class="gmail_default" style="font-family:tahoma,sans-serif"></div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px"><span style="font-family:monospace">data HsExpr p = ....</span></div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px"><span style="font-family:monospace">   | HsLet (XLet p) (HsToken "let" p) </span></div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px"><span style="font-family:monospace">           (HsLocalBinds p) (HsToken "in" p) (LHsExpr p)</span></div>

</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">In the former, if a client wants HsTokes to track the precise source locations of the "let" and "in" keywords, they'd have to put it in the TTG extension field; in the latter, this information is in <i>every</i> syntax tree.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">At the moment we have some of each, which is not satisfactory. We need to decide a policy and stick to it.  If you use HsSyn, HsExpr, HsPat etc, in any way, you should have an opinion.  Please do express it. At the moment we have only a few voices so we risk deciding without enough evidence and use-cases.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Comments with specific use-cases and examples would be particularly helpful.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Thanks!</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div></div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>