module namespaces with "Prelude"

[Simon Marlow]

> It happens in Hugs, too, but somewhat differently.  Here's a=20
> test case.
>=20
> Go to /foo and do mkdir Bar.  In Bar, create IO.hs and make=20
> its contents:
>=20
>   module Bar.IO where
>=20
> then also in Bar create Foo.hs
>=20
>   module Bar.Foo where
>   import IO
>=20
> Then when in directory Bar load ghci (using 5.02.1) and load=20
> Bar.Foo and
> you'll get:
>=20
>   IO.hs: file name does not match module name `IO'

This is the defined behaviour.  I'm aware that we haven't documented the
behaviour yet, but we will do for the next version of GHC. =20

Briefly, if the search path contains directories D1..Dn, and there is an
import requesting a module A.B.C, then GHC will look for the module
first in D1/A/B/C.{hs,lhs}, then D2/A/B/C.{hs,lhs}, and so on.  If the
contents of the file is actually not the required module, then GHC
issues a complaint.

I think Hugs is slightly more liberal in that it also allows the module
to be in a file called A.B.C.hs, but apart from that I believe that GHC,
Hugs, and nhc98 will all have similar behaviour (for a change!).

The advantage of the current story is that it is simple: the language
specification doesn't have to mention hierarchical modules at all, apart
from allowing the '.' character in a module name.  There are some
disadvantages to this scheme, eg. it isn't easy to move a subtree of
modules from one place in the hierarchy to another, so it might be
desirable to extend this to a more flexible scheme in the future.

Cheers,
	Simon