TTG hsSyn for Batch and Interactive Parsing

[Simon Peyton Jones]

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.zimm at gmail.com>
Sent: 10 May 2018 22:35
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-devs <ghc-devs at 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>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20180518/328505d2/attachment.html>