[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; and then force it's
> "failure" upon detection of any interdependencies

I see now that you were responding to Bradd's preference for seeing
erroneous programs fail rather than succeed accidentally (that message was
top-posted, which was why the connection wasn't completely clear to me.)  I
agree that to reliably enforce such failure requires rigorous testing -
again, very similar to the sort of testing that's necessary to detect type
errors in Scheme programs.  In both cases, we have an erroneous condition
cannot necessarily be easily detected in all cases, whether statically or
dynamically.

However, this still has no bearing that I can see on whether an
implementation has "the liberty to conduct as complete as analysis as
desired to enable the parallelization..."  If anything, it simplifies what
an implementation needs to do, since an implementation (at least the
compiler part) should not be required to verify the lack of sequence
dependencies within constructs defined to have no such dependencies.
Checking programs for correctness properties that don't affect compilation
is not necessarily the job of the compiler or even the entire
implementation.  If it was, PLT would be incomplete without MrFlow, for
example.

> (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

It is only erroneous code which is non-portable.  If the code is not
erroneous, it implies that any ambiguity is intentional.  In that case, it
is still just as portable as code which is unambiguous.

Per R5RS, the results of ambiguous code could vary within a single
implementation: "The order of evaluation may be chosen differently for each
procedure call" (4.1.3).  This note indicates to me that the R5RS authors
were thinking specifically of freedoms for the compiler implementor.

> with no tangible benefit to either the programmer, or the language
> implementer;

There are tangible benefits to the programmer, but apparently you don't
accept that these benefits have any worth.  There is potentially substantial
tangible benefit to the compiler implementor, in that many blocks of code do
not have to be analyzed for sequence dependencies, and order of evaluation
is not arbitrarily and unneccesarily constrained.

> if it's not obvious, I'm sorry, but have exhausted my thoughts
> on the subject, best regards.)

Happily, your original question has now been answered quite thoroughly:
"what possible value can be derived from continuing to enable
implementations to ambiguously evaluate..."  I get the impression you didn't
like the answer.  ;)

Anton