The purpose of this thesis is to investigate a type system for databases and object-oriented programming and to design a statically typed programming language for these applications. Such a language should ideally have a static type system that supports: • polymorphism and static type inference, • rich data structures and operations to represent various data models for databases including the relational model and more recent complex object models, • central features of object-oriented programming including user definable class hierarchies, multiple inheritance, and data abstraction, • the notion of extents and object-identities for object-oriented databases. Without a proper formalism, it is not obvious that the construction of such a type system is possible. This thesis attempts to construct one such formalism and proposes a programming language that uniformly integrate all of the above features. The specific contributions of this thesis include: • A simple semantics for ML polymorphism and axiomatization of the equational theory of ML. • A uniform generalization of the relational model to arbitrary complex database objects that

This paper discusses work which is a continuation of [Baker90]. Our birth control scheme for objects of LP type bears a strong resemblance to Barnes'es scheme for controlling access to a resource [Barnes89,9.3]. Barnes does not export a nesting generic unit to handle deallocation, however.

The research presented in this thesis is about the design and implementation of Naira, a parallel, parallelising compiler for a rich, purely functional programming language. The source language of the compiler is a subset of Haskell 1.2. The front end of Naira is written entirely in the Haskell subset being compiled. Naira has been successfully parallelised and it is the largest successfully parallelised Haskell program having achieved good absolute speedups on a network of SUN workstations. Having the same basic structure as other production compilers of functional languages, Naira's parallelisation technology should carry forward to other functional language compilers. The back end of Naira is written in C and generates parallel code in the C language which is envisioned to be run on distributed-memory machines. The code generator is based on a novel compilation scheme specified using a restricted form of Milner's ß-calculus which achieves asynchronous communication. We present the f...

Existential data types as described by Mitchell and Plotkin are an appealing model for data abstraction. However, they are somewhat restrictive within a persistent type system, as values created by an existentially defined package may not be stored and retrieved in different static contexts. This is because values of an abstract type are type equivalent only in the scope of the same package opening. This allows packages to be used as first-class values, but precludes the kind of dynamic type check associated with the retrieval of a value from the persistent store. data types and proposes a new adaptation of these types. The resulting type system loses none of the desirable static properties of Mitchell and Plotkin’s model, but is more flexible dynamically and allows a value of a witness type to be stored in one context and retrieved in another. An intuitive explanation of the new model is given, along with formal type checking rules and an implementation strategy. 1

One important concept established through research of persistent programming languages is orthogonal persistence. The techniques so far proposed for this concept are, however, limited to single language systems. This paper proposes a systematic method to achieve orthogonal persistence in a multilanguage system by combining a technique for higher-order remote procedure calls and a mechanism of orthogonal persistence in a single language system. The proposed method can be used to develop a multilanguage persistent type system, where any data of any types including higher-order functions can persist and can later be used from a different language. The necessary data conversion between languages is transparent to the user. In addition to an effective algorithm to implement a multi-language persistent system, our system has rigorous type discipline and formal properties that enable us to show that multi-language sharing preserves the intended semantics of persistent data.

Abstract not found

The programming language Haskell adds object-oriented functionality (using a concept known as type classes) to a pure functional programming framework. This paper describes these extensions and analyzes its accomplishments as well as some problems.

The 3C model was first developed in [Trac 89] and reviewed at last year's workshop [SMTR 90]. This position paper responds to that review, and in doing so outlines a framework for thinking about 3C aspects of an architecture of components. Such components can be said to be normalized in that they capture one concern of the architecture in their content. Keywords: 3C model, generic architectures, normalized components. 1 Introduction The 3C model was presented and reviewed at our previous workshop, The Third Annual Workshop: Methods and Tools for Reuse [SMTR 90]. Will Tracz summarized his perspective on the discussion: The 3C model was accepted in part by most of the attendees. The most critical critisism focused on the granularity of the modules. I believe people were trying to scale up the model to apply to larger subsystems and were having difficulty in expressing the semantics. Another area that needed further clarification is the process of differentiating the roles of im...

Practice has proven that databases are the keystones for nearly all application systems with a wider functionality, utilization and availabilty. As a consequence, next generation database systems will have to provide their services with a degree of interoperability that has to be substantially improved over existing solutions. In this paper we argue that this objective can be achieved only through full exploitation of current developments in computer language technology.

this report may apply, should support following activities: 1. formulation of a requirement (e.g., total correctness statement, or algebraic specification, or process logic formula), 2. description of a construction (e.g. resp., imperative program, or algebra, or process), 3. verification that a given construction satisfies a given requirement. The verification step 3 above cannot, for any realistic classes of requirements and constructions, be fully automated. Therefore, it generates a proof obligation that may be either proven by hand, or passed over to a heuristic theorem prover, or left unproven but recorded in the construction's documentation for future reference, in case something goes wrong. But then, it is acceptable that the steps 1 and 2 generate proof obligations as well. For instance, an attempt to automatically type check a construction might break down at some point, in which case the type checker would generate a proof obligation for that point and then proceed as if everything worked well. It is important that the number and the complexity of generated proof obligations be kept within reasonable limits. In particular, no proof obligations should be generated where no dependent types and no subtypes are involved. This report presents a simple but powerful language SDDP