- The sources for a module A.B.C would be allowed to be placed in either A.B.C.hs or A/B/C.hs relative to one of the directories in the search path. Currently only A/B/C.hs is allowed.
This is an easy change to make, and I believe Hugs already does it this way.
Sounds useful (provided all major implementations agree). Btw, there's another convention, of adding suffixes to indicate processing phases (e.g., Main.hs.cpp.gz.uue). Is that likely to lead to conflicts (perhaps Main.WWW.hs for pipe through runhugs then post on web site?-)?
- We could provide the ability to specify a module prefix to associate with a directory in the search path. For example, you could say that the directory '.' is associated with the module prefix "Graphics.Rendering.OpenGL" and avoid having to place your sources in the directory Graphics/Rendering/OpenGL.
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].'
Does that mean I can refer to X.hs as [Graphics.Rendering.OpenGL(.Graphics.Rendering.OpenGL)*/]X.hs ?-) Probably no problem with Haskell's explicit imports.
In contrast to the previous suggestion, this would actually save some trips to the OS when GHC is looking for files.
I'm not sure about the details of your first suggestion, but if you take it to permit all mixtures of "."and "/", such as A.B/C.hs (I assume at least A/B.C.hs is already permitted?), you can get rid of the second - e.g., simply make "Graphics.Rendering.OpenGL" a link to ".". That way, directory trees could be compressed (even the middle sections of long paths) while providing visible documentation of those shortcuts. I'd prefer that to compiler options (and instead of shortcutting into ".", I'd probably have one second layer of directories, with shortcuts from "." into those, if only to avoid naming conflicts at the leaves of the tree..). Claus