module namespaces with "Prelude"

[Simon Marlow]

> On Thursday, April 25, 2002, at 11:30 , Simon Marlow wrote:
>=20
> >> All in all, dropping all implicit directories from the search
> >> path gets my vote.
> >
> > "me too".
> >
> > I wasn't aware that Hugs did this, and GHCi certainly doesn't.  It's
> > reasonable to leave "." in the default search path, but adding an
> > implicit root for an imported module will certainly lead to=20
> trouble -
> > after all, we use hierarchical module names because the=20
> modules at the
> > leaves of the tree are expected to overlap.
>=20
> But it is this "." in the default path that is the reason GHCi=20
> gives unexpected results, isn't it?  [See Hal Daume's original=20
> bug report]

Well, that depends what you mean by unexpected - IMHO the behaviour is
entirely reasonable and is well documented.  Let's recap: the directory
structure is something like this (using $$ to represent an arbitrary
path):

	$$/Bar/Foo.hs   contains module Bar.Foo
	$$/Bar/IO.hs    contains module Bar.IO

now if the current directory is $$, then Bar.Foo and Bar.IO map to the
correct filenames/modules.  However, if the current directory is $$/Bar,
as it was in Hal's example, then module IO maps to both ./IO.hs and the
IO module in the standard library.  Clearly there's an overlap, and the
solutaion is not to sit in $$/Bar, or to explicitly remove "." from the
default search path (which you can do in ghc by giving a -i option
without any arguments).

If one root is a subdirectory of another root, then you have an overlap.
Clearly, the "implicit roots" mechanism will always lead to overlap, so
it can't be the right thing to do.

Unfortunately it isn't easy to detect whether the user-specified roots
are overlapped and issue a warning, but I think the rule is fairly
straightforward to understand.  It would be possible to detect whether a
module maps to more than one filename though - perhaps we should do
that.

Cheers,
	Simon