feature request: indexing Haskell projects (Re: [Haskell-cafe] auto-completion for Vim 7)

[Claus Reinke]

[feature request near the end]

Hi Neil,

> Documentation isn't my strong point :) 

i noticed that you often reply to feature requests by pointing to undocumented
tools/features, either already released in secret, or forthcoming. not that it isn't
nice to have those tools, but won't you lose track of your software and its 
capabilities at this rate (not to talk about your customers' confusion)?-)

>It was originally only intended to be an internal thing for Hoogle, but it does 
>seem generally useful.

in spite of the option name, it doesn't seem Hoogle-specific at all, nor does
it really fall into the remit of Haddock as annotation processor. i used to think
that type info and such could be added to tags-files, but that is also not quite
right - tags files can be extended with such info, but they have no room for 
tags without source code reference.

Haddock-ghc might be equipped to provide the information, but do we really
want it to become a general information extractor? perhaps this kind of index
generation should really be a feature of the Haskell implementation itself; and
indeed, there are :browse and :info already. how about an :index command?

> You can always download hoogle.txt, or perhaps we could supply
> summary.txt with the HTML output as the documentation? The GHC people
> would have to be the ones to decide it - Hugs doesn't ship with
> documentation anyway.

separate downloads go out of sync, so tools should be able to rely on info
included with releases. as for documentation: one of the nicest features of
windows GHC releases is the inclusion of html docs - i use that all the time.

of course, Hugs comes with sources instead of docs, so when Hugs was still 
my main platform, :find was one of my favourite features.
 
> My experience with parsing haddock generated HTML is that its painful,
> and usually wrong. The indexes might be a bit clearer, but parsing out
> the type signatures and names was a nightmare.

yes, it is a hack. and it is more pattern-based extraction than proper parsing.

> ghc-haddock will fix that. Extracting names from the index will also
> miss those without type signatures.

for the libraries, anything not documented doesn't exist!-) but yes, until it
is integrated with GHC, Haddock will not produce complete indices. which
brings me back to my point that GHC(i) should produce those indices itself.
 
>>     $ ghc -e ":b Data.Char"
> I experimented with this as the means for getting information for
> Hoogle. It was fine, apart from extracting instances (you needed the
> instance and the type both to be in scope, which you can't really do,
> or the instance is missed). 

yes, if one wants instances, one could use :info <class>, but doing that
automatically for every class becomes tedious quickly. also, the pretty
printing really gets in the way of simple-minded post-processing. Hugs 
used to have a :browse all, but i don't recall what all meant there.

so here is a feature request for Haskell implementations: in addition to
:browse, :info, :[ce]tags, i'd like to see :index, as a way to dump the
symbol table for a Haskell project and libraries (including those not
available in source code). the output should include, for every available
item:

    - identifier (unqualified name/symbol)
    - qualifier (module prefix)
    - namespace (function/data constructor, type/constructor, class, module,..)
    - type
    - package
    - source reference relative to package top
    - doc reference relative to package doc top

all in an easy-to-process-by-various-tools format (think ide/editor, not
usually written in Haskell itself), please?-)

thanks,
claus