The basic concept:
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).
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:
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.
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.
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.
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:
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.
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:
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.