Module system and interface files

Duplicates in a `renaming' list:

Are not reported.

Duplicates in an `import' declaration:

These are reported as errors, which some might argue they shouldn't be. We reckon it's a feature, not a bug.

Export of `renamed' class methods:

Willnae work. That is: you import a class, renaming one or more methods; then export that class -- the renaming of the methods will not propagate. (Otherwise, `renaming' -- disgusting though it may be -- should work.)

Fixities/precedences following `renamed' entities that are exported:

No chance.

`import Foo ()' vs `import Foo':

GHC cannot tell the difference (!). Given that the only module on which you might want to do the former is `import Prelude ()', there are probably much bigger gremlins that would jump out and bite you if the import did work. Besides which, you can achieve the same result with `-fno-implicit-prelude'.

Some selective import/export checking not done:

On selective import and export of type-constructors/classes in which the data-constructors/methods are named explicitly: it'll work; it's just that every conceivable paranoia check won't be done.

Some Prelude entities cannot be hidden:

For example, this doesn't work:

import Prelude hiding (readParen)

That's because there are a few should-be-hideable Prelude entities which need to appear by magic for derived instances. They are `(&&)', `(.)', `lex', `map', `not', `readParen', `showParen', and `showString'. SIGH.

`M..' exports vs multiply-imported entities:

If an entity `foo' is imported from several interfaces, as in...

import A1 (foo); import A2 (foo); import A3 (foo)

... and you then do a "dot dot" export of `A1' (for example), it will be pure luck if `foo' gets exported. This is very sad. Workaround: export `foo' explicitly.

`M..' with Prelude interfaces:

Doing `Prelude<something>..' in an export list; don't even think it.

Export of Prelude types/classes must be explicit:

If you want to export a data type, type synonym or class from a Prelude module (its name starts with `Prelude'), then it must be listed explicitly in the export list. If you say:

module PreludeMeGently ( PreludeMeGently.. , other_stuff ) where ..

then the classes/types in `PreludeMeGently' will not be exported; just add them to the export list. (This shortcoming is only likely to affect people writing their own Prelude modules.)

Can't export primitives types (e.g., `Int#'):

Don't even try...

Naming errors with `-O' but not without:

Documentation by example -- Consider a module with these imports:

... various imports ...
import Prettyterm       -- desired import

import Pretty           -- sadly-needed import

The `import Pretty' is required because it defines a type `Pretty.Doc' which is mentioned in `import Prettyterm'. (Extremely sad, but them's the rules.) But without `-O', GHC uses its `-fuse-get-mentioned-vars' hack (for speed), trying to avoid looking at parts of interfaces that have no relevance to this module. As it happens, the thing in `Prettyterm' that mentions `Pretty.Doc' is not used here, so this module will go through without `import Pretty'. Nice, but wrong.