PLQ #5Done on:   Tuesday, October 27th

Question 1 @ 2020-10-27 20:04

We’ve seen how the core of the Y combinator leads to an inifinte nesting of calls to F:

((lambda (x) (x x))
(lambda (x) (F (x x))))
=>
(F (F (F ...)))

What would we get if we’d change it to:

((lambda (x) (G (x x)))
(lambda (x) (F (x x))))
=>
???
  1. (G (F (G (F …))))
  2. (F (G (F (G …))))
  3. (G (F (F (F …))))
  4. (F (G (G (G …))))
  5. It’s an infinite loop anyway, so it doesn’t matter

Question 2 @ 2020-10-27 20:16

What would I get in Schlac if I evaluate the following code:

(define foo (lambda (x x) x))
(foo 1 2)
  1. 1
  2. 2
  3. 3
  4. 4
  5. Error about the duplicate binding.
  6. Depends on the compiler.
  7. The shadowing would make it use dynamic scope and therefore an error about unbound x.
  8. Forget what #7 said, you’d get an unbound identifier error, but not with the dynamic scope nonsense.

Question 3 @ 2020-10-27 20:23

Assume that Racket had mutable lists, where we can change the tail of a pair using a set-cdr! function. For example:

> (define a (list 1 2))
> (define b (list 3 4))
> (set-cdr! a b)
> a
'(1 3 4)

What will happen if we’d do this:

> (define l (list 1 2 3 4))
> (set-cdr! l l)
> (length l)
?
  1. I don’t know, depends on which language level it is.
  2. I don’t know, depends on how length is implemented.
  3. I don’t know, depends on whether the compiler detects code cycles.
  4. I don’t know, but it doesn’t matter.
  5. We would get an error.
  6. We would get 1.
  7. We wouldn’t get anything since we’d get stuck in an infinite loop.
  8. We would get 12.