Conceptualising Programming Language Semantics

Abstract

The semantics of programming languages tend to be discussed with high levels of formality; much of the previous research—both philosophical and historical—has investigated them from this perspective. In this paper, I draw on the philosophical and cognitive theories of metaphor and use the early work of Adriaan van Wijngaarden as a historical case study to explore the conceptual and discursive surroundings of semantics. I investigate the relationships between the texts of semantics, the abstract entities they denote, and the metaphors, analogies, and illustrative language used to accompany or explain the same. This serves to further understanding of the historical developments of work in this area, the nature of programming languages and their semantics, and the importance of the communicative methods used in dissemination and education of computer science.

1. Introduction

“If, however, the user does not trust his intuition or does not understand what the short description on the lid implies in a particular case, he can open the machine to inspect the precise working. To his surprise, he finds there are actually two machines inside, named $P1$ and $M1$. The working of the machines is explained in much more detail on the lids of the machines. The machine $P1$ is a so-called preprocessor, which chews the offered text and produces another text in a more basic language which is evaluated by the processor, i.e., machine $M1$.”

What is the entity being described here? This passage ([1], p. 18) describes the core of the approach to programming language semantics presented by Adriaan van Wijngaarden in two papers in the first half of the 1960s [1,2]. This may not be immediately apparent, since the passage is redolent in non-literal language: An extended machine metaphor—itself somewhat anthropomorphised—chewing a key object within its jaws: text. The presentation of this image of programming languages provoked consternation when Van Wijngaarden presented it to an audience of programmers, language theorists, and mathematicians. Why did Van Wijngaarden choose this way of demonstrating his work? Why was the reaction so confused? And what can be learnt by studying the language used?

The present paper will explore this early effort to understand the semantics by examining the use of conceptuality: metaphor, analogy, and example—what I call “illustrative devices”, as a reflection of “rhetorical devices”, but with an emphasis on their explanatory nature. My previous work has explored the history of programming language semantics, and concurrency in programming, from a history of science perspective [3,4]. As proposed in the second cited paper, this promises to be a rich vein of study and one which I intend to explore in future research projects. Drawing on considerations of metaphor and conceptuality in mathematics and science, I will take Van Wijngaarden’s work as a case study and argue that by exploring the illustrative devices used by computer science, we can better understand the nature of the field, and its history. In this paper I will use “semantics” to mean that of programming languages except where disambiguation is required.

The discourse around computers is packed with non-literal language, at the level of hardware (Bus), software (Semaphore), interface (Window), application (File) and socio-technical systems (Follow).1 One important and relevant illustrative device is Language itself, examined carefully by Nofre, Priestley, and Alberts [6].2 The authors track and explain the rise of Language to describe the notations used in formulating the instructions given to computers. The metaphor emerged towards the end of the 1950s as the expressive power of the computer was being realised, and as comparisons with “giant brains” [9] fell out of fashion. As Language was evoked to conceptualise programming, notions were brought along not just from linguistics—like syntax and semantics—but from formal logic too [10]. This not only provided programmers and computer scientists with a new set of tools for discussing their objects of study3 but shaped how these objects were formed and handled epistemically [3]. This carefully explored example shows the value of considering illustrative devices to aid in understanding the ontology of computational objects and critically also the history of computing, as the authors showed how the use of the Language metaphor was contingent on the intellectual context in which the historical actors operated.

Most philosophy written about programming language semantics is about the ontology of programs and concerned almost exclusively with the technical properties of the entities.4 For example, White wrote a brief overview of how semantics might be used and some challenging ontological aspects, but the material is technical and overly focused on one specific approach to semantics [13]. Rapaport [14,15] argued that semantics describes the way that given abstractions can be interpreted to form an implementation. In his textbook On the Foundations of Computing, Primiero mentioned semantics only in the context of its role in the program correctness effort [16]. Probably the most prolific writer on the philosophy of programming language semantics is Turner. In [17], he laid out a series of motivating questions, many of which still remain open, and of which many are considered in the present special issue:

“Knowing a language involves more than knowing its syntax; knowing a language involves knowing what the constructs of the language do, and this is semantic knowledge. In general, without such knowledge it would not be possible to construct or grasp such programs. But how is this semantic content given to us; how is it expressed? What constraints or principles must any adequate semantic account satisfy? What are the theoretical and practical roles of semantic theory? Is natural language an adequate medium for the expression of semantic accounts? These are some of the questions that any conceptual investigation of programming language semantics must address. [...] What are the relationships between [the] various approaches? Do they complement each other or are they competitors? Is one taken to be the most fundamental?”

I contend that by investigating the illustrative devices used in semantics we will be able to provide a different set of answers to these questions to those already being posed.

The literature on philosophy of mathematics is likewise very concerned with ontology, as noted by Pérez-Escobar, who observed that discussion of mathematicians’ practice is regularly neglected in favour of testing broader philosophical questions about ontology and metaphysics [18]. One notable exception is a study by Sha of the a-linguistic writing and performance practices of differential geometers [19], a deep and unconventional analysis of the way in which these practices allow the exteriorisation of mathematical thought, which may be communicated with others or, once modified, reinteriorised. By considering the mathematical practice of performance—meaning a combination of acts of speech, writing, and bodily movements—a different ontology of mathematics is formulated. A similar analysis, with a more historio-sociological focus, is that of blackboard practice by Barany and MacKenzie [20]. They explored the specifics of chalk-on-board and its accompanying gestures, discursive shapes, and behaviours; interestingly, while the authors hinted at the metaphorical power of the chalk, they did not go on to analyse it in much depth, being concerned more with the graphic, spatial, and spoken aspects of the practice.

Even Maddy [21], commended by Pérez-Escobar for paying attention to mathematical practice, discussed it in the context of advocating for a realist ontology. Maddy highlighted the tension between the behaviour of mathematicians suggesting that their objects of study really exist and the formalist position of meaningless symbol manipulation as a theoretical fallback when paradoxes emerge. Shapiro [22] calls this “Benacerraf’s dilemma” (after [23]), arguing that an antirealist philosophy provides a strong epistemology but makes it hard to keep a continuity between semantics of mathematics and everyday language, which seems necessary due to their combined usage in the sciences. Shapiro’s own solution is to favour structuralism, in which mathematics becomes the study of patterns (on structures) and its objects are places within those structures, given properties only by their relationship to other things in the structures.

Computer science is even further within the grip of formalism than mathematics, as argued by MacKenzie [24]. Those interested in using mathematical/logical tools for verifying program correctness (typically called “formal methods”)5 tend to believe more in the value of symbol manipulation rules for reasoning about programs than the social processes of mathematical proof. Programming language semantics fits within this framework as a method for establishing the intended meanings of programs; historically, the semantics effort predates most formal methods work but is closely tied in terms of goals, methods, and involved people [3].

Rather than ontology, then, in this paper I will consider programming language semantics from the perspective of its illustrative devices. My discussion centres on the Van Wijngaarden case study to inform the investigation and to allow its history to be illuminated by the philosophical discussion. I begin by exploring some key frameworks for understanding non-literal language, sketch some of the historical background on programming languages before heading into the case study, and finish by looking at a number of reasons for further studying the illustrative devices of computing.

One final note: texts will appear regularly in this paper. We should be straight about the difference between (a) the text of the formal object which constitutes the semantics; (b) the accompanying discussion which serves to explain and illustrate (a); (c) the text in the metaphor A Program is a Text used by Van Wijngaarden to illustrate his work. In this paper, I intend to focus my analysis on (b), although analyses of the others may occur from time to time, or in future work.

2. Metaphor

One major work studying the effects of metaphors is the theory of embodied cognition, the work of Lakoff and Johnson [27,28] (helpfully summarised by [29]). The theory states that human cognition and understanding is embodied and metaphorical. Metaphors shape the way we form conceptual links between ideas and create understanding, particularly for abstract concepts which use metaphors to transfer structures and properties from simpler source to more complex target domains (for example, Love is Burning). The embodiment comes from the ultimate base-level concepts, which are formed from bodily experiences, such as Human Intimacy is Warmth (arguably from the bodily proximity of a newborn to a parent). Alongside the first joint book, further work by Lakoff, Johnson, and additional authors explored the use of metaphors in mathematics [30], philosophy [31], and science [32]. Gibbs [33] collects the perspectives of many authors applying the theory in various areas.

Their ontological position is called “embodied realism”, as a way to balance objectivism and relativism, a pragmatic attitude where truth is judged to exist when a model works sufficiently in a given (social) situation, stands up to scrutiny from different perspectives, and its tenets are formed from the convergence of diverse methods. This informs their “empirically-responsible philosophy” ([34], p. 3), the principle that philosophy should (as much as possible) align with the results of empirical science.

In more abstract domains, however, like that of semantics, truth becomes more ambiguous and comes to rely more on internal consistency than anything empirical; here, the theory tells us less about how to use metaphors to aid in understanding. We must take care, since abstraction is a key principle in computing [11,35] and especially central to semantics ([36], Ch. 1). Since levels of abstraction are also a way to understand the ontology of computation itself [16], we must ensure we can understand how abstraction is dealt with as effectively as possible. There is an interesting parallel here to the mathematics of Ancient Greece as presented by Netz, where the necessity of a proof was built from the necessity of its opening statements, properties taken for granted by the writer and audience, and maintained only through the combination of these in appropriate ways [37]. This particular proof practice worked due to its social context: belief in the value of oral persuasion and recognised expertise.

Lakoff and Johnson’s framework, however, centres embodied interpretation above all other potential influences on metaphor choice and usage, such as cultural contingency. Alongside other criticisms (some of which are summarised in [29]), Friedman [38], citing Lassègue [39], notes that the approach “flattens” notions of concept by reducing everything to embodied and sensorimotor roots, which ignores the socio-cultural origins of metaphors in mathematics.6 Embodied cognition focuses heavily on the universality of embodied experiences, yet as more abstract metaphors tend to be built from other metaphors, there is far more opportunity for cultural contingency. Further issue is taken with the embodied basis by Sha, who notes that certain examples of their supposedly basic and universal concepts, such as “chair” and “blond”, are in fact heavily culturally contingent [19]. Sha also challenges the idea that the human body should be the model for the understanding of every concept. The absence of any other medium for interpreting concepts, such as those present in mathematics, could lead to a narrow and overly anthropocentric ontology; while I promised to limit ontology, it is worth pausing a moment to note that the inclusion of computers as non-human agents suggests we might consider whether other frames of interpretation might be necessary.

In contrast to Lakoff and Johnson, Friedman outlines the position of Blumenberg. Here, the central notion is “concept”, which may be literal but is usually non-literal and thereby closer to my “illustrative device”. For Blumenberg, the development of concepts is characterised by an exploration of an unknown space, a Vorfeld (forefield) of nonconceptuality. This process is immediately partial and may take quite some time (and frequent repetition). The role of metaphor here is to provide the linguistic and cognitive tools to explore the Vorfeld.

Returning to philosophy, the theory of embodied cognition is an important challenge to the idea that logic is a priori, disembodied, and literal [34]. However, we must recognise that much of the work on programming language semantics (if not all) is in the formalist tradition, with its notions of set-models and meaningless symbols given meaning only via relation with these models. An alternative, which may be of use when we think about illustrative devices, is to consider simulation semantics, originating in the work of Barsalou and colleagues in cognitive science (e.g., [40,41]). Their framework for conceptual understanding of words, supported by some empirical study, combines a linguistic system which recognises the form and linguistic relations of words, and a situated simulation system which in which the mind recreates images of experiences related to the concept. The situation of the simulation is relevant, with the same word producing different simulations depending on situation; the situation may be in the moment, in previous experiences, or in the linguistic context of the concept to be understood. Simulation semantics, as explained by Johnson, is the way in which meaning is given to entities by mental simulation of engagement with the affordances of those entities (and further empirical study suggests that limited neuronal activity in this situation mirrors that of taking the affordance) [32]. With formal objects like programming languages, one simulates these affordances by imagining oneself writing a statement; calculating an output value; or determining how many times a loop runs in a particular case. The choice of the words used to evoke these concepts, consequently, matters, as this influences the affordances present in the situated simulation.

This can be seen as a case of extended cognition [42], where aspects of the cognitive processes of thought, understanding, and meaning are externalised from the brain and placed in outside entities (or, more accurately, in the human–entity nexus). This could be in dialogue with another human, written words on paper, chalk on a board, or even virtual assistants.7 Why could these external entities not include programming language semantics? Understanding cognitive practice must include understanding its metaphors, Friedman argues [38], taking the example of oceanic metaphors in mathematics as a way to frame encounters with the unknown.

Knowability is a key aspect of the philosophical study of metaphor presented by Ricoeur [44]: while a metaphor’s interpretation is questionable, as in the Vorveld of Blumenberg, it is considered “living”; once its meaning is understood without ambiguity, the metaphor is dead. Writing about this work, Vincent noted “the foundation of hermeneutics is the discursive operation of all language, to which metaphor is the indispensable key.” ([45], p. 413). Hermeneutics is the study of interpretation [46], and programming language semantics often attempts to resolve many questions of interpretation, albeit in a somewhat constrained manner. One kind of operational semantics, started by McCarthy [47], is known as “abstract interpreters” ([36], p. 38), and more generally, many writers (including Van Wijngaarden ([1], p. 17)) wrote of “interpreting” programs using either a written semantics or an intuitive understanding of the language.

Therefore, studying the metaphors used to accompany semantics could aid in our understanding thereof, as they shed light on the interpretative positions of the semantics writer. While Ricoeur wrote only about the use of metaphor in a purely natural linguistic context, interesting parallels can yet be drawn to programming language semantics. He argued that analysis cannot be purely based on the pair of denotation and connotation (my words); reference must be included. He also argued that a model can be judged on its authenticity—how effectively it redescribes reality. These questions will recur in the study of programming languages, both because programming languages are the tools used to create models of reality (i.e., programs) and because semantic descriptions of programming languages are themselves models of an implementation (and perhaps also vice versa).

Another direction which we might take from philosophy of language is to consider the use of rhetoric and its associated devices, such as the four “Master Tropes” of Burke [48]: alongside metaphor and metonymy, synecdoche and irony are also present. We have discussed metaphor; Burke’s definition is one of perspective, a reframing of one concept in terms of another in order to highlight some particular quality of the concept in question. Irony, or dialectic, presents an interesting direction: by putting the historian in the position of Burke’s privileged observer, we are afforded the ability to grasp at the true nature of something—in this case, the semantics of programming languages—by examining dialectic formed by the interaction of the perspectives of each historical actor. That, however, would require the historian to have a comprehensive overview of those perspectives and a firm confidence in their interpretive analysis; at this stage in my research, I have neither. Synecdoche, per Burke’s definition, comes closest to my interests here: the representation of a concept by some related aspect of it; specifically, metonymy is a reduction, a “convey[ing of] some incorporeal or intangible state in terms of the corporeal or tangible” ([48], p. 424). If we allow abstract concepts to be these incorporeal or intangible states, then metonymy could be at play when the semantics of programming languages is described with some other device. Metonymy is a key component of another rhetorical analysis: Netz’s study of the development of deduction in Ancient Greek mathematics [37]. He argues that the lettered diagram is a metonym of the mathematical argument, serving to represent and illustrate without capturing the entirety of the proof. Netz shows the value of close reading to the “cognitive historian” (his term) and develops a convincing case to explain how the persuasiveness and generality of Greek proofs emerged from their social structures and oral traditions. This suggests that a reading of computer science texts as rhetorical works, replete with rhetorical devices, could be a worthwhile direction of study.

However, within the current paper, I intend to keep my focus on illustrative devices. I justify this by arguing that computer science texts are replete with complex illustrations containing analogies, scenarios, and examples. Consider the dining philosophers scenario [49], as analysed in [4]. Can this really fit within the framework of embodied metaphors? Yet, all the key aspects of representation (processes as philosophers), embodiment (resource utilisation as eating), and culture (spaghetti) are clearly present. Surely, this is just as deserving of study as the idea that a programming notation is a language. In the remainder of this paper, then, I shall draw from the ideas presented in the various analyses of metaphor mentioned in this section and recognise and acknowledge the presence of further literature or rhetorical devices where they are emergent. I intend not limit myself to (for example) the purely embodied basis of Lakoff and Johnson; and rather to take a broad view of illustrative devices in considering how we can understand the nature of semantics and its history—starting by situating it within the story of programming languages themselves.

3. Machines, Notations, and Languages

The history of programming languages really requires a full-length book study yet has to cope with four internalist retrospective volumes [50,51,52,53], and assorted papers on specific topics (e.g., [54,55,56,57] on ALGOL alone). A short introduction here must suffice.

Early computers were given “orders” encoded into machine-readable commands, with a structure closely mirroring that of the hardware [58]. As the complexity and power of machines grew, programs became longer, and there was a desire for more compact and human-intelligible programs [59]. Storing program texts on the computer enabled such richer programming systems [10]. One example was the “subroutine”, a frequently used sequence of commands bundled together; these were originally saved in a (paper) notebook before later being loaded from machine storage [60]. Programs were made by compiling various such subroutines, providing the origin for “compiler”. An important routine was the “interpreter routine” which could translate programs written in a pleasant notation into machine code on the fly [61].

Hopper later referred to one such system, the MIT Summer Sessions Computer, as a “mask” being worn by Whirlwind, the computer on which it was running in 1952 [62]. This put a different face on the machine, one with a friendlier demeanour towards the students using it. It is worth observing that Hopper referred to the program providing this “mask” not as a system or notation or language, but actually as a different machine.

“Coding” entered the lexicon of the computer user from that of the telegraph operator, and denoted the (often repetitive, boring, later gendered, and even later “reclaimed”) task of translating a desired behaviour into a machine-readable (but human-unreadable) notation [63].8 Coding systems, programs which automated some of the task of coding, grew in popularity, flexibility, and number throughout the 1950s, with some even still enduring today. The programs created with these systems became increasingly important to their users, who wanted to be able to run them on newly acquired machines, or to share programs across organisations with different machines—ignoring differences in hardware. Thus grew the search for an ultimate, or universal, language in which such programs could be easily expressed and could be easily compiled or interpreted for any machine [6,11].

The goal of an ultimate universal language has a longer history, much of which is covered in Umberto Eco’s Search for the Perfect Language, though he does not consider programming or other scientific languages [64]. Blumenberg wrote that mathematics had such an ideal since the time of Descartes, yet it proved repeatedly unreachable [38]. This, argued Friedman, was unavoidable: a universal language with no ambiguity, as Descartes desired, would be without metaphor, and it is in fact the power of both metaphor and ambiguity which enables nonconceptuality—encounters with the not-yet-known—providing the discovery mechanism for new knowledge. The Language metaphor for programming, for example, enabled ideas of translation, and new definitions of equivalence as “mutually inter-translatable” [11].

Another important intellectual development, enabled by the separation of programming notations from specific machines, was the reification of programming languages as independent entities; together with the Language metaphor, this opened up new ontologies of programming [3].9 However, the introduction of intermediaries between program and machine brought dangers: the very programs which translated “high-level languages” into machine code (compilers) could contain errors like any other program. Without the operations of a machine to inspect, how could these errors be found—independent of errors in programs? How, indeed, could the correctness of a language itself be ascertained? Working on independent high-level languages led some to feel what Strachey characterised as “a rather vague feeling of unease, and though we think we know what we mean about [various language features] we are not altogether happy that we have really got to the bottom of the concepts involved” [66]. The realisation towards the end of the 1950s that trying to develop a semantics from an implementation was extremely challenging [13] led some, like McCarthy [67], to start searching for the basic first principles from which a properly mathematical theory of computation could be formed.

This short introduction to the history of programming languages and how it created a context in which work began on formal semantics is expanded in my earlier work [3,56,68] and is mentioned in other contexts by others [10,16,24,69]. In brief, the need for clearer ways to understand programming languages led to the creation of specification mechanisms characterised by concepts brought from mathematics, logic, and linguistics: formal, precise notations, and abstract entities whose behaviour or properties were related to that of the programming language. We shall see one such example in the next section.

4. Texts and Machines

I turn now to the early work of Van Wijngaarden for a historical case study. His later work on ALGOL 68 is perhaps better known (see [58,70] for some historical accounting). That controversial programming language, widely disliked by the academic computing community who had embraced ALGOL 60 [71,72], was presented along with a novel and complicated formal definition; I argued that this unfortunate pairing led to the non-acceptance of both ([68], §7.1). Van Wijngaarden’s earlier work on formal definition and semantics specifically, however, is much less known. The current section is divided into four parts. First, I sketch the background and context of Van Wijngaarden’s work. Then, I consider the major components of his approach to programming language definition. Finally, I discuss and analyse the reaction to this approach, alongside its key illustrative devices.

4.1. Background

Adriaan van Wijngaarden (1916–1987) graduated from the Technical University of Delft with a degree in mechanical engineering in 1939 [73]; he worked there through the Second World War on fluid mechanics calculations, which he found tedious and rejected writing up because “it lacked beauty” [74]. Following the War, he was sent on a tour of the UK, including to Cambridge, to see what could be learnt about mechanical and naval engineering. Instead, he returned full of excitement about electronic calculating machines. When a new research institute, the Mathematisch Centrum (Mathematical Centre), was founded in 1946, Van Wijngaarden was invited to run its computing department, starting in 1947 [73].10 There, he worked on building machines, and the first, the Automatische Relais Rekenmachine Amsterdam (Automatic Relay Calculator Amsterdam, ARRA), was electromechanical in nature. Van Wijngaarden launched the programming career of a young physics graduate, Edsger Dijkstra, hiring him in 1952 to help with the machine’s programming even before its dedication that year [75]. It is less well known that Van Wijngaarden also hired twelve young women11 to undertake calculation and programming work; these rekenmeisjes van Van Wijngaarden (computing/calculating girls of Van Wijngaarden) helped create the ARRA and its successor ARRA II [77].

While those around him worked on programming, Van Wijngaarden’s work focused on mathematics and engineering until a sudden shift in 1958 towards programming languages following a visit to the UK in which his wife was tragically killed in a car accident [74]. In this period, the International Algebraic Language, later known as ALGOL 58, had just been published,12 and Van Wijngaarden became deeply involved in developing its successor ALGOL 60. He was an author of the 1960 Report [80] and the 1963 Revised Report [81] which were the language’s defining documents (from this point on, I shall use “ALGOL” to mean “ALGOL 60”, as was the terminology of the time). Together with Dijkstra, he made an important contribution to ALGOL by insisting the language must have recursive procedures: “Asked why recursion was such a big issue to the Amsterdam team, van Wijngaarden responded in terms of ethos, “a matter of honour and intellectual decency” ([82], fn. 27).13

At Mathematisch Centrum, Dijkstra and Jaap Zonneveld implemented a (indeed, the first) compiler for ALGOL 60 to run on the newly developed Electrologica X1 machine. Contrasted with the second compiler, the ALCOR effort led by Bauer and Samelson across a number of institutions, which implemented a subset of ALGOL for efficiency’s sake, the X1 compiler was slow but implemented the whole language. This was typical of Van Wijngaarden’s lead: he favoured flexibility in a language over restriction in the name of efficiency. As a result, Samelson called him a “liberalist” or “trickologist” [79]. The term “generalist” is preferred by historians Alberts and Daylight [82]: Van Wijngaarden insisted on the equal treatment of all language constructs—some would say to a fault with ALGOL 68 later—and this was also remarked upon by Zemanek ([84], pp. 1–2):

“From the very beginning I have sensed the dual character of his unique personality: the large mind which has always extended beyond my horizon, and the sharp brain that can suddenly focus on the smallest detail, but will illustrate by it some general aspect; the “generalizer” who generalized even a general purpose programming language, and the “specializer” whose production of sentences and questions has often reminded me of a pencil sharpener.”

What is meant by “generalising a general purpose programming language”? This describes the two major early works of Van Wijngaarden which are the focus of my case study. The context is the search in the early to mid 1960s for a successor to ALGOL 60, from which Van Wijngaarden’s proposal eventually was chosen ([68], §7.1). In the early works, however, he was taking his ideas about ALGOL and working on developing something broader and more universal for a new language.

Van Wijngaarden presented “Generalized ALGOL” [1] in Rome, 1962, at Symbolic Languages in Data Processing, the first symposium established by a new UNESCO-sponsored International Computation Centre [85]. The Centre was an effort to establish a collection of top-end computing machines which could be used and shared by research establishments across Europe; its symposia were intended to raise the profile of the Centre. “Recursive definition of syntax and semantics” [2] was presented two years later at the 1964 Formal Language Description Languages in Baden-bei-Wien. This conference, the first IFIP Working Conference, brought together programmers, language designers, machine creators, and formal language theorists; it had a catalysing effect on European computer science as I outlined in [3].14 It is a particularly valuable historical record, since post-presentation discussions were recorded and transcribed for the proceedings; sadly, the discussions following Van Wijngaarden’s earlier presentation were not recorded.

4.2. Processing and Preprocessing

Despite his input, Van Wijngaarden was unhappy with the generality of ALGOL, and wanted it unburdened from syntactical niceties. As part of the move towards developing independent mechanisms for specifying programming language semantics highlighted above, Van Wijngaarden laid forth his ideal ([1], p. 17):

“the definition of the language should be the description of an automatism, a set of axioms, A Machine or whateverone likes to call it that reads and interprets a text or program, any text for that matter, i.e., produces during the reading another Text, called the value of the text so far read.”

My emphasis is added here to highlight the central illustrative devices: A Programming Language is a Machine and A Program is a Text.

Let us start with the latter. It is clear that Van Wijngaarden is not talking merely about the syntax of ALGOL, which was defined using BNF.15 This had provided a simple and flexible way to summarise which strings of symbols constituted valid ALGOL programs and also coincided with developments in formal language theory in pleasing ways [87]. However, Van Wijngaarden was uninterested in syntax, calling his approach “syntax-free” ([1], p. 17); instead, he viewed the text of the program as its true form, its sole medium of import, and its ultimate meaning.

What form did this vital text take? The quotation above tells us: the text of the written program itself, plus a second (which he referred to as V), a “sequence ... consisting of truths separated by commas” ([1], p. 20). The truths are propositions, mostly equalities and memberships, over “names”, which entities Van Wijngaarden described carefully, though informally. A name is some reserved symbol (like +), or a character from which an identifier16 might be built, but names can also be concatenated directly, sequentialised with commas, and grouped with brackets. The end result of this is that a full program text is in the end itself a name, and therefore there is no real distinction between a program text and a name in V—though Van Wijngaarden does not clearly highlight this identity nor explore its implications.17 The meaning of names in V is given by the presence of the reserved word value in equalities, which indicates that the value of the name following is that of the right-hand side of the equality. See an example truth from V in Figure 1.

At the beginning of interpreting a program, V is not empty. Some truths are pre-determined by the language, such as the rules for performing addition. Many others are added through the course of interpreting the program. Van Wijngaarden is careful to note that the order of V matters: it is arranged by complexity of names, with the most general at the “bottom”, considered last during interpretation.18

To understand the use of V we must turn to the other chief metaphor, A Programming Language is a Machine. But this is not a specific, physical machine since this would be insufficiently general for Van Wijngaarden who wrote ([1], p. 18):

“We rather see the language as a machine $M0$ which is fed with the program at one end and produces the value at the other end. The rules of the language, i.e., a rough description of the working of $M0$ is printed on the lid of the machine”.

The passage here is that which opens the current paper; I chose it as an epigraph since it is deeply redolent with illustrative devices. Now, in context, we can pick it apart.

The language description printed on the machine’s lid is simple, and high-level, so the user may wish to know in more detail exactly how the language is working. For this, they “can open the machine to inspect the precise working”. Inside, surprisingly, there are two more machines, named $P1$ and $M1$: a preprocessor and a processor. $P1$ “chews the offered text” to make a more basic input for $M1$. Each has a further textual description on its lid, more basic but less intuitive: “harder to understand” but “more uncertainties are settled” ([1], p. 18). Eventually there comes a machine with no further simplification possible and its lid cannot be opened.19

It is the operation of the processor machine which deals with V. To create the ultimate value of the program—itself a name in V—the machine dynamically reads the program, running through the truths in V until it finds one which is applicable, and performs a symbolic transformation on the program text. The search for applicable truths is the closest Van Wijngaarden comes to caring about syntax, since certain rules like “a in 〈letter〉” indicate that a is a suitable value for the meta-linguistic variable 〈letter〉 ([2], p. 16).

The presence of value in a truth means “look again in V to The name is repeatedly rewritten by the processor machine until no more rewriting is possible; What remains is the meaning of the name, its semantic interpretation; and since a program is itself a name, in this way the meaning of a whole program is determined.20 If the resulting text is nonsensical, this indicates the program was meaningless, i.e., likely contained a syntactic error. Any new truths found along the way—like an assignment statement causing a new equality between an identifier and its value—these are added to V.

The final text of V contains not just equivalences showing the final value of all variables, but also a kind of history of computation, and all the rules of the program as they are created. Van Wijngaarden even notes that the rules in V can be altered before a program text is entered, providing different operating rules for the machines, or to say that another way, a different semantics for the language, but it is not clear how this is different from the way in which V is altered during a program interpretation. Perhaps the only difference is that of precedence: the truths introduced by the language designer having more power. It also implies that since V controls the operation of the machine, and the Machine is the Programming Language, then a language is changed during the course of a program execution.21

A sample of the value list is shown in Figure 2.

The centrality of the program text here provides surprising power. As an example, the use of quotation marks in truths suffices to handle procedures, including parameters called by name (procedures without parameters are already handled by the second half of Figure 2—the procedure definition would be in the form 〈 variable $1\rangle =\langle$ variable $2\rangle$). A truth like $s:=‘t’$ delays the evaluation, the first pass of the processor machine simply removing the quotation marks, such that “a note is left in V” ([1], p. 23) to be evaluated at the next pass.

Together, the processor machine, the value list V, and the operation of the machine when it hits value create something approaching the “state” as found in many other semantics methods (described in, e.g., ([36], §3.3)). Yet, everything here is textual; the only entity is a text being manipulated at the level of character recognition. While ideas such as equivalence between procedures and blocks with name substitution for parameters were not unique to Van Wijngaarden, he was working at a purely textual level. There are no meta-equivalences in this world.

In the later paper, Van Wijngaarden’s discussion of the processor gave another indication of his view of the power of pure symbol manipulation, as he defined decimal addition and subtraction in this manner ([2], pp. 17–18). The metalanguage of V is also extended with the introduction of logical operators, and the ability of the writer to define new operations.

Meanwhile, what of $Px$? It is dealt with in more depth in “Recursive definition of syntax and semantics” [2]. Van Wijngaarden gives his motivation for the processor machine in the discussion ([2], pp. 18–19):

“If I look at the [ALGOL] Report, I say to myself, must I define all this by the processor—all these rules? This is far too much for me! So I say, let’s first take all the nonessential things out of ALGOL. Now, this is a task for the preprocessor—to look at this text and say, ‘I’ll translate this text into reduced ALGOL and then define only reduced ALGOL’.”

Specifically, the preprocessor breaks down ALGOL concepts and replaces them textually. As an example, a switch statement is removed by transforming it into a procedure which accepts an integer parameter (the switch variable) and which contains a series of conditional statements leading to go to statements. In another example, a function is transformed into a procedure with an extra variable in the surrounding context to which the desired return value is ultimately assigned. In this way, transformation becomes definition: “By such an intricate but still lexicographical process, one not only eliminates the function designator, but actually defines what it means” ([2], p. 14). Note here the emphasis remains on the text as the ultimate medium of meaning.

It is critical, therefore, that the preprocessor preserves meaning; the program cannot be changed by the preprocessing. When asked to confirm no loss of meaning, Van Wijngaarden replied “Sure. You see, I do not change any identifier” ([2], p. 19). Here, we can see a subtle but important distinction being made between parts of the text: those which preserve meaning and those which do not.

Notably, the illustrative device of a machine with lids, instructions, and jaws is de-emphasised in the second presentation; although Van Wijngaarden still talks of a machine in two parts, processor and preprocessor, the Machine is mentioned specifically only twice. The preprocessor does “stand by” ready to preprocess new pieces of text when a language is being considered that can generate new texts, but it does not chew them in the same way. The presentation rather becomes more anthropomorphic, with the narrator taking actions to change the text just as much as a machine does. There is one more visual flourish worth noting: the preprocessor has the ability to change the colour of the text as a visual aid: “One might visualize the unpreprocessed text as written in black ink, whereas the preprocessor turns out text in red ink” [2].

The most provocative and historically significant aspect of the preprocessor is the way Van Wijngaarden uses it to remove functions and go to statements, transforming them all into procedures. The idea, which he outlined in the same informal but precise language used throughout the papers, is to link the end of each block with the start of another, through careful lexical transformations. He explained ([2], p. 24):

“if you do this trick I devised, then you will find that the actual execution of the program is equivalent to a set of statements; no procedure ever returns because it always calls for another one before it ends, and all of the ends of all the procedures will be at the end of the program: one million or two million ends. If one procedure gets to the end, that is the end of all; therefore, you can stop. That means you can make the procedure implementation so that it does not bother to enable the procedure to return. That is the whole difficulty with procedure implementation. That’s why this is so simple; it’s exactly the same as a goto, only called in other words.”

4.3. Discussion

Van Wijngaarden’s presentation at Formal Language Description Languages provoked a very lengthy discussion—approximately half the length of the published chapter is a transcription of the discussion—despite being the middle talk in a block of three [92]. It is worth noting that full papers were circulated to attendees in advance [93], and on the day each author delivered a presentation, to be followed by discussion. We do not have the presentation on hand, and this could of course have differed from the paper in the proceedings. In this way, we see a strange mixture of a finished piece of prose and the reaction to an oral/visual demonstration; we are left to infer, as did Netz with the mathematics of ancient Greece [37], exactly what that demonstration entailed.

The major reaction was puzzlement; Dijkstra began by stating “I am somewhat baffled, I might say, in many ways.” ([2], p. 20) Many of the participants seemed to struggle to understand the core of Van Wijngaarden’s idea, which caused him quite some annoyance, provoking exclamations of frustration, as in the exchange below about the go to transformation quoted above ([2], p. 21):

DIJKSTRA

I just don’t understand. You have your text. You make another text that remains without procedure calls. Now, you say that somewhere or another you make the insertions; so that we do without procedure calls. Now we have only goto’s.

VAN WIJNGAARDEN

What! What? What? You have only statements—sequences of statements. You have no goto’s whatsoever! You have only sequences of statements, and these sequences of statements are exactly the same sequences of statements that would have been there in the other case. ([2], p. 21)

The transformation of go to statements into procedures (and then into the sequence of statements described above so vehemently) has an interesting subsequent history. While McIlroy challenged this as meaning “the entire history of the computation must be maintained” ([2], p. 24), in fact that was the approach put forth by McCarthy in his paper at the same conference [47].22 What Van Wijngaarden did was repeatedly change the program text, not so much maintaining the history as flattening it out. Reynolds argued that this was the first published example of what was later called “continuation passing style” [94], although he is reinterpreting the work, sixty years later, in light of many subsequent results in programming language theory.23 It is in some sense surprising that none of the influential computer scientists present at Van Wijngaarden’s talk, including Landin and Strachey, both of whom later worked with continuations, made any connection back to Van Wijngaarden. But, as Reynolds observed, the prose was opaque and contained a minor technical error in the description of the transformation., I would add that as Van Wijngaarden was not really concerned with programming language theory in the same way—and saw the function as less basic than the procedure—he did not present his work with the illustrative devices which would have been amenable to the later functional programming community. The go to handling did make a more immediate historical impact, however: Dijkstra spent the next coffee break thinking about what Van Wijngaarden had said and scribbled some ideas on a napkin; this led to his famous letter to the editor of Communications of the ACM making a case against the go to statement (noted by McIlroy, reported in [94]).

Let us now start to unpick the illustrative A Programming Language is a Machine device. An astute question was raised by Hoare, who asked why a distinction was made between the preprocessor and the processor; could the processor not do all the actions of both? Van Wijngaarden replied that the difference was being made only “for psychological reasons”, with the preprocessor having the job of removing “wild ideas” which “people might introduce in languages” ([2], p. 21). Thus, the preprocessor machine acts as a normalising force, reducing a complex and unpleasant world into a more straightforward one. It is surprising that Van Wijngaarden did not return to his chief illustrative device of the earlier paper, with the lidded machines; he might have told Hoare that if he preferred, he could think of $P1$ as sitting within $M0$. Had Van Wijngaarden removed this nesting from within his own mental picture of the semantics? Without a reference to the illustrative device, it is not clear; indeed, the paper has more references to the machines’ juxtaposition than their recursive structure—despite the paper’s title! It is also noticeable that the anthropomorphism of the processor and preprocessor grows significantly within the discussion; when discussing his work orally, Van Wijngaarden repeatedly identifies himself with these, speaking of their functionality in the first person. Here is a kind of synecdoche, with the author standing in for the chief agent of his work.

There is a deeper point underlying Hoare’s question. Which operations of the machine, or machines, constitute semantics? Many later approaches to programming language semantics were concerned with producing an ultimate value or denotation; but, from Van Wijngaarden’s work, one feels it is rather the ongoing removal and replacement of text which is the act of finding meaning. It is therefore more like an operational semantics, with the meaning of the programming language invested in the Machine. Since there is, however, a difference between the parts of the text that are fair game for being chewed by the machine and those that are not (only identifiers?), this distinction is important but not clear. Wirth, in a publication responding to Van Wijngaarden’s papers [96], notes that it is not certain when a portion of text is regarded as fully dealt with by the preprocessor and when it needs further attention (should it go red as soon as the preprocessor has touched it, or only when it is finished?).

Van Wijngaarden’s machine, at least in [1], takes on some additional embodied characteristics, in Lakoff and Johnson’s language “personification” ([28], Ch. 7): the processor machine is “fed” a program and the preprocessor machine “chews” the text. We see not just the ascription of agency to the machine, but also a kind of animalistic hunger: there is also metonymy here as the machine’s behaviour is reduced from full personhood to merely a masticator. This contrasts with the apparently helpful nature of these machines; recall the distinction between processor and preprocessor introduced in ([1], p. 18) to assist the user who wants to understand in more detail how the language is working: deeper nested machines are “harder to understand” but “more uncertainties are settled”. At the same time as reducing uncertainty, the machine(s) remove intuitiveness: we see here an embodied mechanisation of the role of semantics in providing interpretation between levels of abstraction—as in the work of Rapaport [14]. Further, we can observe a juxtaposition between the way in which Van Wijngaarden’s textual manipulation happens at a very basic level by the processor, providing a kind of “semantics of the word” in the Ricoeur sense [44,45]: names in the program and in V are given meaning via low-level transformations; one might view the preprocessor then as a “semantics of discourse”, giving meaning at a higher level. But, a continuity exists between these machines, even as they appear and disappear throughout Van Wijngaarden’s work. Indeed, this appearance and disappearance of the machine recurs throughout the early years of computer science, and the slow disappearance of the same is a characteristic of the maturing intellectual field [11]. As such, the machine becomes increasingly less attractive as a metonym to illustrate the computer–program–abstraction complex. Van Wijngaarden was clearly a machine-in person in this period (though perhaps less in his later work) and he was not alone in this view.

Peter Landin, who also spoke at the 1964 conference [97], developed a semantic approach involving translation of program constructs into “applicative expressions” which are interpreted using a combination of states and transition rules which Landin called a “machine” [98]. Though he was typically reluctant to take credit for ideas, he did allow himself the invention of the “abstract machine” as a way to interpret a program. This work was influential in particular on the IBM Laboratory in Vienna, whose subsequent work creating a “Universal Language Document”, a formal specification of PL/I, referred to their semantic mechanism as a “machine (interpreter)” [99].24 In the early work of Dijkstra, he saw a close correspondence with languages and machines, writing “A machine defines (by its very structure) a language, viz. its input language; conversely, the semantic definition of a language specifies a machine that understands it” ([100], p. 1).

Another conception of machine was put forward by Gorn in a summary of the 1963 Working Conference on Mechanical Language Structures [101]. Gorn wrote of a “background machine” which he felt must be in the mind of every programmer who looks at a program and imagines it being run; however, unlike the Landin and Vienna machines, which were abstract, formalised entities, Gorn’s had clear hardware aspects: control counters, instruction registers, and address selectors. Indeed, he claimed “I am one of those extremists who feel that it is impossible to separate a language from its interpreting machine” ([101], p. 133). In other words, Gorn takes a position like that advanced by simulation semantics: meaning is inextricably linked to a mental imagining of the entity’s affordances [40]. Van Wijngaarden, however, had already written that he did not wish to use “precise axioms” or a “precise description of the machine” since the definition of a language should allow “distinction between fundamental concepts and useful but logically unnecessary conventions” ([1], pp. 17–18)—thus making an identity between a precise machine, and a precise syntax.

So, we can see a variety of different machines acting as illustrative devices even in this small corner of computing history; while the name is shared, the characteristics are very different, which suggests that to understand more deeply A Programming Language is a Machine we need to interrogate the machine in question. Van Wijngaarden’s machines were strongly focused on symbol manipulation, even to the extent that they disregarded numbers ([2], p. 23):

“Now, you say that numbers are not strings in that sense. Now, I know exactly what a number is; it is a string of digits. It may be preceded by a plus or minus sign, and it may be preceded by a decimal point. There is no other thing in ALGOL that is a metaconcept called ‘number’ of which this is the number. To me the number 13 is just the sequence of symbols 1, 3. I have never seen a ‘number’.”

This intense focus on the text is reflected by the memories of contemporary Dana Scott, who wrote that Van Wijngaarden claimed “If you can’t do it by symbol manipulation, then it’s not worth doing it” adding that Van Wijngaarden was next to Haskell Curry in being the most symbolically minded people he knew [102]. Van Wijngaarden himself stated this, telling Landin “I can’t do any kind of computation apart from acting on symbols” ([97], p. 294).

This heavily textual attitude to programs is not one shared by many—if any—other writers of semantics. Indeed, McCarthy directly opposed the use of strings of symbols as a fundamental basis for semantic interpretation, which he felt was too connected to implementation specifics, and contrasted Van Wijngaarden’s attitude with his own desire to use an abstract syntax ([2], p. 23) (as in, for example, [47]). Dijkstra also opposed the focus on text, writing later [103]:25

“It is practically impossible to give such a mechanistic definition without being over-specific. The first time that I can remember having voiced these doubts in public was at the W.G.2.1 meeting in 1965 in Princeton, where van Wijngaarden was at that time advocating to define the sum of two numbers as the result of manipulating the two strings of decimal (!) digits. (I remember asking him whether he also cared to define the result of adding INSULT to INJURY; that is why I remember the whole episode.)”

Yet, these were conflations; Van Wijngaarden had the same desire to avoid implementation specifics, wishing that “the language should not be burdened by syntactical rules which define meaningful texts” ([1], p. 17). He simply saw strings of symbols as the appropriately abstract core basis. Such a basis, however, was confused by the multiple roles being played by the text. As Wirth raised, it was not obvious which rules should be seen as syntactic and which semantic [96]. Van Wijngaarden would likely argue that he wanted to avoid a distinction here: all he works with is text, but all of it could be value producing. Only when the processor finds no applicable rule in V is the text found to be meaningless (and therefore syntactically invalid). So, syntax was managed in some way by Van Wijngaarden, despite his desire for a syntax-free language.

A Program is a Text will take some more analysis here than A Programming Language is a Machine. It could be considered in the Lakoff and Johnson mould as part of an objectivist theory of communication, in which a version of the Language is Conduit metaphor is used. Meanings are objects and so are linguistic expressions; communication happens when the latter carries the former from the speaker to the hearer ([28], Ch. 26). But, there is something else going on here, because the text is at the same time the static program, the ongoing meaning of the program, and the ultimate semantic basis, all mixed together. In this sense, it brings something of the character of mathematics, as explained by Sha ([19], p. 39): “simultaneously concept and technology [...] both the generation of the concept and the means to articulate and actualize these concepts as material.” While Sha presented this as a special character, the same remarks could apply to the study of natural languages, or even neuroscience. The strength of text as a basis was its flexibility; but, as an illustrative device, it caused problems: being too reductive, being an unhelpful metonym, and bringing conflation rather than distinction. Without an extra abstract framework (like McCarthy’s abstract syntax [47]) naming the parts of the program, and with V containing program text as well as meta-identities, operators, and dynamic values, and a lack of clear distinction between the processor and preprocessor machines—there is a great deal of conflation and confusion. As Wirth wrote, “The reader is left with the uneasy feeling of having been told only half the story” [96].

Here is where a strong illustrative device could have helped clarify certain matters: but Machine had so many different meanings, even amongst the small group of attendees in Baden-bei-Wien in 1964, and Text carried many undesired connotations. The presentation format of Van Wijngaarden’s work, with his unusual choice of illustrative device, obscured some of the intellectual merit in ideas which went on to have great penetration in computer science [94]. Considered from Lakoff and Johnson’s perspective of embodied realism [34], the truth of Van Wijngaarden’s models was lacking since his illustrative devices failed to convince in the social situation of academic presentation; taking his presentation as a rhetorical argument, in the style of Greek mathematical proofs as discussed by Netz [37], the “atoms of necessity” which begun his argumentation were not agreed as necessary by his audience, and they were not convinced his transformations preserved any necessity present. Van Wijngaarden’s work needed to change to reach a larger audience—and ultimately convince the ALGOL committee to entrust its successor project with him. There is evidence of this beginning even in the 1964 presentation, as some of the machinic imagery diminishes in favour of a focus on language, and the trappings of the nascent formal semantics field appear. His later work on ALGOL 68 would continue this trend, making great use of powerful “two-level grammars” for transforming program texts, and only a little attention paid to an underlying interpreting machine [104].26

The two core metaphors in Van Wijngaarden’s work are not terribly uncommon in the intellectual context of the time, and nor is their progeny too hard to grasp. Machines were a physical presence in the room, too large, noisy, and smelly to ignore; and programs as textual or metatextual objects is a consequence of autocoding, even the stored program concept itself. The more mathematically inclined people in the room may have read Church or Post and been familiar with the ideas of textual rewriting. Yet, perhaps due to the changing nature of computer science in this moment, away from the machine and towards something more vauntedly abstract than “mere” syntax (for which Van Wijngaarden’s text was mistaken), the metaphors failed to communicate effectively with Van Wijngaarden’s audience. Further historical work could uncover deeper heritages for illustrative devices in semantics and help take apart their composition and consequences—the role played by Text is clearly linked to the role of text in human–human communication, but philosophical analyses of the same miss of the distinctive aspects of program texts. More work is needed to uncover, classify, and unpack the vast array of illustrative devices in computing—and this work could have many important uses.

5. Future Work

It is noted by Nofre that metaphors play a “normative and epistemic” role in science, and their use in computer science (and its history) is largely unstudied.27 Hans Blumenberg’s characterisation of the space of mathematical knowledge as “controlled ambiguity” follows the late Wittgenstein: rather than fossilised in theorems, knowledge is open for re-exploration and redefinition in multiple forms, which forms may themselves unlock new knowledge [106]. This period in the history of semantics shows multiple cases of experimentation with knowledge forms—to varying levels of formality, and consequent varying levels of openness. These forms, such as the illustrative devices of Machine and especially Text from Van Wijngaarden were contested and argued over, provoking strongly felt responses from other participants and Van Wijngaarden himself. Johnson [32] insists that such emotions, feelings, and aesthetics are a crucial part of knowledge, with the embodied qualities of many metaphors having power precisely because of these evocations.

Another direction for more research, for which I am grateful to a suggestion from an anonymous reviewer, is an exploration more that is informed by the frameworks of literary analysis and rhetorical devices, which I have but hinted at in this paper.

Evidence from recent cognitive science suggests that language has a particularly strong role in shaping abstract conceptualisation and, possibly as a consequence, understanding of abstract concepts tends to be more culturally and linguistically contingent than concrete components [107]. Given the high preponderance of abstract ideas in computer science, analysis of the language is likely to be fruitful for further work in understanding computer science. One direction for study here could be the use of spatial and motion-based metaphors, which are prevalent in mathematics [30]. Recent studies in computer science education suggest that improved spatial skills correlate with STEM achievement in general [108], and effective grappling with computer science concepts in particular [109].

The importance of metaphors in education more broadly is highlighted by Low [110] who points to their role in replacing unfamiliar abstract concepts with more familiar ones, and the transfer of structural relationships from source domain to target (though noting this can also be problematic when unwanted properties are transferred). Ricoeur argued that metaphors have a particular importance in teaching when they are fresh and “living”, since they offer the student a feeling of participation in the learning experience [44]. Beyond metaphors, Eriksson et al. [111] insist on the need for analogy competence in science educators; following my point above about the Dining Philosophers scenario, I contend that this should be broadened to the full illustrative device category. There is some empirical work undertaken already applying conceptual metaphor theory in computer science education: Sanford et al. [112] interviewed educators on an introductory module about their metaphors, and Harper et al. [113] undertook classroom observations of a similar module, specifically observing the use of metaphors to describe recursion.

With these works and that of Nofre showing the value of examining metaphors in computing and the present paper showing one case study, I propose there is space for a long-form examination of illustrative devices across the history of computing, and a consideration of their impact in the classroom and beyond. For example, a metaphor that has given rise to an entire theory of computation is that centered on actor/script/message, used by Hewitt [114] in his attempt to understand Alan Kay’s ideas on object-oriented programming.28 I am grateful to another anonymous reviewer for providing this suggestion. One angle which may prove valuable is considering those devices which show particular cultural contingency, such as Dijkstra’s Secretaries and Directors for hierarchies of concurrency [49]; the Missionaries and Cannibals algorithm presented in, for example, [116,117]; and the widespread (though today diminishing) Master and Slave [118].