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