> 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@adventurousmind.com
______________________________ Reply Separator _________________________________ Subject: Re: Re[2]: Structure of objects and execution (with effects Author: "Michael S. Klein" mklein@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
squeak-dev@lists.squeakfoundation.org