GHC 7.10 GHC-API Changes and proposed changes.
There are a number of changes in GHC 7.10 that will make it easier for tool writers to use the GHC API. These include 1. More parser entrypoints, to explicitly parse fragments [Andrew Gibiansky] The following parsers are now provided parseModule, parseImport, parseStatement, parseDeclaration, parseExpression, parseTypeSignature, parseFullStmt, parseStmt, parseIdentifier, parseType, parseHeader 2. No more landmines in the AST [Alan Zimmerman] In the past it was difficult to work with the GHC AST as any generic traversals had to carefully tiptoe around an assortment of panic and undefined expressions. These have now been removed, allowing standard traversal libraries to be used. There is a third change currently being discussed, and I would like feedback on it's desirability. 3. Introduce an annotation structure to the ParsedSource to record the location of uncaptured keywords. At the moment the location of let / in / if / then / else / do etc is not captured in the AST. This makes it difficult to parse some source, transform the AST, and then output it again preserving the original layout. The current proposal, which can be seen at [1] and a proof of concept implementation at [2] returns a structure keyed to each AST element containing simply the specific SrcSpan's not already captured in the AST. This is the analogue of the Language.Haskell.Exts.Annotated.Syntax from haskell-src-exts, except a custom SrcSpanInfo structure is provided for each AST element constructor, and it is not embedded within the AST. [1] https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations [2] https://phabricator.haskell.org/D297 So, apart from HaRe, are there any other users who would be interested in using this? Regards Alan
I am very much in favor of this. IHaskell does not need this (...yet?), but
I have played around with writing other source-transforming tools, and
having to rely on HSE for parsing and reformatting and relying on GHC API
for interpreting and typechecking is a little bit of a pain.
Besides HaRe, I'd love a tool equivalent to `go fmt` which normalized stuff
like indentation, alignment, and usage of `where` vs `let`, and
automatically applied various changes (of course details are complicated);
that sort of thing requires good support for the sort of work you're doing
in HaRe.
Also, I *very strongly* support any work that goes into improving the GHC
API. Working with it was a nightmare at the beginning due to lack of
documentation, lack of exposed symbols, and other issues.
(That said, I'm also fine with using the dynamic typing approach that was
mentioned elsewhere to avoid an extra type parameter. Have the annotation
be a Dynamic or something. The motivation for this would be to make the
change less intrusive.)
-- Andrew
On Wed, Oct 1, 2014 at 11:34 AM, Alan & Kim Zimmerman
There are a number of changes in GHC 7.10 that will make it easier for tool writers to use the GHC API.
These include
1. More parser entrypoints, to explicitly parse fragments [Andrew Gibiansky]
The following parsers are now provided
parseModule, parseImport, parseStatement, parseDeclaration, parseExpression, parseTypeSignature, parseFullStmt, parseStmt, parseIdentifier, parseType, parseHeader
2. No more landmines in the AST [Alan Zimmerman]
In the past it was difficult to work with the GHC AST as any generic traversals had to carefully tiptoe around an assortment of panic and undefined expressions. These have now been removed, allowing standard traversal libraries to be used.
There is a third change currently being discussed, and I would like feedback on it's desirability.
3. Introduce an annotation structure to the ParsedSource to record the location of uncaptured keywords.
At the moment the location of let / in / if / then / else / do etc is not captured in the AST. This makes it difficult to parse some source, transform the AST, and then output it again preserving the original layout.
The current proposal, which can be seen at [1] and a proof of concept implementation at [2] returns a structure keyed to each AST element containing simply the specific SrcSpan's not already captured in the AST.
This is the analogue of the Language.Haskell.Exts.Annotated.Syntax from haskell-src-exts, except a custom SrcSpanInfo structure is provided for each AST element constructor, and it is not embedded within the AST.
[1] https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations [2] https://phabricator.haskell.org/D297
So, apart from HaRe, are there any other users who would be interested in using this?
Regards Alan
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On 10/01/2014 07:34 PM, Alan & Kim Zimmerman wrote:
There are a number of changes in GHC 7.10 that will make it easier for tool writers to use the GHC API.
These include
1. More parser entrypoints, to explicitly parse fragments [Andrew Gibiansky]
The following parsers are now provided
parseModule, parseImport, parseStatement, parseDeclaration, parseExpression, parseTypeSignature, parseFullStmt, parseStmt, parseIdentifier, parseType, parseHeader
Awesome.
2. No more landmines in the AST [Alan Zimmerman]
In the past it was difficult to work with the GHC AST as any generic traversals had to carefully tiptoe around an assortment of panic and undefined expressions. These have now been removed, allowing standard traversal libraries to be used.
There is a third change currently being discussed, and I would like feedback on it's desirability.
Also awesome.
3. Introduce an annotation structure to the ParsedSource to record the location of uncaptured keywords.
At the moment the location of let / in / if / then / else / do etc is not captured in the AST. This makes it difficult to parse some source, transform the AST, and then output it again preserving the original layout.
The current proposal, which can be seen at [1] and a proof of concept implementation at [2] returns a structure keyed to each AST element containing simply the specific SrcSpan's not already captured in the AST.
This is the analogue of the Language.Haskell.Exts.Annotated.Syntax from haskell-src-exts, except a custom SrcSpanInfo structure is provided for each AST element constructor, and it is not embedded within the AST.
[1] https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations [2] https://phabricator.haskell.org/D297
So, apart from HaRe, are there any other users who would be interested in using this?
Regards Alan
I imagine that basically *any* tool that ever cares about source locations of things would benefit. Naming existing specifics is difficult because they currently no doubt use some other way of dealing with the problem. I want to say ‘yes, we could use this to implement a bunch of stuff in Yi!’ but at the same time if HaRe can do it then we should simply hook up into that and never care for it ourselves. So while I appreciate SPJ making multiple attempts at reaching out for wider feedback, I think that in actual fact HaRe would be *the* big user here. It is hard to come up and say ‘if GHC gets this then I'll write XYZ’ because it might be the case that ‘if GHC gets this then HaRe will be able to do XYZ which we can use’. I'd also like to say that it seems like it would make lexer-stuff easier but I am unsure whether that is even remotely related: this is for what parser spits out and the lexer would give us that information anyway, right? I think the lexer is currently not exposed either way… In conclusion, I think that if it makes it possible for HaRe to implement better transformations then it's a good change. I can't comment on the implementation impact here, this is merely from ‘do we want this or not’ point of view. -- Mateusz K.
participants (3)
-
Alan & Kim Zimmerman -
Andrew Gibiansky -
Mateusz Kowalczyk