Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#4832 closed bug (fixed)

Inconsistent import of instances in GHCi

Reported by: sebf Owned by:
Priority: high Milestone: 7.4.1
Component: GHCi Version: 7.0.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Issuing import M in GHCi does not bring the same instances into scope as issuing :m + M and loading a file that contains import M do.

For example, the module Control.Applicative imports Control.Monad.Instances which defines a Functor instance for ((->) r). The following GHCi session demonstrates that this instance is not in scope after issuing an import command in GHCi but it is in scope after issuing an :m + command. It is also in scope after loading a file that imports Control.Applicative.

Prelude> fmap id id ()

<interactive>:1:1:
    No instance for (Functor ((->) ()))
      arising from a use of `fmap'
    Possible fix: add an instance declaration for (Functor ((->) ()))
    In the expression: fmap id id ()
    In an equation for `it': it = fmap id id ()
Prelude> import Control.Applicative
Prelude Control.Applicative> fmap id id ()

<interactive>:1:1:
    No instance for (Functor ((->) ()))
      arising from a use of `fmap'
    Possible fix: add an instance declaration for (Functor ((->) ()))
    In the expression: fmap id id ()
    In an equation for `it': it = fmap id id ()
Prelude Control.Applicative> :m + Control.Applicative
Prelude Control.Applicative> fmap id id ()
()

I expected that issuing an import command in GHCi has the same effect as issuing an :m + command or loading a file with an import statement.

Change History (4)

comment:1 Changed 9 years ago by igloo

Milestone: 7.2.1

Thanks for the report.

comment:2 Changed 9 years ago by simonmar

Priority: normalhigh

see also #5074

We should really fix this, it's not hard.

comment:3 Changed 9 years ago by batterseapower

Resolution: fixed
Status: newclosed

Quite annoying to track down, but it is now fixed and pushed:

commit 3deca8f44135bd1a146902f498189af00dd4d7b4
Author: Max Bolingbroke <batterseapower@hotmail.com>
Date:   Sun Apr 3 16:50:47 2011 +0100

    Use tcRnImports rather than rnImports with GHCi "import" statement: fixes #4
    
    The bug here was that just using rnImports does not ensure that any dependen
    orphan modules are loaded, so instances declared by such modules will not be
    usable from the GHCi command line after an "import".
    
    This did not affect the :m syntax because it takes a different code path and
    uses getModuleExports directly, which contains its own calls to the orphan-m
    loading stuff.

I added a test as well.

I think that mkExportEnv, hscGetModuleExports, getModuleExports, tcGetModuleExports could probably be deleted by just making the :m codepath a special case of the "import" codepath (in InteractiveEval.setContext), but I'm not familiar enough with the code to be confident about making that change.

comment:4 in reply to:  3 Changed 9 years ago by simonmar

Replying to batterseapower:

I think that mkExportEnv, hscGetModuleExports, getModuleExports, tcGetModuleExports could probably be deleted by just making the :m codepath a special case of the "import" codepath (in InteractiveEval.setContext), but I'm not familiar enough with the code to be confident about making that change.

Yes - Simon and I looked at this and came to the same conclusion.

Note: See TracTickets for help on using tickets.