Introduction to the Ivory Programming System

The Ivory system provides integrated data storage. This is based around the notion of a set of objects associated with what is termed an active data store (ADS). The term active arises from expressions with side effects, which are able to modify both the expressions within a store or to interact with the external environment.

Objects are evaluated expressions referred to by values of type Ref and subtypes of Ref distinguish objects; furthermore, the type of every object can be determined at run-time.

Ivory is not object-oriented in that objects are primarily storage entities and are not directly related to type classes. However because the type of an object can be obtained at run-time, type class methods may be dispatched dynamically to achieve a similar result.

Special objects enable stores to provide a localised global namespace. This is subdivided into a tree hierarchy using a conventional naming scheme modelled closely on the files and directories within a network filing system.

There are three different types of store with a transparent access mechanism. These are:

1. Local
   Data is maintained in main memory and exists for the lifetime of an Ivory session;
2. Persistent
   Data is maintained in secondary storage and persists between Ivory sessions;
3. Remote
   Data is maintained by a remote process.

Given the inevitable additional overheads imposed by such a scheme, it is considered important that an Ivory system implements data stores with reasonable efficiency. The aim is support access rates orders of magnitude faster than could be achieved with ,say, a relational database.

The Ref type means that there may be more than one reference to the same data. For this reason reverse references are maintained. They simultaneously provide reference counts as well as a useful navigation capability for component-based application models.

Sets of store names are implemented as namespace objects and each store has a special one known as its root namespace. Access is via the Select class operator `.': Thus: .x refers to a named value in the root namespace of the root store.

Values are uniquely identified by a pathname resulting from a hierarchy based on separate namespaces provided implicitly by ADS or explicitly by Namespace objects. An example of a pathname is:

.x.y.z

This would refer to a local name z to be found in the explicit or implicit namespace of the value denoted by .x.y. The first . in a pathname is known as the root namespace for an evaluation context.

An Ivory system application is expected to be largely rule triggered. The reason for this is to de-couple state changes and dependent actions.

A simple ECA (Event Condition Action) approach is used where conditions and actions are combined in case expressions of functions with a common type signature known as rule methods.

(Rule -> (Exp *) -> ADS -> EventPhase -> Void)

There is a set of event types corresponding to external events and data store transactions. The most important of these are:

• StartEvent
signals system start-up.
• StopEvent
signals request to stop system.
• CreateObjectEvent
after creation of an object
• DestroyObjectEvent
before destruction of an object
• AddPropertyEvent
after addition of a property
• UpdatePropertyEvent
before/after property update (invoked twice)
• RemovePropertyEvent
before removal of a property
• AddRefEvent
after addition to a property reference list
• RemoveRefEvent
before removal from a property reference list

Events are always associated with a particular data store, and there is a simple built-in function to raise (or signal) them:

raiseEvent event::(Exp *) ads::ADS =
   let invokeMethod ref::Ref =
      case ref of {
         rule::Rule -> ((rule.method) rule event ads)::Void
      }
   in
      mapProcRefs invokeMethod (ads.ruleList)

This is for illustrative purposes only. In practice, there is an extra argument of type EventPhase that allows actions to be deferred until all rule methods have been evaluated.

Rules are associated with data stores by including them in the ruleList property of the host ADS object. Note that the same rule may apply to more than one data store.

mapProcRefs is a built-in function to apply a procedure successively to each element of a RefList (a vector of object references).

mapProcRefs proc !refs =
   let !doFrom !i proc !refs =
      if i < (length refs) then {
          proc (getAtRefList refs i);
          (doFrom (i + 1) proc refs)::Void
      }
   in
      doFrom 0 proc refs

This is usually implemented tail recursively as would be expected for a functional language. However, IvoryScript requires an explicit type constraint on tail recursive applications.

Pattern matching is used by the method property of a rule (typically a built-in function) to filter out particular events of interest. For the standard timer rule, this would involve invoking the appropriate operating system specific functions.

monitorTimer rule::Ref event ads::ADS =
   case event of {
      StartEvent _ -> ...
      -- Instantiate all timers in the store
      
      CreateObjectEvent timer::Timer -> ...
 	   -- O/S specific function to instantiate a timer

      UpdatePropertyEvent After timer::Timer #period
 	   -- O/S specific function to change the period of a timer
   }