RE: TTG hsSyn for Batch and Interactive Parsing

[Simon Peyton Jones via ghc-devs]

If we are always going to generate a parse tree with annotations from the 
parser, let’s not generate two!

I’m fine with always generating the annotations, but we just need to check that 
it doesn’t have insupportable costs.

Simon

From: Alan & Kim Zimmerman 
Sent: 18 May 2018 15:31
To: Simon Peyton Jones 
Cc: ghc-devs 
Subject: Re: TTG hsSyn for Batch and Interactive Parsing



On 18 May 2018 at 16:13, Simon Peyton Jones 
> wrote:

We can’t make the result type depend on DynFlags! (Yet)(

parser :: DynFlags -> String

  -> HsSyn (GhcPass (Parsed (if …

then WithApiAnnotations

else WihoutsApiAnnotations)

We could conceptually have

  parser :: DynFlags -> String -> Either (HsSyn (Parsed WithApiAnnotations)) 
(HsSyn (Parsed NoApiAnnotations))

The main point is that the next phase can make use of either of the variants.

And it may be simplest to just always use the annotations, the ParsedSource is 
normally discarded after renaming anyway.

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: TTG hsSyn for Batch and Interactive Parsing

[Alan & Kim Zimmerman]

On 18 May 2018 at 16:13, Simon Peyton Jones  wrote:

>
>
> We can’t make the result type depend on DynFlags! (Yet)(
>
> *parser :: DynFlags -> String *
>
> *  -> HsSyn (GhcPass (Parsed (if … *
>
> *then WithApiAnnotations*
>
> *else WihoutsApiAnnotations)*
>
>
We could conceptually have

  parser :: DynFlags -> String -> Either (HsSyn (Parsed
WithApiAnnotations)) (HsSyn (Parsed NoApiAnnotations))

The main point is that the next phase can make use of either of the
variants.

And it may be simplest to just always use the annotations, the ParsedSource
is normally discarded after renaming anyway.

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: TTG hsSyn for Batch and Interactive Parsing

[Simon Peyton Jones via ghc-devs]

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.pdf
[2] 
https://github.com/tree-sitter/tree-sitter
[3] 
https://github.com/alanz/happy/tree/incremental


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs