Re: ghci finding include files exported from other packages?

2009-03-17 Thread Simon Marlow
Duncan Coutts wrote: On Mon, 2009-03-16 at 12:13 +, Simon Marlow wrote: This sounds like a chicken and egg problem. To know which package include directories to use GHCi needs to know which packages your module uses. However to work out which packages it needs it has to load the module

Re: ghci finding include files exported from other packages?

2009-03-17 Thread Duncan Coutts
On Tue, 2009-03-17 at 08:53 +, Simon Marlow wrote: Duncan Coutts wrote: On Mon, 2009-03-16 at 12:13 +, Simon Marlow wrote: Yes, if we know we're using it. If we specify -package blah on the command line then we do know we're using it and everything works (because ghc uses the

Re: ghci finding include files exported from other packages?

2009-03-16 Thread Simon Marlow
Duncan Coutts wrote: On Sat, 2009-03-14 at 23:43 -0700, Conal Elliott wrote: The applicative-numbers package [1] provides an include file. With ghci, the include file isn't being found, though with cabal+ghc it is found. My test source is just two lines: {-# LANGUAGE CPP #-} #include

Re: ghci finding include files exported from other packages?

2009-03-16 Thread Duncan Coutts
On Mon, 2009-03-16 at 12:13 +, Simon Marlow wrote: This sounds like a chicken and egg problem. To know which package include directories to use GHCi needs to know which packages your module uses. However to work out which packages it needs it has to load the module which means

Re: ghci finding include files exported from other packages?

2009-03-16 Thread Conal Elliott
On Mon, Mar 16, 2009 at 2:47 PM, Duncan Coutts duncan.cou...@worc.ox.ac.ukwrote: On Mon, 2009-03-16 at 12:13 +, Simon Marlow wrote: This sounds like a chicken and egg problem. To know which package include directories to use GHCi needs to know which packages your module uses.

Re: ghci finding include files exported from other packages?

2009-03-16 Thread Duncan Coutts
On Mon, 2009-03-16 at 16:04 -0700, Conal Elliott wrote: On Mon, Mar 16, 2009 at 2:47 PM, Duncan Coutts duncan.cou...@worc.ox.ac.uk wrote: On Mon, 2009-03-16 at 12:13 +, Simon Marlow wrote: Perhaps I'm missing something, but if applicative-numbers is an exposed

ghci finding include files exported from other packages?

2009-03-15 Thread Conal Elliott
The applicative-numbers package [1] provides an include file. With ghci, the include file isn't being found, though with cabal+ghc it is found. My test source is just two lines: {-# LANGUAGE CPP #-} #include ApplicativeNumeric-inc.hs I'd sure appreciate it if someone could take a look at the

Re: ghci finding include files exported from other packages?

2009-03-15 Thread Duncan Coutts
On Sat, 2009-03-14 at 23:43 -0700, Conal Elliott wrote: The applicative-numbers package [1] provides an include file. With ghci, the include file isn't being found, though with cabal+ghc it is found. My test source is just two lines: {-# LANGUAGE CPP #-} #include

Re: ghci finding include files exported from other packages?

2009-03-15 Thread Conal Elliott
That did it. I've added :set -package applicative-numbers to my .ghci and am back in business. Thanks! IIUC, there's an inconsistency in ghci's treatment of modules vs include files, in that modules will be found without -package, but include files won't. Room for improvement, perhaps. -

Re: ghci finding include files exported from other packages?

2009-03-15 Thread Duncan Coutts
On Sun, 2009-03-15 at 09:13 -0700, Conal Elliott wrote: That did it. I've added :set -package applicative-numbers to my .ghci and am back in business. Thanks! IIUC, there's an inconsistency in ghci's treatment of modules vs include files, in that modules will be found without -package, but

Re: ghci finding include files exported from other packages?

2009-03-15 Thread Conal Elliott
Thanks for the clarification, Duncan. Seems an easy partial solution would be a single pass (before CPP) that notices just the #include directives. Consult the package database to find those packages. That route would find direct includes but not indirect ones. An optional and still-easy next