Hi

I tried that but I guess I was too impatient to figure out what exactly haddock wants (it seemed to choke on #ifdefs), so I just used the hoogle.txt from darcs and ran it through sed.

Haddock can't cope with #ifdef's, or .lhs files - haddock-ghc will be able to (the next version), so hopefully soon you'll have less of a problem. I just use runhaskell Setup haddocck --hoogle through Cabal, and that handles preprocessing etc. Of course, taking hoogle.txt gives you the same result (thats how I got hoogle.txt) and less work :) Thanks Neil

...

If someone knows of a simple way to generate a function/type list of the standard modules, I'd love to hear about it. Generating such a list on the fly each time is probably not an option, as it would be too slow.

Using a recent version of haddock, the --hoogle flag gives you exactly what you want.

Neil: is there any documentation on the output format? i couldn't find the flag in the haddock manual, so i was surprised to see it in haddock --help; it works, though, and does seem to generate modules with implementations removed, and some declarations simplified? one problem with this is that hoogle.txt is not included with releases, nor are the library sources, so this route won't be available for most ghc users. that is why my Doc.vim, announced earlier today, extracts information somewhat tediously from the haddock html index files that are included at least with windows releases. Stephan: if your goal is intelligent, context-aware completion, that's quite ambituous for Haskell!-) you might want to reuse the more simple-minded completion and information extraction included in Doc.vim as a start, so that you can focus on the more interesting context-sensitive bits. the current version of Doc.vim allows to write out the docindex, once extracted from the haddocks, and with simple reading it back in rather than re-generation, completion seems reasonably quick. Doc.vim supports CTRL-X CTRL-U insert-mode completion by looking for matching prefixes in the docindex, including all unqualified names in the libraries. one can also separately qualify names. if you want (naive) completion based on text in imported files as well, you can tell Vim's standard insert-mode completion (CTRL-N) to follow imports, by using 'set include= ' and 'set includeexpr= '. there's an example in the by now ancient hugs.vim at http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/Vim/ to provide completion also for non-libraries identifiers, perhaps completion based on tags-files (as generated by :ctags in ghci), via CTRL-X CTRL-] , might be a good approach. those tags-file don't include type info yet, but then i'm not quite sure how you'd be able to use type info for completion in Vim (which doesn't know anything about Haskell types). ghc -e ":ctags" Main.hs ought to give you a tags file, including exported identifiers in your project, but not in the libraries. with these three completion variants, one can get by, though putting everything together and adding at least some context-sensitivity would be nice. the haddock --hoogle route has the additional issue that it will miss identifiers without type declarations. you could use ghc itself to provide identifier lists: $ ghc -e ":b Data.Char" digitToInt :: Char -> Int data Char type String = [Char] chr :: Int -> Char .. with the obvious disadvantage that you'd need to name every module. but you could get those from 'ghc-pkg describe base'. anyway, let us know about any progress with such Haskell/Vim utilities. claus ps. i'm still rehacktoring Doc.vim, adding and removing bugs and features, but don't want to bother the list with updated versions. a recent one, including functions for writing/reading docindex, can be found here: http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/Vim/Doc.vim

[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