Proposals for changes to searching behaviour
Tue, 10 Dec 2002 00:39:23 +1100
On Mon, Dec 09, 2002 at 12:40:18PM -0000, Simon Marlow wrote:
> - 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.
I like this idea, especially if this is currently the way Hugs
does it. It's great for smaller projects.
> - 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].'
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 :).
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.
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
#ozone/algorithm <email@example.com> - trust.in.love.to.save