abstraction issues

[RE01 Rice Brian T. EM2]

Since I'm quite new to this discussion group, I feel that I should ask
about the state of the project's members' ideas on the mechanism for
abstraction.  I feel that I should also clarify some of the statements I
made in my introduction that were mostly misunderstood.  Most of those
problems, I feel, are due solely to a mis-matched understanding of some
terms we throw around quite loosely.

Apparently, most of you are fans of the 'pure lambda-calculus' approach
to the issue of abstraction.  It obviously resembles the language
meta-structure for most languages, including procedural, object-based,
and the obvious functional programming metaphors.  I believe, however,
that the issue needs to be explored more fully in light of certain
newly-developed ideas like aspect-based programming (to factor out
abstractions) (see Xerox PARC research) and older ideas like declarative
programming (which can be said to consist of meta-programming
information only, extended to fully specify the program).

My point of view on this question of mine is that programming languages
as such are interfaces (albeit crude ones), and reflective programming
systems constitute a human-computer interaction (HCI) ontology.  My
point is that ontologies, in a philosophical sense, are every bit as
relative (or arbitrary) as the various programming methods which exist
today.  If our system is to be truly general, then our abstraction
mechanisms have to be easy to understand and simple to extend into the
ultimate abstraction: multiple ontological perspectives on the state of
a Tunes system with coherency calculated and generated within a finite
interval, preferably one that the user may tolerate (the optimization,
obviously, enabled by reflection).  One must also keep in mind that with
a open reflective programming system, only the interfaces defined for
the user should be available to the computer and no others.  In other
words, while the user may communicate via an interface impractical for
the computer to access (e.g. 2-d GUI's, voice recognition, 3-d worlds),
the meta-language for these interfaces (i.e. "meaning") must be some
form of the interface that the system uses for abstraction, with various
aspects reified or made explicit.  Also, the desire for automation
within our system begs for the abstraction to allow the computer to use
the code at the same cognitive level that the user does, including the
thought processes for writing code, the issues that the user thinks of
while writing a document, designing a piece of engineering technology,
composing music, solving a mathematical problem, creating visual
artwork, ...

If you step back and 'reflect' for a moment, you will realize with me
that Every case of computation (that is, anything done by the system) is
in some form of these interfaces' algebra, and that the elements of
reflection (which, of course, may be distinct in capabilities per
interface?) must be able to account for all transformations across the
system between ontologies (and respective interfaces) in order for the
system to avoid an 'ontological fracture', the characteristic which we
abhor among current systems.

So, specifically, I ask:
	How are aspects (orthogonolization of meta-protocols) of programming
methods integrated with pure lambda-calculus?
	What other ontologies from which the user might benefit than the
'everything is an object' metaphor?
	What ideas does the Tunes group have for generating ontologies that
allow finite descriptions of desired computational objects which contain
countably or even uncountably many elements, like axioms, recursion
operations, nonlinear problem-solving, nonlinear ontologies (explained
later), ... ?