[GHC] #10643: GHC cannot import submodules when run from subfolder

15 Jul 2015

      #10643: GHC cannot import submodules when run from subfolder
-------------------------------------+-------------------------------------
              Reporter:  FPtje       |             Owner:
                  Type:  bug         |            Status:  new
              Priority:  normal      |         Milestone:
             Component:  Compiler    |           Version:  7.10.1
              Keywords:  subfolder   |  Operating System:  Unknown/Multiple
  import submodule cd                |   Type of failure:  GHC rejects
          Architecture:              |  valid program
  Unknown/Multiple                   |        Blocked By:
             Test Case:              |   Related Tickets:
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------
 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:
 {{{#!hs
 module Yes.A where

 import Yes.B
 }}}

 3. Create Yes/B.hs with the following code:
 {{{#!hs
 module Yes.B where
 }}}

 4. 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:

 {{{#!hs
 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.

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10643
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler