Proposals for changes to searching behaviour
Wed, 11 Dec 2002 15:08:18 -0600
Simon Marlow wrote:
>>> - We could provide the ability to specify a module prefix
>>> 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
>>> 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
>>> ghc -i '-i[Graphics.Rendering.OpenGL].'
>>Does that mean I can refer to X.hs as
>>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.