Comments on: SICP sections 4.1.1 - 4.1.2

By: Michal Marczyk

Michal Marczyk — Mon, 11 Feb 2008 01:24:17 +0000

It seems to me that the expressions composing the body of the lambda cannot be evaluated at the time of creation of the lambda, because in general:

(1) they may cause side effects which the user would presumably expect to take place if and when the lambda is executed (applied to a set of arguments) — and, in general, it is hard to tell whether an expression has the potential to cause any side effects or not (it would be necessary to check any and all procedures which would be called if the expression was to be evaluated, possibly finding further procedures inside those first ones and so on…);

(2) if they reference free variables, then those variables can hold different values at the time of execution of the procedure created by the lambda form than those they held at the time of evaluation of the lambda form, in which case the new values should be used at the time of execution.

If it was actually possible to determine that a given lambda is `safe’ in the sense that one does not have to worry about (1) and (2) above, or any similar concerns, in its particular case — which may be the case with very simple procedures or if we know beforehand that the environment in which the procedure will be closed has no bindings for any `un-safe’ constructs (no value changes for variables) — then that would mean that we are dealing with a purely functional fragment of Lisp/Scheme and evaluation order is inconsequential anyway.

All best

By: valery

valery — Thu, 31 Jan 2008 15:06:56 +0000

I’m now reading ‘Lisp In Small Pieces’. Hope I’ll understand this after I am through.

By: eliben

eliben — Tue, 29 Jan 2008 17:34:50 +0000

valeriy, this is an interesting question. Perhaps it’s not valid to do the optimization you mention exactly for this reason ?
It would be interesting to find out the answer, maybe in the comp.lang.scheme newsgroup

By: valeriy

valeriy — Mon, 28 Jan 2008 23:33:17 +0000

It is interesting, can you explain one thing about ex 4.1 in SICP.
I understand that solutions with let* must be correct, as well as with
two nested let’s. But, in Scheme R5RS, all ‘let’ forms are listed as ‘library syntax’,
and that every form of variable binding can be expressed with ‘lambda’. This:

(let ((x a)) (f x)) is ((lambda (x) (f x)) a)

Now, if we rewrite the function with lambda’s:

(define (list-of-values exps env)
(if (no-operands? exps)
‘()
((lambda (x)
((lambda (y) cons x y) (list-of-values (rest-operands exps))))
(eval (first-operand exps) env))))

We notice that both lambdas are actually closures. The problem is that R5RS does
not specify semantics of procedure creation, but only procedure application.
And, for evaluator, it would be a valid strategy to evaluate the subexpressions
of the closure which only depend on the free variables when constructing the lambdas, this could be actually a good optimization somethings.
So it basically can evaluate (list-of-values (rest-operands exps)),
when creating the outer lambda, thus, the order of evaluation would be from right to left.

I feel something is wrong with my reasoning, but I don’t understand where.