darcs patch: FIX #1463 (implement 'ghc-pkg find-module')

[Claus Reinke]

> Nice. So I suppose the --simple-output flag works with it?

yes, it is just like 'list package', only it matches on 
exposedModules rather than package id.

note: if you apply the patch, you will want to add find-module 
to 'usageHeader' as well - seems i missed that.
 
> The solution we were thinking of for cabal though would be for Cabal to
> ask ghc-pkg for all of its information and then Cabal can perform
> whatever queries it needs rather than making lots of calls to ghc-pkg.
> http://hackage.haskell.org/trac/ghc/ticket/1839
> Ticket #1839 (need ghc-pkg dump feature)

what you're really saying is that you'd like to relegate ghc-pkg
to a format conversion and do all the work in cabal. is it then
still sensible to have two separate tools, or should cabal take
over completely?
 
> As you suggest it would be great for Cabal to tell you that you're
> missing package dependencies rather than letting ghc stumble over the
> problem with a correspondingly more confusing error message. Indeed we
> could do nice things like building without needing a .cabal file or
> automatically generating a minimal .cabal file by inspecting local files
> and the package dbs.
> http://hackage.haskell.org/trac/hackage/ticket/171
> Ticket #171 (Add command to automagically create an initial cabal
> package)

we had a discussion about ghci vs cabal a while back:

http://www.haskell.org/pipermail/glasgow-haskell-users/2006-November/011554.html

and the topic keeps coming up in different contexts:

http://www.haskell.org/pipermail/glasgow-haskell-users/2007-February/012035.html

it took me a while to find these two again - perhaps your
cabal ticket is the place to keep these urls?

in current ghc head, there are several related ghci commands:

    - ':show modules' (currently loaded modules)
    - ':show packages' (package options + packages loaded)
    - ':set' (now shows dynamic flag settings)

so you could load your main module into ghci, let it figure out
the module dependencies and packages, and use those 
commands to contribute to an initial cabal file. you'd still need
to eliminate non-exposed modules and implicit dependencies
in packages, as well as flags that are at default settings.

that leaves other settings, like paths, which brings us back
to the earlier question and emails: 

    for any non-trivial project depending on non-standard
    settings, shouldn't ghci work from a cabal file, or ghci
    be started by cabal, or ghci and cabal collaborate, to 
    record those settings from the start and uniformly? 

it makes no sense to re-enter .cabal settings in ghci just 
because it can't load .cabal files, and it makes no sense
to write .cabal files from scratch when you've already
constructed a workable ghci session for your project.

the solution i've in mind is something like the ability
to import and export ghci sessions as .cabal files.

enabling ghci to explain all its session settings is one
way to get there, and since ghci is currently my main
interface to haskell code, i tend to add to that path. i
just patched ghc-pkg because it seemed sensible and
simple, but i also have a patch to make ':info <module>'
work in ghci.

do you have a specification of what cabal needs from 
an implementation, how it would like to query for that
information, and an idea of how ghc, hugs, nhc, etc. 
would implement that spec? 

for ghc, one might be tempted to ask for an augmented 
-M, but the prevalence of hugs and ghci seems to suggest 
an "import/export session as .cabal" route as necessary,
if not sufficient. then there's nhc, which left dependency 
chasing to a separate nhc-make tool (wasn't that one 
of the starting points for cabal?), and i don't know about 
the other implementations.

claus