Exact-print info in the the HsSyn syntax tree

Jakob Brünker jakob.bruenker at gmail.com
Thu Jul 13 13:46:43 UTC 2023


Sure, done

Jakob


On Thu, Jul 13, 2023 at 3:32 PM Simon Peyton Jones <
simon.peytonjones at 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 <jakob.bruenker at gmail.com>
> 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 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/2fca2ce9/attachment.html>


More information about the ghc-devs mailing list