Hello Simon, >> Am 18.01.2004 um 11:31 schrieb Ketil Malde: >> >> > HNBeck@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