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@adventurousmind.com
______________________________ Reply Separator _________________________________ Subject: Re: Structure of objects and execution (with effects on visu Author: Daniel Vainsencher danielv@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@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.
squeak-dev@lists.squeakfoundation.org