This sounds fine. But I still don’t understand
There would still be a single parser definition in Parser.y, which would make use of functions to add the additional info to the generated source tree, which would be NOPs if the information was not being kept. This is similar to what happens at present with the Api Annotations.
What is the type of the parser? Does it produce
parser :: String -> HsSyn (GhcPass (Parsed WithApiAnnotation)
or
parser :: String -> HsSyn (GhcPass (Parsed WithoutApiAnnotation)
?
We can’t make the result type depend on DynFlags! (Yet)(
parser :: DynFlags -> String
-> HsSyn (GhcPass (Parsed (if …
then WithApiAnnotations
else WihoutsApiAnnotations)
So I’m puzzled.
Nomenclature. I’d say “NoApiAnnotations” rather than “WithoutApiAnnotations”.
Also: do we have data to show that it’s not OK to always keep API annotations. That would be simpler, wouldn’t it.
Incidentally the Haddock stuff, decorations of type (Maybe LHsDocString) somehow belong in this world too, don’t they?
SImon
From: Alan & Kim Zimmerman
Sent: 10 May 2018 22:35
To: Simon Peyton Jones
Cc: ghc-devs
Subject: Re: TTG hsSyn for Batch and Interactive Parsing
I have updated the Wiki with the clearer names, and noted that a single parser definition would still be used, as at present, but would only keep the extra info if it was requested to.
The naming around interactive and batch is to anticipate a further step I would like to take, to make the parser fully incremental, in the sense that it would process as input the prior parse tree and a list of changes to the source, and then generate a fresh parse tree, with the changed nodes marked. This mode would be tightly coupled to an external too like haskell-ide-engine, to manage the bookkeeping around this.
My thinking for this is to use the approach presented in the paper "Efficient and Flexible Incremental Parsing" by Wagner and Graham[1].
The plan is to modify `happy`, so that we can reuse the existing GHC Parser.y with minor modifications. This is the same approach as used in the library tree-sitter[2], which is a very active project on github.
WIP is at [3], but it is very early stage.
Regards
Alan
[1] https://pdfs.semanticscholar.org/4d22/fab95c78b3c23fa9dff88fb82976edc213c2.p...https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpdfs.semanticscholar.org%2F4d22%2Ffab95c78b3c23fa9dff88fb82976edc213c2.pdf&data=02%7C01%7Csimonpj%40microsoft.com%7C186cfaf7a10a4663ce2f08d5b6bdf0f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636615849263176553&sdata=itxDiaFAuZY4MH1oZDKOudKLNcsqrm7cywA9vt4Y1DI%3D&reserved=0
[2] https://github.com/tree-sitter/tree-sitterhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftree-sitter%2Ftree-sitter&data=02%7C01%7Csimonpj%40microsoft.com%7C186cfaf7a10a4663ce2f08d5b6bdf0f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636615849263176553&sdata=HmYE2FMO97ouuAR1vQHPfaEooI1oxtcU4aNWNg3E9T8%3D&reserved=0
[3] https://github.com/alanz/happy/tree/incrementalhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Falanz%2Fhappy%2Ftree%2Fincremental&data=02%7C01%7Csimonpj%40microsoft.com%7C186cfaf7a10a4663ce2f08d5b6bdf0f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636615849263332819&sdata=3RcrS%2FMH53aENrS%2FFmdKt%2Fc9JUjIeEq6h5xugF7HmhU%3D&reserved=0
