[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