next up previous contents index
Next: 3. Aspects Up: The TUNES System Specification Previous: 1. Overview   Contents   Index

Subsections

2. The System

2.1 Introduction

A running TUNES system consists of a self-supporting CONFIGURATION of OBJECTs.

2.2 Description

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.

2.3 Requirements

2.3.1 Fully-Reflective

The system must contain at least one standard exectuable EXPRESSION of its full architecture within itself.

2.3.2 Unified

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

2.3.3 Verifiable

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.

2.3.4 Higher-Order

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.

2.3.5 Self-Extensible

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.

2.3.6 Dynamic

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.

2.3.7 Fine-Grained

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.

2.3.8 Fault-Tolerant

A TUNES system must provide some means for assuring that no mismatch or variation of expected behavior will interrupt the system as a whole.

2.3.9 Distributed

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.

2.3.10 Scalable

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.


next up previous contents index
Next: 3. Aspects Up: The TUNES System Specification Previous: 1. Overview   Contents   Index
Brian Rice 2003-08-23