Opened 9 years ago

Closed 9 years ago

Last modified 7 years ago

#2452 closed feature request (fixed)

Add a flag to disable the implicit qualified import of every available module in interactive mode

Reported by: jcpetruzza Owned by: simonmar
Priority: normal Milestone: 6.10.1
Component: Compiler (Type checker) Version: 6.9
Keywords: Cc: gwern0@…, id@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


In interactive mode every available module is implicitly imported qualified. While this is very convenient when working with GHCi, it can be a little annoying in other contexts.

For instance, in a lambdabot-like application, one would like to rely on the type of a given expression to decide if it is side-effect free and, thus, safe to execute. However, because every module in the base package is imported qualified one has to do a manual check to filter out cases like:

ghc -e 'System.IO.Unsafe.unsafePerformIO (evilStuff >> return "i'm an innocent string")'

Another example would be a GHC-API based refactoring tool that wants to check if a refactored expression typechecks before modifying the code. If every module is imported qualified, the tool might get many false positives.

The proposal is to keep the current behaviour as the default but to add a -fno-implicit-import-qualified flag to disable it when needed. The following should fail to execute:

ghc -fno-implicit-import-qualified -e 'System.IO.Unsafe.unsafePerformIO (evilStuff >> return "i'm an innocent string")'

Attachments (1)

no-implicit-import-qualified-flag.dpatch (58.3 KB) - added by jcpetruzza 9 years ago.
patch that adds this flag (ghc 6.9)

Download all attachments as: .zip

Change History (14)

Changed 9 years ago by jcpetruzza

patch that adds this flag (ghc 6.9)

comment:1 Changed 9 years ago by jcpetruzza

Owner: set to igloo

Since it looks like a simple enough fix, I've added a patch for it.

comment:2 Changed 9 years ago by igloo

difficulty: Unknown
Milestone: 6.10.1
Owner: igloo deleted

Thanks for the patch! However, before applying it I'd like to be sure that it is the right thing to do.

For lambdabot, I think we really want Safe Haskell (#1380).

Should a refactoring tool be using interactive mode if it wants to do that?

comment:3 Changed 9 years ago by Isaac Dupree

Cc: id@… added

FWIW, I'd like this as an option for using interactive mode interactively in the normal way :-), on occasion I want to do that to simplify my bug-fighting or maybe reduce ambiguities

comment:4 Changed 9 years ago by jcpetruzza

IMO, the GHC-API in interactive mode can be used to build very cool IDE-tools. Maybe an interactive refactoring tool is not the best example one can think of, but I hope it still illustrates the idea.

In any case, the point I wanted to make is this: in interactive mode, the typechecker behaves in a unique way and right now there is no way to turn this off. Thus, one simply cannot write an application that uses powerful features from interactive mode and simultaneously relies on a "standard" typechecker.

comment:5 Changed 9 years ago by guest

Cc: gwern0@… added; id@… removed

comment:6 Changed 9 years ago by guest

Cc: id@… added

comment:7 Changed 9 years ago by guest

Igloo: I don't really think this is much related to the Safe Haskell proposal, which is pretty comprehensive and addresses all the attacks circumventing IO. Rather, this is more "I want modules and imports to work the way they already do (in normal source files), and to stop being exceptional when it goes through the GHC API" (ie. not allowing the code to do stuff the imports forbid), if you follow me.

I mean, if you import Foreign, everything will still be as unsafe as before. This just avoids GHC going out of its way to sabotage security efforts.

-- gwern

comment:8 Changed 9 years ago by guest

So, I'd just like to mention an example of why I really don't like this bug: it forces me to use stuff like the Hint sandboxing to work around it.

Why is this so bad? Well, I just blew 5 or 6 hours this evening because of the Hint sandboxing. I was trying to add UTF support, since lambdabot can handle it, and I was having serious problems: each and every time compilation failed with UTF chars, even though they are perfectly valid in GHCi and Lambdabot.

As I eventually discovered: turns out that while evaluating straight through the GHC API works fine when your expression contains strange UTF characters, Hint's sandboxing internally works via writing a module to a file and also one's expression. And of course it uses the usual 'writeFile' function, and as we all know, the basic GHC IO functions are all broken w/r/t Unicode, and of course I didn't remember that the sandboxing flag changed the route. And that is how my evening was wasted.

Now, is it this bug/GHC's fault that Hint used the standard IO functions instead of uft8-string's functions? No. (Well, maybe in the broader sense.) Is it even Hint's fault? Not really. But the fact remains that my evening was quite unpleasant because of this unchangeable behavior.

comment:9 Changed 9 years ago by simonmar

Owner: set to simonmar

comment:10 Changed 9 years ago by simonmar

Resolution: fixed
Status: newclosed


Tue Aug  5 08:17:30 PDT 2008  Simon Marlow <>
  * Add -fno-implicit-import-qualified (#2452)
  The flag is off by default, but GHCi turns it on (in Main.hs).  For
  GHCi it can be overriden on the command-line or using :set.

comment:11 Changed 8 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:12 Changed 8 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:13 Changed 7 years ago by guest

Type of failure: None/Unknown

I assumed, that I could achieve the wanted behaviour with

ghci -hide-all-packages -package haskell98

in GHC-6.10.4, but it aborts with

GHCi, version 6.10.4:  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Loading package syb ... linking ... done.
Loading package array- ... linking ... done.
Loading package filepath- ... linking ... done.
Loading package old-locale- ... linking ... done.
Loading package old-time- ... linking ... done.
Loading package unix- ... linking ... done.
Loading package directory- ... linking ... done.
Loading package process- ... linking ... done.
Loading package random- ... linking ... done.
Loading package haskell98 ... linking ... done.
<command line>: Could not find module `Prelude':
  it is a member of the hidden package `base-'
  it is a member of the hidden package `base'
  Use -v to see a list of the files searched for.

For my taste, the Unsafe modules should go to an extra package anyway.

Note: See TracTickets for help on using tickets.