I worked with setContext, et. al., to get something other than an empty list. However, while working on a good test case, it occurred to me that setContext and getNamesInScope is not the correct approach -- the GHC interface assumes a static environment, not a dynamic environment as exemplified by a IDE. I'm not really sure what you mean by this. What's wrong with setContext/getNamesInScope? Does it not work? Can you demonstrate it not working, by sending us a program that shows it not working?
S Consequently, it's more advantageous to manually extract and cache module data insofar as is feasible because the user is editing source that typically can't be parsed or is in an intermediate type-checked form that hasn't been loaded into the interpreter (Q: Would one really want to do that?) I'm not sure if GHC's interface to cached module data is exposed, or, even if that data is available from another internal source. It's not that hard to read modules and emulate what the interpreter is doing, although, having to extract re-exported symbols from the mi_usages Usage list kind of threw me off. -scooter On Thu, Jan 20, 2011 at 9:40 AM, Simon Peyton-Jones <[email protected]<mailto:[email protected]>> wrote: That's odd. If you setContext then the getNamesInScope should return all the names in scope. Can you give me a program (as described below) that shows that this does not happen? S From: Scott Michel [mailto:[email protected]<mailto:[email protected]>] Sent: 20 January 2011 16:55 To: Simon Peyton-Jones Cc: GHC Subject: Re: Generating IDE completions via GHC I'm not confident that I can expose the issue as simply as you suggest. Even if I call GHC.setContext, I get [] from getNamesInScope. What isn't clear are the prerequisites for calling getNamesInScope. -scooter On Thu, Jan 20, 2011 at 3:25 AM, Simon Peyton-Jones <[email protected]<mailto:[email protected]>> wrote: If it's not doing what you expect, could you make a test case to demonstrate it. Somethign like module Main where import GHC main = do { .... blah; ns <- getNamesInScope; print ns } where you get an empty list and you didn't expect one. I think that would be the easiest way to expose the difficulty Simon From: Scott Michel [mailto:[email protected]<mailto:[email protected]>] Sent: 20 January 2011 05:56 To: Simon Peyton-Jones Subject: Re: Generating IDE completions via GHC Simon: Thanks for the suggestion, but no dice. GHC.getNamesInScope returns an empty list. -scooter On Mon, Jan 10, 2011 at 1:36 AM, Simon Peyton-Jones <[email protected]<mailto:[email protected]>> wrote: Try GHC.getNamesInScope, which will give you all the entities in scope. Then use GHC.lookupName to see what manner of beast the Name is bound to (an Id, Class, TyCon etc) Does that help? Simon | -----Original Message----- | From: [email protected]<mailto:[email protected]> [mailto:glasgow-haskell-<mailto:glasgow-haskell-> | [email protected]<mailto:[email protected]>] On Behalf Of Scott Michel | Sent: 07 January 2011 06:31 | To: [email protected]<mailto:[email protected]> | Subject: Generating IDE completions via GHC | | I'm a little stuck trying to generate context-sensitive completions for | EclipseFP. For example, if the editor point is after "::" or "->", I'd like | to offer all types currently visible, including those offered via the | module's imports. There doesn't seem to be a way to do this via the GHC API, | unless I emulate the compiler's operation (i.e. reading interface files, etc) | | Am I missing something in the API? Basically, getting top-level names for a | module (and it's import decls) helps, but there's no selectivity. Is there a | way to interrogate a reader environment to do this? | | Looking at Leksah's code, I'm not looking forward to reading and processing | .hi files. And adding more complexity to (and more divergence from | nominolo's) scion-server. | | | -scooter | _______________________________________________ | Glasgow-haskell-users mailing list | [email protected]<mailto:[email protected]> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
