[plt-scheme] to define, or to let

Paul Schlie wrote:
> The answer was within the context of Bradd's below statement; as such,
> the only way to guarantee the "failure" of code which is ambiguous due
> to scheme's presently un-specified parameter evaluation order, would
> be to exhaustively analyze parameters for their relative
> interdependencies ....

That's just a verbose way of saying that you need thorough testing to
guarantee failures. That's hardly a new idea.

> and then force it's "failure" upon detection of any interdependencies,
> as the code by Bradd's definition would not conform to scheme's
> semantics ....

Side effects in non-sequential constructs are fine, so long as you don't
care about the order of the side effects. For example, it's normally OK
to use CONS in non-sequential subexpressions, and it's often OK to use
arbitrary side effects in a commutative, non-sequentual construct.

Because of that, side effects in non-sequential conform to Scheme's
semantics just fine. They might be incorrect with respect to the
program's requirements and design, but they're just fine from the
language standpoint. That's exactly why it's a *programming* problem,
not a language specification problem.

> which require that only non-interdependent parameters be passed to
> functions, let, etc., as otherwise their evaluation yields ambiguous
> results.

The evaluation is only "ambiguous" if the program is incorrect, and as
Anton said, that's not a big deal. It does make it harder to test and
flush out bugs, which is unfortunate, but it's not a show-stopper.

> (candidly, I'm not sure why this topic is controversial, as it should
> be obvious that scheme's present semantics in this regard only enables
> the specification of ambiguous (non-portable) code, with no tangible
> benefit to either the programmer, or the language implementer ....

Both of your claims here are simply incorrect. Non-sequential constructs
only make *incorrect* code ambiguous, and the ability to encode them has
at least two tangible benefits: It communicates the program's detailed
design to other programmers, and it permits the compiler greater
latitude for optimization.

Note that a compiler *cannot* reorganize code with side effects if you
specify left-to-right evaluation. It cannot even reorganize CONSes,
because the compiler cannot determine whether it's safe to move
allocations. For example, a memory-intensive algorithm might exhaust all
available memory unless you perform operations in a specific order. The
inability to move allocations is a major limitation for a list-oriented
language like Scheme.
-- 
Bradd W. Szonye
http://www.szonye.com/bradd