PLQ #8Done on:   Tuesday, November 15th

Question 1 @ 2022-11-15 18:37

Consider the following expression:

(if if 1 2)

If we try in the the usual #lang pl, we get a “bad syntax” error, but in the lazy language (#lang pl lazy) it runs fine. What’s happening?

  1. The lazy language has if bound to a plain function value, and since it’s not #f, we get a result of 1.

  2. The lazy language has if bound to a plain function value, and since it’s not #t, we get a result of 2.

  3. The lazy language does not force the evaluation of the second if, instead, it short circuits to a result of 1.

  4. The lazy language does not force the evaluation of the second if, instead, it short circuits to a result of 2.

Question 2 @ 2022-11-15 18:44

What will the following `pl lazy’ expression output if evaluated in the REPL?

> (define sevens (let ([xs (cons 7 xs)]) xs))
> sevens
  1. 7
  2. #promise:sevens
  3. #procedure:sevens
  4. xs: undefined
  5. #0=’(7 . #0#)
  6. expected: 6, given: 7

Question 3 @ 2022-11-15 18:47

Consider our evaluator to compiler transformation.

True or false:

It didn’t end in a real compiler, in the sense that it just produces racket functions instead.

T F

Question 4 @ 2022-11-15 18:48

Consider our evaluator to compiler transformation.

True or false:

It separates an all-in-one evaluation operation into two stages: compilation and runtime execution.

T F

Question 5 @ 2022-11-15 18:48

Consider our evaluator to compiler transformation.

True or false:

It removes the need for an environment while running the program.

T F

Question 6 @ 2022-11-15 18:49

Consider our evaluator to compiler transformation.

True or false:

It allows type based optimizations.

T F

Question 7 @ 2022-11-15 18:50

Consider our evaluator to compiler transformation.

True or false:

It provides runtime speed improvements.

T F

Question 8 @ 2022-11-15 18:51

Consider our evaluator to compiler transformation.

True or false:

Compiled versions of TOY programs are translated into Racket closures.

T F

Question 9 @ 2022-11-15 18:52

Consider our evaluator to compiler transformation.

True or false:

Compiled versions of TOY programs are indirectly translated into machine code.

T F

Question 10 @ 2022-11-15 18:53

Consider our evaluator to compiler transformation.

True or false:

It makes it possible to separate the evaluator into two standalone pieces of code: the compiler code and the runtime code.

T F

Question 11 @ 2022-11-15 18:54

Consider our evaluator to compiler transformation.

True or false:

Checking the structure of a TOY program happens at runtime.

T F

Question 12 @ 2022-11-15 18:55

Consider our evaluator to compiler transformation.

True or false:

AST values live only in the compiler, not in the runtime.

T F

Question 13 @ 2022-11-15 18:55

Consider our evaluator to compiler transformation.

True or false:

ENV values live only in the compiler, not in the runtime.

T F