A running TUNES system consists of a self-supporting CONFIGURATION of OBJECTs.
A TUNES system is distinguished from a programming language, an operating system, or various mixtures of these concepts as such. TUNES is first and foremost an environment; that is, it is defined by the services it provides rather than the form, structure, or interface that those services take on in a given implementation. The project is moreover an attempt to separate service or interface from implementation in a very broad, systematic sense, while providing a coherent environment in which many implementations may co-exist and provide the same services in different CONTEXTs.
The system must contain at least one standard exectuable EXPRESSION of its full architecture within itself.
The system must provide standard support for unification of system ABSTRACTIONs. This requires at least that for any two TYPEs of OBJECT within the system and corresponding CONTEXTs, there must exist some standard way to express (or generate the expression of) each OBJECT in the opposite CONTEXT.2.1
The system must contain and be able to subject its parts to a means of mechanical verification of assertions within contexts. There must also be a published means of communicating these results when migrating software.
Any kind of ABSTRACTION is recursively possible over the system and its OBJECTs. That is, OBJECTs created by abstraction operations should be subjectable to further abstractions based on their TYPE.
The means of expression must be available within the system to abstract
some (any?) issue in a system-wide scope.
There must be a sufficient collection/system of ABSTRACTIONs
available (but not necessarily imposed) in every area of the system
for a meta-system transition in some (any?) manner to be possible
based on them. Examples include basic syntactic quotation, escaping
mechanisms, quotienting in arbitrary directions of abstraction, or
some kind of quotient inversion, where a simple domain is carved out
of a complex domain by adding some required constraints which they
do not all satisfy. This latter example corresponds roughly to a comprehension,
of which various sorts exist.
As with any element of these requirements, this kind of capability
has to be available in any domain within the system or across multiple
systems.
Any operation defined here may be used dynamically without loss of capability. That is, it is expressly permitted for any TUNES system operation to occur in the midst of any computational activity within that system at any time. Any restriction made on what can be done dynamically constitutes the definition of a SUBSET.
A TUNES system must place no limit on the ability to eliminate expressive overhead involved in operations on OBJECTs of a specific TYPE, regardless of its kind, within the system.
A TUNES system must provide some means for assuring that no mismatch or variation of expected behavior will interrupt the system as a whole.
Any operation or object should be implementable or re-implementable by a coordination of many other objects without restriction in expressiveness. This applies to physical distribution as well as semantic distribution.
Each subsystem defined as a TYPE or an operation must be scalable. That is, for a given CONTEXT, there must exist some facility for scaling down the semantic generality covered by the implementation of that OBJECT to the level of semantics actually employed within the CONTEXT. This is related to the notion of partial evaluation.