[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?)

-paul-

> From: "Bradd W. Szonye" <bradd+plt at szonye.com>
> Date: Sun, 21 Mar 2004 16:20:51 -0800
> 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
> 
> Paul Schlie wrote:
>> Felix, Thanks for the clarification, however regardless of the
>> "belief" that a programmer may have with respect to the relative
>> independence of a collection of expressions, they may none the less
>> actually have potentially subtle interdependencies which may not
>> clearly express themselves until executed within an environment which
>> chooses to evaluate them in a different order ....
> 
> That's hardly unique to this feature. The root cause of the problem here
> is that the program's code does not match its design. No matter how you
> spin it, it's still a programming error.
> 
>> ... which will result in an otherwise needless unanticipated failure.
> 
> 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.
> -- 
> Bradd W. Szonye
> http://www.szonye.com/bradd