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

GHC ghc-devs at haskell.org
Thu Jul 16 10:46:48 UTC 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
      Resolution:                    |                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:
-------------------------------------+-------------------------------------

Comment (by svenpanne):

 I think the current behavior is not silly at all, and the proposed
 solution will very probably lead to confusion in non-trivial settings:
 Assume that you have the following directory/file structure:

   Foo/Yes/A.hs
   Bar/Yes/B.hs

 with the same contents as in the OP. GHC(i) can happily load this if you
 set the right import paths and give the module name, not the file name:

 {{{
 $ ghci -iFoo:Bar Yes.A
 GHCi, version 7.10.1.20150630: http://www.haskell.org/ghc/  :? for help
 [1 of 2] Compiling Yes.B            ( Bar/Yes/B.hs, interpreted )
 [2 of 2] Compiling Yes.A            ( Foo/Yes/A.hs, interpreted )
 Ok, modules loaded: Yes.A, Yes.B.
 }}}

 So the assumption that a module name tells GHC exactly the location of the
 subfolder is wrong, the import path effectively overlays several
 directories. This is standard behavior for lots of compilers/interpreters
 which is needed for more complicated projects, and I don't think we should
 change that. As it is, it is already complicated enough, putting some
 "clever" magic into GHC just to avoid a single commandline option is not
 the way to go.

 How does your proposal interact with the import path? How can one avoid
 accidentally finding the wrong module? Should filenames on the commandline
 be handled differently from module names? IMHO the answers to these
 questions are far from obvious and the potential gain (saving a single
 commandline flag) doesn't outweigh the introduced complexity.

 P.S.: What do you mean by "name inconsistency error"?

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10643#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list