nope, I was suggesting rather:<div>./A.hs has module A which has an import A.B line</div><div>./A/ has  B.hs with module A.B  which imports A.B.C</div><div> /C which has module A.B.C in file C.hs</div><div><br></div><div>I think this scenario  should work ....</div>

<div>-carter</div><div><div><br><br><div class="gmail_quote">On Sun, Jul 18, 2010 at 2:18 PM, Anthony Cowley <span dir="ltr">&lt;<a href="mailto:acowley@seas.upenn.edu">acowley@seas.upenn.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

On Sun, Jul 18, 2010 at 1:55 PM, Carter Schonwald<br>
<div class="im">&lt;<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>&gt; wrote:<br>
</div><div class="im">&gt; I&#39;m not sure I follow, because the toy example I&#39;m asking about does in fact<br>
&gt; use hierarchical module names...<br>
&gt; are you proposing that a reasonable workaround in my use case is to do<br>
&gt; :cd ..<br>
&gt; :r<br>
&gt; this seems like a reasonableish approach, or was there a different example<br>
&gt; you had in mind?<br>
<br>
<br>
</div>Yes, that is what I had in mind. The typical scenario for me is to be<br>
editing a file in emacs, C-c-C-l it, and have GHCi complain. I then<br>
issue a &quot;:cd ..&quot; in GHCi, and my subsequent loads are properly rooted<br>
at top of the project directory.<br>
<br>
What I was trying to describe as unwanted is for someone to take your<br>
toy example and, in the file A/B.hs have a line &quot;import B.C&quot; that is<br>
gets correctly resolved by GHC. I&#39;m not sure that you were actually<br>
suggesting this, but this kind of leniency on the part of GHC (or<br>
GHCi) would make the file B.hs fragile with respect to moving it<br>
around on disk.<br>
<font color="#888888"><br>
Anthony<br>
</font><div><div></div><div class="h5"><br>
&gt; On Sun, Jul 18, 2010 at 1:34 PM, Anthony Cowley &lt;<a href="mailto:acowley@seas.upenn.edu">acowley@seas.upenn.edu</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Sun, Jul 18, 2010 at 3:59 AM, Carter Schonwald<br>
&gt;&gt; &lt;<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt; I don&#39;t think that semantics creates the sort of ambiguity that Kevin is<br>
&gt;&gt; &gt; concerned about, and while yes there simple alternative approaches, they<br>
&gt;&gt; &gt; require whatever is starting up ghci to know what the correct directory<br>
&gt;&gt; &gt; to<br>
&gt;&gt; &gt; pass to the -i flag, and that seems a bit of a heavy weight expectation<br>
&gt;&gt;<br>
&gt;&gt; I usually use ghci&#39;s :cd command in this situation, and wouldn&#39;t want<br>
&gt;&gt; to think about changing source files depending on where they were on<br>
&gt;&gt; disk.<br>
&gt;&gt;<br>
&gt;&gt; While having to use fully hierarchical names might seem verbose, I<br>
&gt;&gt; have found it to be a very predictable mechanism that makes managing<br>
&gt;&gt; large-ish projects easier.<br>
&gt;&gt;<br>
&gt;&gt; Anthony<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; Haskell-Cafe mailing list<br>
&gt;&gt; <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
&gt;&gt; <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br></div></div>