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. - Conal On Sun, Mar 15, 2009 at 5:27 AM, 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 "ApplicativeNumeric-inc.hs"

I'd sure appreciate it if someone could take a look at the .cabal file [2] and tell me if I'm doing something wrong. And/or point me to one or more working examples of cabal packages that export include files that are then findable via ghci.

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 pre-processing it!

With cabal we get round this problem because Cabal calls ghc with -package this -package that etc and so when ghc cpp's the module it does know which package include directories to look in.

So if you did ghci -package applicative-numbers then it should work. I'm afraid I don't have any good suggestion for how to make it work with ghci without having to specify any options at all.

Duncan

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 step would be to look inside those includes for further #include directives. I'm unsure whether the cabal solution is as powerful as the single-level include method or the recursive one. - Conal On Sun, Mar 15, 2009 at 2:34 PM, Duncan Coutts wrote:

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 include files won't. Room for improvement, perhaps.

But that's because of the circularity I described. GHC can chase Haskell imports because it can parse Haskell, but chasing CPP #includes would require us to re-implement cpp. Perhaps we could do it by modifying cpphs.

Duncan

On Mon, 2009-03-16 at 12:13 +0000, 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 pre-processing it!

With cabal we get round this problem because Cabal calls ghc with -package this -package that etc and so when ghc cpp's the module it does know which package include directories to look in.

Perhaps I'm missing something, but if applicative-numbers is an exposed package, shouldn't we be adding its include-dirs when invoking CPP?

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 include-dirs when it calls cpp). If we don't specify -package then ghc does not know we need the package until after import chasing is done. Import chasing requires that we run cpp on the .hs file first and that brings us full circle. Duncan

On Mon, 2009-03-16 at 16:04 -0700, Conal Elliott wrote:

On Mon, Mar 16, 2009 at 2:47 PM, Duncan Coutts wrote: On Mon, 2009-03-16 at 12:13 +0000, Simon Marlow wrote:

> Perhaps I'm missing something, but if applicative-numbers is an exposed > package, shouldn't we be adding its include-dirs when invoking CPP?

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 include-dirs when it calls cpp). If we don't specify -package then ghc does not know we need the package until after import chasing is done. Import chasing requires that we run cpp on the .hs file first and that brings us full circle.

Duncan

Unless you drop the cpp-first requirement and have import-chasing look into #include'd files, as I described earlier. - Conal

Yes, that's what I said earlier about re-implementing cpp, possibly via cpphs. That would let you chase #includes and assuming you know which packages provide which include files then we could work out which packages are needed for cpp-ing. Or you could play it fast and loose and assume that you can usually ignore # cpp lines and still work out what the Haskell imports are most of the time. That's not correct but is probably easier and would probably work most of the time. Neither approach is easy or very nice. Duncan

On Tue, 2009-03-17 at 08:53 +0000, Simon Marlow wrote:

Duncan Coutts wrote:

...

On Mon, 2009-03-16 at 12:13 +0000, 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 include-dirs when it calls cpp). If we don't specify -package then ghc does not know we need the package until after import chasing is done. Import chasing requires that we run cpp on the .hs file first and that brings us full circle.

I don't see a reason why we shouldn't pass *all* the include paths for the exposed packages to CPP. Indeed that's what I thought we did, but I've just checked and I see we don't. Wouldn't that fix Conal's problem?

Yes it probably would. On my system that'd only be between 25-50 include directories, which I guess is not too bad. Lets hope not too many packages decide they need a "config.h" file. So, presumably by passing all include dirs for all exposed packages that takes into account -package flags, so when Cabal does -hide-all-packages then it gets its desired behaviour. Duncan