I don't quite follow you. The issue as I see it is whether a module A.B.C can be placed in a file A.B.C.hs, or whether it has to be named A/B/C.hs (substitute / for the local directory separator). IIRC some people wanted to be able to do this - I suppose it might be useful to avoid deep/sparse directory structures.
Except on systems which don't have recursive directories, I don't see any motivation to be able to do this. If we allow A.B.C to be mapped to either A.B.C.hs or A/B/C.hs, shouldn't we also allow: A.B/C.hs A/B.C.hs I think we'd soon be asked to do this for consistency and I'd rather not support all those options - much better to have module names map onto filenames in a small number of ways.
Note that the ghc-users discussion would have a quite different semantics from what Hugs has. Hugs semantics is to simultaneously try to interpret filenames two ways: first relative to the current directory, and second relative to the search path.
How is that different from adding the current directory to the search path? (which is what GHC does by default).
The proposed semantics is to either treat it as relative to the current directory if it contains a leading dot or to treat it as relative to the search path otherwise.
by "current directory" you mean "directory in which the current module resides?" (i.e. not the same as the meaning of ".").
Yes. And I think that's where the difference lies. Adding the current working directory (".") doesn't bother me - users can choose to put it in their search path (or Hugs/ghci can implicitly add it for them). -- Alastair