Robby Findler wrote:
So, I've heard various people saying it would be nice to have a
separate api for check syntax (and presumably the module browser)
pulled out of DrScheme. I definitely agree with that, but I'm
wondering how to prioritize it. Does anyone have some specific use in
mind for the api?
(My wishlist for the next decade of Christmases follows. Feel free to
focus on just the first part, since that's the part that your message
actually asked about.)
I envision two APIs. One handles source code analysis, possibly
including expansion, builds def-use relations, etc. The other handles
annotations to code in editors, allows adding mouseover callbacks to
regions of code, adding right-click menu items, etc.
Some client programs of the first API:
- Find useless definitions: names neither referenced as a variable,
referenced within a syntax template, nor provided.
- Given a collection of modules, find names defined but not referenced
within the collection.
- Find useless 'require' forms.
- Given an expression, find the locally-bound free variables (cf
lambda-lifting).
- Find provided names that don't have Scribble docs.
- Given a module, find decompositions of the module into submodules.
Some client programs of the second API:
- Visualizations of the analyses above.
- Typed Scheme could pop up type information in places where it is
currently implicit: eg, let-bound variables, when the mouse goes over
the variable name.
- The parser-tools 'parser' macro could offer to show the FIRST set of
a nonterminal name as a context-menu command, Spidey-like.
Ideally, we might eventually develop a third API for manipulating
programs in editors. Then programs in the first set of examples could be
incorporated into full-fledged refactoring tools. For example, don't
just compute the useless definitions, allow their interactive deletion.
Ryan
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-dev
