2010-03-19
- Lazy Evaluation: Using a Lazy Scheme (contd.)
- Lazy Evaluation: Shell Examples
- Lazy Evaluation: Programming Examples
- Side Note: Similarity with Generators and Channels
- Call by Need vs Call by Name
- Example of Feature Embedding

========================================================================
There are a few issues that we need to be aware of when we're dealing
with a lazy language.  First of all, remember that our previous attempt
at lazy evaluation has made

  {with {x y}
    {with {y 1}
      x}}

evaluate to 1, which does not follow the rules of lexical scope.  This
is *not* a problem with lazy evaluation, but rather a problem with our
naive implementation.  We will shortly see a way to resolve this
problem.  In the meanwhile, remember that when we try the same in Lazy
Scheme we do get the expected error:

  > (let ([x y])
      (let ([y 1])
        x))
  reference to undefined identifier: y

A second issue is a subtle point that you might have noticed when we
played with Lazy Scheme: for some of the list values we have see a "."
printed.  This is part of the standard way Scheme displays an "improper
list" -- any list that does not terminate with a null value.  For
example, in normal Scheme:

  > (cons 1 2)
  (1 . 2)
  > (cons 1 (cons 2 (cons 3 4)))
  (1 2 3 . 4)

In the dialect that we're using in this course, this is not possible.
The secret is that the `cons' that we use first checks that its second
argument is a proper list, and it will raise an error if not.  So how
come Lazy Scheme's `cons' is not doing the same thing?  The problem is
that to know that something is a proper list, we will have to force it,
which will make it not behave like a constructor.

Finally, there are two consequences of using a lazy language that make
it more difficult to debug (or at lease take some time to get used to).
First of all, control tends to flow in surprising ways.  For example,
enter the following into DrScheme, and run it in the normal language
level for the course:

                   (define (foo3 x)
                     (/ x "1"))

  (define (foo2 x)
    (foo3 x))
                   (define (foo1 x)
                     (list (foo2 x)))
  (define (foo0 x)
    (car (foo1 x)))

           (+ 1 (foo0 3))

In the normal language level, we get an error, and red arrows that show
us how where in the computation the error was raised.  The arrows are
all expected, except that `foo2' is not in the path -- why is that?
Remember the discussion about tail-calls and how they are important in
Scheme since they are the only tool to generate loops?  This is what
we're seeing here: `foo2' calls `foo3' in a tail position, so there is
no need to keep the `foo2' context anymore -- it is simply replaced by
`foo3'.  Now switch to Lazy Scheme and re-run -- you'll see a single
arrow, skipping over everything and going straight to the erroneous
expression.  What's the problem?  The call of `foo0' creates a promise
that is forced in the top-level expression, that simply returns the
`car' of the `list' that `foo1' created -- and all of that can be done
without forcing the `foo2' call.  Going this way, the computation is
finally running into an error *after* the calls to `foo0', `foo1', and
`foo2' are done -- so we get the seemingly out-of-context error.

Finally, there are also potential problems when you're not careful about
memory use.  A common technique when using a lazy language is to
generate an infinite list and pull out the Nth element.  For example, to
compute the Nth Fibonacci number, we've seen how we can do this:

  (define fibs (cons 1 (cons 1 (map + fibs (cdr fibs)))))
  (define (fib n) (list-ref fibs n))

and we can also do this (reminder: the same as an internal definition):

  (define (fib n)
    (letrec ([fibs (cons 1 (cons 1 (map + fibs (cdr fibs))))])
      (list-ref fibs n)))

but the problem here is that when `list-ref' is doing its way down the
list, it might still hold a reference to `fibs', which means that as the
list is forced, all intermediate values are held in memory.  In the
first of these two, this is guaranteed to happen since we have a binding
that points at the head of the `fibs' list.  With the second form things
can be confusing: it might be the case that our language implementation
is smart enough to see that `fibs' is not really needed any more and
release the offending hold, but even if this is the case, tricky
situations are hard to avoid.

(Side note: MzScheme didn't use to do this optimization, but now it
does.)

========================================================================
>>> Lazy Evaluation: Shell Examples

There is a very simple and elegant principle in shell programming -- we
get a single data type, a character stream, and many small functions,
each doing a single simple job.  With these small building blocks, we
can construct more sequences that achieve more complex tasks, for
example -- a sorted frequency table of lines in a file:

  sort foo | uniq -c | sort -nr

This is very much like a programming language -- we get small blocks,
and build stuff out of them.  Of course there are swiss army knives like
awk that try to do a whole bunch of stuff, (the same attitude that
brought Perl to the world...) and even these respect the "stream" data
type.  For example, a simple "{ print $1 }" statement will work over all
lines, one by one, making it a program over an infinite input stream,
which is what happens in reality in something like:

  cat /dev/console | awk ...

But there is something else in shell programming that makes so
effective: it is implementing a sort of a lazy evaluation.  For example,
compare this:

  cat foo | awk '{ print $1+$2; }' | uniq

to:

  cat foo | awk '{ print $1+$2; }' | uniq | head -5

Each element in the pipe is doing its own small job, and it is always
doing just enough to feed its output.  Each basic block is designed to
work even on infinite inputs!  (Even sort works on unlimited inputs...)
(Soon we will see a stronger connection with lazy evaluation.)

As an aside: (Alan Perlis) "It is better to have 100 functions operate
on one data structure than 10 functions on 10 data structures"...  But
the uniformity comes at a price: the biggest problem shells have is in
their lack of a recursive structure, contaminating the world with way
too many hacked up solutions.  More than that, it is extremely
inefficient and usually leads to data being re-parsed over and over and
over -- each small Unix command needs to always output stuff that is
human readable, but the next command in the pipe will need to re-parse
that, eg, rereading decimal numbers.  If you look at pipelines as
composing functions, then a pipe of numeric commands translates to
something like:

  itoa(baz(atoi(itoa(bar(atoi(itoa(foo(atoi(inp)))))))))

and it is impossible to get rid of the redundant "atoi(itoa(...))"s.

========================================================================
>>> Lazy Evaluation: Programming Examples

We already know that when we use lazy evaluation, we are guaranteed to
have more robust programs.  For example, a function like:

  (define (my-if x y z)
    (if x y z))

is completely useless in Scheme because all functions are eager, but in
a lazy language, it would behave exactly like the real if.  Note that we
still need *some* primitive conditional, but this primitive can be a
procedure (and it is, in Lazy Scheme).

But we get more than that.  If we have a lazy language, then
*computations* are pushed around as if they were values (computations,
because these are expressions that are yet to be evaluated).  In fact,
there is no distinction between computations and values, it just happens
that some values contain "computational promises", things that will do
something in the future.

To see how this happens, we write a simple program to compute the
(infinite) list of prime numbers using the sieve of Eratosthenes.  To do
this, we begin by defining the list of all natural numbers:

  (define nats (cons 1 (map add1 nats)))

And now define a `sift' function: it receives an integer `n' and an
infinite list of integers `l', and returns a list without the numbers
that can be divided by `n'.  This is simple to write using `filter':

  (define (sift n l)
    (filter (lambda (x) (not (divides? n x))) l))

and it requires a definition for `divides?' -- we use Scheme's `modulo'
for this:

  (define (divides? n m)
    (zero? (modulo m n)))

Now, a `sieve' is a function that consumes a list that begins with a
prime number, and returns the prime numbers from this list.  To do this,
it returns a list that has the same first number, and for its tail it
sifts out numbers that are divisible by the first from the original
list's tail, and calls itself recursively on the result:

  (define (sieve l)
    (cons (car l) (sieve (sift (car l) (cdr l)))))

Finally, the list of prime numbers is the result of applying `sieve' on
the list of numbers from 2.  The whole program is now:

  ----------------------------------------------------------------------
  (define nats (cons 1 (map add1 nats)))
  (define (divides? n m)
    (zero? (modulo m n)))
  (define (sift n l)
    (filter (lambda (x) (not (divides? n x))) l))
  (define (sieve l)
    (cons (car l) (sieve (sift (car l) (cdr l)))))
  (define primes (sieve (cdr nats)))
  ----------------------------------------------------------------------

To see how this runs, we trace `modulo' to see which tests are being
used.  The effect of this is that each time `divides?' is actually
required to return a value, we will see a line with its inputs, and its
output.  This output looks quite tricky -- things are computed only on a
"need to know" basis, meaning that debugging lazy programs can be
difficult, since things happen when they are needed which takes time to
get used to.  However, note that the program actually performs the same
tests that you'd do using any eager-language implementation of the sieve
of Eratosthenes, and the advantage is that we don't need to decide in
advance how many values we want to compute -- all values will be
computed when you want to see the corresponding result.  Implementing
*this* behavior in an eager language is more difficult than a simple
program, yet we don't need such complex code when we use lazy
evaluation.

Note that if we trace `divides?' we see results that are some promise
struct -- these are unevaluated expressions, and they point at the fact
that when `divides?' is used, it doesn't really force its arguments --
this happens later when these results are forced.

The analogy with shell programming using pipes should be clear now --
for example, we have seen this:

  cat foo | awk '{ print $1+$2; }' | uniq | head -5

The last `head -5' means that no computation is done on parts of the
original file that are not needed.  It is similar to a `(take 5 l)'
expression in Lazy Scheme.

========================================================================
>>> Side Note: Similarity with Generators and Channels

Using infinite lists can often be similar to using channels (see the
talk at http://video.google.com/videoplay?docid=810232012617965344#),
and generators (as they exist in Python).  Here are examples of both,
note how similar they both are, and how similar they are to the above
definition of `primes'.  (But note that there is an important
difference, can you see it?  It has to be with whether a stream is
reusable or not.)

  ----------------------------------------------------------------------
  #lang scheme

  (define-syntax-rule (bg expr ...) (thread (lambda () expr ...)))

  (define nats
    (let ([out (make-channel)])
      (define (loop i) (channel-put out i) (loop (add1 i)))
      (bg (loop 1))
      out))
  (define (divides? n m)
    (zero? (modulo m n)))
  (define (filter pred c)
    (define out (make-channel))
    (define (loop)
      (let ([x (channel-get c)])
        (when (pred x) (channel-put out x))
        (loop)))
    (bg (loop))
    out)
  (define (sift n c)
    (filter (lambda (x) (not (divides? n x))) c))
  (define (sieve c)
    (define out (make-channel))
    (define (loop c)
      (define first (channel-get c))
      (channel-put out first)
      (loop (sift first c)))
    (bg (loop c))
    out)
  (define primes
    (begin (channel-get nats) (sieve nats)))

  (define (take n c)
    (if (zero? n) '() (cons (channel-get c) (take (sub1 n) c))))

  (take 10 primes)
  ----------------------------------------------------------------------

  ----------------------------------------------------------------------
  #lang scheme

  (require scheme/generator)

  (define nats
    (generator (letrec ([loop (lambda (i)
                                (yield i)
                                (loop (add1 i)))])
                 (loop 1))))
  (define (divides? n m)
    (zero? (modulo m n)))
  (define (filter pred g)
    (generator (letrec ([loop (lambda ()
                                (let ([x (g)])
                                  (when (pred x) (yield x))
                                  (loop)))])
                 (loop))))
  (define (sift n g)
    (filter (lambda (x) (not (divides? n x))) g))
  (define (sieve g)
    (define (loop g)
      (define first (g))
      (yield first)
      (loop (sift first g)))
    (generator (loop g)))
  (define primes
    (begin (nats) (sieve nats)))

  (define (take n g)
    (if (zero? n) '() (cons (g) (take (sub1 n) g))))

  (take 10 primes)
  ----------------------------------------------------------------------


========================================================================
>>> Call by Need vs Call by Name

Finally, note that on requiring different parts of the `primes', the
same calls are not repeated.  This indicates that our language
implements "call by need" rather than "call by name": once an expression
is forced, its value is remembered, so subsequent usages of this value
do not require further computations.

Using "call by name" means that we actually use expressions which can
lead to confusing code.  An old programming language that used this is
Algol.  A confusing example that demonstrates this evaluation strategy
is:

  ----------------------------------------------------------------------
  begin
    integer procedure SIGMA(x, i, n);
      value n;
      integer x, i, n;
    begin
      integer sum;
      sum:=0;
      for i:=1 step 1 until n do
          sum:=sum+x;
      SIGMA:=sum;
    end;
    integer q;
    printnln(SIGMA(q*2-1, q, 7));
  end
  ----------------------------------------------------------------------

`x' and `i' are arguments that are passed by name, which means that they
can use the same memory location.  This is called "aliasing", a problem
that happens when pointers are involved (eg, pointers in C and
`reference' arguments in C++).

========================================================================
>>> Example of Feature Embedding

Another interesting behavior that we can now observe, is that the TOY
evaluation rule for `with':

  eval({with {x E1} E2}) = eval(E2[eval(E1)/x])

is specifying an eager evaluator *only if* the language that this rule
is written in is itself eager.  Indeed, if we run the TOY interpreter in
Lazy Scheme (or other interpreters we have implemented), we can verify
that running:

  (run "{bind {{x {/ 1 0}}} 1}")

is perfectly fine -- the call to Scheme's division is done in the
evaluation of the TOY division expression, but since Lazy Scheme is
lazy, then if this value is never used then we never get to do this
division!  On the other hand, if we evaluate

  (run "{bind {{x {/ 1 0}}} {+ x 1}}")

we do get an error when DrScheme tries to display the result, which
forces strictness.  Note how the arrows in DrScheme that show where the
computation is are quite confusing: the computation seem to go directly
to the point of the arithmetic operations (arith-op) since the rest of
the evaluation that the evaluator performed was already done, and
succeeded.  The actual failure happens when we try to force the
resulting promise which contains only the strict points in our code.

========================================================================