[plt-scheme] to define, or to let

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; which will result in an otherwise needless unanticipated failure.

No mater how I look at it (and have honestly tried to identify any redeeming
virtue of the present scheme [pun intended] may have), I still arrive at the
conclusion that expression evaluation order should be clearly defined.

Where then personally (although likely minimally controversial, if not
possibly simply a bad idea for a number of reasons), I'd simplify scheme to
supporting only a sequentially evaluated non-recursively defined let, and a
sequentially evaluated recursively defined let* (effectively retiring the
historical let* let-rec constructs); but not willing to argue for it.

-paul-

> From: Felix Klock's PLT scheme proxy <pltscheme at pnkfx.org>
> Date: Sun, 21 Mar 2004 18:20:11 -0500
> To: Paul Schlie <schlie at comcast.net>
> Cc: "Bradd W. Szonye" <bradd+plt at szonye.com>, <plt-scheme at list.cs.brown.edu>
> Subject: Re: [plt-scheme] to define, or to let
> 
> Paul-
> 
> On Mar 21, 2004, at 5:55 PM, Paul Schlie wrote:
>> Understood, however unambiguous evaluation semantics don't preclude an
>> implementation's ability to parallelize the evaluation of code which
>> has
>> been formally determined not to have interdependencies.
>> 
>> Relying on the code's author to give an implementation the liberty to
>> evaluate code in any order deemed to be convenient regardless of
>> potential
>> ambiguities which may result, seems more like an license to produce a
>> shoddy
>> implementation without the necessity of analysis that would otherwise
>> be
>> required to guarantee unambiguous results, which every programming
>> language
>> should be specified to require, otherwise it's broad usefulness is
>> likely
>> questionable.
>> 
>> ...
> 
> I don't think that Bradd was referring to giving the implementation
> more freedom, even if that was the original motivation for leaving so
> much unspecified in RnRS.
> 
> His essay, to me, seemed to promote the idea of the code directly
> stating that there do not exist sequencing dependencies in the
> expressions, e.g. by the programmer choosing to use LET instead of
> LET*.  This way, other people reading the code can think, "okay, when
> Bob wrote this, he believed that all of the expressions can be
> understood independently of each other."
> 
> In practice, this may be the wrong choice to make when choosing
> language constructs.  But it is distinct, in my mind, from
> implementation concerns.
> 
> -Felix
> 
> ----
> "I don't get it; that chimp was alive when I
> put it in her bedroom closet"  -www.redmeat.com
>