GHC cannot import submodules when run from subfolder

I'm taking a huge risk in looking like an idiot, but it's worth trying to attack the elephant in the room. The first response I expect is "This is expected behaviour!". This is what intuition says, but I disagree. It's a simple problem and the fix should be easy, unless there's some advanced import mechanism that would conflict with the solution that I don't know about. That is exactly where I'm taking the risk in reporting this issue.

The problem is simple:

1. Create a folder called "Yes".
2. Create Yes/A.hs with the following code:

module Yes.A where

import Yes.B

1. Create Yes/B.hs with the following code:

module Yes.B where

1. Open a terminal in the folder that contains "Yes" and run:

$ ghc Yes/A.hs

This works fine. Now try the following:

$ cd Yes
Yes/ $ ghc A.hs

You'll be greeted with the beautiful error:

A.hs:3:8:
    Could not find module ‘Yes.B’
    Use -v to see a list of the files searched for.

A screenshot is worth the above thousand words: http://i.imgur.com/8AxRa0K.png

This is silly. Running with the -v option shows that ghc is not looking for Yes/B.hs, but Yes/Yes/B.hs. I can understand why it looks there, but not why ghc isn't just this tiny bit more intelligent in knowing where to look. After all, the module name tells ghc exactly in which subfolder it is located:

module Yes.A where -- This module is very likely to be in Yes/, because otherwise a name inconsistency error is thrown.

Proposed solution: The module name tells ghc exactly where it is located. If Yes.A imports Yes.B, then you know that they're in the same subfolder. Simple as that. Instead of ignoring that information and looking for Yes/Yes/B.hs, it should simply look for Yes/B.hs. Relative to ghc (which is run from Yes/) this would be ./B.hs.

This solution is scalable. Imagine a module Ding.Dong.Biddly.Bong that imports Ding.Dong.Doodle.Bell. Running "ghc Bong.hs" from Ding/Dong/Biddly/ should not make it look for "Ding/Dong/Biddly/Ding/Dong/Doodle/Bell.hs", but for Ding/Dong/Doodle/Bell.hs. Relative to ghc (run from Ding/Dong/Biddly/), this would be ../Doodle/Bell.hs.

So yeah, right now ghc is arbitrarily restricted to run from the root of the source directory. This looks like intended behaviour until you realise that the silly bug mentioned here is probably the only thing that prevents ghc from running from any subfolder. Of course there are the -i and :set options for ghc that allows one to work around this, but one should not be expected to jump through all the -iFile hoops to be allowed to run ghc from any arbitrary subdirectory of the source folder.

Trac metadata

Trac field	Value
Version	7.10.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture