On Thursday, April 25, 2002, at 11:30 , Simon Marlow wrote:

...

...

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 trouble - after all, we use hierarchical module names because the modules at the leaves of the tree are expected to overlap.

But it is this "." in the default path that is the reason GHCi gives unexpected results, isn't it? [See Hal Daume's original 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