Opened 3 years ago

Closed 2 years ago

Last modified 5 months ago

#11547 closed bug (fixed)

Accessing shadowed definitions in GHCi

Reported by: mniip Owned by: mniip
Priority: normal Milestone: 8.2.1
Component: GHCi Version: 8.0.1-rc1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: #14052 Differential Rev(s): Phab:D2447
Wiki Page:

Description

Apparently GHCi creates a qualified namespace for each line it interprets, as can be observed with:

> data A = A
> data A = B
> :t A
A :: Ghci3.A

Apparently accessing shadowed definitions in this way sometimes breaks GHCi:

> let a = a
> let a = a
> :t Ghci7.a

<interactive>:1:1: error:
     GHC internal error: Ghci7.a is not in scope during type checking, but it passed the renamer
      tcl_env of environment: []
     In the expression: Ghci7.a

More specifically, complete reproduction instructions:

GHCi, version 8.1.20160205: http://www.haskell.org/ghc/  :? for help
> let foo = foo
> :t Ghci1.foo
Ghci1.foo :: t
> let foo = foo
> :t Ghci1.foo

<interactive>:1:1: error:
     GHC internal error: Ghci1.foo is not in scope during type checking, but it passed the renamer
      tcl_env of environment: []
     In the expression: Ghci1.foo

7.10.2 (and 7.8.3 as verified over IRC by monochrom) appears to have a slightly different behavior. It seems it only creates namespaces for data/newtype/class declarations. Yet still, it fails with an error the first time but works completely fine thereafter:

> data A = A
> data A = A
> :t Ghci1.A
Failed to load interface for Ghci1
no package key matching interactive was found
> :t Ghci1.A
Ghci1.A :: Ghci1.A

7.6.3 uses a different approach to displaying out of scope names so the behavior doesn't apply:

> data A = A
> data A = B
> :t A
A :: main::Interactive.A

Change History (11)

comment:1 Changed 3 years ago by simonpj

Is it desirable:

  • To provide full access, using qualified names, to shadowed data types (and maybe values), or
  • To consistently not provide it?

I rather assume the former. After all if you say

> data A = A
> let f A = Int
> data A = XX
> :type f

then we have to print some sensible type for f, but it clearly can't mention the new data type A; it must somehow mention the old data type A. And then you might want to know more about that data type.

So it would be good to document this behaviour, and to make it work consistently. I know how some, but not all, of the moving parts work, so I can advise.

Simon

comment:2 Changed 2 years ago by mniip

If we choose to provide access to shadowed identifiers then, in the debugger, our environment gets littered by Ghci#._result and Ghci#._exception. Is that desirable?

I think I have a patch that implements that, but it breaks the debugger tests because of the above.

comment:3 Changed 2 years ago by mniip

Owner: set to mniip

comment:4 Changed 2 years ago by mniip

Differential Rev(s): D2447

comment:5 Changed 2 years ago by mniip

Differential Rev(s): D2447Phab:D2439

comment:6 Changed 2 years ago by mniip

Differential Rev(s): Phab:D2439Phab:D2447

comment:7 Changed 2 years ago by simonpj

The implementation is easy: delete code.

But what is the user-facing specification? We need user-manual stuff explaining what all this Ghci4.foo stuff means. How would you know whether to say :t Ghci2.foo or :t Ghci3.foo? Can you list all the foo functions? Etc.

Thanks!

comment:8 in reply to:  7 Changed 2 years ago by mniip

Well in the current implementation all Ghci#.foo bindings would show up in :show bindings, although it has been argued that they should be removed from there.

comment:9 Changed 2 years ago by Ben Gamari <ben@…>

In 59d7ee5/ghc:

GHCi: Don't remove shadowed bindings from typechecker scope.

The shadowed out bindings are accessible via qualified names like
Ghci1.foo.  Since they are accessable in the renamer the typechecker
should be able to see them too.  As a consequence they show up in :show
bindings.

This fixes T11547

Test Plan:
Fixed current tests to accomodate to new stuff in :show bindings
Added a test that verifies that the typechecker doesn't crash

Reviewers: austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, thomie

Differential Revision: https://phabricator.haskell.org/D2447

GHC Trac Issues: #11547

comment:10 Changed 2 years ago by bgamari

Milestone: 8.2.1
Resolution: fixed
Status: newclosed

comment:11 Changed 5 months ago by osa1

Note: See TracTickets for help on using tickets.