Expose Other Parsers for GHC API

[Simon Marlow]

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.

Cheers,
Simon

On 31/05/2014 04:09, Andrew Gibiansky wrote:
> Hello,
>
> I would like to be able to use the GHC API for parsing. Right now this
> is in the Parser and Lexer modules:
>
> Parser:
> http://www.haskell.org/ghc/docs/7.8.2/html/libraries/ghc-7.8.2/Parser.html
> Lexer:
> http://www.haskell.org/ghc/docs/7.8.2/html/libraries/ghc-7.8.2/Lexer.html
>
> GHC currently exposes only a few parsers here. I'd like to make a few
> modifications:
>
> 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
> there.
>
> 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
> http://www.haskell.org/mailman/listinfo/ghc-devs
>