module namespaces with "Prelude"

Johan Nordlander
Thu, 25 Apr 2002 23:23:40 +0200

On Thursday, April 25, 2002, at 07:05 , Simon Marlow wrote:

>> On Thursday, April 25, 2002, at 03:00 , Alastair Reid wrote:
>>>> Now, since there's nothing that prevents the directory hierarchies
>>>> starting at these roots from overlapping, we have a potential for
>>>> ambiguity when we want to map module names to filenames.
>>> This suggests that we might want to modify the search algorithm to
>>> find all matches and report and error if two or more candidate files
>>> are found.  If this is a big performance hit, we could make
>> it a :set
>>> option.
>> But wouldn't that just prohibit the use of module names that
>> also appear in the standard libraries?  At least we need to stop
>> searching the directory of the importing module to make
>> something useful of this idea.
> I agree with Alastair - I think it should be an error if there are two
> modules with the same name on the search path.  If it weren't for (a)
> the performance hit and (b) the difficulty in portably determining
> whether two pathnames refer to the same file, I'd have made 
> GHCi do this
> already.
> Yes, it would prohibit the use of module names that also appear in the
> standard libraries.  But after all we're moving to hierarchical
> libraries so there's no need to do that any more!

I subscribe to all of the above.  My worry was that if we don't 
remove the implicit searching of the directory where an 
importing module was found, we'll end up having to report 
ambiguity  pretty much every time the programmer defines a 
module with the same name as a standard module {\em not counting 
any module name prefix}.  I.e., exactly the same problem Hal 
Daume reported.  And it wasn't (still isn't) clear to me if 
Alastair is in favor of dropping the implicit roots.

My view is that we should drop them.  That would simplify the 
search algorithm, and it would make Hugs consistent with GHCi.  
Flagging an error when there are multiple modules with the same 
{\em full} module name could make a nice safety check on top of 

-- Johan