[Haskell-cafe] which tags program should I use?

[Claus Reinke]

>> suggests using :etags in GHCI or hasktags, or gasbag.  Of the three,
>> hasktags comes closest to "working" but it has (for me) a major
>> inconvenience, namely it finds both function definitions and type
>> signatures, resulting in two TAGS entries such as:

Some customization required? Tweaking the output format is
usually the easiest part of a tags file generator. Alternatively, add
information about the kind of tag, have both tags in the tags file,
and do a little filtering on the editor side (in Vim, try ":help 
taglist()"),
so that you can go to the type or value level definition with different
key combinations.

> I'm also a user of the one true editor (namely vim ;) and I'd be
> interested in an answer to that too.  Every once and a while I go look
> at the various tag programs to see if there's anything that works
> better than hasktags.  The continuing proliferation of tags programs
> implies that others are also not satisfied with what's out there, but
> no one is devoted enough to the cause to devote the effort to make the
> One True Tags program.

Some notes from someone who has written his share of tags file
generators:

1. there are trade-offs to consider: fast or detailed? incremental (file by
    file) or tackle a whole project at once? should it work on syntactically
    incorrect code (regexes, parsing, or parsing with recovery)? how much
    detail can your editor handle, without requiring extra scripting (emacs
    tags files can't hold as much info as vim tags files can - the latter 
are
    extensible; but to make use of that extra info, scripting is required)?

2. once you reach the borders of what quick and dirty tags generators
    can do, things get interesting: haskell-src-exts makes it quite simple
    to generate top-level tags with proper parsing, if the file can be 
parsed;
    GHCi knew about top-level definitions anyway, so it was easy to output
    that as a tags file; but what if the file cannot be parsed? what if the
    import hasn't got any source (not untypical in the world of GHC/Cabal)?
    do the interface files of the binary modules have source location info??
    how to handle GHC/Cabal projects, not just collections of files?

3. what about local definitions? what about non-exported top-level
    definitions? Here the editors get into difficulties handling too many
    tags without distinguishing features. As it happens, I've recently
    released support for (lexically) scoped tags in Vim, with a generator
    for Javascript source:

    http://libraryinstitute.wordpress.com/2011/09/16/scoped-tags-support-for-javascript-in-vim/

    I'd love to see a scoped tags generator for Haskell (the scoped
    tags format is language independent, and the Vim script support
    could be reused), but that would double the size and complexity
    of a simple parsing tags generator (beyond traversing top-level
    definitions: traversing expressions, handling Haskell's complex
    scopes) or require additional code for a GHCi-based generator
    (of course, a regex-based generator would fail here); also, the
    Haskell frontend used would need to record accurate source spans;

    I'd also like to see type info associated with scoped tags, for
    presentation as editor tooltips, at which stage the air is getting
    thin - parsing alone doesn't suffice, so you need parsing,
    type-checking, and generic scope-tracking traversals of typed
    ASTs, with embedded source span info; perhaps an application
    of scion, but by then you're beyond simple; and all that power
    comes at a price of complexity, speed and brittleness: no tags
    if parsing or typing fails, where the latter requires reading
    interface files, or handling whole projects instead of isolated files..

Perhaps combining a quick and dirty incremental tags generator
with a detailed and sound full-project generator could do the trick?

Or, you could drop the tags file generation and treat the detailed
and sound full-project analyzer as a server which your IDE/editor
could ask for info about code, while reloading only those files that
change (as if the language query server was a programmed GHCi
session running in the background). Which seemed to be the
direction scion was heading in..

    https://github.com/nominolo/scion

Tags files are a nice interface between language-aware generators
and general purpose editors/IDEs, but they are limited. I still think
it is worth using them, in extended form, but if your editor doesn't
make such extension easy, or if you want to leverage the complex
language frontend for other purposes, switching from offline
tags file generators to online language query servers makes sense
(even back in the C days there were both ctags and cscope).

I hope this helps to explain why there is no One True Tags program?

Claus
http://clausreinke.github.com/