<meta charset="utf-8">Hrm... my example also makes ghc flub too I think... (its been a long day).<div><br></div><div>is there anything implicitly going on behind this behavior that couldn&#39;t be resolved by eg having the reasonable heuristic that for a module named <b>(Prefix ...).Name</b> in file <b>Name</b>, any import of the form<b> (Prefix ...).Blah</b> that isn&#39;t a registered module should be searched for relative to the directory containing the file <b>Name</b>? Ie, given a module A.B in directory A, the prefix would be A, and thus we are looking for a module B.C relative to the offset of  Directory A/. This doesn&#39;t seem to be create any ambiguity, it just more intelligently uses explicitly available in the source information. </div>

<div><br></div><div>I don&#39;t think that semantics creates the sort of ambiguity that Kevin is concerned about, and while yes there simple alternative approaches, they require whatever is starting up ghci to know what the correct directory to pass to the -i flag, and that seems a bit of a heavy weight expectation for anything  that can&#39;t apriori  parse haskell modules (which would seem ironic considering such tools typically use ghc&#39;s libraries for that task!)</div>

<div><b><br></b></div><br><div class="gmail_quote">On Sun, Jul 18, 2010 at 3:22 AM, Kevin Quick <span dir="ltr">&lt;<a href="mailto:quick@sparq.org">quick@sparq.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div></div><div class="h5">On Sat, 17 Jul 2010 22:45:57 -0700, Ivan Lazar Miljenovic &lt;<a href="mailto:ivan.miljenovic@gmail.com" target="_blank">ivan.miljenovic@gmail.com</a>&gt; wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Carter Schonwald &lt;<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>&gt; writes:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello All, I&#39;m not sure if this either a bug in how ghc does path/module<br>
lookup or  it simply is invalid haskell:<br>
<br>
<br>
consider modules A, A.B and A.B.C<br>
where  A imports A.B, and A.B imports A.B.C<br>
with the following file system layout<br>
<br>
A.hs<br>
A/B.hs<br>
A/B/C.hs<br>
<br>
minimal file examples:<br>
module A where<br>
import A.B<br>
 testA = &quot;will it really really work?<br>
------------<br>
module A.B where<br>
import A.B.C<br>
 testB = &quot;will it work<br>
-----------------<br>
module A.B.C where<br>
testC = &quot;will this work?&quot;<br>
----------<br>
if i run ghci A.hs everything&#39;s fine<br>
but if in directory B i rune ghci B.hs,  i get<br>
A/B.hs:2:8:<br>
    Could not find module `A.B.C&#39;:<br>
      Use -v to see a list of the files searched for.<br>
<br>
-----------<br>
it seems to me that if the default search path for ghc(i) includes the<br>
current directory (which according to docs it does), this shouldn&#39;t be<br>
happening.  (or is there some why this is good Behavior?)<br>
</blockquote>
<br>
I think ghci is just not smart enough to know that it should change to<br>
the parent directory and run it from there.  As such, it&#39;s trying to<br>
find &quot;A.B.C&quot; from the context of the current directory, and the file is<br>
not in A/A/B/C.hs so it can&#39;t find it.<br>
<br>
So it&#39;s just a limitation of ghci (I think).<br>
</blockquote>
<br></div></div>
I&#39;m afraid I disagree and would view this as expected behavior.<br>
<br>
&quot;import A.B.C&quot; translates internally to something like load_file_using_paths(&quot;A/B/C.hs&quot;).<br>
<br>
When you are running this from the top level directory (e.g. &quot;top&quot;), ghci includes the current path &quot;top&quot; so the lookup is for &quot;top/A/B/C.hs&quot;, which clearly exists.<br>
<br>
When you are in directory B, ghci includes the current path &quot;top/A/B&quot; so the lookup is for &quot;top/A/B/A/B/C.hs&quot;... which does not exist, thus your error.<br>
<br>
Your example would require ghci to try load_file_using_paths(&quot;B/C.hs&quot;) (and then load_file_using_paths(&quot;C.hs&quot;) to be complete), which discards the directory heirarchy specified by the module nomenclature.  This is not adviseable because it introduces ambiguities.  For example, if you also had a C.hs in A and another C.hs in A/B, which C.hs should it load when you say &quot;import A.B.C&quot;?  Or &quot;import C&quot;? If ghc/ghci discarded paths, then the results would be either (1) a different C.hs depending on your current directory, (2) the bottom-most C.hs, (3) the C.hs in the current directory, (4) random?.  Worse, any of the above results in a trojan-horse style security hole.  Also, what if there was a C.hs in the directory above you (top/..)?  A 1:1 mapping between module heirarchy specification and directory paths is the only dependable mechanism.<br>


<br>
The better solution is to specifically set the paths you expect to form the roots of the (non-default) module heirarchy if you plan to work from within subdirectories of your source tree.  If you invoked ghci as &quot;$ ghci -i /path/to/top&quot; then it would work regardless of your current directory.  I believe that this is the proper solution to <a href="http://hackage.haskell.org/trac/ghc/ticket/3140" target="_blank">http://hackage.haskell.org/trac/ghc/ticket/3140</a> as well.<br>


<br>
-KQ<br>
<br>
-- <br><font color="#888888">
-KQ<br>
</font></blockquote></div><br>