Extracting representation from GHC

[Robin Palotai]

See some additions inline.
BR
Robin

2018-01-19 18:27 GMT+01:00 Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org>:

> |  To do this, my idea is to instruct GHC with a compilation flag to give
> |  out its internal representation of the source code.
>
> Why can't you just use GHC as a library, and ask it to parse and typecheck
> the module and then look at what it gives you.
>
> Last time I checked (GHC 8.2, for haskell-indexer), using the library is
not equivalent to using GHC's Main. GHC's Main does tremendous amount of
magic with flag parsing and state setup, and doesn't expose all the
functionality for libraries to do the same.

AFAIR we saw two possible ways to get the AST out from a complicated setup
(FFI, objects, packages, ...):
1) invoke GHC and use Frontend plugin (but Frontend plugin is/was more
limited at the time - the gist in the below trac entry mentions that even
the Frontend plugin didn't do everything Main does).
2) Refactor GHC Main and expose all the functionality to GHC API.

I filed https://ghc.haskell.org/trac/ghc/ticket/14018 a while ago that's
slightly related.

By the way, you can click around
http://stuff.codereview.me/ghc/#ghc/ghc/Main.hs?corpus=ghc-8.2.1-rc2&signature
in the 'main' function to see all the magic.

Others are more used to the GHC API than me, though.
>
> S
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> |  Németh Boldizsár
> |  Sent: 19 January 2018 09:35
> |  To: ghc-devs at haskell.org
> |  Subject: Extracting representation from GHC
> |
> |  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
> |  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
> |  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  devs&data=02%7C01%7Csimonpj%40microsoft.com%7C9d78fd2d16994ade4d9008d5
> |  5f2007c3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365195135360471
> |  87&sdata=voUEz%2BKTp0p3CtwP1Hx6xA3cXN0qoYONLPd9T7xRve8%3D&reserved=0
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20180119/569ab7bf/attachment-0001.html>