Structure of objects and execution (with effects on v

Steve Dekorte steve at
Tue Oct 27 22:59:34 UTC 1998

> > At each step, information is lost... not gained.  Obviously these two
> > representations are more efficient in certain domains...
> True, parse trees aren't perfect. For example, they don't support comments
> amazingly well.

They could easily be expanded to support comments though.
Those branches just wouldn't produce byte code. 

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

And once you have structured info(parse trees), you have alternatives.
I'd like, for example, not only to be able to see mathematical expressions using 
the syntaxes above, but to be able to explore new and different representation 
schemes for mathematics. I think there is alot to be done in the area of 
information representation, but the lack of sturctured info has so far required 
our representations to be based primarily on history.

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


More information about the Squeak-dev mailing list