Introduction

On Monday, we were looking at mechanism to provide meaning (semantics) to a program in a programming language given that we have created a parse tree for the program.
We discussed the roles of the semantic analyzer.
One of these is to enforce semantic rules such as a variable must be declared before its used or that types must match etc.
This enforcement might happen at compile time (statically) or at run time (dynamically),
Another role of the semantic analyzer was to annotate the parse tree with information needed for intermediate code generation.
We added attributes to the symbols of our programming languages grammar. For example, a symbol Variable might be given two attributes Variable.type and Variable.val.
Then for each production in our grammar, we added rules to say how the values of these attributes should change. For example,
```
L ::= id LT    ⊳ L.c := 1 + LT.c
```
Today, we begin with some final remarks on semantics before talking about Control flow in programming languages.

Remarks on Attribute Grammars

If our attribute rules are such that each symbol has at most one attribute and the values are calculated (synthesized) only in productions in which their symbols appears on the left-hand side of a rule, then the grammar is said to be S-attributed.
If an attribute values are calculated when it appears on the right hand side of a rule, we called it an inherited attribute. For example,
```
expr ::= const expr_tail
   ⊳ expr_tail.st := const.val
   ⊳ expr.val := expr_tail.val
```
S-attributed grammars values can be evaluated as return values going from the bottom up the parse tree if one is doing recursive descent parsing.
If one has inherited attributes the situation is harder. To evaluate them with a recursive descent parser we typically want to pass attributes as arguments to our recursive calls:
```
parseExpr(Attributes exprAttrs, int position, String programString)
```
A particular important case of inherited attribute grammars, known as L-attributed grammars is when each rule satisfies:
1. Each synthesized attribute of a left-hand-side symbol depends only on that symbol's own inherited attributes or on attributes of the production's right-hand-side symbols. For example, val in our example above.
2. Each inherited attribute of a right-hand-side symbol depends only on inherited attributes of the left-hand-side symbol or on attributes (synthesized or inherited) of symbols to its left in the right-hand side. For example, st in our example above.
L-attributed grammars permit a depth first left-to-right evaluation of the parse tree, so the attribute passing idea above will work to allow evaluation of them.
Using attribute grammars, it is possible to generate code for what one should do when we see a particular construct in a program.
We will not go into detail on how this is accomplished as this is not a compiler class, instead we are going to begin talking about Control flow in programming languages.

Control Flow

Out next topic is control flow which concerns the order in which programs are evaluated.
Common language mechanisms for specifying control flow are:
1. Sequencing: Statements are to be executed (or expressions evaluated) in a certain specified order -- usually the order in which they appear in the program text.
2. Selection (aka alternation): Depending on some run-time condition, a choice is to be made among two or more statements or expressions. For example, if and case (switch) statements.
3. Iteration: A given fragment of code is to be executed repeatedly. Iteration constructs include for/do, while, and repeat loops.
4. Procedural abstraction: A potentially complex collection of control constructs (a subroutine) is encapsulated in a way that allows it to be treated as a single unit, usually subject to parameterization.
5. Recursion: An expression is defined in terms of (simpler versions of) itself, either directly or indirectly. Recursion is usually defined by means of self-referential subroutines.
6. Concurrency: Two or more program fragments are to be executed/evaluated "at the same time," either in parallel on separate processors, or interleaved on a single processor in a way that achieves the same effect.
7. Exception handling and speculation: A program fragment is executed optimistically, on the assumption that some expected condition will be true. If that condition turns out to be false, execution branches to a handler that executes in place of the remainder of the protected fragment (in the case of exception handling), or in place of the entire protected fragment (in the case of speculation). For speculation, the language implementation must be able to undo, or "roll back," any visible effects of the protected code.
8. Nondeterminacy: The ordering or choice among statements or expressions is deliberately left unspecified, implying that any alternative will lead to correct results. Some languages require the choice to be random, or fair, in some formal sense of the word.
For this lecture, we will skip Concurrency and Nondeterminacy and focus on the other kinds of control flow.
To begin with we look at the evaluation of expressions, which we need for many of these constructs.

Expression Evaluation

An expression is a value which is either a simple value such as a literal constant, or a named variable, or it is an operator applied to a collection of operand or arguments each of which is an expression.
We can think of an operator as a built-in functions in our language that often have there own syntax. An operand is a argument to a function.
For example, in Ada to add two numbers we write a+b rather than the usual function call syntax that might be "+"(a, b).
For operators with two arguments (binary operators), several different notations are in use in various programming languages:
```
Prefix:  op a b    or    op(a, b)    or     (op a b)
Infix:   a op b
Postfix: a b op
```
Most imperative languages use infix notation for binary operations and prefix notation for unary operators and other functions. The conditional operation in C:
```
cond ? a : b
```
is an exception, and might be though as a kind of three argument infix. Algol has a similar construct. Smalltalk lets you use infix like this for all functions.
Lisp/Scheme/Racket use prefix notation for all functions, but with the third variant above:
```
(* (+ 1 3) 2) ; In infix: (1 + 3) * 2
```
ML/Haskell/OCaml dispense with parentheses altogether, except where needed for disambiguation:
```
max (2 + 3) 4;;  
```
would evaluate to 5.
ML and R let you define new infix operators.

In-Class Exercise

Convert the following infix expressions to prefix and postfix:
```
(a + b) * (c - d)
(- a) + (d - c)
a + (c - d) + b
```
Please post your solution to the Oct 20 In-Class Exercise Thread.

Precedence and Associativity

Operator precedence in a variety of languages

When written in infix notation, without parentheses, expressions can often be ambiguous.
For example, does 7 - 3 + 1 mean (7-3) + 1 = 5 or 7 - ( 3 + 1) = 4? Does 2 + 3 * 4 mean (2 + 3) * 4 = 20 or 2 + (3 * 4) = 14?
To solve the first problem most programming languages have a rule to associate expressions from left-to-right. So 7 - 3 + 1 fully parenthesized would be interpreted as ((7 - 3) + 1). One exception to this is Fortran for exponents where right-to-left associativity is used because that is what's used in math. I.e., for Fortran 4**3**2 is 4 ** (3 ** 2).
To handle the second expression, most languages given certain operators higher precedence (priority) over other operators. As * has higher priority that + in C, 2 + 3 * 4 would mean 2 + (3 *4).
The above chart shows operator precedence for a variety of languages.

Assignment

In a purely functional language, expressions are the building blocks of programs and computation consists entirely of expression evaluation.
The effect of any individual expression on the overall computation is limited to the value that expression provides to its surrounding context.
Complex computations employ recursion to generate a potentially unbounded number of values, expressions, and contexts.
On the other hand, for imperative languages computation consists of an ordered series of changes to values of variables in memory. These changes to variables are done using assignments.
Each assignment takes a pair of arguments a value and a reference to a variable into which the value should be placed.
A programming language construct is said to have a side effect if it influences subsequent computation in any way other than by returning a value for use in the surrounding context. So assignment is an example of an operation with a side effect (the variable referenced acquires a new value).
Imperative languages distinguish between expressions which always produce a value and may or may not have side effects; and statements which are executed solely for their side effects and return no useful value.
A purely functional language has no side effects. For example, Haskell and Miranda. Languages like ML and Lisp are Lisp are most functional, but do allow assignment. C, Java, Python, etc are mostly imperative but do offer some functional features.

References and Values

In a typical assignment in C the variables in the left hand and right hand side of an assignment have different meanings.
Consider:
```
d = a;
a = b + c:
```
In d = a, the right hand side of the assignment refers to the value of a.
In a = b + c, the left hand side of the assignment refers to the location of a where we want to put the sum of b and c.
An expression that denotes a value, we call an r-value; one that denotes a location we call an l-value. The names come from the side of the = sign.
Not all expressions can be l-values. For example, 2 + 3 is an expression, but 2 + 3 = a does not make sense in most programming languages.
That said, it is quite possible to have complicated expressions for l-values. For example (f(a)+3)->b[c] = 2; makes sense in C.
Some languages (Lisp, ML, Clu ,Pascal) make the distinction between l-values and r-values more explicit by using a reference model of variables.
In such a language, every variable is an l-value. When it appears in an r-value context, it must be dereferenced to obtain the value to which it refers.
The figure above shows how items would be stored in internally in Clu for the following program:
```
b := 2;
c := b;
a := b + c;
```
PHP uses a notion like the above for when items likes arrays are created, but then has a copy-on write semantics to handle when one of two things that refer to the same memory changes.

Boxing

You might be wondering why would anyone use a reference model for built-in types?

One reason is to avoid kludges when you need to pass primitive types to something that is expecting an object like in early versions of Java:

import java.util.Hashtable;
...
Hashtable ht = new Hashtable(); 
...
Integer N = new Integer(13); 
ht.put(N, new Integer(31)); 
Integer M = (Integer) ht.get(N); 
int m = M.intValue();

Here we need to create a wrapper type Integer around the primitive type int, so that we can supply it to Hashtable 's get method which expects an Object. (Early versions of Java did not have parameterized types).
Nowadays, we can use code like:
```
ht.put(13,31);
int m = (Integer) ht.get(13);
```
where "boxing/unboxing" is done automatically.

Control Flow

Outline

Introduction

Remarks on Attribute Grammars

Control Flow

Expression Evaluation

In-Class Exercise

Precedence and Associativity

Assignment

References and Values

Boxing