# Notes of Scala course on Coursera -- Week 1

Here are my notes for the week 1’s lecture of Functional Programming Principles in Scala on Coursera.

### Evaluation of Programming

Every non-trivial programming language provides:

• primitive expressions representing the simplest elements
• ways to combine expressions
• ways to abstract expressions, which introduces a name for an expression by which it can be referred to

A non-primitive expression is evaluated as follows:

1. Take the leftmost operator
2. Evaluate its operands (left before right)
3. Apply the operator to the operands

A name is evaluated by replacing it with the right hand side of its definition.

Example:

Definition can have parameters:

Parameter and Return Types:

Evaluation of Function Applications

1. Evaluate all function arguments, from left to right.
2. Replace the function application by the function’s right-hand side, and, at the same time,
3. Replace the formal parameters of the function by the actual arguments.

Example:

### The substitution model

The scheme of expression evaluation is called the substitution model.

The idea is that all evaluation dose is reduce an expression to a value.

It can be applied to all expressions, as long as they have no side effects.

The substitution model is formalized in the λ-calculus, which gives a
foundation for functional programming.

### Call By Value v.s. Call By Name

Both strategies reduce to the same final values as long as

• the reduced expression consists of pure functions, and
• both evaluations terminate.

Call-by-value has the advantage that it evaluates every function
argument only once
.

Call-by-name has the advantage that a function argument is not
evaluated if the corresponding parameter is unused in the evaluation
of the function body
.

An Example of CBV:

An Example of CBN:

CBV vs CBN:

• If CBV evaluation of an expression e terminates, then CBN evaluation of e terminates, too.
• The other direction is not true.

Let’s define

and consider the expression first(1, loop).

Under CBN, it will terminate.

Under CBV, it won’t.

Scala normally uses call-by-value.

• Because it avoids this repeated recomputation of argument expressions that call by name entails
• It plays much nicer with, imperative effects and side effects because you tend to know much better when expressions will be evaluated

But if the type of a function parameter starts with => it uses call-by-name.

Example:

Let’s trace the evaluations of

### Conditional Expressions

It looks like a if-else in Java, but is used for expressions, not statements.

Example:

### Value Definitions

def: “by-name”, its right hand side is evaluated on each
use.

var: “by-value”, Example:

#### Value Definitions and Termination

A definition

is OK, but a definition

will lead to an infinite loop.

#### Exercise

Write functions and and or such that for all argument expressions x
and y :

(do not use || and && in your implementation)

It seems OK, but what if

OOPS! What’ wrong? y: Boolean is a call-by-value form, let’s change it to call-by-name form:

Try and(false loop) again, it’s OK!

### Blocks and Lexical Scope

#### Nested functions

It’s good functional programming style to split up a task into many small functions.

But the names of functions like sqrtIter, improve, and isGoodEnough matter only for the implementation of sqrt , not for its usage.

Normally we would not like users to access these functions directly.

We can achieve this and at the same time avoid “name-space
pollution”
by putting the auxciliary functions inside sqrt.

#### Blocks in Scala

• A block is delimited by braces { … }
• It contains a sequence of definitions or expressions.
• The last element of a block is an expression that defines its value.
• This return expression can be preceded by auxiliary definitions.
• Blocks are themselves expressions; a block may appear everywhere an expression can.

#### Blocks and Visibility

• The definitions inside a block are only visible from within the block.
• The definitions inside a block shadow definitions of the same names outside the block.

#### Lexical Scoping

Definitions of outer blocks are visible inside a block unless they are

Therefore, we can simplify sqrt by eliminating redundant
occurrences of the x parameter
, which means everywhere the same
thing:

#### Semicolons

In Scala, semicolons at the end of lines are in most cases optional.
You could write

but most people would omit the semicolon.
On the other hand, if there are more than one statements on a line,
they need to be separated by semicolons:

#### Semicolons and infix operators

One issue with Scala’s semicolon convention is how to write
expressions that span several lines. For instance

would be interpreted as two expressions:

There are two ways to overcome this problem.
You could write the multi-line expression in parentheses, because
semicolons are never inserted inside (…) :

Or you could write the operator on the first line, because this tells
the Scala compiler that the expression is not yet finished: