> It happens in Hugs, too, but somewhat differently. Here's a
> test case.
>
> Go to /foo and do mkdir Bar. In Bar, create IO.hs and make
> its contents:
>
> module Bar.IO where
>
> then also in Bar create Foo.hs
>
> module Bar.Foo where
> import IO
>
> Then when in directory Bar load ghci (using 5.02.1) and load
> Bar.Foo and
> you'll get:
>
> 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.
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
_______________________________________________
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
