[plt-scheme] to define, or to let

Anton van Straaten wrote:
>> If there is under-specification present here, surely it is actually
>> in the language which disallows the specification of order
>> independence, despite such order independence being a manifest
>> property of large parts of real world systems?

Matthias Felleisen wrote:
> I agree with this part of your message. R5RS's (non)specification of
> function application is similar to its "overloading" of lambda. As you
> perfectly well know, in R5RS lambda abstracts *and* allocates a
> mutable piece of storage. If you think about it for just one moment,
> you see that this non-orthogonality at an extreme. (Still, I won't
> argue its occasional practicality.)

You're referring to the combination of functional abstraction, lexical
closure, and extension of the environment to include actual arguments,
yes? If so, I'd argue that it's more than occasionally practical; it's
a very common case for lispy programming styles. That makes it a good
candidate for inclusion in the language.

> Now think about function application in the same way. It combines
> apply proper with *sequential* non-determinism. Why? I have thought
> about this for a long time, and I can't find a reason for the
> combination of non-determinism and sequentiality.

And here you're referring to the fact that the unspecified order
corresponds to some sequential order, yes? That's not an impurity in the
model; it's just an alternative way of saying that each subexpression is
atomic, so that you don't need to worry about reentrancy and similar
issues. There are at least three options for evaluating a set of
subexpressions:

1. In a specific, sequential order.
2. In any non-reentrant, atomic order.
3. In any order, possibly even concurrently.

In my experience, #2 is what I want most of the time, and that's the
"default" in Scheme.

> Turn around and think about the following. Say we introduce a
> construct "evaluate these expressions in any order and   give me all
> the values." Call it values*. You can then use the resulting values
> for function application (apply proper) or for the construction of a
> data structure. Why just use them for apply?

You could do it that way, but it would be very inconvenient to write
programs in that style if most of your function applications require
atomic but non-sequential argument evaluation.
-- 
Bradd W. Szonye
http://www.szonye.com/bradd