holistic code-generation model

[RE01 Rice Brian T. EM2]

Note: all issues which have been delayed in their resolution have been
marked with an asterisk for future reference. So, an asterisk means an
open issue which must be resolved later.  Hopefully, this spawned thread
will successfully contain a successful solution for a holistic model for
code-generation, Tunes-style.

For this model, I will try to outline the issues relevant to the purpose
of generating code in a 'useful' way.  By useful, I mean in a general
sense as supported by Tunes.  The issues to which 'useful' applies
include, but are not limited to the following:
*	total development time: If the computer can resolve an issue faster
than the user can, or if some HCI will resolve it faster, then the
effort should be shifted towards the computer system in the appropriate
way.  So, one metric for HCI ontologies (user interfaces) would be the
appropriate distribution of development effort.  A possible mapping
function from software goal to this metric would probably take the form
of "divide the development problem into creative/non-linear aspects for
the user and retain as many straight-forward/linear aspects for the
software system as can be perceived."  This function would have to be
applied 'at fine grain', of course.
*	reversibility/abstraction: All code generated must retain some link to
the 'source code', an object in the user's viewpoint which defines the
code.  Because of implicit meaning in the language(s) chosen for the
code, this object's apparent semantic meaning would be
context-sensitive.  There is a question as to where along the
abstraction chain(s) from the meta-context(s) to the run-time context
the links to auxiliary aspect definitions should be placed, based on
this holistic model.*
*	re-use: Although apparently answered by the abstraction solution,
there may still exist properties of the holistic system which would make
re-use in certain cases less trivial than normal.  I think we should
keep this in mind as we develop the model, to avoid possible problems
later.
*	derived interfaces: Along with the idea of re-use, but perceived
differently in the mind of the developer, would be the issue of 'not
re-inventing the wheel' at any cost.  What I refer to is re-use of code
as aspects for other code, possibly quite a novel idea.  This means that
a solution that a user makes to deal with one problem should be used to
deal with many similar problems.  This transfer could be reversible as
well, for having created this piece of code, the user could later see
how to derive it from other pieces of semantics in the system using a
simple metaphor: "Oh, I see that solving this problem is similar to how
I went about solving that other problem."  Then, the user could tell the
computer about the metaphor, and the computer would return to the user a
newly-generated interface for dealing with the problem in ways that the
user had not intended originally, but increase usefulness by giving the
user more freedom in the first-order interface.  (I say first-order
since the objects actually presented by the computer are usually assumed
to be semantically well-understood by the user, and therefore that the
user does this cognitive connection of all (beyond the first) aspects of
the distant object to the object in the user's view.)  The user had the
freedom, but would have a higher burden on his/her memory in order to
deal with this total metaphor management.  In our intended case, the
user, after having established the single metaphor, would have the
related methods at his/her disposal on the screen, for instance, in a
visual/iconic interface, instead of having these methods tangible only
after "browsing" for each method.
*	efficiency: We would like to balance the overhead of this
code-generation scheme in a way which will please the user.  By
'please', I again mean a total sense of satisfaction in knowing that the
computer is not wasting its time in a kernel routine which was not
necessary, or swapping virtual memory around only to swap it back again
due to idiotic memory-management schemes.  Hopefully, the system will
far outperform traditional systems even in these tasks under the 'old'
metrics.  However, in light of the first issue's paramount importance,
that of minimizing total development time, we must remember that this
issue must be subservient.  However, the viewpoint that any time that
the user waits on the computer is a complete waste of time and
intolerable by reasonable people seems to regard both issues as one.  To
do so, we must develop several 'scenes' in which the user is doing some
action, or possibly waiting on the computer to formulate some answer
(the latter being undesirable: in any case, if the computer must
continually process something that excludes user-interaction for
efficiency reasons, then the Tunes system is not doing its job, so to
speak.).  These scenes would be quite different from the average user's
scenes from today's computing world, where the user's interest is
divided several monolithic software products, instead of the software
conforming to the user's desires.  Here are some examples which seem to
reasonably apply to what people really want out of computers:
*	sending stuff to other people (software stuff). I first wanted to
state this as letter-writing, but I realized that this is only a
compromise based on technology and tradition.
*	talking to others and playing together (real-time interaction).
*	getting the computer to help them work with an idea. artists,
engineers, technicians, scientists (of all kinds), mathematicians,
researchers, historians, sociologists, anthropologists, ... (I could
continue for a while).  It has already been realized in the industrial
world that computers are a fantastic tool for visualization, but only in
a pitifully small way, so far.  We want an interface that allows the
user to separate information into tradition and meaning, and be able to
play with the meaning in an infinite number of ways.
*	digital assistants carrying a form of the user's own natural way of
thinking about the world, to help automate information tasks for the
user, via predictive algorithms etc.
*	operating systems that just work, that only require to be told about
the  operation of a new piece of hardware to allow it to be
accommodated.