[plt-scheme] to define, or to let

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; 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, which
require that only non-interdependent parameters be passed to functions, let,
etc., as otherwise their evaluation yields ambiguous results.

(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; if it's not obvious,
 I'm sorry, but have exhausted my thoughts on the subject, best regards.)

-paul-

> Bradd W. Szonye wrote:
>
> The failure might be unanticipated, but I disagree that it's needless.
> Given a program where the code does not match the design or the
> programmer's intent, I would much rather see it fail than have it
> "accidentally" succeed.

-paul-

> From: "Anton van Straaten" <anton at appsolutions.com>
> Date: Sun, 21 Mar 2004 20:21:21 -0500
> To: <plt-scheme at list.cs.brown.edu>
> Subject: RE: [plt-scheme] to define, or to let
> 
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> 
>> 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
>