[plt-scheme] Re: to define, or to let

From: Joe Marshall (jrm at ccs.neu.edu)
Date: Fri Apr 23 11:13:17 EDT 2004

Bill Richter <richter at math.northwestern.edu> writes:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
>    Joe Marshall <jrm at ccs.neu.edu> responds to me:
>
>    > A procedure call (foo goo) where the side-effects of foo affect
>    > goo.  In R5RS Scheme, that's a bug, because you don't know the
>    > eval order.
>    >
>    > In Mzscheme, that's "formerly-buggy", because Mzscheme specifies
>    > left->right evaluation.  We know that foo is gonna get evaluated
>    > first, and so we can count on that, and know what the effect on
>    > goo's evaluation is gonna be.
>
>    There is a subtle flaw in your logic here.  
>
> I don't think so, Joe.  I think it's a subtle communication problem:
>
>    If you *know* that foo will have an effect on the evaluation of goo
>    in the second example, you should also *know* that in the first
>    example.  Therefore, you *wouldn't* write the first example in that
>    way, you'd write something more like
>
>      (let* ((proc (foo))
> 	    (arg  (goo)))
> 	(proc arg))
>
> Good!  And as I said, it would be a bug to write (foo goo), in R5RS
> Scheme, where we don't know the eval order.  But didn't you mean
>
>      (let* ((proc foo)
> 	    (arg  goo))
> 	(proc arg))
>
> as an alternative to (foo goo)?  Your code is an alternative, as you
> write below, to ((foo) (goo)).  Let's puzzle this out: For me, foo was
> gonna return a procedure.  The obvious way to do this is of course 
> (define (foo goo) .... )
> But for you, hmm..  foo will return a lambda expression, so (foo)
> which will then return a procedure?  Sounds like 
> (define foo '(lambda (goo) .... ))

I did in fact change your example code, and that was on purpose.  You
wrote:

>  [consider] A procedure call (foo goo) where the side-effects of foo
>  affect goo. 

In the expression (foo goo) as normally understood, both foo and goo
are variables and evaluating a variable does not cause side-effects.
Thus the example doesn't demonstrate anything with regard to order of
evaluation.

By writing ((foo) (goo)) and not defining either foo or goo I leave
the door open for either one to affect the evaluation of the other.
It is implied that whatever foo does it must return a function of
arity 1 or greater.

> Good!  And as I said, it would be a bug to write (foo goo), in R5RS
> Scheme, where we don't know the eval order.  But didn't you mean
>
>      (let* ((proc foo)
> 	    (arg  goo))
> 	(proc arg))

In the absence of introspection this is identical to (foo goo) no
matter what the order of evaluation is because FOO and GOO are
variables.

I'll respond to the rest of your article later today.



Posted on the users mailing list.