In an orthogonally persistent programming system the longevity of data is independent of its other attributes. The advantages of persistence may be seen primarily in the areas of data modelling and protection resulting from simpler semantics and reduced complexity. These have been verified by the first implementations of persistent languages, typically consisting of a persistent store, a run-time system and a compiler that produces programs that may access and manipulate the persistent environment. This thesis demonstrates that persistence can deliver many further benefits to the programming process when applied to software construction and execution. To support the thesis, a persistent environment has been extended with all the components necessary to support program construction and execution entirely within the persistent environment. This is the first known example of a strongly-typed integrated persistent programming environment. The keystone of this work is the construction of ...

Traditional database technology may be extended by taking advantage of the facilities of an integrated persistent programming environment. This paper focuses on how such an environment may be used to provide new solutions to a long standing problem in traditional databases, that of schema evolution. A general mechanism is first described, followed by a description of a specific schema editing tool. The persistent environment provides an underlying technology which allows the schema editor to locate and change, either manually or automatically, all affected program and data. The advantages of the mechanism are that it provides understandable semantics for evolution by controlling when the changes are made and by ensuring that changes to schema, program and data are consistent and made in lock step. It is shown how these changes together may be grouped as a transaction within a live system; furthermore, the accommodation of lazy data changes allows minimum loss of availability.

This paper briefly and selectively reviews the experience gained in designing and implementing the orthogonally persistent programming languages PS-algol and Napier88. A major design issue is how much is built into the support system and how much is built on top of the language itself. The PS-algol and Napier88 systems provide at the system or language level: a persistent store with root(s), reachability and referential integrity; code as data; an infinite union type with dynamic injection and projection; and two type magic procedures, one to find a type representation of a value, and one to convert a sequence of bytes into a language value. Within a strongly typed system this provision allows the programming techniques of strongly typed linguistic reflection, hyper-programming and persistent schema evolution, the last two of which are especially significant since they are new paradigms that are only available in orthogonally persistent systems. The essence of the paper is to suggest h...

. In the last three years we have been working with persistence and distribution, in particular migration of higher-level objects (such as procedures) between autonomous persistent programs. In this paper we introduce persistence and the suitability of Napier88 --- the persistent system we have used for our experiments --- as an agent language. We then present a few examples of opportunities and many more challenges that exist in the combination of persistence with agents. 1 Introduction The main motivation for this paper is our perception that free variables and persistence have not been properly addressed by the agent research community. Persistence is important because many of the examples presented in the agent literature include local or remote database access. Free variables are also of interest --- and unavoidable in a persistent environment --- because data and code are highly and strongly inter-connected in the persistent store. This paper is based on our experience with pers...

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.

The paper describes a new reflective language mechanism and its implementation. The mechanism called Octopus is designed to support a wide variety of database programming and software engineering applications which previously required much heavier weight mechanisms, such as the use of a compiler at run-time, or unsafe language mechanisms. The implementation of this mechanism requires structured type representations to be available for manipulation at run-time and architecture support for boxed values. These implementation techniques are described and the cost of these mechanisms is examined. 1 Introduction In most programming languages, programs and data form directed graphs with nodes consisting of arbitrary values, such as program fragments (e.g. procedures), records and arrays. Scalars form the leaf nodes of the graphs; they may be referenced but do not themselves reference other values. Figure 1.1 shows a conceptual view of such a graph in which the nodes represent ...

Abstract not found

Persistent programming systems are generally recognised as the appropriate technology for the construction and maintenance of large, long-lived object based application systems such as software environments. Here some of the advantages of providing all the support required for the software process within a persistent object store with referential integrity are examined. It is shown that powerful new techniques may be supported by having system specifications, programs, configuration management tools and documentation all within a single persistent environment. 1

Reflective systems allow their own structures to be altered from within. Here we are concerned with a style of reflection, called linguistic reflection, which is the ability of a running program to generate new program fragments and to integrate these into its own execution. In particular we describe how this kind of reflection may be provided in the compiler-based, strongly typed object-oriented programming language Java. The advantages of the programming technique include attaining high levels of genericity and accommodating system evolution. These advantages are illustrated by an example taken from persistent programming which shows how linguistic reflection allows functionality (program code) to be generated on demand (Just-In-Time) from a generic specification and integrated into the evolving running program. The technique is evaluated against alternative implementation approaches with respect to efficiency, safety and ease of use.

Problems with the inconsistent behaviour of system construction components for building large and long-lived application systems are identified. They make the programmer's task harder and the user's world more confusing in the same way that the disharmonies between programming languages and databases did. Persistent programming languages overcame those disharmonies. This paper challenges researchers to design and build a common substrate to the construction components. The construction components would be re-built using the substrate to achieve consistent behaviour. Application systems would then use this new family of construction components. The substrate, called the Scalable Persistent Foundation promises several advantages: consistent application system behaviour even when under stress, accelerated application system building and maintenance, genuine longevity of application systems and improved operational efficiency. The search for a design and implementation of this foundation w...