The same thing happens that happened in Exercise 1.5 and for the same reason. Because new-if uses normal order evaluation, the rewritten sqrt-itr never terminates. In contrast, plain-old if uses applicative order evaluation. The original sqrt-itr can terminate (without calling itself) once the good-enough? condition is satisfied.
<< Previous exercise (1.5) | sicp-solutions | Next exercise (1.7) >>
I agree with jsdalton. The reason why new-if runs out of memory is applicative order evaluation, so if the plain-old if uses applicative order evaluation, it should not work either.
And I guess for a certain interpreter, maybe it should use a consistent way for all processes?
I believe this solution is incorrect.
new-if does not use normal order evaluation, it uses applicative order evaluation. That is, the interpreter first evaluates the operator and operands and then applies the resulting procedure to the resulting arguments. As with Excercise 1.5, this results in an infinite recursion because the else-clause is always evaluated, thus calling the procedure again ad infinitum.
The if statement is a special form and behaves differently. if first evalutes the predictate, and then evaluates either the consequent (if the predicate evalutes to #t) or the alternative (if the predicate evalues to #f). This is key difference from new-if -- only one of the two consequent expressions get evaluated when using if, while both of the consequent expressions get evaluated with new-if.