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 <alan.z...@gmail.com>
Sent: 10 May 2018 22:35
To: Simon Peyton Jones <simo...@microsoft.com>
Cc: ghc-devs <ghc-devs@haskell.org>
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.pdf<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-sitter<https://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/incremental<https://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>
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
