Opened 6 years ago

Closed 12 months ago

#1896 closed feature request (wontfix)

Keep old bindings until :load succeeds

Reported by: tibbe Owned by:
Priority: low Milestone: 7.6.2
Component: GHCi Version: 6.8.1
Keywords: Cc: jonas.duregard@…, patrick@…, etienne@…, bgamari@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

Imagine you make a change to a module which is already loaded into GHCi and then try to :load it again. If the load fails not only will you not have the new bindings but the old ones are lost as well. This prevents you from e.g. using :type to figure out why your new change doesn't type check.

A more ambitious solution would be to try to incrementally load the module and keep all bindings up to the one that fails (and its dependents.) This would allow you to debug the failure more interactively (e.g. compose functions and look at their combined types.) This is probably trickier as previous bindings might be invalidated.

Attachments (1)

parcs-context-reversion-reload.patch (1.9 KB) - added by parcs 3 years ago.
retains bindings after a failed :reload

Download all attachments as: .zip

Change History (23)

comment:1 Changed 6 years ago by tibbe

  • Version set to 6.8.1

comment:2 Changed 6 years ago by igloo

  • Difficulty set to Unknown
  • Milestone set to 6.8 branch

We should think about what the best behaviour is here.

comment:3 Changed 6 years ago by igloo

  • Milestone changed from 6.8 branch to 6.10 branch

comment:4 Changed 6 years ago by simonmar

  • Architecture changed from Multiple to Unknown/Multiple

comment:5 Changed 6 years ago by simonmar

  • Operating System changed from Multiple to Unknown/Multiple

comment:6 Changed 5 years ago by igloo

  • Milestone changed from 6.10 branch to 6.12 branch

comment:7 Changed 4 years ago by igloo

  • Milestone changed from 6.12 branch to 6.12.3

comment:8 Changed 4 years ago by igloo

  • Milestone changed from 6.12.3 to 6.14.1
  • Priority changed from normal to low

comment:9 Changed 3 years ago by igloo

  • Milestone changed from 7.0.1 to 7.0.2

comment:10 Changed 3 years ago by igloo

  • Milestone changed from 7.0.2 to 7.2.1

comment:11 Changed 3 years ago by JonasDuregard

  • Cc jonas.duregard@… added
  • Type of failure set to None/Unknown

Changed 3 years ago by parcs

retains bindings after a failed :reload

comment:12 Changed 3 years ago by parcs

  • Cc patrick@… added
  • Status changed from new to patch

Hi,

The attached patch seems to retain bindings after a failed :reload. It saves the state of the linker and the GHC session before attempting to load and restores it on failure.

comment:13 Changed 3 years ago by simonmar

Thanks for the patch. One thing I'd be concerned about with saving the entire GHC session across :reload is space leaks - we're careful to discard modules in :reload to avoid keeping two copies of the code in memory at the same time.

Also I think this ticket is asking for something a bit different - keeping the previous bindings in a module until they are replaced by successfully typechecked new code (if I understand correctly) so that the old code can still be inspected after a type error.

comment:14 Changed 3 years ago by igloo

  • Milestone changed from 7.2.1 to 7.4.1

comment:15 Changed 2 years ago by atnnn

  • Cc etienne@… added

#5624 also addresses the same problem (and more).

comment:16 Changed 2 years ago by igloo

  • Milestone changed from 7.4.1 to 7.6.1

comment:17 Changed 22 months ago by bgamari

  • Cc bgamari@… added

comment:18 Changed 22 months ago by parcs

Doesn't the '-fdefer-type-errors` flag provide this feature?

comment:19 Changed 22 months ago by pcapriotti

It's not the same thing, because the old bindings are still discarded and replaced with new ones that might contain type errors, but I suppose it covers some (most?) of the use cases.

comment:20 Changed 19 months ago by igloo

  • Milestone changed from 7.6.1 to 7.6.2

comment:21 Changed 15 months ago by morabbin

Since some/most of the use-cases are covered, perhaps someone who cares about the remainder ought to make a new ticket?

comment:22 Changed 12 months ago by igloo

  • Resolution set to wontfix
  • Status changed from patch to closed

For the :reload case, I don't think we want to fall back to the previous state if the reload fails.

For example, suppose you have A and B loaded, B imports A, and you make a change to A and reload. If B is no longer well-typed, then I think you want to end up with the new A loaded so that you can see how to fix B.

I'm going to close this ticket, but if anyone thinks there's a case that should be handled differently than it currently is, please open a new ticket and include step by step instructions to demonstrate the current (wrong) behaviour, and say what you think the right behaviour should be.

Note: See TracTickets for help on using tickets.