Structure of objects and execution (with effects on v

Jerome Garcia Jerome.Garcia at wj.com
Mon Oct 26 21:38:54 UTC 1998


     I think compactness of the parse tree matters but not as much as the 
     following:
     
     - The ability of the GUI to ask at each node what is possible and 
     present that information to the code developer as either restrictions 
     on actions or choices of actions.
     
     - The ability of the system and the user to copy, paste, and merge 
     branches as they desire and obtain assistance from the system in 
     resolving problems.
     
     - The ability of the system to analyze, compact, and optimize the 
     parse tree automatically. Such changes should be reflected to the 
     developer via the GUI. As necessary, the system should be capable of 
     requesting confirmation from the developer prior to proceeding with 
     changes.
     
     Basically what I would like as a long term goal is a development 
     system which learns how to improve itself by analyzing and 
     manipulating the parse tree or any more appropriate representation. 
     But, I also want it to be able to reflect all changes to the developer 
     in a human understandable form so that the developer can also learn 
     from the process and therefore provide better feedback into the system 
     the next time he or she interacts with the system.
     
     Jerome
     
     --
     
     Jerome E. Garcia
     jegarcia at adventurousmind.com


______________________________ Reply Separator _________________________________
Subject: Re: Structure of objects and execution (with effects on visu
Author:  Daniel Vainsencher <danielv at netvision.net.il> at INTERNET
Date:    10/25/98 11:03 PM


To be be truthful, I honestly don't think it matters, how compact ParseTrees 
are, so long as they're convenient, and can easily and cheaply change formats...
I trust the power of generic compression algorithms, and good code generators.
     
In fact, I don't care if the system usually holds all the ParseTrees compressed,
making them even less readable (directly) than
CompiledMethods are now - so long as they open up automatically when the user 
turns his gaze on them.
Actually, it seems like a very good starting point for the usual compressed 
format for code to remain CompiledMethods, or something
similar - again, so long as the user and system tools get to work with a 
parseTree, transparently.
     
Compactness isn't the (or even a) key feature here - a direct, usable 
representation of that which matters to people and programs, is.
     
And I'm not especially attracted by a particular use for them, but by all of 
them together.
Type inference is interesting,
Alternative implementation schemes are interesting, 
Flexible binding for code is interesting,
Automatic code layout is interesting (anything to keep the programmer on the 
real issues...),
Better code editors are interesting (the mistakes structured editors made are 
assets, not proof this can't be done right, right? 8-),
Visual representations for code are interesting, 
Code transformation is interesting,
Real time code complexity metrics are interesting, 
etc...
     
And it seems to me they're all fairly begging to be rid of the tyranny of the 
string and the CompiledMethod.
     
CompiledMethods (bytecodes) were an inspired combination of compact 
representation and executability by a VM -
but, IMHO, we can now afford to separate those two concerns from one another, 
and from everything else we do with code.
     
Dan Ingalls wrote:
     
> Dwight Hughes <dwighth at ipa.net> wrote ...
> >He is wanting to improve the prettyPrinting
> >to the point that it would be the preferred option (and be customizeable 
> >of course) -- allowing most of the source to be drastically reduced in
> >size, down to basically parse trees. 
>
> Just to be clear about a couple of things... 
>
> The prettyPrinting with comments would save space because METHODS are 
extremely compact; not because Parse Trees are;  they are not.  In fact I 
believe parse trees are the worst of the three (text, parse trees, methods) in 
compactness.  What's nice is that the decompiler can build parse trees from 
methods, and those, in turn can (re)generate source code.
>
> ...and that's not to say I'm opposed to working with parse trees either.  The 
original Fabrik (and ThingLab before it) built parse trees from its graphical 
structure and then generated code from the result.
>
>         - Dan
>
> P.S. There are other nice things about parse trees, such as being able to 
execute them for type.  A simple type inference mechanism can be built this way.
 One should be able to execute the methods themselves for type, but the
compilation of ifTrue: and the other optimized control constructs prevents it.
     





More information about the Squeak-dev mailing list