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

   Bradd W. Szonye <bradd+plt at szonye.com> replies to me:

   Language specs generally aren't supposed to be algorithms. 

I think it's a fabulous idea for a language spec to be an algorithm,
even if Mzscheme is the first such language.  It's MF's fixation: to
reason about programs, including interpreters.  If the interpreter
isn't an algorithm, it's hard to reason about it.

   language implementations that encourage [...] ignoring the "where
   sequencing matters" issue are irresponsible on some level, IMO.

But nobody's in favor of such ignorance!   The question is whether it
could be good programming to take advantage of the Mzscheme features.
So, is it always bad design to write code like
(foo goo)
or
(let ([x foo] [y goo] ... ))
where side-effects of foo affect goo?  Before Mzscheme, it was a bug,
so we think it's bad design, but maybe it's not always.

   > But suppose that C/C++ from the beginning had mandated a
   > non-ambiguous eval order (say l->r).  Then these order of eval
   > bugs aren't bugs necessarily ....

   Sure they are. 

Precision, please.  You don't mean this, as you say:

   In the engineering contexts I'm used to, an implementation that
   doesn't match the design or that's fragile is almost as buggy as
   one that's more obviously incorrect. 

So why is this formerly-buggy coding now always fragile?

   And if your design doesn't consider things like "where sequencing
   matters," then your design is incomplete at best.

Sure, but could we use these new left->right-enabled side-effect
features as part of our design?

Is there Mzscheme code in DrScheme using these side-effect features?