The design of a module system for constructing and main- taining large programs is a difficult task that raises a number of theoretical and practical issues. A fundamental issue is the management of the flow of information between program units at compile time via the notion of an interface. Experience has shown that fully opaque interfaces are awkward to use in practice since too much information is hidden, and that fully transparent interfaces lead to excessive interdependencies, creating problems for maintenance and separate compilation. The "sharing" specifications of Standard ML address this issue by allowing the programmer to specify equational relationships between types in separate modules, but are not expressive enough to allow the programmer com- plete control over the propagation of type information be- tween modules.

Statically typed programming languages allow earlier error checking, better enforcement of disciplined programming styles, and generation of more efficient object code than languages where all type consistency checks are performed at run time. However, even in statically typed languages, there is often the need to deal with data whose type cannot be determined at compile time. To handle such situations safely, we propose to add a type Dynamic whose values are pairs of a value v and a type tag T where v has the type denoted by T. Instances of Dynamic are built with an explicit tagging construct and inspected with a type safe typecase construct. This paper explores the syntax, operational semantics, and denotational semantics of a simple language including the type Dynamic. We give examples of how dynamically typed values can be used in programming. Then we discuss an operational semantics for our language and obtain a soundness theorem. We present two formulations of the denotational s...

Typed λ-calculus is an important tool in programming language research because it provides an extensible framework for studying language features both in isolation and in their relation to each other. In earlier work we introduced a predicative function calculus, XML, for modeling several aspects of the Standard ML type system. Following MacQueen, our study focused on the use of dependent types to represent the modularity constructs of Standard ML. In addition to shedding some light on the trade-offs between language features, our analysis suggested that the first-order modules system of ML could be naturally extended to higher orders. However, whereas ML maintains a clear distinction between compile-time and run-time in both its implementation and formal semantics, the XML calculus blurs this distinction. Since static type checking is, in our view, essential to the practical utility of ML, we introduce a refinement of the XML calculus for which type checking is decidable at compile time....

A theory of data types and a programming language based on category theory are presented. Data types play a crucial role in programming. They enable us to write programs easily and elegantly. Various programming languages have been developed, each of which may use different kinds of data types. Therefore, it becomes important to organize data types systematically so that we can understand the relationship between one data type and another and investigate future directions which lead us to discover exciting new data types. There have been several approaches to systematically organize data types: algebraic specification methods using algebras, domain theory using complete partially ordered sets and type theory using the connection between logics and data types. Here, we use category theory. Category theory has proved to be remarkably good at revealing the nature of mathematical objects, and we use it to understand the true nature of data types in programming.

Data Types Konstantin Läufer Martin Odersky Loyola University of Chicago Universität Karlsruhe laufer@math.luc.edu odersky@ira.uka.de June 5, 1994 Technical Report LUC-001 Abridged version appeared in Transactions of Programming Languages and Systems Abstract Many statically-typed programming languages provide an abstract data type construct, such as the module in Modula-2. However, in most of these languages, implementations of abstract data types are not first-class values. Thus they cannot be assigned to variables, passed as function parameters, or returned as function results. Several higher-order functional languages feature strong and static type systems, parametric polymorphism, algebraic data types, and explicit type variables. Most of them rely on Hindley -Milner type inference instead of requiring explicit type declarations for identifiers. Although some of these languages support abstract data types, it appears that none of them directly provides light-weight abstract dat...

A formal methodology is presented for the systematic evolution of modular Standard ML programs from specifications by means of verified refinement steps, in the framework of the Extended ML specification language. Program development proceeds via a sequence of design (modular decomposition), coding and refinement steps. For each of these three kinds of steps, conditions are given which ensure the correctness of the result. These conditions seem to be as weak as possible under the constraint of being expressible as "local" interface matching requirements. Interfaces are only required to match up to behavioural equivalence, which is seen as vital to the use of data abstraction in program development. Copyright c fl 1989 by D. Sannella and A. Tarlecki. All rights reserved. An extended abstract of this paper will appear in Proc. Colloq. on Current Issues in Programming Languages, Joint Conf. on Theory and Practice of Software Development (TAPSOFT), Barcelona, Springer LNCS (1989)....

. We precisely characterize a class of cyclic lambda-graphs, and then give a sound and complete axiomatization of the terms that represent a given graph. The equational axiom system is an extension of lambda calculus with the letrec construct. In contrast to current theories, which impose restrictions on where the rewriting can take place, our theory is very liberal, e.g., it allows rewriting under lambda-abstractions and on cycles. As shown previously, the reduction theory is non-confluent. We thus introduce an approximate notion of confluence. Using this notion we define the infinite normal form or L'evy-Longo tree of a cyclic term. We show that the infinite normal form defines a congruence on the set of terms. We relate our cyclic lambda calculus to the traditional lambda calculus and to the infinitary lambda calculus. Since most implementations of non-strict functional languages rely on sharing to avoid repeating computations, we develop a variant of our calculus that enforces the ...

Extended ML is a framework for the formal development of programs in the Standard ML programming language from high-level specifications of their required input/output behaviour. It strongly supports the development of modular programs consisting of an interconnected collection of generic and reusable units. The Extended ML framework includes a methodology for formal program development which establishes a number of ways of proceeding from a given specification of a programming task towards a program. Each such step gives rise to one or more proof obligations which must be proved in order to establish the correctness of that step. This paper is intended as a user-oriented summary of the Extended ML language and methodology. Theoretical technicalities are avoided whenever possible, with emphasis placed on the practical aspects of formal program development. An extended example of a complete program development in Extended ML is included.

Machine" [BB90], except that there are no "cooling" and "heating" transitions (the process sets of this semantics can be thought of as perpetually "hot" solutions). The concurrent evaluation relation extends "7\Gamma!" to finite sets of terms (i.e., processes) and adds additional rules for process creation, channel creation, and communication. We assume a set of process identifiers, and define the set of processes and process sets as: ß 2 ProcId process IDs p = hß; ei 2 Proc = (ProcId \Theta Exp) processes P 2 Fin(Proc) process sets We often write a process as hß; E[e]i, where the evaluation context serves the role of the program counter, marking the current state of evaluation. Definition4. A process set P is well-formed if for all hß; ei 2 P the following hold: -- FV(e) = ; (e is closed), and -- there is no e 0 6= e, such that hß; e 0 i 2 P. It is occasionally useful to view well-formed process sets as finite maps from ProcId to Exp. If P is a finite set of process state...

This paper describes eXene, a user interface toolkit implemented in a concurrent extension of Standard ML. The design and use of eXene is inextricably woven with the presence of multiple threads and a high-level language. These features replace the object-oriented design of most toolkits, and provide a better basis for dealing with the complexities of user interfaces, especially concerning such aspects as type safety, extensibility, component reuse and the balance between the user interface and other parts of the program. 1