Exploring Programming Language Design: A Mini-Language Approach, Study notes of Programming Languages

Download Exploring Programming Language Design: A Mini-Language Approach and more Study notes Programming Languages in PDF only on Docsity!

Design Concepts in Programming Languages

Chapter 1: Introduction

Franklyn Turbak and David Gifford

with Mark A. Sheldon

The MIT Press Cambridge, Massachusetts London, England

4 Chapter 1 Introduction

language design space, study decisions to be made along each dimension, and consider how decisions from different dimensions can interact. We will teach you about a wide variety of neat tricks for extending programing languages with inter- esting features like undoable state changes, exitable loops, and pattern matching. Our approach for teaching you this material is based on the premise that when language behaviors become incredibly complex, the descriptions of the behaviors must be incredibly simple. It is the only hope.

1.2 Syntax, Semantics, and Pragmatics

Programming languages are traditionally viewed in terms of three facets:

1. Syntax — the form of programming languages.
2. Semantics — the meaning of programming languages.
3. Pragmatics — the implementation of programming languages.

Here we briefly describe these facets.

Syntax

Syntax focuses on the concrete notations used to encode programming language phrases. Consider a phrase that indicates the sum of the product of v and w and the quotient of y and z. Such a phrase can be written in many different notations — as a traditional mathematical expression:

vw + y/z

or as a Lisp parenthesized prefix expression:

(+ (* v w) (/ y z))

or as a sequence of keystrokes on a postfix calculator:

v enter w enter × y enter z enter ÷ +

or as a layout of cells and formulas in a spreadsheet:

1 2 3 4 A v= v*w = A2 * B B w= y/z = C2 / D C y= ans = A4 + B D z=

1.2 Syntax, Semantics, and Pragmatics 5

or as a graphical tree:

v w

y (^) z

Although these concrete notations are superficially different, they all designate the same abstract phrase structure (the sum of a product and a quotient). The syntax of a programming language specifies which concrete notations (strings of characters, lines on a page) in the language are legal and which tree-shaped abstract phrase structure is denoted by each legal notation.

Semantics

Semantics specifies the mapping between the structure of a programming lan- guage phrase and what the phrase means. Such phrases have no inherent mean- ing: their meaning is determined only in the context of a system for interpreting their structure. For example, consider the following expression tree:

1 11

Suppose we interpret the nodes labeled 1 , 10 , and 11 as the usual decimal notation for numbers, and the nodes labeled + and * as the sum and product of the values of their subnodes. Then the root of the tree stands for (1 + 11) · 10 = 120. But there are many other possible meanings for this tree. If * stands for exponentiation rather than multiplication, the meaning of the tree could be 12^10. If the numerals are in binary notation rather than decimal notation, the tree could stand for (in decimal notation) (1 + 3) · 2 = 8. Alternatively, suppose that odd integers stand for the truth value true, even integers stand for the truth value false, and + and * stand for, respectively, the logical disjunction (∨) and conjunction (∧) operators on truth values; then the meaning of the tree is false. Perhaps the tree does not indicate an evaluation at all, and only stands for a property intrinsic to the tree, such as its height (3), its number of nodes (5), or its shape (perhaps it describes a simple corporate hierarchy). Or maybe the tree is an arbitrary encoding for a particular object of interest, such as a person or a book.

1.3 Goals 7

practical programming languages, and discuss the interplay between semantics and pragmatics. Because syntactic issues are so well covered in standard compiler texts, we won’t say much about syntax except for establishing a few syntactic conventions at the outset. We will introduce a number of tools for describing the semantics of programming languages, and will use these tools to build intuitions about programming language features and study many of the dimensions along which languages can vary. Our coverage of pragmatics is mainly at a high level. We will study some simple programming language implementation techniques and program improvement strategies rather than focus on squeezing the last ounce of performance out of a particular computer architecture. We will discuss programming language features in the context of several mini- languages. Each of these is a simple programming language that captures the essential features of a class of existing programming languages. In many cases, the mini-languages are so pared down that they are hardly suitable for serious programming activities. Nevertheless, these languages embody all of the key ideas in programming languages. Their simplicity saves us from getting bogged down in needless complexity in our explorations of semantics and pragmatics. And like good modular building blocks, the components of the mini-languages are designed to be “snapped together” to create practical languages. Issues of semantics and pragmatics are important for reasoning about proper- ties of programming languages and about particular programs in these languages. We will also discuss them in the context of two fundamental strategies for pro- gramming language implementation: interpretation and translation. In the interpretation approach, a program written in a source language S is directly executed by an S-interpreter, which is a program written in an implementa- tion language. In the translation approach, an S program is translated to a program in the target language T , which can be executed by a T -interpreter. The translation itself is performed by a translator program written in an im- plementation language. A translator is also called a compiler, especially when it translates from a high-level language to a low-level one. We will use mini- languages for our source and target languages. For our implementation lan- guage, we will use the mathematical metalanguage described in Appendix A. However, we strongly encourage readers to build working interpreters and trans- lators for the mini-languages in their favorite real-world programming languages. Metaprogramming — writing programs that manipulate other programs — is perhaps the most exciting form of programming!

8 Chapter 1 Introduction

1.4 PostFix: A Simple Stack Language

We will introduce the tools for syntax, semantics, and pragmatics in the context of a mini-language called PostFix. PostFix is a simple stack-based language inspired by the PostScript graphics language, the Forth programming lan- guage, and Hewlett Packard calculators. Here we give an informal introduction to PostFix in order to build some intuitions about the language. In subsequent chapters, we will introduce tools that allow us to study PostFix in more depth.

1.4.1 Syntax

The basic syntactic unit of a PostFix program is the command. Commands are of the following form:

• Any integer numeral. E.g., 17 , 0 , -3.
• One of the following special command tokens: add, div, eq, exec, gt, lt, mul, nget, pop, rem, sel, sub, swap.
• An executable sequence — a single command that serves as a subroutine. It is written as a parenthesized list of subcommands separated by whitespace (any contiguous sequence of characters that leave no mark on the page, such as spaces, tabs, and newlines). E.g., (7 add 3 swap) or (2 (5 mul) exec add).

Since executable sequences contain other commands (including other executable sequences), they can be arbitrarily nested. An executable sequence counts as a single command despite its hierarchical structure. A PostFix program is a parenthesized sequence consisting of (1) the token postfix followed by (2) a natural number (i.e., nonnegative integer) indicat- ing the number of program parameters followed by (3) zero or more PostFix commands. Here are some sample PostFix programs:

(postfix 0 4 7 sub) (postfix 2 add 2 div) (postfix 4 4 nget 5 nget mul mul swap 4 nget mul add add) (postfix 1 ((3 nget swap exec) (2 mul swap exec) swap) (5 sub) swap exec exec) In PostFix, as in all the languages we’ll be studying, all parentheses are required and none are optional. Moving parentheses around changes the structure of the program and most likely changes its behavior. Thus, while the following

10 Chapter 1 Introduction

N : Push the numeral N onto the stack. sub: Call the top stack value v 1 and the next-to-top stack value v 2. Pop these two values off the stack and push the result of v 2 − v 1 onto the stack. If there are fewer than two values on the stack or the top two values aren’t both numerals, signal an error. The other binary arithmetic operators — add (addition), mul (multiplication), div (integer divisiona^ ), and rem (remainder of integer division) — behave similarly. Both div and rem signal an error if v 1 is zero. lt: Call the top stack value v 1 and the next-to-top stack value v 2. Pop these two values off the stack. If v 2 < v 1 , then push a 1 (a true value) on the stack, otherwise push a 0 (false). The other binary comparison operators — eq (equals) and gt (greater than) — behave similarly. If there are fewer than two values on the stack or the top two values aren’t both numerals, signal an error. pop: Pop the top element off the stack and discard it. Signal an error if the stack is empty. swap: Swap the top two elements of the stack. Signal an error if the stack has fewer than two values. sel: Call the top three stack values (from top down) v 1 , v 2 , and v 3. Pop these three values off the stack. If v 3 is the numeral 0 , push v 1 onto the stack; if v 3 is a nonzero numeral, push v 2 onto the stack. Signal an error if the stack does not contain three values, or if v 3 is not a numeral. nget: Call the top stack value v (^) index and the remaining stack values (from top down) v 1 , v 2 ,.. ., v (^) n. Pop v (^) index off the stack. If v (^) index is a numeral i such that 1 ≤ i ≤ n and v (^) i is a numeral, push v (^) i onto the stack. Signal an error if the stack does not contain at least one value, if v (^) index is not a numeral, if i is not in the range [1..n], or if v (^) i is not a numeral. (C 1... Cn ): Push the executable sequence (C 1... Cn ) as a single value onto the stack. Executable sequences are used in conjunction with exec. exec: Pop the executable sequence from the top of the stack, and prepend its component commands onto the sequence of currently executing commands. Signal an error if the stack is empty or the top stack value isn’t an executable sequence. a (^) The integer division of n and d returns the integer quotient q such that n = qd + r, where r (the remainder) is such that 0 ≤ r < |d| if n ≥ 0 and −|d| < r ≤ 0 if n < 0.

Figure 1.1 English semantics of PostFix commands.

(postfix 2) −^ [3 −,−4]→ 3 {Initial stack has 3 on top with 4 below.} (postfix 2 swap) −^ [3 −,−4]→ 4 (postfix 3 pop swap) −^ [3 −,−^4 ,−5]→ 5

1.4.2 Semantics 11

It is an error if the actual number of arguments does not match the number of parameters specified in the program.

(postfix 2 swap) −^ [3] −→ error {Wrong number of arguments.} (postfix 1 pop) −^ [4 −,−5]→ error {Wrong number of arguments.}

Note that program arguments must be integers — they cannot be executable sequences. Numerical operations are expressed in postfix notation, in which each operator comes after the commands that compute its operands. add, sub, mul, and div are binary integer operators. lt, eq, and gt are binary integer predicates returning either 1 (true) or 0 (false).

(postfix 1 4 sub) −^ [3] −→ - (postfix 1 4 add 5 mul 6 sub 7 div) −^ [3] −→ 4 (postfix 5 add mul sub swap div) −^ [7 −,−^6 ,−^5 ,−^4 ,−3]→ - (postfix 3 4000 swap pop add) −^ [300 −−−,^20 −,−1]→ 4020 (postfix 2 add 2 div) −^ [3 −,−7]→ 5 {An averaging program.} (postfix 1 3 div) − −−^ [17]→ 5 (postfix 1 3 rem) − −−^ [17]→ 2 (postfix 1 4 lt) −^ [3] −→ 1 (postfix 1 4 lt) −^ [5] −→ 0 (postfix 1 4 lt 10 add) −^ [3] −→ 11 (postfix 1 4 mul add) −^ [3] −→ error {Not enough numbers to add.} (postfix 2 4 sub div) −^ [4 −,−5]→ error {Divide by zero.} In all the above examples, each stack value is used at most once. Sometimes it is desirable to use a number two or more times or to access a number that is not near the top of the stack. The nget command is useful in these situations; it puts at the top of the stack a copy of a number located on the stack at a specified index. The index is 1-based, from the top of the stack down, not counting the index value itself. (postfix 2 1 nget) −^ [4 −,−5]→ 4 {4 is at index 1, 5 at index 2.} (postfix 2 2 nget) −^ [4 −,−5]→ 5 It is an error to use an index that is out of bounds or to access a nonnumeric stack value (i.e., an executable sequence) with nget.

(postfix 2 3 nget) −^ [4 −,−5]→ error {Index 3 is too large.} (postfix 2 0 nget) −^ [4 −,−5]→ error {Index 0 is too small.} (postfix 1 (2 mul) 1 nget) −^ [3] −→ error {Value at index 1 is not a number but an executable sequence.}

1.4.2 Semantics 13

Exercise 1.1 Determine the value of the following PostFix programs on an empty stack.

a. (postfix 0 10 (swap 2 mul sub) 1 swap exec)

b. (postfix 0 (5 (2 mul) exec) 3 swap)

c. (postfix 0 (() exec) exec)

d. (postfix 0 2 3 1 add mul sel)

e. (postfix 0 2 3 1 (add) (mul) sel)

f. (postfix 0 2 3 1 (add) (mul) sel exec)

g. (postfix 0 0 (2 3 add) 4 sel exec)

h. (postfix 0 1 (2 3 add) 4 sel exec)

i. (postfix 0 (5 6 lt) (2 3 add) 4 sel exec)

j. (postfix 0 (swap exec swap exec) (1 sub) swap (2 mul) swap 3 swap exec)

Exercise 1.

a. What function of its argument does the following PostFix program calculate? (postfix 1 ((3 nget swap exec) (2 mul swap exec) swap) (5 sub) swap exec exec)

b. Write a simpler PostFix program that performs the same calculation.

Exercise 1.3 Recall that executable sequences are effectively subroutines that, when invoked (by the exec command), take their arguments from the top of the stack. Write executable sequences that compute the following logical operations. Recall that 0 stands for false and all other numerals are treated as true.

a. not: return the logical negation of a single argument.

b. and: given two numeric arguments, return 1 if their logical conjunction is true, and 0 otherwise.

c. short-circuit-and: return 0 if the first argument is false; otherwise return the second argument.

d. Demonstrate the difference between and and short-circuit-and by writing a PostFix program with zero arguments that has a different result if and is replaced by short- circuit-and.

Exercise 1.

a. Without nget, is it possible to write a PostFix program that squares its single argument? If so, write it; if not, explain.

14 Chapter 1 Introduction

b. Is it possible to write a PostFix program that takes three integers and returns the smallest of the three? If so, write it; if not, explain.

c. Is it possible to write a PostFix program that calculates the factorial of its single argument (assume it’s nonnegative)? If so, write it; if not, explain.

1.4.3 The Pitfalls of Informal Descriptions

The “by-example” and English descriptions of PostFix given above are typical of the way that programming languages are described in manuals, textbooks, courses, and conversations. That is, a syntax for the language is presented, and the semantics of each of the language constructs is specified using English prose and examples. The utility of this method for specifying semantics is apparent from the fact that the vast majority of programmers learn to read and write programs via this approach. But there are many situations in which informal descriptions of programming languages are inadequate. Suppose that we want to improve a program by trans- forming complex phrases into phrases that are simpler and more efficient. How can we be sure that the transformation process preserves the meaning of the program? Or suppose that we want to prove that the language as a whole has a particular property. For instance, it turns out that every PostFix program is guaranteed to terminate (i.e., a PostFix program cannot enter an infinite loop). How would we go about proving this property based on the informal description? Natural language does not provide any rigorous framework for reasoning about programs or programming languages. Without the aid of some formal reasoning tools, we can only give hand-waving arguments that are not likely to be very convincing. Or suppose that we wish to extend PostFix with features that make it easier to use. For example, it would be nice to name values, to collect values into arrays, to query the user for input, and to loop over sequences of values. With each new feature, the specification of the language becomes more complex, and it becomes more difficult to reason about the interaction between various features. We’d like techniques that help to highlight which features are orthogonal and which can interact in subtle ways. Or suppose that a software vendor wants to develop PostFix into a product that runs on several different machines. The vendor wants any given PostFix program to have exactly the same behavior on all of the supported machines. But how do the development teams for the different machines guarantee that they’re all implementing the “same” language? If there are any ambiguities in the PostFix specification that they’re implementing, different development

16 Chapter 1 Introduction

These approaches support the unambiguous specification of programming lan- guages and provide a framework in which to reason about properties of programs and languages. Our discussion of tools concludes in Chapter 5 with a presentation of a technique for determining the meaning of recursive specifications. Through- out the book, and especially in these early chapters, we formalize concepts in terms of a mathematical metalanguage described in Appendix A. Readers are encouraged to familiarize themselves with this language by skimming this ap- pendix early on and later referring to it in more detail on an “as needed” basis. Part II focuses on dynamic semantics, the meaning of programming lan- guage constructs and the run-time behavior of programs. In Chapter 6, we in- troduce FL, a mini-language we use as a basis for investigating dimensions of programming language design. By extending FL in various ways, we then ex- plore programming language features along key dimensions: naming (Chapter 7), state (Chapter 8), control (Chapter 9), and data (Chapter 10). Along the way, we will encounter several programming paradigms, high-level approaches for viewing computation: function-oriented programming, imperative programming, and object-oriented programming. In Part III, we shift our focus to static semantics, properties of programs that can be determined without executing them. In Chapter 11, we introduce the notion of type — a description of what an expression computes — and develop a simple type-checking system for a dialect of FL such that “well-typed” programs cannot encounter certain kinds of run-time errors. In Chapter 12, we study some more advanced features of typed languages: subtyping, universal polymorphism, bounded quantification, and kind systems. A major drawback to many of our typed mini-languages is that programmers are required to annotate programs with significant amounts of explicit type information. In some languages, many of these annotations can be eliminated via type reconstruction, a technique we study in Chapter 13. Types can be used as a mechanism for enforcing data abstraction, a notion that we explore in Chapter 14. In Chapter 15, we show how many of the dynamic and static semantics features we have studied can be combined to yield a mini-language in which program modules with both value and type components can be independently type-checked and then linked together in a type-safe way. We wrap up our discussion of static semantics in Chapter 16 with a study of effect systems, which describe how expressions compute rather than what they compute. The book culminates, in Part IV, in a pragmatics segment that illustrates how concepts from dynamic and static semantics play an important role in the implementation of a programming language. Chapter 17 presents a compiler that translates from a typed dialect of FL to a low-level language that resembles

1.5 Overview of the Book 17

assembly code. The compiler is organized as a sequence of meaning-preserving translation steps that construct explicit representations for the naming, state, control, and data aspects of programs. In order to automatically reclaim memory in a type-safe way, the run-time system for executing the low-level code generated by the compiler uses garbage collection, a topic that is explored in Chapter 18. While we will emphasize formal tools throughout this book, we do not imply that formal tools are a panacea or that formal approaches are superior to informal ones in an absolute sense. In fact, informal explanations of language features are usually the simplest way to learn about a language. In addition, it’s very easy for formal approaches to get out of control, to the point where they are overly obscure, or require too much mathematical machinery to be of any practical use on a day-to-day basis. For this reason, we won’t cover material as a dry sequence of definitions, theorems, and proofs. Instead, our goal is to show that the concepts underlying the formal approaches are indispensable for understanding particular programming languages as well as the dimensions of language design. The tools, techniques, and features introduced in this book should be in any serious computer scientist’s bag of tricks.