Proposals for changes to searching behaviour
Mon, 9 Dec 2002 23:30:41 -0000
> - 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,
> ghc -i '-i[Graphics.Rendering.OpenGL].'
Does that mean I can refer to X.hs as
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..).