Structure of objects and execution (with effects on visual programming, and reversible debugging, )

Les Tyrrell tyrrell at
Sat Oct 24 17:46:39 UTC 1998

Actually, I believe we already have a somewhat compact representation
of the parse tree in the compiled methods-  unless you need to guarantee
uniqueness of a particular parse tree in multiple, disparate uses it
is probably sufficient to regenerate it from the compiled method.
That being done, then I am definitely in the camp that the Parse trees
have been neglected, and that in particular the parse tree enumerators
are very powerful tools.  I'm willing to write enumerators for Squeak,
and actually have started on this.  It shouldn't take much effort.
In my case, I want to write software analysis tools to enable me to 
determine what batches of messages are being sent to various entities...
with a parse tree enumerator, this is trivial- walk the tree, gather
the message sends, note to which objects the messages are sent.
There is a whole heapin' horde of information available to tools like
that.  And in systems like VisualWorks and Squeak, it's easy to build
those tools.  The biggest problem is dealing with the sheer mass of
analysis results.

I've written a pretty formatter for VisualWorks before... so I am
aware of the various problems that crop up, such as the displacement
of the comments ( or loss ) and the ambiguity in determining just
which statement a comment actually belongs to ( the VisualWorks
belief is actually that the commment comes AFTER the statement, whereas
most people appear to put them before the statement ).  It would
not surprise me to see similar behavior in Squeak.  The biggest
hurdles deal with comments ( where do they REALLY belong ) and
parser optimizations ( what you get isn't what you wrote, but better ).
If people don't mind the parser rewriting their code ( as long as
it is correct ) then there really isn't much of a problem.

So here is my list of things that I either know or think a parse tree
enumerator could do:

	1) create alternate representations of your code...
		1) text ( formatted )
		2) graphical ( such as Randy Griffen's )
	2) analyse your code ( in lotso ways )
	3) generate the compiled method ?
	4) generate the C translation nodes ?

I'd be happy to pitch in on this, I've been through much of it before
with VisualWorks.


More information about the Squeak-dev mailing list