RE: search path wierdness

On 10 January 2005 18:44, Duncan Coutts wrote:

>>> So I think probably a module like Graphics.UI.Gtk.Foo is importing
>>> and re-exporting from Graphics.UI.Gtk.Signals. Because, and only
>>> because, the file Signals.hi is in the directory Graphics/UI/Gtk,
>>> the import works.
>> 
>> Aha!  I see now.  GHC 6.4 has an improvement here:
>> 
>> $ cat >A.hs
>> module B where
>> $ cat >C.hs
>> import A
>> $ ghc -c A.hs
>> $ ghc -c C.hs
>> 
>> C.hs:1:0:
>>     Failed to load interface for `A':
>>         Interface file "./A.hi"
>>         contains module `B',
>>         but we were expecting module `A'
>>         Probable cause: the source code which generated          
>>         "./A.hi" has an incompatible module name
>> 
>> Duncan, I think that should address your problem, right?
> 
> I think it would. Thanks.
> 
> It might even be reasonable to give a warning (not an error) on
> compiling A.hs in your example above. The only time I can think of
> where the module name would be different from the file name is when
> you've got no module declaration line and so the module name defaults
> to Main (and that of course should not give a warning).

This is allowed (on purpose).  In GHCi, it makes sense to allow loading
any module from any file, and we didn't want to add special cases.  In
fact, it seems some people want to use their own naming scheme for
filenames - this is supported in GHCi and --make, as long as you name
all the files on the command line so that GHC doesn't have to go looking
for them.

Cheers,
        Simon