"Talking" with the compiler

[Peter Thiemann]

Hello Simon,

    >> Am 18.01.2004 um 11:31 schrieb Ketil Malde:
    >> 
    >> > HNBeck at t-online.de (Hans Nikolaus Beck) writes:
    >> >
    >> >> in order to build a programming environement, it would be 
    >> nice to ask
    >> >> the GHC about symbols etc found in a given Haskell program.
    >> >
    >> > I suppose a programming environment could talk to GHCi 
    >> (which provides
    >> > commands like :type, :info, :browse to explore the currently defined
    >> > symbols)?
    >> 
    >> I've look shortly at the GHCi documentation. So I think it would be 
    >> possible to include a "GHC engine" into a IDE application by 
    >> redirecting input and output from GHCi to pipes (I rembemer 
    >> that emacs 
    >> used something similar for doing it's compile stuff). But that's 
    >> hardcore UNIX,  I've forgot how to do that  :-(((

    sm> For the Visual Studio plugin we're going to need to talk to GHCi.  We
    sm> plan to do this by designing an appropriate API for GHCi and calling it
    sm> directly; you *could* do it by talking over a pipe, but it's going to be
    sm> a lot of work (and slow).  If you want to do this, please talk to us
    sm> about what API you'd like to see, and we can hopefully implement
    sm> something that will be generally useful.

we need exactly such a thing for the typebrowser that we are building
on top of the theory presented in our ICFP'03 paper. The browser is
not going to interact with the compiler, it just needs to gobble up
the environment of a given module to get going. Clearly, we would like
to spare ourselves the royal pain to implement the module system and all
that. At the present stage, the most useful functionality for us would be:

1. Make GHC load a module and then dump the entire symbol table of
   the current module (all accessible symbols (qualified and
   unqualified), classes, instances, typings), in some external
   representation. That external representation might be XML where you
   just use the names of the types and constructors inside of GHC.
   (I actually started to hack this up, but it would be nice to have a
   declared standard for such a representation. Yes, it could be
   automated using drift, but not all the constructors and
   fields are interesting outside of GHC, so you want to have
   "intelligent" shortcuts. Example: information about which fields in
   a record type are "banged" does not matter if you are just
   interested in typing.)

   It would be even nicer, if there was a way to have GHC ignore all
   definitions in the current module and just construct the imported
   environment. As far as I've seen the datastructures inside GHC
   allow for that. 

2. How about making the annotated syntax tree available in an XML
   format adapted from the datatypes of the GHC parser? BTW, does 
   Language.Haskell.Parser.parseModule already perform infix
   resolution? 

Of course, a library API would be useful, too, but the internal
structure of GHC's symbol table is sufficiently complicated that you
may not want to expose it. Instead, you'd like some way to look up
the information attached to a (qualified) symbol in the current
module's scope and get the result in a simple format, i.e., probably
not using GHC's internal datatypes. 

-Peter