Add flag -fno-it
ClosedPublic

Authored by mpickering on Jan 10 2018, 10:59 AM.

Details

Reviewers
bgamari
Commits
rGHC41afbb3f20f3: Add flag -fno-it
Trac Issues
#14336
Summary

This flag stops ghci creating the special variable it
after evaluating an expression. This stops ghci leaking
as much memory when evaluating expressions. See Trac #14336

Diff Detail

Repository
rGHC Glasgow Haskell Compiler
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
mpickering created this revision.Jan 10 2018, 10:59 AM

I'm not sure I understand why it is leaking. Surely we should be able to expunge the old binding after it is shadowed, no?

docs/users_guide/ghci.rst
1031

These need to be double ticks.

I'm not sure I understand why it is leaking. Surely we should be able to expunge the old binding after it is shadowed, no?

As I understand it another variable could bind it, ie let f = it and so if we remove the binding then f will break. There is no special logic for it, it is the same as any variable bound in ghci so it behaves the same when shadowed.

I'm not sure I understand why it is leaking. Surely we should be able to expunge the old binding after it is shadowed, no?

As I understand it another variable could bind it, ie let f = it and so if we remove the binding then f will break. There is no special logic for it, it is the same as any variable bound in ghci so it behaves the same when shadowed.

That sounds plausible. I would say ideally we would the previous it from our context after every successful evaluation but if this isn't easy I suppose this is a reasonable workaround.

As I understand it another variable could bind it, ie let f = it and so if we remove the binding then f will break. There is no special logic for it, it is the same as any variable bound in ghci so it behaves the same when shadowed.

That sounds plausible. I would say ideally we would the previous it from our context after every successful evaluation but if this isn't easy I suppose this is a reasonable workaround.

Silly me, of course this wouldn't work. let x = it; 45; x would then crash as we would have let go of the it which x refers to.

Documentation

bgamari accepted this revision.Jan 15 2018, 12:22 PM

Looks good to me.

This revision is now accepted and ready to land.Jan 15 2018, 12:22 PM
This revision was automatically updated to reflect the committed changes.

I'm not sure I understand why it is leaking. Surely we should be able to expunge the old binding after it is shadowed, no?

I'm not sure if you've seen this comment, but it surprised me the first time I read it: https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/main/HscTypes.hs;cf2c029ccdb967441c85ffb66073974fbdb20c20$1385

This leads to the following behavior:

$ ./inplace/bin/ghc-stage2 --interactive       
GHCi, version 8.5.20180114: http://www.haskell.org/ghc/  :? for help
Prelude> 1
1
Prelude> 2
2
Prelude> 3
3
Prelude> 4
4
Prelude> 5
5
Prelude> Ghci
Ghci1.it  Ghci2.it  Ghci3.it  Ghci4.it
Prelude> Ghci4.it 
4
Prelude> Ghci3.it 
3
Prelude> Ghci2.it
2
Prelude> Ghci1.it
1
Prelude>