Difference between revisions of "Import"

From HaskellWiki
Jump to navigation Jump to search
m (Made it 3 variables instead of two.)
(explicitely say multiple imports are allowed; do some minor reorganizing)
(10 intermediate revisions by 4 users not shown)
Line 1: Line 1:
  +
[[Category:Language]]
The <hask>import</hask> statement is used to import functions and other definitions from another module. In the simplest case, you just write
 
  +
[[Category:Glossary]]
 
The <hask>import</hask> statement is used to import functions and other definitions from another module. The shortest form of the import statement is
 
<haskell>
 
<haskell>
 
import Data.Maybe
 
import Data.Maybe
 
</haskell>
 
</haskell>
to import the named module (in this case <hask>Data.Maybe</hask>).
+
that imports the named module (in this case <hask>Data.Maybe</hask>).
   
  +
However, there are more options:
However, in more complicated cases, the module can be imported qualified, with or without hiding, and with or without renaming. Getting all of this straight in your head is quite tricky, so here is a table (lifted directly from the language reference manual) that roughly summarises the various possibilities:
 
   
  +
# Modules can be imported '''qualified''' (forcing an obligatory namespace qualifier to imported identifiers).
Suppose that module <hask>Mod</hask> exports threefunctions named <hask>x</hask>, <hask>y</hask> and <hask>z</hask>. In that case:
 
  +
# Some identifiers can be skipped via the '''hiding''' clause.
  +
# The module namespace can be renamed, with an '''as''' clause.
  +
 
Getting all of this straight in your head is quite tricky, so here is a table (lifted directly from the language reference manual) that roughly summarises the various possibilities:
  +
 
Supposing that the module <hask>Mod</hask> exports three functions named <hask>x</hask>, <hask>y</hask> and <hask>z</hask>...
   
 
{|
 
{|
Line 21: Line 29:
 
| <hask>import Mod ()</hask>
 
| <hask>import Mod ()</hask>
 
| (Nothing!)
 
| (Nothing!)
  +
| (Useful for only importing instances of typeclasses and nothing else)
| (Why would you do this?)
 
 
|-
 
|-
| <hask>import Mod (x)</hask>
+
| <hask>import Mod (x,y)</hask>
| <hask>x, Mod.x</hask>
+
| <hask>x, y, Mod.x, Mod.y</hask>
| (Only <hask>x</hask>, no <hask>y</hask> or <hask>z</hask>.)
+
| (Only <hask>x</hask> and <hask>y</hask>, no <hask>z</hask>.)
 
|-
 
|-
 
| <hask>import qualified Mod</hask>
 
| <hask>import qualified Mod</hask>
Line 31: Line 39:
 
| (Only qualified versions; no unqualified versions.)
 
| (Only qualified versions; no unqualified versions.)
 
|-
 
|-
| <hask>import qualified Mod (x)</hask>
+
| <hask>import qualified Mod (x,y)</hask>
| <hask>Mod.x</hask>
+
| <hask>Mod.x, Mod.y</hask>
| (Only <hask>x</hask>, only qualified.)
+
| (Only <hask>x</hask> and <hask>y</hask>, only qualified.)
 
|-
 
|-
| <hask>import Mod hiding ()</hask>
+
| <hask>import Mod hiding (x,y)</hask>
| <hask>x, y, z, Mod.x, Mod.y, Mod.z</hask>
+
| <hask>z, Mod.z</hask>
| (Same as with no <hask>hiding</hask>.)
+
| (<hask>x</hask> and <hask>y</hask> are hidden.)
 
|-
 
|-
| <hask>import Mod hiding (x)</hask>
+
| <hask>import qualified Mod hiding (x,y)</hask>
| <hask>y, z, Mod.y, Mod.z</hask>
+
| <hask>Mod.z</hask>
| (<hask>x</hask> is hidden.)
+
| (<hask>x</hask> and <hask>y</hask> are hidden.)
|-
 
| <hask>import qualified Mod hiding ()</hask>
 
| <hask>Mod.x, Mod.y, Mod.z</hask>
 
| (Same as with no <hask>hiding</hask>.)
 
|-
 
| <hask>import qualified Mod hiding (x)</hask>
 
| <hask>Mod.y, Mod.z</hask>
 
| (<hask>x</hask> is hidden.)
 
 
|-
 
|-
 
| <hask>import Mod as Foo</hask>
 
| <hask>import Mod as Foo</hask>
Line 55: Line 55:
 
| (Unqualified names as before. Qualified names use <hask>Foo</hask> instead of <hask>Mod</hask>.)
 
| (Unqualified names as before. Qualified names use <hask>Foo</hask> instead of <hask>Mod</hask>.)
 
|-
 
|-
| <hask>import Mod as Foo (x)</hask>
+
| <hask>import Mod as Foo (x,y)</hask>
| <hask>x, Foo.x</hask>
+
| <hask>x, y, Foo.x, Foo.y</hask>
| (Only import <hask>x</hask>.)
+
| (Only import <hask>x</hask> and <hask>y</hask>.)
 
|-
 
|-
 
| <hask>import qualified Mod as Foo</hask>
 
| <hask>import qualified Mod as Foo</hask>
Line 63: Line 63:
 
| (Only qualified names, using new qualifier.)
 
| (Only qualified names, using new qualifier.)
 
|}
 
|}
  +
  +
Note that multiple import statements for the same module are also allowed, so it is possible to mix and match styles if its so desired (for example, importing operators directly and functions qualified)
  +
  +
===Hiding Prelude===
  +
  +
By default, ''every module'' implicitly imports <hask>Prelude</hask>. However, if you add an ''explicit'' import declaration for the prelude, this turns off the implicit one. Thus, if you wanted (for example) to write a module that redefines <hask>zip</hask> you could do
  +
<haskell>
  +
module Mod where
  +
  +
import Prelude hiding (zip)
  +
  +
zip = {- ... -}
  +
</haskell>
  +
Without the <hask>import</hask> statement, you could receive a compile-time error about an 'ambiguous use of <hask>zip</hask>'. A slightly more messy alternative is to do
  +
<haskell>
  +
module Mod where
  +
  +
import qualified Prelude as P
  +
  +
zip = {- ... -}
  +
</haskell>
  +
This has the disadvantage that (say) '<hask>P.show (2 P.+ 3 P.* 3) P.++ "abc"</hask>' is very messy to read. Typically a module only redefines a few prelude functions, and it's simpler to just hide the ones you don't want to clash with.
  +
  +
Note that any module ''using'' a module that redefines prelude functions will need to import either the prelude or the other module (or maybe both) qualified and/or with hiding for the same reason.
  +
  +
== See also ==
  +
  +
* [[Import modules properly]] - Some thoughts that may help to decide what form of the import statement to use.

Revision as of 14:16, 28 January 2012

The import statement is used to import functions and other definitions from another module. The shortest form of the import statement is

import Data.Maybe

that imports the named module (in this case Data.Maybe).

However, there are more options:

  1. Modules can be imported qualified (forcing an obligatory namespace qualifier to imported identifiers).
  2. Some identifiers can be skipped via the hiding clause.
  3. The module namespace can be renamed, with an as clause.

Getting all of this straight in your head is quite tricky, so here is a table (lifted directly from the language reference manual) that roughly summarises the various possibilities:

Supposing that the module Mod exports three functions named x, y and z...

Import command What is brought into scope Notes
import Mod x, y, z, Mod.x, Mod.y, Mod.z (By default, qualified and unqualified names.)
import Mod () (Nothing!) (Useful for only importing instances of typeclasses and nothing else)
import Mod (x,y) x, y, Mod.x, Mod.y (Only x and y, no z.)
import qualified Mod Mod.x, Mod.y, Mod.z (Only qualified versions; no unqualified versions.)
import qualified Mod (x,y) Mod.x, Mod.y (Only x and y, only qualified.)
import Mod hiding (x,y) z, Mod.z (x and y are hidden.)
import qualified Mod hiding (x,y) Mod.z (x and y are hidden.)
import Mod as Foo x, y, z, Foo.x, Foo.y, Foo.z (Unqualified names as before. Qualified names use Foo instead of Mod.)
import Mod as Foo (x,y) x, y, Foo.x, Foo.y (Only import x and y.)
import qualified Mod as Foo Foo.x, Foo.y, Foo.z (Only qualified names, using new qualifier.)

Note that multiple import statements for the same module are also allowed, so it is possible to mix and match styles if its so desired (for example, importing operators directly and functions qualified)

Hiding Prelude

By default, every module implicitly imports Prelude. However, if you add an explicit import declaration for the prelude, this turns off the implicit one. Thus, if you wanted (for example) to write a module that redefines zip you could do

module Mod where

import Prelude hiding (zip)

zip = {- ... -}

Without the import statement, you could receive a compile-time error about an 'ambiguous use of zip'. A slightly more messy alternative is to do

module Mod where

import qualified Prelude as P

zip = {- ... -}

This has the disadvantage that (say) 'P.show (2 P.+ 3 P.* 3) P.++ "abc"' is very messy to read. Typically a module only redefines a few prelude functions, and it's simpler to just hide the ones you don't want to clash with.

Note that any module using a module that redefines prelude functions will need to import either the prelude or the other module (or maybe both) qualified and/or with hiding for the same reason.

See also