cabal should be able to use the index file to find a module's package; find functions in packages

[cheater]

I propose a facility to find packages if you know modules.

Use case: quite often you want to check out some Haskell code without actually installing it or all of its dependencies. If you have all the dependencies, ghc-pkg find-module pretty much does the job. However, quite often this isn't the case.

If it were possible to find a module's package, I could, for example, create a command in my editor which - when a function is highlighted - displays the current documentation for it on Hackage. For example, in Vim you could press K and you'd be presented with a lynx session which displays the help for that function. This makes development and learning about code much faster and prevents the user from losing focus because he has to navigate to the documentation. Hackage looks really good in lynx which is a plus - even better than most man pages.

I do not believe this belongs in ghc-pkg because it needs to robustly support packages that are not installed.

A proposed interface would be:

$ cabal find-module Control.Lens lens

Additionally, one might want to find modules only in the current cabal package. So if you are editing code which is part of a cabal package, you could do:

$ cabal find-module --package Control.Lens lens-3.1

This would find the package that would be installed given the .cabal file. This would be very good because linking to the latest documentation could be misleading - docs change a lot with versions of the libraries being installed.

It would make lives much easier if you could also find functions:

$ cabal find-function alongside lens: Control.Lens.Type

and similarly in a package's dependencies:

$ cabal find-function --package lens lens-3.2: Control.Lens.Type

It is necessary because depending on the version of the package the function might be in a different module or the module might have a different name.

I cannot begin to describe how much easier this would be than having to go to hoogle or hackage, type in the necessary search strings, look over the results, and figure out what comes from where.

Not even using lambdabot comes close to being able to script such a tool via the command line and get documentation with one keystroke.

I'm curious as to what everyone thinks about this idea.

Thanks!

[23Skidoo]

Do you know about Hoogle?

[cheater]

Sure. However it is not conclusive and inexact:

$ hoogle Control.Lens package lens package lens-family package lens-family-core package lens-family-th package lenses package aeson-lens package data-lens package data-lens-fd package data-lens-ixset package data-lens-template package edit-lenses package edit-lenses-demo package partial-lens package pointless-lenses package time-lens

And only works for installed packages:

$ hoogle alongside No results found

Plus, it's not aware of .cabal files.

As a workaround, I was going to scrape the online version of Hoogle for now. This is however not a great way to do things.

[UnkindPartition]

I like the idea, but does it have to belong to Cabal/cabal-install?

Why can't you do this as a separate program using Cabal-the-library?

[cheater]

cabal is the program for querying information about packages and their contents; it seems natural for it to fit in here.

[tibbe]

I think we should write a separate tool and then integrate it with cabal, just like we do with Haddock. Here's an outline of how I think it should work:

• Compile code using the GHC API to get an AST.
• Walk the AST an find all names (i.e. identifiers) and output a file containing all of these, with metadata (e.g. source location and type).
• Take one or more files of names with metadata and build a reverse index.

That way we can write an exact search engine for Haskell code that can answer queries such as "give me all call sites of Data.Map.insert" and give an exact answer even if the call sites don't mention insert qualified (this relies on the name resolution GHC does for us when creating the AST).

[cheater]

That sounds like a plan. But would this information be hosted by Hackage? This is important because otherwise it's impossible to find most things. Then, cabal could just present this precompiled information.

[23Skidoo]

@cheater Doesn't Hayoo already provide what you want? Try searching for alongside and Control.Lens on Hayoo.

[UnkindPartition]

@tibbe I actually am working on much of what you describe — only based on the Haskell Suite instead of the GHC API.

Right now I'm working on integrating that with Cabal — should be ready in a week or two.

So if any of you guys want to take part in that, please get in touch.

[UnkindPartition]

@cheater and yes, I hope to make that information eventually distributable from Hackage.

[cheater]

Yes and no. On one hand it has an API (which I didn't know about until now) which allows you to make the queries I spoke about that are agnostic to the .cabal, on the other hand it cannot be instructed to process a .cabal file and spit out results based on that. Maybe I should talk to the Hayoo guys about including something like this? Sounds like a good idea...

Thanks for reminding me of the Hayoo API. It solves my immediate need and allows me to progress with my project. You guys are great.

Feel free to close the issue as solved.

[cheater]

@feuerbach how is that different from Hayoo? I know nothing about your project but the Hayoo JSON api is pretty much what I need except for constraints taken from .cabal files.

[UnkindPartition]

@cheater I think I'm doing something more general than Hayoo (but, like you, I wasn't aware of its API). If it suits your needs, go for it.

[cheater]

How would you compare? Can you give some examples?

[23Skidoo]

Closing this ticket since there appears to be a consensus that this functionality should be implemented as a separate tool (or a patch for Hoogle or Hayoo).

[UnkindPartition]

@cheater I'll blog about it when it's more or less ready, but if you want more details right now, just drop me a mail.