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

Joe Marshall wrote:
>    To tell the truth, the primary reason that order of evaluation is
>    not specified is because MIT did it right to left and Indiana did
>    it left to right and there was no compelling argument that could
>    sway either side.

The following RRRS post by Bill Rozas has a summary circa 1984, which
gives a more substantial rationale:

http://zurich.csail.mit.edu/pipermail/rrrs-authors/1984-December/000029.html

Bill Richter wrote:
> Thanks.  I'm compelled by the Standard Reduction theorem of LC, which
> says reducing the left-most redex always returns the beta-nf, if it
> exists.

I presume this doesn't refer to normal order evaluation, since that's not
the same as Scheme's order or LC_v's order anyway.  See the note in the
above link about the Rabbit compiler - normal-order LC evaluation is
actually an argument for the unspecified order in R5RS.

If you're talking about LC_v reduction, then we've gone over this:
argument evaluation order is arbitrary in LC_v.  By arbitrary, I mean that
using an argument evaluation order other than left to right doesn't affect
the ability, in LC_v, to reach a normal form - if it's reachable in LC_v,
it's reachable with any argument eval order.  So what's  "compelling" you
is simply that you want to do it a certain way out of convention.  Which
is fine, of course.  I'm just trying to keep the facts from being too
badly mangled here.

The real compelling reason for fixed order, of course, is in the presence
of mutation, but neither LC nor pure LC_v has anything to say about that.

> To me, you're driving home the point that McCarthy didn't
> know LC or LC_v, and/or wasn't particularly concerned with it.

You're confusing Lisp with Scheme.  The Scheme inventors were explicitly
interested in LC.  Again, see the LC connection made in the above link.

>    That is crucial difference!  Yes, the resulting actions of the
>    computer might be identical, but the impression that it has on the
>    next person reading the code is quite different.
>
> To R5RS Schemers, yes!  To folks who have been thoroughly ingrained in
> Mzscheme's l->r order, maybe not.  Right now, there may not be any
> such folks.

There will never be any such folks, unless they are capable of divining
intent from information that's not present in the source code.

> I was asking Anton if life might be better if C, C++ & Scheme had from
> the beginning mandated l->r eval order.  Because then we flat out
> wouldn't have the category of order of eval bugs!!!

The latter sentence is simply wrong, and that's the whole point.

Languages with fixed evaluation order suffer from order of evaluation bugs
- these days, I see them in Java, and Joe mentioned seeing them in Common
Lisp.

Fixing an order means that expressions that depend on that order will
work, without having to explicitly specify that they depend on an order. 
But the class of bugs we're talking about are not "expressions which
depend on eval order", but rather "expressions which contain unintended
side effect interactions".

A subset of these expressions are those which depend on some eval order to
work (whether intentional or not); another subset may simply be buggy all
the time, due to an effect interaction which shouldn't exist.  Fixing eval
order only eliminates a subset of these bugs, the subset of expressions
which depend on the chosen fixed eval order (intentionally or otherwise). 
But pervasively fixing the order makes it harder to detect the other kinds
of bug, because now there's no way to tell from the code when side effect
interactions are intended, and when they're not.

> Anyway, Joe, what about my question: What does HtDP say about mutation
> & order of eval issues?  Is there something deficient about HtDP's
> approach?  Doesn't handle enough real-world mutation complexities?

HtDP doesn't introduce mutation until chapter VII, the second-last
chapter.  It starts out showing how to use BEGIN to sequence side effects.
 In the very last section of that chapter, in subsection 38.3, "The
Meaning of Advanced Scheme", it points out that expressions with side
effects need to be evaluated in a particular order: "To avoid such
problems, we use the fixed ordering but give ourselves more freedom when
no state variables are involved."  It's talking about the HtDP rules for
evaluating programs here, not about style in writing real programs.  So,
afaict, it doesn't address the issue we've been discussing.

Anton