[plt-scheme] to define, or to let

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