RE: "Talking" with the compiler
| Yes, the HEP was one attempt to define the interface. There was a | "HEP-lite" implementation at one point, I believe, but it was never | fully adopted. But in effect, GHCi-as-a-library amounts to a HEP expressed as a Haskell library rather than a COM object. So we're getting there. S ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: "Talking" with the compiler
> > 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. > > What's about the HEP ? > The paper at haskell.org is a little bit old, and I could not find > newer information about the API or it's use. Yes, the HEP was one attempt to define the interface. There was a "HEP-lite" implementation at one point, I believe, but it was never fully adopted. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: "Talking" with the compiler
Hi, 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. What's about the HEP ? The paper at haskell.org is a little bit old, and I could not find newer information about the API or it's use. Greetings Hans ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: "Talking" with the compiler
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. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: "Talking" with the compiler
Hello Simon, >> Am 18.01.2004 um 11:31 schrieb Ketil Malde: >> >> > [EMAIL PROTECTED] (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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: "Talking" with the compiler
Hi, I agree. It would be nice to have also a Iterator interface for the AST, i.e. for jump to next/previous symbol of a special kind. Also information about the caller of a symbol would be nice (I don't know if that is already part of the compiler manager interface). I'm interested in code visualization and refactoring, so this all would be nice to have :-)) BTW: My host system will be Squeak ... greetings Hans Am 20.01.2004 um 11:32 schrieb Simon Marlow: 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 , :browse , :type 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. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: "Talking" with the compiler
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 , :browse , :type 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: "Talking" with the compiler
> 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 > , :browse > , :type 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. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: "Talking" with the compiler
> Am 18.01.2004 um 11:31 schrieb Ketil Malde: > > > [EMAIL PROTECTED] (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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: "Talking" with the compiler
Hi, Am 18.01.2004 um 11:31 schrieb Ketil Malde: [EMAIL PROTECTED] (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 :-((( Greetings Hans -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: "Talking" with the compiler
[EMAIL PROTECTED] (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)? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: "Talking" with the compiler
Hi, thank you, it's seems very helpful :-)) Greetings Hans Am 18.01.2004 um 00:31 schrieb Donald Bruce Stewart: HNBeck: Hi, 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've read that GHC has a interface, which was originally intended to plug in other backends. But I've never found a detailed description or API Can someone help me ? Perhaps you are talking about the external Core interface. Documentation for that is here: http://www.haskell.org/ghc/docs/latest/html/users_guide/ext-core.html Also, there are many -ddump-xxx options, that can give you very useful information, at any level of the compiler. Info for that is here: http://www.haskell.org/ghc/docs/latest/html/users_guide/flag- reference.html#AEN6775 Cheers, Don ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: "Talking" with the compiler
HNBeck: > Hi, > > 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've read > that GHC has a interface, which was originally intended to plug in > other backends. But I've never found a detailed description or API > > Can someone help me ? Perhaps you are talking about the external Core interface. Documentation for that is here: http://www.haskell.org/ghc/docs/latest/html/users_guide/ext-core.html Also, there are many -ddump-xxx options, that can give you very useful information, at any level of the compiler. Info for that is here: http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html#AEN6775 Cheers, Don ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
"Talking" with the compiler
Hi, 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've read that GHC has a interface, which was originally intended to plug in other backends. But I've never found a detailed description or API Can someone help me ? Thanks Hans ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
