- 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
- 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
- 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