Because operator might be a thunk, or allow me to call it delayed expression! For eg:
Consider tha ‘lambda’ passed as an argument.
1 (map (lambda (x) (+ x 1)) '(1 2 3 4)')
Let’s first view how a
map procedure might look:
1 2 3 4 5 (define (map proc items) (if (null? items) '() (cons (proc (car items)) (map proc (cdr items)))))
With normal order evaluation,
proc is a thunk and it contains
thunk (lambda (x) (+ x 1)).
Now since it is a
thunk, so we need to force its evaluation and need to we call
actual-value can work in both cases, either we pass a thunk or not. If thunk is passed then it first get the expression inside the thunk and evaluates it else it directly evaluates the expression.
So, we can always call
actual-value instead of
eval, because it will work for both cases either when operator is a thunk or not.
I think it’s better to explain the logical/conceptual reason for why something might work or not instead of explaining that what will happen if that code is executed. It’s better to explain why by saying because it is this thing we need to do this instead of saying because code won’t work correctly in that way.
The reason is that latter explains why it won’t work in a certain way but it won’t explain why it would would work in the proposed way.
For eg: in the above code, another way to explain is
If we had used
eval, then this code
(proc (car items)) won’t work because evaluating
proc would not work because proc contains
'thunk and when we pass this to
eval will try to lookup the procedure
thunk instead of executing
Notice that this explanation only explained why calling
eval won’t work it did not explained why calling
actual-value would work.
I might have done similar explanation earlier, I hope I will stick to logical way to explain instead of implementation way of explaining things.