Important System goal: incremental development

[Tril]

On Mon, 12 Oct 1998, RE01 Rice Brian T. EM2 wrote:

> >> what i am saying is to use the principal of
> >> partial-evaluation/partial-proof to create an easily-available form
> >> (or set of forms) for access at various levels of semantics, and to
> >> determine what policy should be used for generating those.
> >
> >Okay, I think I'm with you here, but can you give a more specific
> >example of how you think this would actually work?
> 
> Since the Tunes system's hll is 'reflective' as a primary feature, the
> generation of arbitrary languages should be little more than trivial.
> Since any language is equivalent to a calculus of atoms, this allows the
> richer type system which is desirable and should be available.  These
> languages would probably be generated incrementally towards specific
> application-development.  Their semantics could therefore be checked
> incrementally long before their application to some object, and would
> persist beyond most object's lifetimes.  That is my intended means of
> static type-checking.  This also ties in with my intention to have the
> hll completely abstract with respect to the usual programming languages
> usually used.  To me, the hll is the cart which morphs into
> horse-and-cart.

The 'incremental' approach (called 'refinement' by Fare) is a vital part
of TUNES, because we would like to build the system to support and
automate ESR's Bazaar development model as much as possible.  The idea is
to minimize turnaround on improving the system by making it possible to
take a few seconds out of your work, locate the area the needs to be
changed, make the necessary change, and resume working, while the system
can automatically propagate the change to the internet.  The following
features lend to that goal:

* Orthogonality, means you can change only what is needed, and no more.
* Fine-grain means you can make very small changes
* Persistence means you don't have to save the changes manually
* The system is abstract for natural visualization
* Human-readable notes and documentation can be integrated with
objects and their source
* Multidimensionality: Every object is accessible from many different
places.
* Dynamic reflection lets you experiment with changes in realtime, with
undo, so the user can easily find out exactly what to change.
* Distributed collaborative development is built-in, so your changes can
be immediately available for others.
* Check out other features for yourself.  I suspect every one of them
contributes to the "integrated-Bazaar" in some way.  

> In light of the obvious benefits and potential elegance of the Xerox
> PARC lab's aspect-oriented language development, it seems obvious to me
> to create code as an object whose interfaces are defined in terms of
> statements in languages which the user picks.  These choices at first
> should probably be static with reference to the code-generation phase to
> allow for simpler analysis in the project's early development.

So the code generator will have access to all the code, but it just won't
use it all initially.  This fits with the incremental approach to
developing a compiler.  

Note that aspects are (in Fare's words) only one specific example of
metaprogramming, so they are nothing special from the perspective of
TUNES.

David Manifold <dem@tunes.org>