General HLL Concepts

Objects

• The language manipulates objects.
• Any identifiable abstraction in the system is an object.

Attributes

The basic concept:

• Among objects, some are attributes of others, and this attribution link between objects is a further object.
• Attributions are equivalent to unary functions that always return the same result when applied to the same object, which associates a value to every object.
• Attributes are just particular objects, and thus share other features with objects. In particular, attributes can have attributes, and can be associated as values to objects by attributes.

In principle, a whole Tunes system can be described in terms of objects and these attribute relations, or attribution triples. The triple would then consist of:

<key, object, value>

It is noteworthy that these do not have to have some fundamentally-sequential or otherwise structure: this is merely a notation for an object with some attributes. These are fundamental meta-objects within Tunes, although higher-order of course (since attributes may have attributes).

Object-Attribute Implementation

The attribute concept is specified in an abstract way to intentionally allow for the implementation to vary on a case-by-case basis, or even to vary over time. Since the system is taken to be reflective, the compiler can be given suggestions via aspect-type assertions about what specific implementation style to choose or what heuristic should be taken for granted, so the programmer still has optional control.

Some typical means:

• As a "member" of a structure that implements the objects (e.g., in C/C++ members of a structure or object; in Lisp, car and cdr of a cons cell or elements of vectors, etc.).
• As some kind of structure external to objects: for instance an association list or hash-table, that contains a set of object to value association pairs, where only one pair can be retrieved with for a given object; or an array indexed by numbers otherwise associated to an object can also be used.
• As an arbitrary procedure that takes an object as a parameter, and computes and returns the value associated by the attribute to the object.
• As information nodes inserted into a structure.
• Into a centralized or decentralized association list or hash table.
• As a combination of several techniques at once, one technique per object or a layered technique, with, say, an optimized table as a fallback to "journalled" modifications to the table that may or may not be intended for incorporation into the table.

An interesting symmetry with respect to this notion is that we could exchange the role of objects and of attributes, and consider that an object associates a value to every attribute. This symmetry can be taken advantage in the implementation of attributes by exchanging the role of objects and attributes in the above techniques.

Multiple attributes may share structures or code, or deduced one from the other; they may be implemented partially using object-based attribute-to-value tables, and partially using attribute-based object-to-value tables; the implementation of a given attribute may change over time, so as to efficiently adapt to its changing usage pattern; tables of a modified object/attribute may be swiftly or lazily deduced from tables of the original object/attribute, etc.

All this to say that the language supports the notion of attribute independently from any possible implementation, so that programmers can focus on the semantics of it during program specification, and still be able to use arbitrarily nifty tricks when doing the implementation, instead of having to give the computer a bad compromise between them during a unique programming phase.

Similarly, it should be understood that the HLL allows as much decoupling as possible between specification of abstract semantics and of concrete implementation. Never should the programmer be tied to a given implementation of an abstract object, or to a given abstract view of a concrete object.

Attributes vs. Functions

An attribute can be conceptually thought of as a memoized function: you have a function that associates some abstract value to some objects, but want to remember that value permanently without having to recompute it.

• If the function is pure, then there is no semantical difference between an attribute and a function.
• If the attribute gets garbage collected, then all the individual memoized information gets garbage collected; if an object gets garbage collected, its attribute disappears, too.
• If you want to be able to associate varying values to objects, then use a reference as the attribute; that's the ML way of making side-effects orthogonal to other computations.

Examples

• You've got a structure that you'd want to pretty-print, display, or edit. Then, you're going to define for every "node" in the structure attributes that describe where and how it will be displayed (font, indentation, size, color, whatever).
• The system has a concept of "user", built in some module. You want to add some accounting/logging information about users. No need to rewrite the module that define users. Just define a new attribute of users. Same goes with password systems, etc.
• You want to type a program. Give each node a type attribute. Note: programs are stored abstract structures, not ASCII).
• You are not satisfied with the way the pretty printer manages parts of your program; you ask it to remember the layout, or particular layout tactic to use for such parts of the program.
• You want to comment a program. Annotate its structure with comments in French, German, Chinese, Martian.
• You want to translate a program. Annotate each node with all the meanings you could find about it, before you can understand it and synthetize a translation.

Context

An object is never considered alone, but in a context, or space, that describes the meaningful aspects of the object: the context gives the full semantics of the object.

In fact, objects must be created within contexts, so for each object, there is some context that provides its identity: its identifiability. However, objects can exist in multiple contexts, but this naturally reduces the context association with an object to be like that of a view on it, so there are issues of consistency and coherency.

Only meaningful constructors may be used on objects; for example, even if an object could be modified, by considering it in a context where modifying it is excluded, it is made read-only; by considering an object in a context which has a modifier method, the object is made read-write.

The context may also explicitly define specifications of the object, so that the system may simplify programs in a way that will keep the semantics by doing transformations that let meaningful things unchanged, while limiting resource allocation in unmeaningful dependences. E.g., if your methods for a list maintain a count of list elements that you don't need, it may be ripped off automatically by the system if not declared meaningful somewhere. Note that different views on the "same" object may consider different things as meaningful.

Obviously, contexts are different in important ways from the bare concept of Tunes objects. What immediately comes into question is whether the objects created within a context are attributes of the context. Generally, the answer seems to be negative: contexts themselves have their own operations and attributes which are distinct semantically from the objects they engender. So, contexts are basically special kinds of meta-objects with protocols and behaviors for managing the identity of objects.

Meta-objects

The prefix "meta-" means "after" or "beyond" in a physical sense, but is often taken with its incidental meaning "about", and excessive use dilutes the effectiveness of the concept. Within Tunes, "meta-object" refers to a broad category of objects whose sole purpose and attention is on other objects, rather than some domain that a user has in mind that relates to the outside world.

In particular, these objects describe and relate to the existential or ontological status of normal program objects (or even other meta-objects), but there are many categories of this usage of the term. This implies that wherever the term meta-object is used without qualification, that it is a place where additional specification is required.

For reference, the general use of the term in Tunes generally abides by the Common Lisp Object System's terminology (though it emphasizes meta-classes, which is relatively unique among languages but has a useful terminology in the logical sense. Basically, in this sense, an object's sole "non-meta" feature is its identity, its existence, even apart from its implementation. Attributes and contexts and methods or functions are all things considered "after" or "beyond" the point where one assumes that there is something that can be identified. In other words, the information that an indentifiable thing exists must be given before the thing can be given or queried for attributes or any other kinds of facts, and that is what makes the objects that encode these things, meta-objects. There is a type of logic that works this way, a slightly modified version of predicate logic called dynamic logic (as seen in Dynamo).

The usual meta-object architecture for Tunes:

• Any object is created within some theory, some space of possibilities. One meta-object exists to assert/pose that existence for the given object. As alluded to above, this meta-object will be directly related to the context within which the object was created.
• As more things are stated about an object, meta-objects are created to record this information and its behavior within the environment. The system will further make inferences to refine the possibilities and possibly detect incompatibilities (i.e., contradictions).
• The execution model would be interesting to describe, since this potentially arbitrary way of grouping things together is not really programming in the usual sense. At worst, however, these things are still interpreted: there is no need here of "hard AI". There is, however, still a role here for choosing representations and implementations of the object and its attributes or even inlining the object within some surrounding context. This is where the graduated version of the modern compiler and run-time optimizer fit in, only in a more general, open, and portable way.

There definitely are security concerns with meta-object access: reflective access is widely, and rightly, regarded as an incredible insecurity in a language or system. This is one reason for the extensive rationale behind Tunes' security system design.

Rewrite

Every language has an evaluation model. Tunes requires a flexible evaluation model: one that can exist as an object within the system and be safely adjusted in ways that are understandable.

The general principles:

• We need some way to express the fact that objects interact, and knowledge evolves. Specifically, we need update of attributes through time, and some notion of fact and even possible proof about these things. These notions of update and proof of fact should be unified as well.
• Maybe this means that we manipulate not only objects, but also projects: a concept covering both contexts and general systems. Specifically, we need to understand how objects and their updates fit within systems, and how multiple nested systems and objects interact.
• Rewrite has Higher Order semantics: the Maude programming language research has demonstrated that a certain kind of concurrent rewriting logic can express a very effective theory of itself, within which rewriting strategies can be expressed and specialized for particular problems or domains. Some of these domains importantly include other logical inference systems as well as distributed interacting processes. Maude is also significant in being both a specification language and concurrent programming language in a relatively unified way compared with other solutions, so it is very important to draw from this idea for Tunes.

Active annotations

• Attributes/functions need not be statically-defined but are dynamically given (with or without side-effect, thanks to promises).
• In some metaspaces, objects may have active attributes, that are evaluated together with the object.

  Examples:

  • Scheduling/usage information as call counter for a function
  • Notification of one user's login to others.
• Actively annotating objects may be a fairly standard programming technique:

  Parsing a text may be accomplished by dynamically annotating it while reading it; active annotations to the byte reader may correspond to the program's state; it may then become trivial to write programs that depend on the past and future of the local input context.

  However, this feature should be made static (i.e., removed from the dynamic context) whenever not needed, because it hampers good implementation. In fact, active annotation may mean that an object must notify others whenever it is evaluated; dynamic active annotations mean some space and/or time overhead so that such notification is done for every element in a dynamically-evolving list of objects.