. This note introduces Peter Landin's 1965 technical report "A Generalization of Jumps and Labels", which is reprinted in this volume. Its aim is to make that historic paper more accessible to the reader and to help reading it in context. To this end, we explain Landin's control operator J in more contemporary terms, and we recall Burge's solution to a technical problem in Landin's original account. Keywords: J-operator, secd-machine, call/cc, goto, history of programming languages 1. Introduction In the mid-1960's, Peter Landin was exploring functional programming extended with control. Initially, Landin had added the control operator J (for jump) to his language of Applicative Expressions in order to explicate the goto statement from Algol 60 [10]. This general control construct, however, was powerful enough to have independent interest quite beyond the application to Algol: Landin wrote a series of technical reports [11, 12, 13] on functional programming with control, the most si...

This paper is a condensed version of the author's PhD thesis [19]. Besides the compiler for the im- perative language described in this paper, the thesis derives implementations of a simple functional and a simple logic programming language

oatatioa ad :ato am//d acbiea. The components ff NIP am: a distributed abared eo ate otiisedram//d object-odeted rora6' : distdbti o oe: the 0dea ff tbe am//d ate. Theater deabea the :eimets /aaed o the Keords: Implicit Parallelism; Neorks oF Workstations; Lazy Task Creation; Distributed Shared Memos.

This document describes version 4.5 of the Q programming language and system.

In this paper we introduce a calculus VPD for vernacular program derivations. We show that this calculus is in accordance with practice (in the sense of Feferman) by providing an interpretation of VPD derivations as idiomatic English. We also show how VPD derivations can be given a precise intensional semantics in terms of proofs within a theory of types and operations EOL (based on the theory EON due to Beeson). The main result, the adequacy theorem show that these proofs are intensionally adequate models of the VPD derivations. The paper revolves around a worked example: the derivation of the insert-sort algorithm from a specification of sorting. This example serves to illustrate the ideas informally. 2 Introduction This paper concerns the relationship between what we will call vernacular program derivation and formal program derivation. Vernacular arguments are those one might expect to find in a text-book. They may be precise but are not fully explicit. They are, in principle...

Implicitly parallel programming languages place the burden of exploiting and managing parallelism upon the compiler and runtime system, rather than on the programmer. This paper describes the design of NIP, a runtime system for supporting implicit parallelism in languages which combine both functional and objectoriented programming. NIP is designed for scaleable distributed memory systems including networks of workstations and custom parallel machines. The key components of NIP are: a parallel task execution unit which includes a novel and efficient method for lazily creating parallel tasks from loop iterations; a novel distributed shared memory system optimised for parallel object-oriented programs; and a load balancing system for distributing work over the nodes of the parallel system. The paper describes the requirements placed on the runtime system by an implicitly parallel language and then details the design of the components that comprise NIP, showing how the components meet these requirements. Performance results for NIP running programs on a network of workstations are presented and analysed.

ing out and studying those patterns of computation as useful objects in their own right leads to further insights into the nature of computation. The list operators studied later in these notes follow this approach. ffl Functional programs are usually an order of magnitude more concise than their imperative counterparts. Besides being shorter, they can be much more readable. The functional community like to cite studies that show the number of bugs per line is more or less constant, independent of the level of the language in use. Higher-level languages encode more concept per line, and therefore have relatively fewer bugs. ffl Functional programs are often more akin to formal specifications than their conventional counterparts. A good notation goes a long way towards solving the problem[47]. ffl Lazy evaluation permits a new approach to some algorithms. It is a simple but powerful idea that can remove the need for explicit backtracking, and can allow the programmer to manipulate in...

ions . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4.5 Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4.6 Case Distinctions . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.4.7 Extended Expressions . . . . . . . . . . . . . . . . . . . . . . . . 21 4 Parameterization 22 4.1 Parameterized Structures . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2 Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5 Names and Scopes 25 5.1 Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.1.1 Origin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.1.2 Kind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.1.3 Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.1.4 Overload Resolution . . . . . . . . . . . . . . . . . . . . . . . . . 27 CONTENTS 2 5.2 Scopes . . . . . . . . . . . . . . . . . . . . . . . . ....

this report, deals only with the constructive aspects of the language, i.e., the signature part and the implementation part

Abstract not found