Introduction

Last week, we had begun talking about control flow in programming languages.
We said the major categories of control flow were: Sequencing, Selection, Iteration, Procedural abstraction, Recursion, Concurrency, Exception Handling, and Nondeterminacy.
We said that many of these constructs make use of expressions so we started examining expression evaluation.
We looked at common ways programming languages write expressions prefix, infix, postfix.
We looked at associativity and priority as means to control the default way of evaluating expressions.
We then talked about assignments and how expressions have different meanings on the left and right hand side of assignments. We said what l-values and r-values were and discussed how assignments are one kind of operation that has side effects.
Finally, we discussed the concept of boxing/unboxing of primitives types as objects.
We begin today by looking at how assignments are handled can affect the orthogonality of a programming languages...

Orthogonality

Orthogonality in programming languages means that features can be used in any combination, the combinations all make sense, and the meaning of a given feature is consistent, regardless of the other features with which it is combined.

The following Algol snippet shows assignment orthogonality in Algol:

begin
    a := if b < c then d else e; 
    a := begin f(b); g(c) end;
    g(d);
    2+3
end

Notice assignment can be done with any kind of statement, simple such as a:=3 or compound begin...end.
Any kind of statement has a value. For a begin...end block this is the last expression. For if..then..else.. what the final selected expression evaluates to, for assignment, the r-value expression.

That assignment have values, also appears in C:


if (a == b) {
/* do the following if a equals b */ ...
if (a = b) {
/* assign b into a and then do
the following if the result is nonzero */

Many languages like C, Java, Rust, etc support assignment operators such as: a +=5; b.c[3].d *= e;
These operators can prevent problems in evaluating operations like:
```
A[index_fn(i)] = A[index_fn(i)] + 1;
```
where the function index_fn has a side-effect which we don't want to execute twice.
C has increment (++) / decrement (--) operators which can be either written in prefix or postfix position:
```
b = a++; //add 1 to a but return original value of a;
b = ++a; // same as a += 1; b =a;
```
Some languages like Clu, ML, Perl, Python, and Ruby support multi-way assignment:
```
a, b = c, d // equivalent to a=c; b=d;
```

Which of the following statements is true?

Even though most imperative languages have a notion of assignment, they might not always allow giving an initial value to a variable as part of its declaration.
Such initial values though are useful:
1. A static variable local to a subroutine needs an initial value to be useful.
2. Statically allocated variables with initial values can have that value set in preallocated global memroy at compile time.
3. Having an initial value for a variable can avoid errors of using an unassigned value.
A syntax for initial values of primitive types is common in many programming languages. For example:
```
int a= 5;
```
An orthogonal approach should provide ways to initialize aggregates such as instance of structs and classes.
As initialization for objects is often cheaper that default initialization followed by initialization (because default value memory must be freed), it makes sense to allow initialization for objects (usually a constructor call) as part of declarations.
Some languages perform a dynamic check to see if a variable is being used before assignment (PHP) and give a semantic warning/error if it is. Other languages, use compile-time rules like the rule of definite assignment we mentioned earlier used in Java, and C# to prevent a variable from being used before given an initial value.

Consider the following expression:
```
f(a, g(b), h(c))
```
Our rules for associativity and priority of operators, don't tell us whether to evaluate g(b) first or h(c) first.
This can be important because:
1. Function calls might have side effects. - For example, g(b) might modify the value of c which h take as input.
2. One order might allow for code optimizations the other doesn't. For example in a * b + f(c). If we evaluate a*b before f(c) then we need memory to store this product; whereas, if we evaluate it afterward we don't.
Because of the importance of code improvement, many languages say that the order of evaluation of operands and arguments is undefined. Java and C# are unusual in that they enforce left-to-right order.

If we have a boolean expression, we can often determine its value without having to completely evaluate it.
For example, (true || any_condition) will always evaluate to true, and (false && any_condition) will always evaluate to false.
A compiler (such as a C, Rust, Java compiler) that performs short-circuit evaluation of Boolean expressions will generate code that skips the second half || and && computations when the overall value can be determined by the first half.

Doing this can save time in expressions like:

if (very_unlikely_condition && very_expensive_function()) ...

Some languages support an alternative version of conjunction and disjunction for the case where we want both arguments evaluated.
For example, in Perl we can use && if we want short-circuit evaluation, and if we don't. In C we can use && if we want short-circuit evaluation, & if we don't.

In assembly language control flow is achieved by means of conditional and unconditional jumps.
Fortran (and many languages since) mimicked this behavior by using goto statements for nonprocedural control flow:
```
if (A .lt. B) goto 10
...
10 
```
In the above 10 is a statement label.
The meaning of this code is: if A has value less than B then flow of control jumps to the code at the label 10.
A paper in the late 60s by Dijkstra argued that goto's made it hard to understand program flow because it is not structured.
Because of this, many languages developed from the 70s onward either completely abandoned the goto statement (Java, most scripting languages) or severely limit (Ada, C#) its application.
This abandonment of gotos was part of the structured programming revolution of the 1970s.
Structured programming is programming that emphasizes modularization of code, structured types, descriptive variable and constant names, and extensive comments. gotos in structured programming are replaced with sequencing using blocks, selection , and iteration constructs like while, for, etc.