In a type secure persistent programming system, all data is governed for its entire lifetime by a single type system. The universality of the persistent type system has implications in terms of both the modelling and protection provided by the type system itself, and also presents some new challenges in terms of implementation. With respect to modelling, the persistent type system must be sufficiently flexible to allow the modelling of activities normally provided by untyped support systems. Such activities include, for example, the linking of separately prepared program units, and file system access protection. Methods of achieving such flexibility whilst maximising safety include the controlled use of infinite unions, parametric and inclusion polymorphism. With respect to protection, the increased role of a type system means that any protection mechanisms programmed at a high level may be fully relied upon to protect the data for its lifetime, as access from outside the constraints...

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 ...

This paper introduces the NODS project been currently conducted at the LSR-IMAG laboratory, Grenoble { France. NODS aims at dening an open, adaptable, evolutionary architecture that can be extended and customized on a per-application basis. A database system is seen as an infrastructure comprised of co-operating adaptable and extensible services from which applications can build their customized NODS database components. Furthermore, services or database systems conguration can be adapted at runtime (e.g., add new services, change services internal policies), according to environmental changes. 1

LIGHTWEIGHT SUPPORT FOR FINE-GRAINED PERSISTENCE ON STOCK HARDWARE FEBRUARY 1995 ANTONY LLOYD HOSKING B.Sc., UNIVERSITY OF ADELAIDE M.Sc., UNIVERSITY OF WAIKATO Ph.D., UNIVERSITY OF MASSACHUSETTS AMHERST Directed by: Professor J. Eliot B. Moss Persistent programming languages combine the features of database systems and programming languages to allow the seamless manipulation of both short- and long-term data, thus relieving programmers of the burden of distinguishing between data that is transient (temporarily allocated in main memory) or persistent (residing permanently on disk). Secondary storage concerns, including the representation and management of persistent data, are directly handled by the programming language implementation, rather than the programmer. Moreover, unlike traditional database systems, persistent programming languages extend to persistent data all the data structuring features supported by the language, not just those imposed by the underlying database system. P...

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.

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.

Persistent programming is concerned with creating and manipulating data in a manner that is independent of its lifetime. The persistence abstraction yields a number of advantages in terms of orthogonal design and programmer productivity. One major advantage is that the abstraction integrates the database view of information with the programming language view. For this reason persistent programming languages are sometimes called database programming languages. A number of design principles have been devised for persistent systems. Following these rules, languages may be designed that provide persistence as a basic abstraction. This in turns begs the question of how these languages should be implemented and what architectural support is required for persistence. Here we will review the concepts of persistence and re-examine the design issues that appear in persistent languages and architectures. 1.

This thesis documents the design and implementation of procedures in a database programming language. The purpose of this thesis is to integrate procedure facilities into an existing relational database system. A relation is defined over a set of attributes. Given the values of a subset of attributes as input, a selection operation looks up the relation and outputs the values of the remaining attributes. Our proposed procedure construct supports this concept: a procedure is defined over a set of parameters, and the procedure can be invoked with different subsets of input parameters. This is accomplished by allowing procedures to have a sequence of blocks within the procedure body. Each block abstracts a sequence of actions which requires a subset of parameters as input. Users can select different blocks to be activated by supplying different subsets of input parameters. While a relation can be selected with any subset of input attributes, a procedure can only be invoked wi...

Persistent programming languages exhibit several requirements that affect the generation of native code, namely: garbage collection; arbitrary persistence of code, data and processes; dynamic binding; and the introduction of new code into a running system. The problems of garbage collection are not unique to persistent systems and are well understood: both code and data may move during a computation if a compacting collector is employed. However, the problems of garbage collection are exacerbated in persistent systems which must support garbage collection of both RAM resident and disk resident data. Some persistent systems support a single integrated environment in which the compiled code and data is manipulated in a uniform manner, necessitating that compiled code be stored in the object store. Furthermore, some systems assume that the entire state of a running program is resident in a persistent store; in these systems it may be necessary to preserve the state of a pro...