...

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

dervived

...

from the parse-tree.

This can also be reversed... the Decompiler takes byte-codes and generates first the parse tree,

No, the parse tree is close, but not the same in all cases. All that is required is functional equivalence. Here is example from VW: plook |x y z | x := y := false. z := (x or: [y]) ifTrue: [ y ifTrue: [self yourself] ifFalse: [x]]. ^z or: [x] plook "pretty-printed" | x y z | x := y := false. z := (x or: [y]) ifTrue: [y ifTrue: [self yourself] ifFalse: [x]]. ^z or: [x] plook " ***This is decompiled code.*** " | t1 t2 t3 | (t3 := ((t1 := t2 := false) or: [t2]) ifTrue: [t2 ifTrue: [self yourself] ifFalse: [t1]] ifFalse: [nil]) ifTrue: [^true]. ^t1

The Decompiler in Squeak does better, probably because it does fewer optimizations.

...

At each step, information is lost... not gained.

I believe that any current information loss due to these transformations can be solved. The bytecodes used for the Smalltalk VM map rather well into the model of execution that actually is presented to the user, and I don't think there really is all that much opportunity for information loss even in the existing system.

Consider that this roots your ideas of what "source" might be. For example, this view completely precludes any posibilities of macros (Please.. no flames... I'm not saying we should add macros).

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.

These "user-system interactions" , to the extent that they can be review and edited produce source. Source need not take the form of linear text... visual construction is a prim example. The parse tree does not include geometrical coordinates in a visual language.... these are part of the source.

[snip on MorphicWrappers]

Yeah. These are nice. I can't wait until I can have the target of a MorphicWrapper as a literal in my code.

...

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.

Exactly my point... parse trees are nice for code analysis tools... not humans

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.

Again. I would like to move away from *just* text as source. Parse trees provide some part of the answer, but a small part. They lose more than they gain, for humans.

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.

My personal opionion is that comments should be attached to regions of source. For abstract meanings of 'region' and 'source'.

...

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) ?

'Meaning' cannot be seen. I can "see" the "parse-tree" structure easiest in well-written text. All of the other visual means for showing this that I've seen are worse.

...

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.

I siad I would like to be able to *read* it this way... not *write* it this way.

But that means you need alternatives.

Someday....

[Parse trees] could easily be expanded to support comments though. Those branches just wouldn't produce byte code.

I dont want to have to extent parse trees every time I extend my notion of source. Simple example: the time & author stamp.

The other great thing about structured representations is they allow

for lively

interaction. Imagine dragging and droping elements of an equation

around and the

UI only allowing valid operations. Kids could learn about the dynamics

of equations

by treating the thing like a physical puzzle. Likewise imagine

trigometric equations

being displayed in a structured interactive geometric form. Kids could

learn about

complex trigometric relationships without algebra...

You don't have to imagine it. Go look at GraphingCalculator on the Mac. (It's a desk accessory)

-- Mike