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