[plt-scheme] to define, or to let

Paul Schlie wrote:
>> 2. [In a language which provides both left-to-right and nonsequential
>> evaluation order, would] you simply always use the l-to-r constructs
>> in this language, even in cases where you knew order was irrelevant,
>> and avoid the other constructs?

> - yes.

Some excerpts from Steve McConnell's excellent /Code Complete/:

    Although organizing straight-line code is a relatively simple task,
    some subtleties of organization influence code quality, correctness,
    readability, and maintainability ....

    Key point: When statements have dependencies that require you to put
    them in a certain order, take steps to make the dependencies clear.

McConnell stresses the importance of making order dependencies clear,
which of course requires that you're aware of them in the first place.

    You might encounter cases in which it seems as if the order of a few
    statements or a few blocks of code doesn't matter at all. One
    statement doesn't depend on, or logically follow, another statement.
    But ordering affects readability, performance, and maintainability
    ....

This is another important point: For some code, the order of execution
isn't important, but the order of presentation is very important.
McConnell goes on to explain how to order non-sequential code so that
it's more readable, efficient, and maintainable.

The most important thing here is that understanding a program's
sequencing requirements is essential to detailed design. If you aren't
sure where order matters, the design is incomplete. If you are sure, and
the language gives you a convenient way to encode the decision you made,
then why would you want to throw that information away?

>> 3. Even if your answer to #2 is "Yes", can you see why someone might
>> want to use both?

> - No, I honestly can't see why someone would want both, as enabling a
>   programmer to assert (I believe the following expression's parameters
>   are evaluation order independent) isn't interesting ....

I couldn't disagree more strongly. It allows you to encode an important
design decision -- whether order matters -- directly in the program.

That information helps maintainers and code analyzers reorganize and
refactor code. A maintainer could refer to a separate design doc, but
it's more effort, and it's less reliable. Design docs typically don't
include design decisions at that level of detail. And a program analysis
tool normally can't use a separate design doc at all.

It also helps code reviewers, white-box testers, and automated testing
tools to determine whether the code implements the design correctly.
When a code reviewer sees a possible order dependency, he can quickly
verify whether it was intentional. Testers can specifically exercise the
code for unintended sequence dependencies.

Maybe you don't find this stuff "interesting," but I certainly do.

> - being able to identify ambiguous expressions is interesting only in
>   the context that the language allows such expressions; but not
>   otherwise.

All languages allow expressions where the order of evaluation doesn't
matter. Only a few allow you to explicitly state where it's important
and where it isn't (according to the program design).

> Ergo, define scheme's expression parameter evaluation order, all scheme
> expressions are unambiguous ....

That's incorrect. In such a language, the program's design is ambiguous.
You need to consult external documentation (if it exists) or conduct an
expensive analysis to recover the design.
-- 
Bradd W. Szonye
http://www.szonye.com/bradd