Exact-print info in the the HsSyn syntax tree

[Jakob Brünker]

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:

    AsPat xa name tok pat -> do
      tellName name
      AsPat xa name tok <$> traverse (liftMaybeT . evacPats) pat

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.
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.

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.

Jakob

On Thu, Jul 13, 2023 at 1:23 PM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear GHC developers
>
> Could you please look at #23447 Where should "tokens" live
> <https://gitlab.haskell.org/ghc/ghc/-/issues/23447>?
>
> In brief, the question is whether we want to have:
>
> data HsExpr p = ....
>    | HsLet (XLet p) (HsLocalBinds p) (LHsExpr p)
> or
>
> data HsExpr p = ....
>    | HsLet (XLet p) (HsToken "let" p)
>            (HsLocalBinds p) (HsToken "in" p) (LHsExpr p)
>
>
> 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 *every* syntax
> tree.
>
> 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.
>
> Comments with specific use-cases and examples would be particularly
> helpful.
>
> Thanks!
>
> Simon
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230713/8d643627/attachment.html>