Introduction

The aim of these notes is to describe the monadic and incremental approaches to the denotational semantics of programming languages. This is done via the use of suitable typed metalanguages, which capture the relevant structure of semantic categories. The monadic and incremental approaches are formulated in the setting of a type-theoretic framework for the following reasons:

• a type theory with dependent types allows a precise, concise and general description of the two approaches, based on signatures as abstract representations for languages;

• there are various implementations (e.g. LEGO and CoQ) which provide computer assistance for several type-theories, and without computer assistance it seems unlikely that either of the two approaches can go beyond toy languages.

On the other hand, the monadic and incremental approaches can be described already with a naive set-theoretic semantics. Therefore, knowledge of Domain Theory and Category Theory becomes essential only in Section 6.

The presentation adopted differs from advanced textbooks on denotational semantics in the following aspects:

• it makes significant use of type theory as a tool for describing languages and calculi, while this is usually done via a set of formation or inference rules;

• it incorporates ideas from Axiomatic and Synthetic Domain Theory into metalanguages, while most metalanguages for denotational semantics are variants of LCF;

• it stresses the use of metalanguages to give semantics via translation (using the monadic and incremental approaches), but avoids a detailed analysis of the categories used in denotational semantics.

Introduction

The aim of these notes is to explain how games can provide an intensional semantics for functional programming languages, and for a theory of proofs. From the point of view of program semantics, the rough idea is that we can move from modelling computable functions (which give the ‘extensional’ behaviour of programs) to modelling ‘intensional’ aspects of the algorithms themselves. In proof theory, the tradition has been to consider syntactic representations of (what are presumably intended to be ‘intensional’) proofs; so the idea is to give a more intrinsic account of a notion of proof.

Three main sections follow this Introduction. Section 2 deals with games and partial strategies; it includes a discussion of the application of these ideas to the modelling of algorithms. Section 3 is about games and total strategies; it runs parallel to the treatment in Section 2, and is quite compressed. Section 4 gives no more than an outline of more sophisticated notions of game, and discusses them as models for proofs. Exercises are scattered through the text.

I very much hope that the broad outline of these notes will be comprehensible on the basis of little beyond an understanding of sequences (lists) and trees. However the statements of some results and some of the exercises presuppose a little knowledge of category theory, of domain theory and of linear logic.

Introduction

The “classical” paradigm for denotational semantics models data types as domains, i.e. structured sets of some kind, and programs as (suitable) functions between domains. The semantic universe in which the denotational modelling is carried out is thus a category with domains as objects, functions as morphisms, and composition of morphisms given by function composition. A sharp distinction is then drawn between denotational and operational semantics. Denotational semantics is often referred to as “mathematical semantics” because it exhibits a high degree of mathematical structure; this is in part achieved by the fact that denotational semantics abstracts away from the dynamics of computation—from time. By contrast, operational semantics is formulated in terms of the syntax of the language being modelled; it is highly intensional in character; and it is capable of expressing the dynamical aspects of computation.

The classical denotational paradigm has been very successful, but has some definite limitations. Firstly, fine-structural features of computation, such as sequentially, computational complexity, and optimality of reduction strategies, have either not been captured at all denotationally, or not in a fully satisfactory fashion. Moreover, once languages with features beyond the purely functional are considered, the appropriateness of modelling programs by functions is increasingly open to question. Neither concurrency nor “advanced” imperative features such as local references have been captured denotationally in a fully convincing fashion.

Introduction

Computational behaviours are often distributed, in the sense that they may be seen as spatially separated activities accomplishing a joint task. Many such systems are not meant to terminate, and hence it makes little sense to talk about their behaviours in terms of traditional input-output functions. Rather, we are interested in the behaviour of such systems in terms of their often complex patterns of stimuli/response relationships varying over time. For this reason such systems are often referred to as reactive systems.

Many structures for modelling reactive systems have been studied over the past 20 years. Here we present a few key models. Common to all of them, is that they rest on an idea of atomic actions, over which the behaviour of a system is defined. The models differ mainly with respect to what behavioural features of systems are represented. Some models are more abstract than others, and this fact is often used in informal classifications of the models with respect to expressibility. One of our aims is to present principal representatives of models, covering the landscape from the most abstract to the most concrete, and to formalise the nature of their relationships by explicitly representing the steps of abstraction that are involved in moving between them. In following through this programme, category theory is a convenient language for formalising the relationships between models.

To give an idea of the role categories play, let us focus attention on transition systems as a model of parallel computation.

A debate has been raging on both CompuServe and the Internet lately about the use and abuse of accessing methods for getting and setting the values of instance variables. Since this is the closest thing I've seen to a religious war in a while, I thought I'd weigh in, not with the definitive answer, but with at least a summary of the issues and arguments on both sides. As with most, uh, “discussions” generating lots of heat, the position anyone takes has more to do with attitude and experience than with objective truth.

Let's see if I can get through this third column on how objects are born without blushing. So far we've seen two patterns: “Objects from States” and “Objects from Collections.” This time we'll look at two more sources of objects: “Objects from Variables” and “Objects from Methods.” All four patterns have one thing in common—they create objects that would be difficult or impossible to invent before you have a running program.

These patterns are part of the reason I am suspicious of any methodology that smacks of the sequence, “design, then program.” The objects that shape the way I think about my programs almost always come out of the program, not out of my preconceptions. Thinking “the design phase is over, now I just have to push on and finish the implementation” is a sure way to miss these valuable objects and end up with a poorly structured, inflexible application to boot.

“I'm not dead yet.” That's what I thought when Don Jackson at SIGS offered to put my articles together into a book. It's probably that every book I've ever seen with “Complete” or “Collected” in the title is no longer with us. Last I checked, I'm still here.

Having established that I am alive enough to be typing this, let's get to the point of the Preface—convincing you to buy this book. You are standing here trying to decide whether to spend your hard-earned dinero for that exquisite literature you saw with the swords and dragons and stuff on the cover or a collection of my articles. Here's my pitch—my entire career has been spent learning how to communicate with other people about programs. This book chronicles how I learned what I know and how I learned to tell people stories about it.

I just finished my first book, The Smalltalk Best Practice Patterns. It is easy to see how a book written end to end can have a single theme. This book has no such theme. It has a story—no, two stories.

The first story could be called “Kent Discovers the Importance of People.” I got into computing to avoid having to deal with people. As a sophomore in high school, I took physics instead of biology so I wouldn't have to try to understand “all that squishy stuff.” The rest of my academic career was spent in search of deeper understanding of the mechanics of things, whether the topic was computing or music.

Previously, I talked about how objects could be created from the states of objects that acted like finite-state machines (the “Objects from States” pattern). I'll continue on the theme of where objects come from for this and several issues.

I won't be saying much about the conventional source of objects, the user's world. There are lots of books that will tell you how to find those objects. Instead, I'll focus on finding new objects in running programs.

In the June issue, where I took on accessor methods, I stated that there was no such thing as a truly private message. I got a message from Nikolas Boyd reminding me that he had written an earlier article describing exactly how to implement really truly private methods. One response I made was that until all the vendors ship systems that provide method privacy, Smalltalk cannot be said to have it. Another is that I'm not sure I'd use it even if I had it. It seems like some of my best “reuse moments” occur when I find a supposedly private method in a server that does exactly what I want. I don't yet have the wisdom to separate public from private with any certainty.

On a different note, I've been thinking about the importance of bad style. In this column, I always try to focus on good style, but in my programming there are at least two phases of project development where maintaining the best possible style is the farthest thing from my mind. When I am trying to get some code up and running I often deliberately ignore good style, figuring that as soon as I have everything running I can simply apply my patterns to the code to get well-structured code that does the same thing.

Should you be using Distributed Smalltalk? That is the question I'll address here. This isn't a full-blown product review, nor a technical piece. I'll introduce the history and technical background of Distributed Smalltalk as they apply to the question of who should be using it.

First, what is Distributed Smalltalk? It is a Common Object Request Broker Architecture (CORBA)-compliant extension to ParcPlace System's Visual-Works developed and marketed by Hewlett-Packard. “HP? The hardware company? Those C++ guys?”

My first reaction when I saw that HP had done a Smalltalk product was, “What does HP know about Smalltalk?” The answer to this question is twofold. One answer is “a lot.” HP has been involved peripherally in Smalltalk since it first escaped Xerox. They were one of the first four companies to write a virtual machine. They have also had pockets of interest in Smalltalk ever since. Their 700 series of workstations has held the title for fastest Smalltalk for several years.

In the last issue, I wrote about what instance-specific behavior is, why you would choose to use it, and how you implement it in Smalltalk-80 …er…Objectworks\Smalltalk (which way does the slash go, anyhow?) …er… VisualWorks (is that a capital W or not?). This month's column offers the promised Digitalk Smalltalk/V OS/2 2.0 implementation (thanks to Mike Anderson for the behind-the-scenes info) and a brief discussion of what the implementations reveal about the two engineering organizations.

I say “brief discussion” because as I got to digging around I found many columns' worth of material there for the plucking. I'll cover only issues raised by the implementation of classes and method look-up. Future columns will contrast the styles as they apply to operating system access, user interface frameworks, and other topics.

I kind of ran out of steam towards the end of that last series on creating new objects. I think the message that many of the most important objects are not the ones you find by underlining nouns in problem statements is still valid. The objects that emerge (if you're watching for them) late in the game, during what is typically thought of as maintenance, can profoundly affect how you as a programmer view the system. By the time I got to the fourth part, though, I was tired of the topic. Those last couple of patterns still deserve some reexamination in the future.