On Sun, 18 Jul 2010 12:02:39 -0700, Carter Schonwald
carter.schonw...@gmail.com wrote:
nope, I was suggesting rather:
./A.hs has module A which has an import A.B line
./A/ has B.hs with module A.B which imports A.B.C
/C which has module A.B.C in file C.hs
I think this scenario should work
Ivan Lazar Miljenovic wrote:
I think ghci is just not smart enough to know that it should change to
the parent directory and run it from there. As such, it's trying to
find A.B.C from the context of the current directory, and the file is
not in A/A/B/C.hs so it can't find it.
So it's just a
On Sat, 17 Jul 2010 22:45:57 -0700, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
Carter Schonwald carter.schonw...@gmail.com writes:
Hello All, I'm not sure if this either a bug in how ghc does path/module
lookup or it simply is invalid haskell:
consider modules A, A.B and A.B.C
Hrm... my example also makes ghc flub too I think... (its been a long day).
is there anything implicitly going on behind this behavior that couldn't be
resolved by eg having the reasonable heuristic that for a module named *(Prefix
...).Name* in file *Name*, any import of the form* (Prefix
On Sun, Jul 18, 2010 at 3:59 AM, Carter Schonwald
carter.schonw...@gmail.com wrote:
I don'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
I'm not sure I follow, because the toy example I'm asking about does in fact
use hierarchical module names...
are you proposing that a reasonable workaround in my use case is to do
:cd ..
:r
this seems like a reasonableish approach, or was there a different example
you had in mind?
On Sun, Jul
On Sun, Jul 18, 2010 at 1:55 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
I'm not sure I follow, because the toy example I'm asking about does in fact
use hierarchical module names...
are you proposing that a reasonable workaround in my use case is to do
:cd ..
:r
this seems like a
nope, I was suggesting rather:
./A.hs has module A which has an import A.B line
./A/ has B.hs with module A.B which imports A.B.C
/C which has module A.B.C in file C.hs
I think this scenario should work
-carter
On Sun, Jul 18, 2010 at 2:18 PM, Anthony Cowley
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/18/10 14:18 , Anthony Cowley wrote:
On Sun, Jul 18, 2010 at 1:55 PM, Carter Schonwald
carter.schonw...@gmail.com wrote:
are you proposing that a reasonable workaround in my use case is to do
:cd ..
:r
this seems like a reasonableish
begin Brandon S Allbery KF8NH quotation:
The fundamental problem is that ghci has no concept of projects. The
correct place for this is in Cabal, which *does* have project support, but
as yet it has no support for ghci. It's conceivable that the ghci user
commands capability could be used to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/18/10 16:10 , Mike Dillon wrote:
Not sure if anyone mentioned this possibility elsewhere in the thread,
but I was thinking that having a cabal console command would be a nice
way to handle this. Cabal would parse the *.cabal file and invoke
Hello All, I'm not sure if this either a bug in how ghc does path/module
lookup or it simply is invalid haskell:
consider modules A, A.B and A.B.C
where A imports A.B, and A.B imports A.B.C
with the following file system layout
A.hs
A/B.hs
A/B/C.hs
minimal file examples:
module A where
Carter Schonwald carter.schonw...@gmail.com writes:
Hello All, I'm not sure if this either a bug in how ghc does path/module
lookup or it simply is invalid haskell:
consider modules A, A.B and A.B.C
where A imports A.B, and A.B imports A.B.C
with the following file system layout
A.hs
13 matches
Mail list logo
