Structure of objects and execution (with effects on v

Daniel Vainsencher danielv at
Tue Oct 27 22:42:38 UTC 1998

Michael S. Klein wrote:

> The parse tree is derived from the source, and the byte-codes are dervived
> from the parse-tree.

This is merely the way things are right now, not some axiom. The parse tree can
be derived from many different
types of user-system interactions (structured editing, visual construction,
logging of manual execution*), and can
be optimized for execution in many ways besides byte codes.

But to the extent that the language remains Smalltalk, the parse trees will
remain the same.

* -Gerardos and Lucianos excellent MorphicWrappers allow you to have any kind
of object (smallIntegers, for example)
on a morphic world, not just Morphs, and to send them messages by drag and
drop, in a very natural, tactile way. A
friend of mine and I have written a small addition that logs every action you
do with the objects to the Transcript, so after
you're done, you have executable code. That's another way of creating parse
trees. Unfortunately, they are currently
hard enough to create directly that we chose to go through text again, which
was rather unnatural, ugly, and annoying.

> At each step, information is lost... not gained.  Obviously these two
> representations are more efficient in certain domains...

Look at the RefactoringBrowser - it uses parse trees. Why? because parse tree
are a more efficient representation
for what it is trying to do - figure out and improve code. Well, whaddaya
know... that's precisely what I'm trying to
do most of the time!
True, parse trees aren't perfect. For example, they don't support comments
amazingly well. Which is not surprising,
because having text as the only way of writing code made it almost unavoidable
that they would be easy to use in text
(easy to layout manually using spaces and such, for example). Because comments
are the one piece of information
that the execution engine care nothing about, it is naturally lost en route.
But that's valid only if you think the only client
for things other than text is the VM, and that's not the case.
This doesn't mean that's the only way things could be. If you think (as I do),
that comments are there to clarify specific
elements of code (at whatever level - a statement, a method, a block, a message
send), then it makes perfect sense to
make them attach to specific parse tree nodes, and not to specific text
locations. How these comments are then rendered
on screen is a flexible matter, to be solved by UI wizards. But since the
subject of each comment will be clearly defined,
their task will be clearer than the prettyPrinters' is now.

> Of course, no one wants to see UI gestures when reading source, but then
> I really dont want to see parse-trees either.

You want to see the meaning of the code you're writing, at the level of objects
sending messages (not bytecodes) ?
that's what determines, directly, the parse trees structure.

> If a representation is
> neither more readable, not more writable, leave it to the computer.

Of course we still DO have to render and edit the parse tree in a useable way,
but that's fine so long as we're clear as to
what we're looking at.

> It sure would be nice to be able to read ((a+b)/(c+(d raisedTo: n))) as
>      a + b
>      ------
>           n
>      c + d
> (Well, layed out nicer than posible with ASCII art)
> But it is dificult to write that way, using linear text, and difficult
> to parse that way, using linear text.

The answer - when it's important to you to write this way, don't use linear
But that means you need alternatives.

> -- Mike


More information about the Squeak-dev mailing list