Extracting representation from GHC

[Matthew Pickering]

I have too wanted this in the past and made a post to a similar effect
on the mailing list 6 months ago.

https://mail.haskell.org/pipermail/ghc-devs/2017-July/014427.html

It references this proposal for a similar feature.

https://ghc.haskell.org/trac/ghc/wiki/FrontendPluginsProposal#no1

If you would be glad to implement it then feel free to add me as a reviewer.

Cheers,

Matt

On Fri, Jan 19, 2018 at 9:35 AM, Németh Boldizsár <nboldi at elte.hu> wrote:
> Dear GHC Developers,
>
> I would like to ask your opinion on my ideas to make it easier to use
> development tools with GHC.
>
> In the past when working on a Haskell refactoring tool I relied on using the
> GHC API for parsing and type checking Haskell sources. I extracted the
> representation and performed analysis and transformation on it as it was
> needed. However using the refactorer would be easier if it could work with
> build tools.
>
> To do this, my idea is to instruct GHC with a compilation flag to give out
> its internal representation of the source code. Most build tools let the
> user to configure the GHC flags so the refactoring tool would be usable in
> any build infrastructure. I'm thinking of using the pre-existing plugin
> architecture and adding two new fields to the Plugin datastructure. One
> would be called with the parsed representation (HsParsedModule) when parsing
> succeeds, another with the result of the type checking (TcGblEnv) when type
> checking is finished.
>
> What do you think about this solution?
>
> Boldizsár
>
> (ps: My first idea was using frontend plugins, but I could not access the
> representation from there and --frontend flag changed GHC compilation mode.)
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs