Exact-print info in the the HsSyn syntax tree

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

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@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Thanks Jakob -- but would it be possible to comment *on the ticket*, not
here? (I should have said that more clearly.)
Simon
On Thu, 13 Jul 2023 at 13:31, 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@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Sure, done Jakob On Thu, Jul 13, 2023 at 3:32 PM Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
Thanks Jakob -- but would it be possible to comment *on the ticket*, not here? (I should have said that more clearly.)
Simon
On Thu, 13 Jul 2023 at 13:31, Jakob Brünker
wrote: 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@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
participants (2)
-
Jakob Brünker
-
Simon Peyton Jones