On Thu, 26 Apr 2001, Simon Marlow wrote:

Yes, this is another thing we'd like to do, but haven't got around to yet. (you can always define your own :compile command using :def of course, but the benefit of a built-in one would be that it could take advantage of the in-memroy interfaces rather than reading them from the disk).

IMHO to make compilation in ghci convenient the set of visible names from compiled modules should not differ that much from names visible from interpreted modules. It's not nice that even Prelude names are not in scope when the main module is compiled. Especially if :c without parameters compiled the main module by default. I understand that there are technical difficulties of inavailability of the source context inside compiled modules. One can emulate a better behavior by writing a module consisting of appropriate imports, so why ghci can't do that for me? Let's try to see how it could look like. Unqualified names in scope are drawn from three sources: 1. Names exported by a set of modules chosen by the user. Modules can be individually added to and removed from this set. Probably the full power of imports should be supported: :import Module :import Module (foo, bar) :import Module hiding (bar, baz) :import Module as M -- Perhaps not needed because qualified names -- are managed in a different way. Mentioning the same module twice combines the two effects, as for imports in the source. Prelude is implicitly in this set except if it is included explicitly, as for imports in the source. There is also :unimport Module and a way to display the active imports. 2. All top level definitions and things imported by a chosen source module (i.e. names available inside it), if one is chosen; it must be possible to forget it. When the user chooses a module for which both the source and *.o is available, the module is interpreted. It's impossible to choose a module without the source. Although it would make sense to allow more than one module available this way, it should probably be simplified to be at most one, i.e. choosing some forgets the previous one. Using unqualified ambiguous names coming from combined 1. and 2. is an error. Note that the module in 2. needs not to be present in the set of 1. Particularly when the chosen module reexports some variables qualified and doesn't have them available unqualified, they are not available. 3. Variables bound interactively. I'm not sure when they should be forgotten. If choosing another module in 2. must forget them due to some technical reasons, then ok, but I would prefer to forget them explicitly (not necessarily individually). These definitions cover other things with the same names, as if we were inside a 'do' block. -- Marcin 'Qrczak' Kowalczyk