Opened 7 years ago

Closed 6 years ago

Last modified 4 years ago

#1360 closed task (fixed)

ghci :load and :add clear module context

Reported by: Frederik Owned by:
Priority: normal Milestone: 6.10 branch
Component: GHCi Version: 6.6
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Difficulty: Easy (less than 1 hour)
Test Case: Blocked By:
Blocking: Related Tickets:

Description

If I add modules with a ":m" command, and then load a file with ":l" or add something with ":a", then the effect of the previous ":m" incantation seems do disappear, is this for a reason?

Change History (8)

comment:1 Changed 7 years ago by simonmar

  • Difficulty changed from Unknown to Easy (1 hr)
  • Milestone set to 6.1
  • Type changed from bug to task

It's by design to some extent, because this was the easiest thing to do. Some of the modules you added with :m may have gone away since you reloaded. Of course that doesn't apply to package modules, so we could keep those around.

comment:2 Changed 7 years ago by Frederik

What about traversing the expression context module list when something is loaded, and if a module has disappeared then remove it but print a warning message, and otherwise keep it - would that behaviour make sense?

comment:3 Changed 6 years ago by simonmar

See also #1556, which is this same issue applied to reload. Reload is somewhat easier, since it is likely that the previous context still makes sense.

The problem with this ticket is deciding exactly what to implement. If someone could have a go at specifying something, that would be a good starting point. The context consists of two sets of modules (as,bs) where as are the *M modules and bs are the non-* modules. Specify a way to decide what (as,bs) should be after a load/add, given the previous (as,bs).

comment:4 Changed 6 years ago by simonmar

  • Resolution set to fixed
  • Status changed from new to closed

I think I've made this work better now:

Fri Nov 16 15:21:48 GMT 2007  Simon Marlow <simonmar@microsoft.com>
  * Attempt at fixing #1873, #1360
  
  I think I figured out a reasonable way to manage the GHCi context,
  comments welcome.
  
  Rule 1: external package modules in the context are persistent.  That
  is, when you say 'import Data.Maybe' it survives over :load, :add,
  :reload and :cd.
  
  Rule 2: :load and :add remove all home-package modules from the
  context and add the rightmost target, as a *-module if possible.  This
  is as before, and makes sense for :load because we're starting a new
  program; the old home-package modules don't make sense any more.  For
  :add, it usually does what you want, because the new target will
  become the context.
  
  Rule 3: any modules from the context that fail to load during a
  :reload are remembered, and re-added to the context at the next
  successful :reload.
  
  Claus' suggestion about adding the "remembered" modules to the prompt
  prefixed with a ! is implemented but commented out.  I couldn't
  decide whether it was useful or confusing.
  
  One difference that people might notice is that after a :reload where
  there were errors, GHCi would previously dump you in the most recent
  module that it loaded.  Now it dumps you in whatever subset of the
  current context still makes sense, and in the common case that will
  probably be {Prelude}.

comment:5 Changed 6 years ago by simonpj

Sounds great. If the design "sticks", let's not forget the documentation.

Simon

comment:6 Changed 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:7 Changed 6 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:8 Changed 4 years ago by simonmar

  • Difficulty changed from Easy (1 hr) to Easy (less than 1 hour)
Note: See TracTickets for help on using tickets.