Complete and integrate a tags and module-graph analyser using the GHC API
Norman and Kathleen started a tags-file generator based on the GHC Api. Their patch is attached (description below). It's very incomplete, which is no fault of theirs
This task is to keep track of their patch, and to encourage any enthusiasts to finish the job. Things to think about
- Norman and Kathleen had it structured as a standalone application, using the GHC Api. That makes sense, but it's awkward to put it into GHC's build tree, because there is no build-system support for "build this tool after GHC stage2 is built". Furthermore, we would not want to distribute it as a standalone binary in the GHC distribution, because (lacking shared libraries) it'd be another 10M binary!
Conclusion: either make it a completely independent repository, built with Cabal etc, or integrate it into GHC, so you can say ghc --tags
- There's an existing small tags-generation thing, invokable from GHCi only (:tags). Don't want to duplicate.
- Much of the same technology would be useful to generate other useful info. Specifically (a) module dependency graphs, (b) function dependency graphs within a module.
- Norman and Kathleen encontered performance problems, becuase they call
checkModule
on every module. That's perfectly reasonable, but it stupidly makes GHC do a full dependency analysis each time; result quadratic behaviour. This should be fixed by thinking about the GHC Api design.
Here are the patch descriptions for the attached patch
Fri Sep 15 19:50:33 EDT 2006 Norman Ramsey <nr@eecs.harvard.edu>
* initial, very incomplete tags generator
The ultimate goal is to replace hasktags with
a tags generator based on GHC-as-a-library.
This file is a very incomplete first cut.
Sat Sep 16 19:27:55 EDT 2006 Norman Ramsey <nr@eecs.harvard.edu>
* cover more cases; take GHC options on command line
Bit of a dog's breakfast here:
* generate tags for more cases in the syntax
* accept -package ghc and other args on command line
* scrub away old code for snaffling thru text
Sat Sep 16 20:23:53 EDT 2006 Norman Ramsey <nr@eecs.harvard.edu>
* tell GHC not to generate code (thanks Simon M)
Sat Sep 16 20:24:30 EDT 2006 Norman Ramsey <nr@eecs.harvard.edu>
* load all files at once and compute tags for all
Sat Sep 16 20:34:10 EDT 2006 Norman Ramsey <nr@eecs.harvard.edu>
* do notation for the Maybe monad
Sat Sep 16 21:15:29 EDT 2006 Norman Ramsey <nr@eecs.harvard.edu>
* desperate attempts to handle the GHC build
What's happening here is a series of attempts to successfully swallow
what the GHC build process chooses to throw at the tool. I'm clearly
out of my depth and so will revert to trying one module at a time.
Sat Sep 16 21:54:51 EDT 2006 Norman Ramsey <nr@eecs.harvard.edu>
* if the whole group fails, try one file at a time
Sat Sep 16 21:55:39 EDT 2006 Norman Ramsey <nr@eecs.harvard.edu>
* get names of data constructors
Sun Sep 17 01:08:00 EDT 2006 Norman Ramsey <nr@eecs.harvard.edu>
* change representation of FoundThing
refactored FoundThing to use GHC's native representation of
source-code locations and to carry the module name so that the TAGS
file can contain a qualified name as well as the unqualified name
Sun Sep 17 01:30:46 EDT 2006 Norman Ramsey <nr@eecs.harvard.edu>
* refactoring for more readable source code
Wed Sep 20 00:26:07 EDT 2006 Norman Ramsey <nr@eecs.harvard.edu>
* working 'ghctags' Makefile target (requires stage=2)
Wed Sep 20 00:27:57 EDT 2006 Norman Ramsey <nr@eecs.harvard.edu>
* first cut at missing case for ids defined in pattern
Wed Sep 20 00:28:39 EDT 2006 Norman Ramsey <nr@eecs.harvard.edu>
* proper HC entry for bootstrapping in Makefile
Wed Sep 20 00:29:13 EDT 2006 Norman Ramsey <nr@eecs.harvard.edu>
* correct minor spelling error s/patterng/pattern/
Fri Oct 13 16:27:56 EDT 2006 nr@eecs.harvard.edu
* new README file for utils/ghctags
Fri Oct 13 16:28:25 EDT 2006 nr@eecs.harvard.edu
* accomodate changes in the GHC API
Fri Oct 13 16:29:22 EDT 2006 nr@eecs.harvard.edu
* request for documentation of a new argument