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
|