#1873: ghci loses pre-error context after :reload
---------------------+------------------------------------------------------
Reporter: claus | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.8.2
Component: GHCi | Version: 6.9
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
---------------------+------------------------------------------------------
Comment (by claus):
i see. but if there is no obvious general scheme, perhaps we can get there
by small moves? the issue in #1556 was that `:reload` reloaded the top
module, not the whole context, as set up via `:module`, the issue here in
#1873 is that failure in `:reload` resets the context (actually, further
`:reloads` still refer to the source that is no longer part of the `ghci`
session scope, which is also odd).
it would help to distinguish between an intended context and whether or
not which modules in it have been successfully loaded/reloaded. then a
failure in `:reload` would simply mark some of the modules in the current
context as invalid, without resetting the context itself. that would
reestablish the old `ghci` behaviour for simple cases, fixing the really
annoying #1873, could be extended to modules gone missing (#1360), and
still leave your fix for #1556 intact, yes?
so, my proposal for an improved `ghci` context scheme would be:
- command `:load M1 .. Mn` establishes a new context with `M1 .. Mn>`
(and possibly `Prelude`) and loads the new context (*).
- command `:add M` adds `M` to the current context and loads it (*).
- command `:reload` reloads the current context (*).
- command `:module +-M` adds or removes `M` from/to the current context
(where add only works if module `M` is loaded explicitly or implicitly, as
a package module). question: should there be a `:remove M` to undo `:add
M` and actually unload explicitly loaded modules?
(*) if any of the modules in the current context fail to load during
`:load`, `:add` or `:reload`, they remain part of the context, but are
marked with an error flag in the session prompt, and their contents are
inaccessible.
since we already have `*` to mark modules for which all top-level items
are in scope (in contrast to the usual exports only), i suggest `?` for
missing modules and `!` for modules with other load errors.
example (imaginary session:-):
{{{
Prelude> :l M Dir.N
*M *Dir.N> -- top-levels of M and Dir.N are available
*M *Dir.N> :m *M Dir.N
*M Dir.N> -- top-level of M, but only exports of Dir.N available
-- add errors in M, then
*M Dir.N> :r
!*M Dir.N> -- M unavailable due to errors, exports of Dir.N available
-- fix M, then
!*M Dir.N> :r
*M Dir.N> -- top-level of M, plus exports of Dir.N available
*M Dir.N> :cd Dir
?*M (Dir.)N> -- M unavailable due to missing source, exports of Dir.N
available
}}}
that last line is perhaps wishful thinking, but `:cd` is another issue
with `ghci` session contexts and, in principle, `ghci` could interpret at
least relative `:cd` correctly. anyway, the idea is to keep the context
separate from which of its modules are successfully loaded. does that
help?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1873#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
