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 :-(((
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. Cheers, Simon
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. For what I wanted, the ability to evaluate/compile expressions was not necessary, just to browse through symbol information. Duncan
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
Peter wrote:
BTW, does Language.Haskell.Parser.parseModule already perform infix resolution?
Unless it changed very recently, then no. I have written some code for this very task: http://www.cs.mu.oz.au/~bjpop/code/Infix.hs You give it the infix rules that are in scope and a module and it returns the module with the infix applications resolved. (Of course knowing what rules are in scope is another story, not solved by this piece of code). Perhaps it is of some use to you? Cheers, Bernie.
participants (4)
-
Bernard James POPE -
Duncan Coutts -
Peter Thiemann -
Simon Marlow