PLQ #9

Question 1 @ 2024-03-19 19:11

When we converted our evaluator to a compiler, we started by currying eval. What was the point of doing that?

A
It was a purely syntactic change that makes the code more readable, in preparation for the conversion process.
B
Currying eval merges the compile-time and run-time stages, which simplifies the compilation process.
C
Currying eval separates the environment argument, which creates two stages: a place in the code which is compile-time, and a place which is run-time.
D
Currying eval makes the compile-time and run-time stages more efficient by eliminating the need for an environment.
E
Curried functions that take only one argument are easier to compile.

In the compiled Toy language from last lecture, what would be the result of running the following program (assuming the usual global environment)?

{+ 1 n}

A
An unbound identifier error being thrown while the code is being compiled (a compile-time error).
B
An unbound identifier error being thrown after compilation, while the compiled form of the program is running (a run-time error).
C
An arithmetic error being thrown during run-time by the underlying Racket implementation.
D
1

Say that in some extended version of last week’s compiler, you see the following:

(define (compile expr)
...
(cases expr
...
[...
(if ...something...
(lambda ([env : ENV])
(error ...)) ; <---
(lambda ([env : ENV])
...))]
...))

What can you say about this error?

A It’s a typical compile-time error.
B It’s a typical run-time error.
C It’s a typical type error.
D It’s nonsensical code.
E It’s a case where we know that there’s an error at compile-time, but need to defer throwing it at run-time for whatever reasons.

Why is debugging in a lazy language difficult?

A
The order of evaluation of expressions can be unclear.
B
Control flow in lazy languages is linear, making it harder to trace back errors.
C
Lazy evaluation can cause some expressions to be evaluated multiple times, complicating the tracking of state changes.
D
Lazy languages do not produce runtime errors.
E
As we’ve seen, errors happen at a dynamic context that is usually useless.