> 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 above illustrates one of my problems with the use of linear text 
     as source and the thought that parse trees have to be derived from the 
     such source. I think that in the above case it is more user friendly 
     to provide a GUI editor which manipulates the "parse tree" directly. 
     The individual plus, raiseTo, and divide nodes encapsulate the 
     knowledge and behavior necessary for their individual requirements 
     including bug catching and prevention along with the pointers linking 
     the nodes to each other. The GUI provides the support and spatial 
     information that is necessary for building and maipulation of the tree 
     itself. The GUI can have multiple faces including the ((a+b)/(c+(d 
     raisedTo: n))) type of face and the parse tree form for those that 
     prefer. The difference is that of editing structure rather than linear 
     text.
     
     My point is that I do not see the advantage of having a form that 
     needs to be parsed.
     
     Jerome
     
     --
     
     Jerome E. Garcia
     jegarcia at adventurousmind.com


______________________________ Reply Separator _________________________________
Subject: Re: Re[2]: Structure of objects and execution (with effects 
Author:  "Michael S. Klein" <mklein at alumni.caltech.edu> at INTERNET
Date:    10/27/98 10:48 AM


     
>     - The ability of the system and the user to copy, paste, and merge
     
The following is an obvious statement, but it bears saying:
     
The parse tree is derived from the source, and the byte-codes are dervived 
from the parse-tree.
     
At each step, information is lost... not gained.  Obviously these two 
representations are more efficient in certain domains... byte codes are 
easier to execute, more compact, parse trees are easier to analyze. But 
these are all optimizations, derived from the source.  Alternate source 
representations should move in the direction of the user, not the computer.
     
For instance, in principle, with enough contextual information availiable, 
the "source" text is derivable from a series of UI gestures.  The text can 
then be viewed as a compilation of these gestures.  If someone cut & pasted 
code from one method to another, this info might indicate area ripe for 
factoring.
     
Of course, no one wants to see UI gestures when reading source, but then 
I really dont want to see parse-trees either.  If a representation is 
neither more readable, not more writable, leave it to the computer.
     
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.
     
-- Mike