Problem with hierarchical libraries in Hugs compared to ghc/nhc98
Fri, 07 Mar 2003 14:35:47 +0000
When trying to make our Haskell tracer Hat work with Hugs (November
2002) I noticed that
* Hugs' implementation of hierarchical libraries differs from those
of ghc and nhc98, and
* Hugs' implementation choice makes it more restrictive than ghc/nhc98
A simple example:
There is module B in file B.hs
There is module Test.B in file Test/B.hs
There is module Test.A in file Test/A.hs
Module Test.A contains "import B".
When compiling module Test.A both nhc98 and ghc imports module B from
file B.hs. In contrast, Hugs imports module Test.B from file Test/B.hs
and then stops with an error, because the module name is wrong.
The simple reason why Hugs behaves so is that when searching a module it
*always* searches the current directory (* where the import was demanded
*) first. Only afterwards the paths set with the -P option are searched.
I know that we generally try to avoid specifying filename and directory
However, this is not really a filename issue, but a problem of relative
and absolute module names (wrt possibly several hierarchies). An "import
B" in module Test.A could mean either module B or module Test.B.
I suggest that the absolute module name takes precedence, because
otherwise there is no way to import module B from module Test.A, whereas
you can always import module Test.B from module Test.A by saying "import
I admit that this has the slight disadvantage that moving a set of
modules into the hierarchical library will require not only changing all
module names at the top but also in every import declaration, to not
inadvertedly import the wrong module. So in the end this suggests that
we should not allow relative module names at all.
Note that this proposal still allows the current directory (of Hugs or
in which the compiler was started) to be the root of the hierarchy that
is searched first. In fact, this is probably the desirable default
Currently the hierarchical library proposal
does not say much about the semantics of the hierarchical module names.
It really should.
I'd very much like to hear other people's opinion on this (especially
the Hugs maintainers').
The current behaviour of Hugs makes it impossible for Hat to work with
Hugs. Hat creates a shadow hierarchy of transformed libraries: the
transformed variant of Prelude is Hat.Prelude, the transformed variant
of Control.Arrow is Hat.Control.Arrow etc. Nearly all of the transformed
modules import both Prelude and Hat.Prelude ...
Dept. of Computer Science, The University of York, York YO10 5DD, UK.
Tel: +44 1904 434756; Fax: +44 1904 432767