Simon Marlow wrote:
- 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.
Good point, which should be cleared up. We don't intend GHC to have any knowledge of relative pathnames and the meaning of '.' or '..'. So the meaning of an import path [Graphics.Rendering.OpenGL]D would be simply this: when looking for a module's source/interface, if the module name is of the form Graphics.Rendering.OpenGL.M, then we look for D/M.hs. If it doesn't exist, we move on to the next entry in the search path.
One comment relating to this potential new syntax: this is the exact syntax used for filesystem paths in [Open]VMS. I believe VMS paths look like this: "DISK:[dir.subdir.subdir]filename.ext", and I think the "DISK:" part is optional. So, if you should ever want to port GHC to OpenVMS (I believe it is a POSIX compliant system), you might regret this particular choice of syntax. Also, programmers familiar with VMS might be confused by the syntax. My 2ยข: I would personally prefer not to change the import path syntax and go with the other suggestion: allow directories named X.Y.Z. It would be easy just to say "-i D" and make a directory D/Graphics.Rendering.OpenGL/ with the modules inside it. Also it keeps module hierarchy apparent in the directory structure, rather than being buried in a Makefile somewhere. Regards, Matt Harden