darcs patch: initial, very incomplete tags generator (and 16 more)

Claus Reinke claus.reinke at talk21.com
Sun Oct 15 07:41:24 EDT 2006

> > http://haskell.org/ghc/docs/6.6/html/users_guide/ghci-commands.html
> Doco suggests that this code is just calling hasktags. 

not at all, it is built in to ghci. though I can see that the docs may be 
somewhat misleading, due to the reference to Section 10.1, which 
doesn't mention the built-in functionality.. but that reference is only
there because of limitations of the current ghci version (all modules
must be interpreted, no direct commandline tool to replace that
old hasktags). 

I was sort of hoping you were working on extending that existing
functionality, and moving it out of the ghci code itself - given that
ghci and "ghc --make" are ideally just two clients of the ghc API,
it would make sense to have the tags code in a separate module,
and just call on it from within ghci, ghc, and perhaps ghctags.

Instead of fiddling with separate makefiles, I'd prefer options to 
ghc, so that I could say "ghc --make -ctags", just as I can say,
in ghci ":ctags". Of course, there are at least two use cases:
code browsing, when one just wants the tags, no building, and
code development, when one wants to build and keep the tags
up to date.

> How would I know for sure?

It's been hiding in the sources for a long time, so perhaps most
folks have missed it - the relevant posts were


I seem to recall that Simon did quite a bit of cleaning up of
my initial attempts before committing (and later renamed the
command to :ctags/:etags, to avoid abbreviation conflict with 
:type), but it hasn't seen any further work since (so it is great 
to have you look into things!-). the current state can be found 
in ghc/compiler/ghci/InteractiveUI.hs (search for "tags").


> > Norman: adding a standalone-tool will be nice, but I hope
> >     that ghctags and :[ce]tags are using the same codebase,
> >     providing the same functionality with different user-level
> >     frontends?
> Once I can get stuff working, I'll see about coupling it into ghci.
> But at present performance troubles make it unusable.
> Norman
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

More information about the Glasgow-haskell-users mailing list