RE: TTG hsSyn for Batch and Interactive Parsing

[Simon Peyton Jones via ghc-devs]

Thanks.  But I still don’t see the connection with “interactive”.  Why should 
maintaining API annotations have anything to do with interactivity?


Maybe

  data Process = WithApiAnnotations | WithoutApiAnnotations



I understand you want two different variants of the syntax tree, but I don’t 
understand what functions might produce or consume them.



In particular does the parser produce (HsSyn (GhcPs WithApiAnnotations)) or 
without?



Simon






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

I have updated the Wiki.

On 9 May 2018 at 10:15, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
Thanks.

I am absolutely behind this objective:
I propose to move the API Annotations to where they belong, inside the AST.
Indeed I thought that was always part of the TTG plan.

But I don’t understand what this has to do with interactive vs batch parsing.  
Why don’t you unconditionally retain API-annotation info?  How would GhcPs be 
used differently to GhcPsI?

You might want to answer by clarifying on the wiki page, so that it is a 
persistent record of the design debugged in dialogue by email.

Simon

From: Alan & Kim Zimmerman mailto:alan.z...@gmail.com>>
Sent: 08 May 2018 21:02
To: Simon Peyton Jones mailto:simo...@microsoft.com>>
Cc: ghc-devs mailto:ghc-devs@haskell.org>>
Subject: Re: TTG hsSyn for Batch and Interactive Parsing

I have started a wiki page at 
https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/IdeSupport

On 8 May 2018 at 10:54, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
At first blush, “running the parser in two modes” and “changing the Pass” type 
don’t match up in my mind.  One seems quite local (how to run the parser).  The 
other seems more pervasive.

Can you say more about your proposed design, perhaps even on a wiki page?

Simon

From: ghc-devs 
mailto:ghc-devs-boun...@haskell.org>> On Behalf 
Of Alan & Kim Zimmerman
Sent: 07 May 2018 16:17
To: ghc-devs mailto:ghc-devs@haskell.org>>
Subject: TTG hsSyn for Batch and Interactive Parsing

I want to be able to run the GHC parser in one of two modes, batch which 
functions as now, and interactive which will (eventually) be incremental.
In addition, the hsSyn AST for each will have different TTG[1] annotations, so 
that it can better support IDE usage.
I think this can be done by changing the types in HsExtension to introduce a 
'Process'  type as follows

data Pass = Parsed Process | Renamed | Typechecked
 deriving (Data)

data Process = Batch | Interactive
  deriving (Show, Data)
We then rename the pass synonyms so that batch is the default

type GhcPs   = GhcPass ('Parsed 'Batch)
type GhcPsI  = GhcPass ('Parsed 'Interactive)
I have attached a simple proof of concept file, which emulates parsing and 
renaming.
Is this an appropriate approach to take?
Alan

[1] Trees That Grow 
https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow


___
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]

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/fab95c78b3c23fa9dff88fb82976ed
c213c2.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