Program construction and evolution in a persistent integrated programming environment.

In orthogonally persistent systems, data is treated independently of its persistence allowing storage management details to be ignored by programmers. The coexistence of all data within a persistent repository provides new opportunities for the persistent environment to participate in a number of software engineering processes, namely, software: . construction, . debugging, . maintenance, . evolution, and . distribution. A novel programming methodology supporting various styles of binding allows the persistent environment to participate in the software construction process. Existing programs and data may be bound to an application at different times during the application's lifetime, namely, at run-time, compile-time and program construction-time. This wide range of binding styles enables. the programmer to trade off binding safety and binding flexibility. A mechanism called Octopus enables the programmer to access a rich source of information about the bindings within arbitrary values. Using this information, existing applications may be interrogated and manipulated in ways in which the programming language alone would not normally permit. However, Octopus ensures that the type system of the programming language remains inviolate, thus providing a type safe mechanism for constructing debugging, maintenance and evolutionary tools. Another feature of Octopus is that it permits portions of an application's object graph to be isolated and transmitted. Nodules permit a style of template programming that enables data values and executable code to be shared between different Nodule instances. The essence of this mechanism is to allow programs to be constructed and compiled without the requirement that the values used by the program be present. In this manner, individual components may be constructed independently and later assembled to form a complete application. Nodules also provide a rich source of information about the structure of an application and may be used in conjunction with Octopus to develop and maintain software components. This thesis describes in detail a persistent programming environment, the Octopus and Nodule mechanisms, and illustrates how each of these mechanisms, when used in conjunction with each other, provide a persistent integrated programming environment that supports a wide variety of software engineering activities otherwise lacking in conventional, or non-persistent systems.Thesis (Ph.D.) -- University of Adelaide, Faculty of Engineering, 199

Multiparadigm data structures in Leda

Multiparadigm programming is a term used to describe a style of software development that makes use of facilities originally designed in support of a number of different programming language paradigms. In this paper we illustrate our conception of multiparadigm programming, by describing how various data structures can be implemented in the programming language Leda. Leda is a strongly-typed compiled multiparadigm programming language that we have been developing over the past several years. Our exposition serves both to illustrate the idea of multiparadigm programming, and to describe the features of the language Leda

LEDA : a blending of imperative and relational programming

This paper describes features of a new strongly typed, compiled programming language, called LEDA. LEDA attempts to combine aspects of both imperative (value-oriented) and logical (relation-oriented) styles of programming. Logical behavior is introduced by means of a new programming structure, called a relation. Relations have similarities to functions and procedures, but are distinct from both. Several examples are presented illustrating how the combination of features from the two paradigms are mutually beneficial. Finally a short overview of the implementation is given

Low cost first class functions

We describe a. new approach to implementing functions as first class values. Using this technique, there is no additional overhead imposed for the most common case, that of non-nested functions bound at compile time. Invoking function values assigned to variables requires two additional instructions. It is only when functions are invoked which contain nested functions that can outlive their defining context that the full overhead of the construction of dynamic closures is required. The approach is being used in a new strongly typed compiled multi-paradigm programming language being developed by the author