Expose Other Parsers for GHC API
marlowsd at gmail.com
Wed Jun 4 07:33:25 UTC 2014
I'd say (1) and (3) are good, but we typically don't do (2) in the compiler.
On the other hand, if you want to export a clean and self-contained API
for the parser from the GHC module, I think that would be great. There
is GHC.parser for parsing a whole module, but I'm sure a more complete
API would be useful.
On 31/05/2014 04:09, Andrew Gibiansky wrote:
> I would like to be able to use the GHC API for parsing. Right now this
> is in the Parser and Lexer modules:
> GHC currently exposes only a few parsers here. I'd like to make a few
> 1. Expose a few more parsers than currently are exposed in the Parser
> module. In particular, I'd like import statements, type signatures,
> declarations, and expressions, at least, in addition to what's already
> 2. Re-export some things from Lexer from Parser, since they're reused.
> This would include unP, PState, and the 2-3 other core things you
> /have/ to use in order to use the GHC Parser.
> 3. Add some Haddock documentation to the top of the Parser module
> describing how to use it, since the types themselves are pretty opaque here.
> I think (1) and (3) are definitely a good idea, not so sure about (2)
> though IMHO it would be convenient for using the Parser.
> Would this make for an acceptable patch? Thoughts?
> -- Andrew Gibiansky
> ghc-devs mailing list
> ghc-devs at haskell.org
More information about the ghc-devs