Proposals for changes to searching behaviour

[Andre Pang]

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,
>     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 :).

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
directory structure?


-- 
#ozone/algorithm <ozone@algorithm.com.au>          - trust.in.love.to.save