Ben Millwood
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?
I would suggest this situation to be an error, but ghc currently appears to handle ambiguitiy by picking the first one that fits (according to my experimentation with multiple source directories and the -i option).
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.
As mentioned, there is already ambiguity, but of course this proposal would increase the number of paths to search.
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.
Yes, I don't see how to do that either, unless you introduce a generalized --main-is option, or similar. (Speaking about which, one obvious exception would be that the file Foo.hs could contain the Main module in addition to any modules in the Foo.* hierarchy. So it'd allow more structure to single-file applications. For what it's worth.)
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.
Not sure about that, you'd still be able to build multiple .o/hi's, and conditional compilation could be done by checksumming the indidual modules. Anyway, I think the main use-case here is for multiple small modules, so the impact on compile times might even be positive (for trivial modules, the compile time might be dominated by the IO operations).
This is not to say I'm against the proposal, but it's probably not as clear-cut as it sounds.
Thinking about it, I guess I'm really wanting to address a weakness in my development system (namely that it is cumbersome to work with a myriad of tiny files). And it occurs to me that the compiler might not be the appropriate place to do solve this. -k -- If I haven't seen further, it is by standing in the footprints of giants