"Talking" with the compiler

Simon Marlow simonmar at microsoft.com
Tue Jan 20 10:32:29 EST 2004

> On Mon, 2004-01-19 at 11:34, Simon Marlow wrote:
> > For the Visual Studio plugin we're going to need to talk to 
> GHCi.  We
> > plan to do this by designing an appropriate API for GHCi 
> and calling it
> > directly; you *could* do it by talking over a pipe, but 
> it's going to be
> > a lot of work (and slow).  If you want to do this, please talk to us
> > about what API you'd like to see, and we can hopefully implement
> > something that will be generally useful.
> I wanted something like that for a Haskell IDE I was working on (not
> much progress on it at the moment, but I may pick it up again).
> The main things I wanted was enough information to be able to 
> implement
> "jump to definition". Where you select a symbol in your 
> editor and move
> to where that variable/function/type/class was defined, in the same
> module or another module.  It would also be useful to find out the
> module and package a symbol comes from so that an IDE could 
> have a good
> stab at finding some documentation.
> For that, you'd want an API for wandering through the useful 
> information
> in .hi files. An API corresponding to hugs/ghci's :info 
> <name>, :browse
> <modname>, :type <name> would be a good start. You'd want to 
> be able to
> specify which root module to load up the symbols for, optionally
> specifing a search path and expect it to also load up the .hi 
> files for
> any imported modules.

This is all stuff that we need for Visual Studio too.  VS will typecheck
your program as you type, so you'll get errors underlined in the source
code.  A side effect of this is that it will collect all the information
reuqired to implement "jump to definition" and "tell me the type of this
identifier" in the editor.

My plan is to have an API where you can request a :load of a module
source (perhaps omitting the code generation steps for speed) and then
request information about the module, by source location (GHC now has
completely accurate source location information in its abstract
datatype; we did this recently in order to support the Visual Studio
work).  The API will most likely be a derivative of the existing
compilation manager interface: see ghc/compiler/compMan/CompManager.lhs.


More information about the Glasgow-haskell-users mailing list