<div dir="ltr">See some additions inline.<div>BR</div><div>Robin<br><div class="gmail_extra"><br><div class="gmail_quote">2018-01-19 18:27 GMT+01:00 Simon Peyton Jones via ghc-devs <span dir="ltr"><<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>| To do this, my idea is to instruct GHC with a compilation flag to give<br>
| out its internal representation of the source code.<br>
<br>
</span>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.<br>
<br></blockquote><div>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.</div><div><br></div><div>AFAIR we saw two possible ways to get the AST out from a complicated setup (FFI, objects, packages, ...):</div><div>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).</div><div>2) Refactor GHC Main and expose all the functionality to GHC API. </div><div><br></div><div>I filed <a href="https://ghc.haskell.org/trac/ghc/ticket/14018">https://ghc.haskell.org/trac/ghc/ticket/14018</a> a while ago that's slightly related.</div><div> </div><div>By the way, you can click around <a href="http://stuff.codereview.me/ghc/#ghc/ghc/Main.hs?corpus=ghc-8.2.1-rc2&signature">http://stuff.codereview.me/ghc/#ghc/ghc/Main.hs?corpus=ghc-8.2.1-rc2&signature</a> in the 'main' function to see all the magic.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Others are more used to the GHC API than me, though.<br>
<br>
S<br>
<div><div class="gmail-m_-4871082759436209286h5"><br>
| -----Original Message-----<br>
| From: ghc-devs [mailto:<a href="mailto:ghc-devs-bounces@haskell.org" target="_blank">ghc-devs-bounces@haske<wbr>ll.org</a>] On Behalf Of<br>
| Németh Boldizsár<br>
| Sent: 19 January 2018 09:35<br>
| To: <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
| Subject: Extracting representation from GHC<br>
|<br>
| Dear GHC Developers,<br>
|<br>
| I would like to ask your opinion on my ideas to make it easier to use<br>
| development tools with GHC.<br>
|<br>
| In the past when working on a Haskell refactoring tool I relied on<br>
| using the GHC API for parsing and type checking Haskell sources. I<br>
| extracted the representation and performed analysis and transformation<br>
| on it as it was needed. However using the refactorer would be easier<br>
| if it could work with build tools.<br>
|<br>
| To do this, my idea is to instruct GHC with a compilation flag to give<br>
| out its internal representation of the source code. Most build tools<br>
| let the user to configure the GHC flags so the refactoring tool would<br>
| be usable in any build infrastructure. I'm thinking of using the pre-<br>
| existing plugin architecture and adding two new fields to the Plugin<br>
| datastructure. One would be called with the parsed representation<br>
| (HsParsedModule) when parsing succeeds, another with the result of the<br>
| type checking (TcGblEnv) when type checking is finished.<br>
|<br>
| What do you think about this solution?<br>
|<br>
| Boldizsár<br>
|<br>
| (ps: My first idea was using frontend plugins, but I could not access<br>
| the representation from there and --frontend flag changed GHC<br>
| compilation mode.)<br>
|<br>
| ______________________________<wbr>_________________<br>
| ghc-devs mailing list<br>
| <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
</div></div>| <a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h" rel="noreferrer" target="_blank">https://na01.safelinks.protect<wbr>ion.outlook.com/?url=http%3A%<wbr>2F%2Fmail.h</a><br>
| <a href="http://askell.org" rel="noreferrer" target="_blank">askell.org</a>%2Fcgi-bin%2Fmailman<wbr>%2Flistinfo%2Fghc-<br>
| devs&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40<wbr>microsoft.com</a>%7C9d78fd2d16994a<wbr>de4d9008d5<br>
| 5f2007c3%7C72f988bf86f141af91a<wbr>b2d7cd011db47%7C1%7C0%7C636519<wbr>5135360471<br>
| 87&sdata=voUEz%2BKTp0p3CtwP1Hx<wbr>6xA3cXN0qoYONLPd9T7xRve8%3D&<wbr>reserved=0<br>
<div class="gmail-m_-4871082759436209286HOEnZb"><div class="gmail-m_-4871082759436209286h5">______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div></div></div>