# [plt-scheme] Re: to define, or to let (last try)

Paul Schlie <schlie at comcast.net> writes:
>* Please, you've got to be kidding:
*>*
*>>* This is incorrect. When I see a fragment of code written thus:
*>>*
*>>* (foo (compute-a) (compute-b))
*>>*
*>>* Then I know that it is equivalent to this:
*>>*
*>>* (let ((arg2 (compute-b)))
*>>* (foo (compute-a) arg2))
*>>*
*>>* or vice versa.
*>*
*>* - no, they're equally ambiguous if compute-a/b are interdependent.
*>* (so in truth, your presumed equivalence doesn't hold in R5RS)
*
If they are not equivalent, then this is not a legal program under
R5RS.
>>* However were it written like this:
*>>*
*>>* (let* ((arg1 (compute-a))
*>>* (arg2 (compute-b)))
*>>* (foo arg1 arg2))
*>>*
*>>* I *know* that this:
*>>*
*>>* (let* ((arg2 (compute-b)))
*>>* (foo (compute-a) arg2))
*>>*
*>>* is a different program.
*>*
*>* - yes, just as it would be a different program than:
*>*
*>* (foo (compute-a) (compute-b))
*>*
*>* - which would be equivalent to (if evaluation order were fixed L->R):
*>*
*>* (let ((arg1 (compute-a))
*>* (arg2 (compute-b)))
*>* (foo arg1 arg2))
*
These last two programs are equivalent independent of evaluation order.
>* which is actually a far more useful and unambiguous equivalence to have.
*
How can this be construed as an argument for fixing the order of
evaluation?
----
Incidentally, why not specify the other `unspecified' things in R5RS,
such as the return value of one-arm conditionals or the result of SET!
There is *no* argument for specifying the order of argument evaluation
that does not apply equally well to specifying the return value of
SET! or one-armed IF.