Introduction

On Monday, we were continuing our discussion of functional programming and the Scheme language.
We looked at how we could use the notion of closure to do object oriented programming using message passing.
We discussed applicative versus normal order (lazy) evaluation of arguments to functions.
To understand how these really work, given a function `f(x_1,...,x_n)` it helps to distinguish between its parameters, `x_1, ..., x_n` and the arguments `arg_1, ... arg_n` we supply to these parameters. In general, an argument is either a constant such as 0, 2.3, etc., some current scope variable, my_var1, etc, or an expression built from these atoms 2.3*my_var, etc.
In applicative order evaluation, when evaluating function with arguments, we evaluate the arguments first and send these to the function.
In normal order evaluation, we replace the function call on the arguments with the body of function where occurrence of the function parameters have been replaced with the supplied arguments, and then start evaluating.
Scheme functions use applicative order evaluation, Scheme macros (special forms) use normal order evaluation.
Scheme macros can be defined using define-syntax.
We showed how the delay macro could be defined using define-syntax, and the force function could be defined as an ordinary Scheme function.
We used delay and force to show how streams, infinite lists, could be implemented in Scheme.
Finally, we concluded last day by going over various built-in functions in Scheme.
We begin today by looking at order of evaluation again...

Language Strictness

On Monday, we gave situations where applicative order was faster than normal order evaluation and vice-versa.
Evaluation order can also affect program correctness.
For example, you might have a program where the second argument, if evaluated, would cause a divide-by-zero error, so under applicative order evaluation an error always occurs; however, if that second argument is unneeded for normal order evaluation then the program might run successfully.
We define a function to be strict if it is undefined (fails to terminate, or encounters an error) when any of its arguments is undefined. A function that is not strict we call nonstrict.
A language is said to be strict if it is defined in such a way that functions are always strict. A language is nonstrict otherwise.
If a language always uses applicative order evaluation it will be strict. Example strict languages include: Standard ML, OCaml, and Scheme without macros.
A nonstrict language cannot use applicative order; it must use normal order to avoid evaluating unneeded arguments. Example nonstrict languages include: Miranda and Haskell.

Implementing Lazy Evaluation Efficiently

As we said before normal order evaluation is slow versus applicative order evaluztion when we need to reuse a subexpression more than once:
```
(define double (lambda (x) (+ x x)))
(double (* 3 4))
=>(+ (* 3 4) (* 3 4))
=>(+ 12 (* 3 4))
=>(+ 12 12) ; we compute (* 3 4) twice
=>24
```
In automatic lazy evaluation, we keep a table of arguments we have evaluated previously, if an argument's value is needed we first check this table and use the value there if present, otherwise, we compute the argument, store its value in the table, then use it.
This table is called a memo table, and this process is called memoization.

In a lazy/nonstrict language such as Miranda or Haskell, we could imagine an expression like (double (* 3 4)) being compiled internally as:

(define f 
  (lambda ()
    (let ((done #f) 
         (memo '())  ; memo initially unset
         (code (lambda () (* 3 4)))) 
      (if done memo ; if memo is set, return it
         (begin
            (set! memo (code)) ; remember value 
            (set! done #t) ; note that we set it
            memo)))))  ; and return it

Given f, (double (* 3 4)) become (double (f)) which evaluates as:

=>(+ (f) (f))
=>(+ 12 (f))  ; first call computes value of (*3 4)
=>(+ 12 12) ; second call uses remembered value
=>24

In-Class Exercise

The Fibonacci Sequence is defined as: `F_0 = F_1 = 1`, and `n >= 0`, `F_{n+2} = F_{n+1} + F_n`.
So, `F_2 = 2`, `F_3 = 3`, `F_4 = 5`, `F_5 = 8`, ...
Write a Scheme function fib using memoization (in this case here just make a list of values of `F_n`), so that (fib n) compute the `n`th Fibonacci number.
Please post your solution to the Nov 17 In-Class Exercise Thread.

Parameter Passing Mechanisms

Since we have looked at when arguments passed to procedures are evaluated, it also makes sense to consider a little how these arguments are in fact passed.
Here are some different ways data can be fed into parameters:
- Pass by Value - replace all the parameters in the body of the procedure by the corresponding argument value (might use of applicative order)
- Pass By Reference - pass the location of the argument (might use for objects in Java). In C++, this might correspond to a function with a signature involving an &. For example, int foo (int& a);
- Pass By Value Result - do pass by value, then take the final result of the procedure and copy it back to the location of the passed argument. To see how this differs from Pass By Reference, consider the following C code:
```
void p(int x, int y)
{
   x++;
   y++;
}
int main()
{
   int a = 1;
   p(a,a);
   ...
}
```
  The above would have value 3 under Pass By Reference, value 2 under Pass By Value Result.
- Pass By Name and Delayed Evaluation - this is essentially what happens with a macro.

I/O and Streams

Recall 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. For example, an assignment statement in C has a side effect.
One major source of side effects can be found in traditional I/O: an input routine will generally return a different value every time it is called, and multiple calls to an output routine, though they never return a value, must occur in the proper order if the program is to be considered correct.
One way to avoid these side effects is to model input and output as streams -- unbounded length lists whose elements are generated lazily.
In this setting, our program might take the form:
```
(define output (my_prog input))
```
where we imagine output and input are streams.
When my_prog needs a value it calls head on the input stream to get a value, and passes as yet unevaluated tail to the rest of the program.

To drive execution, the language implementation repeatedly forces evaluation of the car of output, prints it, and repeats:

(define driver 
  (lambda (s)
    (if (null? s) '() ; nothing left 
       (begin
         (display (car s))
         (driver (cdr s))))))
(driver output)

Purely Functional I/O Example

The following code prompts the user for a sequence of numbers such that after each number it prints their squares.

If Scheme employed lazy evaluation of input and output streams (it doesn't), then we could write:

(define squares 
  (lambda (s)
    (cons-stream "please enter a number\n"
          (let ((n (head s))) ; head, tail, and cons-stream
                              ; for streams from last day
             (if (eof-object? n) '()
                (cons-stream (* n n) 
                    (cons-stream #\newline (squares (tail s)))))))))
(define output (squares input)))

More Order of Evaluation