On Sun, Nov 22, 2009 at 7:13 PM, Ketil Malde
E.g. if module Foo.Bar isn't found in Foo/Bar.hs GHC could look in Foo.hs (which would just contain a concatenation of what would currently reside in Foo.hs and Foo/Bar.hs).
The obvious question arising here is what if module Foo.Bar *is* found in Foo/Bar.hs as well as in Foo.hs - is the latter ignored? It doesn't sound like an insurmountable problem but one of the nicest things about the current module system is its simplicity and predictability, both of which are somewhat attacked by this proposal. Also, it sounds like your proposal would disallow definition of multiple top-level modules in a file, because we wouldn't know where to look for them. This is not necessarily unreasonable, but it's an unexpected special case. Presumably having the modules together in a file would also mean that they could only be compiled together and would produce a single .o or .hi file. Then you might ask whether the ABI or whatever is necessarily broken by a change to *any* of the modules involved, in which case modularisation starts to become purely about name qualification. Thinking about that, it's worth noting that importing one module twice with two different names works fine. This is not to say I'm against the proposal, but it's probably not as clear-cut as it sounds.