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 text. But that means you need alternatives.

-- Mike

Daniel