Abstract. This paper describes a new language feature that is a hybrid of labels and procedures. It is closely related to jumping out of a functional subroutine, and includes conventional labels and jumping as a special, but probably not most useful, case. It is independent of assignment, i.e., it can be added to a “purely-functional” (“non-imperative”) system (such as lisp without pseudo-functions or program feature). Experiments in purely functional programming suggest that its main use will be in success/failure situations, and failure actions. This innovation is incorporated in the projected experimental system, iswim. Keywords: “Explaining to programmers the logical structure of programming languages is like a cat explaining to a fish what it feels like to be wet”—Gorn.

. 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...

The early sixties saw conventional labels "got rid of", and then reintroduced in a nuclear variant that was hoped to be so awesome that they would never be used again except for exceptions. But guilt-free remote control of dangerous instruments was already undermining the entente. This note is a very personal view of, and from, the first half of that decade, with very close horizons. But there is a lesson to be drawn. In the phrase "the meaning of rest of the program", there has been the same snare that sometimes traps people into not recognizing when, and when not, it's safe to confuse a node of a DAG with its reachable sub-DAG. Mile End Road, London E1 4NS, UK. E-mail: P.Landin@dcs.qmw.ac.uk 1-1 1 J J popped out onto the the third galleys of the 1965 CACM article "A Correspondence between ALGOL 60 and Church's Lambda Notation" [4]. So much for refereeing. Indeed, scrutiny of that paper seemed concerned only with whether a space should separate "algol" and "60". It was a ...

Domain engineers describe universes of discourse such as bookkeeping, the financial service industry, container shipping lines, logistics, oil pipelines, railways, etc. In doing so domain engineers have to decide on such issues as identification of that which is to be described; which of the describable phenomena and concepts are (to be described as) entities, operations, events, and which as behaviours; which entities are (to be described as) continuous which are (...) discrete, which are (...) atomic, which are (...) composite and what are the attributes of either and the mereology of composite entities, i.e., the way in which they are put together from sub-entities. For each of these issues and their composite presentation the domain engineer has to decide on levels of abstraction, what to include and what to exclude. In doing so the domain engineer thus has to have a firm grasp on the a robust understanding and practice of the very many issues of description: what can be described, identifying what is to be described, how to describe, description principles, description techniques, description tools and laws of description. This paper will outline the issues in the slanted type font.