Hi Andre,
I like this idea, especially if this is currently the way Hugs does it. It's great for smaller projects.
Yes, we believe Hugs does allow "A.B.C.hs" as well as "A/B/C.hs". Ultimately, I think it is actually going to quite important that the different Haskell tools provoide reasonably compatible ways of finding sources/libraries. That includes the mechanisms discussed here as well as a package mechanims.
I'm not sure what syntax we'd use for this. Henrik suggested placing the module prefix in square brackets before the directory, eg. ghc -i '-i[Graphics.Rendering.OpenGL].'
This seems a bit unpredictable to me; it means that you can have a whole bunch of unrelated modules sitting together in the same directory, and then confuse the user even more with obscure GHC commandline switches :).
First, the point here is to reduce the number of assumptions built into a Haskell system about where sources live and what they are called. The fewer assumptions that are made, the greater the likelyhood that it will interoperate smoothly with other tools. Try to use the current mapping from hierarchical module names to file names with the Make VPATH mechanism for an example of what I mean. Second, I don't think this particular example of command line syntax is that obscure. Being able to tell GHC (and ultimately, I would hope, other Haskell implementations), what part of the module hierarchy they can find along a certain search path seems quite natural to me.
I'd argue that if you have a Graphics.Rendering.OpenGL module, you should make it 100% obvious that the module is in a Graphics.Rendering category; either putting it in a Graphics/Rendering directory or having a Graphics.Rendering.OpenGL.hs file makes this explicit.
I see little merrit in having a Haskell system enforce such rules. When dealing with large systems possibly involving many different languages and tools, it is very hard to predict what kind of source structure that is going to be most suitable and most easy for someone to get familiar with. Ultimately, the person(s) implementing an application/library is/are the one(s) best qualified for making such decisions, and the tools should ideally support that (within reason), not get in the way. Furthermore, different people might have different opinions on what's obvious, or what's the best tradeoff betweem "obviousness"/conveniece.
To put it another way -- is there a situation where you don't want to use either of the above two module naming schemes, and can justify having unrelated modules in an arbitrarily organised directory structure?
Well, again, ultimately I think the application/libabry implementor(s) should gave the ultimate say as to how to organize his/her/their sources, and what files that are sufficiently related to be put in a single directory. One reason I don't particularly like the "A/B/C" scheme, is that my sources can end up being spread out over several directories just because of the names I happen to choose for the modules. If, say, a library consists of the top-level module "A.B.C" and a bunch of internal components "A.B.C.M1", "A.B.C.M2", etc., I can't see why I should not be allowed to put them all in one directory. Another reason is how it interacts with tools like "Make". I've already mentioned the VPATH mechanism. Other make facilities like its (as well as the invoked shell's) wildcard support for file name matching also becomes much less useful. The reason I'm not quite happy with "fully qualified" file names, is that they could become inconveniently long, and that it still can make sense to use directories for part of the module hierarchy. I think the two suggestions ("." as an alternative to "/", and the possiblity to associate a search path with a module prefix) complement each other quite nicely, yielding a scheme which lets the implementors decide how to best organize their source code. /Henrik -- Henrik Nilsson Yale University Department of Computer Science nilsson@cs.yale.edu