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

   > why is a fixed order of evaluation safer?

   It's safer than an unspecified order, in the presence of side
   effects.  If you have side effects in an expression with an
   unspecified order of evaluation, then the expression tends to have
   multiple possible meanings, i.e. its meaning is ambiguous.  That's
   the semantic ambiguity I mentioned.  It means you can't rely on the
   program's behavior, hence it is unsafe.

Anton, if that's true, then Scheme was an unsafe programmers before
MzScheme.  Do folks believe that?  I thought unspecified order just
meant that in an expression (f x), that side-effects given by
evaluating f and evaluating x shouldn't collide.  And you can always
specify the order if you're gonna have collisions:

(let ([first-f f])
  (let ([now-x x])
    (first-f now-x)))

or vice-versa.  But for compiler writers, like MF, the ambiguity is
serious.  How can you reason about a program (the interpreter itself)
if it's not algorithm?  And MF is I bet much more serious about
reasoning about the interpreter than most Scheme implementors.

   > Maybe it's safer to be forced to code so that order of evaluation
   > doesn't matter.

   Definitely, but if you're concerned with the semantics of full
   Scheme, you can't just close your eyes and ignore the bits you
   don't like.  R5RS Scheme supports side effects, but most of it has
   unspecified evaluation order.  That makes many of its constructs
   semantically ambiguous in the sense described above.  The only easy
   way to achieve semantic certainty (safety) in this case is to
   choose a fixed evaluation order.

I think we're in agreement, Anton.  Your semantic ambiguity is real
but bites the interpreter writers much harder than the programmers.

   However, if you're going to have a functionally-oriented language,
   and you want to use it functionally, then the ability to
   communicate which bits of your program are intended to be
   functional (in the side-effect-free sense) and which aren't, is
   useful.  That doesn't mean you can't have a fixed evaluation order,
   but it does mean you need constructs that are explicitly intended
   for code that doesn't rely on evaluation order.  Without that,
   you're forced to write code that says more than you mean to say.

That's subtle.  Should we really ask, "What's the complete meaning of
this program I just wrote?"  If so, the ambiguous R5RS DS is a
problem.  It seems better to ask, "What's does my program mean to me?"
Code-reusability is a huge problem, and indeed, MF's crew has
mathematical ideas about this as well...