[plt-scheme] to define, or to let

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.

Since the only way to guarantee that all expressions in scheme are
unambiguous, the order of evaluation of expressions which have
interdependencies must be defined; those without interdependencies may be
evaluated in any order convenient. This is equivalent to specifying the
order of evaluation of all expressions; where an implementation may take
liberties and evaluate non-interdependent expressions in any order
convenient, with the exception that for the purposes of debugging, the
observable state of the program must be made consistent with the expected
sequential evaluation semantics at all expression boundaries, as otherwise
debugging could become an interesting experience to say the least.

With respect to the below code being "correct" in the presents of it's
presently allowable ambiguous behavior is the "problem" with scheme's
present definition; as it truly only enables the specification of ambiguous
code, with no redeeming benefits which couldn't be safely achieved though
appropriate analysis as is now done in most modern compilers.

With respect to static dependency analysis; like most things in life, it's
easy to do a basic job, more difficult to do a good job, and possibly
practically impossible to do a perfect job; the good news is that the 80/20
rule likely applies, enabling most implementations which actually attempt to
take advantage of code parallelization (of which I'm not I aware of any), to
derive a majority of benefit with a reasonable effort, leaving those
expressions which can't be easily determined to be non-interdependent to be
simply evaluated sequentially.

All in all, it seems quite reasonable to me to require that scheme's
language specification not enable the specification of ambiguous code,
especially when it is possible to achieve similar benefits unambiguously.

-paul-

> From: "Bradd W. Szonye" <bradd+plt at szonye.com>
> Date: Sun, 21 Mar 2004 13:11:26 -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
> 
> Bradd wrote:
>>> ... While I am personally opposed to left-to- right LET and LETREC, I
>>> feel that implementors should have the freedom to implement them that
>>> way, as extensions.
> 
> Paul Schlie wrote:
>> Out of curiosity, what possible value can be derived from continuing
>> to enable implementations to ambiguously evaluate of code like:
>> 
>>  (let [(a (read in)) (b (read in))]
>>       (list a b))
>> 
>> or:
>> 
>>  (list (read in) (read in))
>> 
>> Personally I see none.
> 
> In any function or expression, some operations require a specific
> sequence, and some don't. For example, in (* (+ a b) (+ c d)), the
> additions must finish before the multiplication, but it doesn't matter
> which addition you perform first.
> 
> In my opinion, it's very useful to encode that information explicitly in
> the code. It helps code reviewers and maintainers to understand control
> flow in the function, which ultimately helps them evaluate and modify
> the code. One of the things I like about Scheme is that it supports this
> explicit encoding. When sequencing is important, you can use LET*,
> BEGIN, or subexpressions to express the dependency. For unsequenced
> code, you can use LET, LETREC, or function application.
> 
> According to this viewpoint, the example code above is incorrect,
> because the sequence matters, but it uses constructs that declare,
> "sequence doesn't matter here." It's a flaw in the example, not a flaw
> in the standard.
> 
> The main problem with this idea is that it's difficult to check for
> violations with static analysis tools. To put it another way, the code
> above is not ambiguous; it's incorrect in a way that's difficult to
> diagnose mechanically. Humans can spot the problem fairly easily, if
> they know what to look for, but compilers can't. That's a major
> weakness. although I still think there's value in the current spec.
> -- 
> Bradd W. Szonye
> http://www.szonye.com/bradd