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
_______________________________________________
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
