Proposals for changes to searching behaviour

[Matt Harden]

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