[plt-scheme] to define, or to let

However one represents an example of a program's failure to behave as
desired within the true breadth of it's range and domain; the other
is an example of scheme's failure to specify it's semantics sufficiently
to warrant a program's equivalent behavior differing, yet "compliant",
environments.

(the later can be easily remedied; solve the former, and you'll be wealthy.)

-paul-

> From: "Anton van Straaten" <anton at appsolutions.com>
> Date: Sun, 21 Mar 2004 19:58:27 -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
> 
> Bradd W. Szonye wrote:
>> 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.
> 
> Right.  For example, you could make the exact same argument for static
> typechecking:
> 
> "Regardless of the 'belief' that a programmer may have with respect to the
> types of expressions, they may none the less actually have potentially
> subtly different types which may not clearly express themselves until
> executed with a particular set of inputs ... which will result in an
> otherwise needless unanticipated failure."
> 
> PLT Scheme experiences such a "needless" unanticipated failure every time it
> produces a runtime type error.  Languages and programs that are not
> statically typed have various disturbing semantic properties of their own,
> but some of us like to put up with those, because we care more about the
> other side of the tradeoff, to the point where we're willing to take a risk
> that we know can be entirely eliminated, at a cost.
> 
> We're just arguing about its cost vs. its worth, and that's entirely
> subjective and probably even domain-dependent.
> 
> Anton
>