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