I'd like a module, call it leoInspect, which would, in effect, provide
answers to questions about Leo's source code such as:

- Where are all assignments to 'w' in leoEditCommands.py?

- Which of those assignments are "unusual" or "suspect" (in ways to be
specified)?

This is, in essence, a re-imagining of the new-pylint project, which
has been a "hobby" project of mine for several years. Rather than
attempting global "proofs" of difficult propositions, as in new-
pylint, the leoInspect module answer specific pattern-oriented
questions about specific files.  We could use such answers while
debugging, or as documentation, or especially as the foundation for
*fast* unit tests.

My first thought was that the simplest thing that could possibly work
would be a souped-up search command. As a quick prototype, yesterday I
wrote a short script, based on a simple Python tokenizer, that would
find non-comment, non-string lines containing assignments.

Suppose we are interested, for whatever reason, in assignments to "i".
Such a script, when run on itself, yields assignments to "i" like::

    result,i,line_number=[],0,0
    kind,i= "S",i+1
    i+= 1
    kind,i= "S",g.skip_to_end_of_line(s,i)

This illustrates the pitfalls of text-based approaches.  Finding the
"real" assignments to "i" will be ugly.  In retrospect, this is hardly
surprising. An approach based on AST trees will be cleaner and more
flexible in the long run.

The AST traversal code in new-pylint will form the foundation of
leoInspect.  Traversals creates semantic data (symbol tables, etc.)
that will also be useful in leoInspect.

As I write this, I see that the problem is to create a "query
language" that can be translated into specific AST traversals.  By
"query language" I mean any mechanism that could produce specific
searches.  API might be a better word for what I imagine.  In any
case, creating queries of AST trees creates a new world of
invention...

Happily, speed is *not* a big problem.  The kind of queries I envisage
can certainly be done in time proportional to O(N) where N is the size
of the code being examined.  More sophisticated queries might require
multiple passes over the tree (or data structures built from the tree)
but that's still O(N).  I expect most queries to take less than a
second, even on Leo's largest source files.  For example, new-lint
takes 1.5 seconds to create AST trees for *all* of Leo's sources, and
another 2 seconds to traverse all the trees.

Your comments please, Amigos.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/leo-editor?hl=en.

Reply via email to