[plt-scheme] to define, or to let

> The corollary would then be, in order to detect programmer errors
> enabled by an inherently error prone ambiguously evaluated function,
> let, let*, and let-rec constructs, to require that their parameters
> to be exhaustively evaluated for interdependencies which would
> otherwise result in ambiguous results when evaluated in different
> implementations; as opposed to giving the implementation the liberty
> to conduct as complete as analysis as desired to enable the
> parallelization of otherwise safe and simple sequential evaluation
> semantics.
>
> (The latter seems more practical to me, doesn't it to you?)

I don't see the connection between the two points.  The first point assumes
that a requirement is being imposed to automatically detect such errors
statically, or at least prior to normal execution.  That's an arbitrary
requirement, however, and there's certainly no need for the compiler to be
involved in this.

Re compiler analysis, compilers are in no way constrained by function or
LET-style constructs with unspecified evaluation order.  By definition, they
are free to compile those constructs in any order they see fit, without any
analysis whatsoever.  Nor are they unnecessarily constrained by sequencing
constructs, since where they can prove that sequence does not in fact
matter, they are as free to rearrange the sequence as they would be in any
other situation.

Looking at things from a compiler-centric perspective, I would be satisfied
if the compiler and development environment collaborated to visibly mark all
detected sequence dependencies in my code.  But given that, I would probably
still want a way for programmers to mark areas where they believe their
knowledge exceeds that of the compiler.  These beliefs can then be tested
via specific test suites, or general-purpose testing tools.

Anton