CHROME and IRON data typing (by alaric)

Due to CHROME's use of uniqueness types, any immutable version of a type can actually be used in a way that is implemented by mutation, for efficiency; the runtime system will invisibly be using the mutable version of the type under the hood.

Mutable types all have two constructors; one to create an ephemeral in-memory instance, and one thar will connect to a persistent instance in TUNGSTEN. The latter constructors are designed to deal with versioning issues; if the persistent object does not exist, it will be created with defaults. If it exists but is of slightly different type, then it will cope, perhaps by using metadata supplied to the constructor; when adding a new field to a record, you could also provide either a default for existing instances that lack that field, or a function that accepts the existing row and returns a new value for the field.

Persistent objects are either referenced by a programmer-chosen name, unique within the entity, like a global variable; or by their system-assigned ID. The named objects form the root set of the persistent object graph for an entity, and nameless objects form the other nodes.

On top of the above basic set can be built strings, booleans (a Union of Nulls), dates, rational numbers, complex numbers, and so on.

Bear in mind that each of the above types will have several drastically different implementations; in-memory mutable and immutable forms, serialised forms for communication and archival, and persistent forms with complex distributed transactional state management protocols. Yet where possible, the same interface is used to the application code. The only difference the application code sees is between mutable and immutable forms, for in a uniqueness typed system, shared mutable state needs special interfaces to synchronise both read and write access to an external-world-state object - although, as mentioned above, objects that are mutable within the context of a single thread with no sharing can just be done in terms of the immutable version and unique typing. This is a topic too complex to go into here; read up on Concurrent Clean for more information. However, suffice to say that the Mutable versions of data structures need to be explicitly locked and unlocked to gain read or write access to the shared state; the system should implement the immediate ceiling priority protocol to prevent deadlocks and priority inversion.

But, I hear you cry, what of object orientation and data hiding and encapsulation?

Well. We've defined a format for on-the-wire data in terms of a fixed set of basic atomic and structured types, with fixed accessor methods. This is nicely portable; we can write access libraries for IRON in any language we care.

CHROME layers the OO stuff on top of IRON. Normally, Array(Float,[*,*]) defined in one place is identical to Array(Float,[*,*]) define anywhere else; such types are considered equal if they are structurally identical. However, CHROME also has classes as well as basic IRON structural types.

A CHROME class consists of an underlying IRON type for the state of an instance, plus zero or more methods. The class is either defined globally, and identified by its name in the CARBON directory, or is local to a specific entity, in which case it is identified by the TUNGSTEN persistent object ID containing the class specification.

Equality of a class and an unadorned IRON type is always false. Equality of two CHROME classes is tested by seeing if they have the same identification in CARBON or TUNGSTEN.

To code using the class rather than just using a type, the difference is large; the underlying IRON type is invisible. All you get are the methods defined by the user. Under the hood in CHROME, each IRON type is actually a class anyway, so you can make your own classes that are variants on standard IRON data structures by writing a class that inherits from them - and to avoid a type system that actually has to deal with two different notions, 'type' and 'class'.

Pages: 1 2

1 Comment

Other Links to this Post

1. Snell-Pym » A syntax for IRON — Wed 4th Jul 2007 @ 3:12 am

RSS feed for comments on this post. TrackBack URI

Leave a comment