Alex Farkas

Persistent Hyper-Programs

The traditional representation of a program as a linear sequence of text forces a particular style of program construction to ensure good programming practice. Tools such as syntax directed editors, compilers, linkers and file managers are required to translate and execute these linear sequences of text. At some stage in the execution sequence the source text is checked for type correctness and its translated form linked to values in the environment. When this is performed early in the execution process confidence in the correctness of the program is raised, at the cost of some flexibility of use.

Persistent Program Construction through Browsing and User Gesture with some Typing

One method of evaluating programs is for them to be prepared as self contained pieces of source, then compiled, linked and executed. The last phase may involve binding to and manipulating persistent values. When the persistent store is supported by a user interface, the program construction can be augmented by the use of tokens as denotations for persistent values. That is, the manipulation of the persistent store by gesture, for example by an iconic interface linked to a mouse, can be used to provide tokens for persistent values. These tokens can be resolved to provide bindings at run-time, compile-time, program construction time or any mixture of these.

Octopus: A Reflective Language Mechanism for Object Manipulation

A class of database programs exist which are required to operate over an infinite number of types; included in this class are object browsers and query tools. The types over which these programs operate cannot be enumerated statically. One solution to this problem is to provide a reflective language mechanism that permits the types of values to be abstracted over and the values manipulated in a type independent manner; this paper describes such a mechanism. The mechanism is called Octopus which is an acronym for Object Closure Transplantable to Other Persistent User Spaces. The essence of the technique is to allow values from the programming language value space to be hoisted up to a meta level and manipulated in ways which the programming language would not otherwise permit. When manipulation is complete they may be dropped back into the value space, provided that they still conform to the language’s type system. An additional feature of this technique, as the name suggests, is the ability to isolate portions of closures, and copy them to other locations. Partial closures may be rewired, possibly in a different context, using the meta level interface supplied by Octopus.

Current Directions in Hyper-Programming

The traditional representation of a program is as a linear sequence of text. At some stage in the execution sequence the source text is checked for type correctness and its translated form is linked to values in the environment. When this is performed early in the execution process, confidence in the correctness of the program is raised. During program execution, tools such as debuggers are used to inspect the running state of programs. Relating this state to the linear text is often problematical. We have developed a technique, hyperprogramming, that allows the representations of source programs to include direct links (hyper-links) to values, including code, that already exist in the environment. Hyperprogramming achieves our two objectives of being able to link earlier than before, at program composition time, and to represent sharing and thus closure and through this the run-time state of a program. This paper reviews our work on hyper-programming and proposes some current research areas.

Changing Persistent Applications

During the lifetime of an application, the objects and bindings in a persistent store may require modification in order to fix bugs or incorporate changes. Two mechanisms, Octopus and Nodules, supporting the evolution of persistent applications are presented. The first, Octopus permits code and data values to be evolved, even if they are encapsulated. Type evolution is addressed by the separation of type information from the executable code. In many cases type evolution is possible, without the expense of total or partial system recompilation. Nodules are a complementary mechanism to Octopus in that they allow generic templates to be defined independently of any referencing environment. Nodules may be specialised in order to yield instances by binding them to values and types. When combined into a single system, Nodules and Octopus enable a rich collection of information about the structure and state of applications to be maintained and made available to programmers not only during the construction phase, but during the entire lifetime of applications.

Keynote Discussion on Evolution in Persistent Systems

Evolution is without doubt one of the hardest problems to address with respect to programming systems. When the systems under consideration handle large amounts of long-lived data, the ability to handle evolution becomes not only essential, but also even harder to provide. When some of the intrinsic restrictions of traditional databases are removed, as is the case with persistent programming systems, the problems become harder still.