[plt-scheme] Re: to define, or to let (last try)

Paul Schlie wrote:
> commutative monads are the loose idiosyncratic exceptions ....

They're *common* exceptions.

> ... unlike most typical monadic function specifications which have
> well defined sequential behaviors, such as I/O, stream, counting, etc.
> functions do ....

I wouldn't call that "typical" if it ignores a common exception.

> ... as such their order of evaluation should not be ambiguous by it's
> host language ....

A program that correctly uses those constructs in a commutative way is
not ambiguous. Programs that don't use them commutatively are almost
always incorrect. This is a fundamental point, and you keep missing it.

>> Currently Scheme's unspecified evaluation order indeed gives us a way
>> to notationallly distinguish computations whose side effects are
>> commutative in exactly this sense.  Examples as suggested by SPJ
>> above are
>> 
>>  (+ (random) (random))
>> 
>>  (list (gensym) (gensym) (gensym))
>> 
>> etc.  

> Unfortunately or not, it does no such thing; it merely specifies that
> the order of evaluation of function's arguments are unspecified, not
> that it's a semantic un-diagnosed error for function arguments to have
> mutable state [dependencies].

The latter implies the former. Indeed, some language standards even make
it explicit. For example, C89 section 4 states, "A strictly conforming
program ... shall not produce output dependent on any unspecified,
undefined, or implementation-defined behavior, and shall not exceed any
minimum implementation limit."

Note that everything on that list is already an error in Scheme, except
for dependence upon unspecified behavior.

> (which basically inhibits such argument use, inhibiting otherwise
> perfectly syntactically correct and potentially useful programs, which
> would also be semantically unambiguous if evaluation order were
> defined, thereby enabling the safe generalized use of monadic and
> similar functions arguments, which I've seen no rational argument to
> prohibit.)

Huh? It's perfectly fine to mix mutable state and unspecified evaluation
order, so long as you design the program such that it doesn't depend
upon the order. Indeed, that's exactly what happens in commutative and
similar operations.

> In a nutshell if evaluation order were defined, all presently
> unambiguous programs would remain unambiguous, and equivalent to their
> ordered evaluation counterparts; and all presently ambiguous programs
> would become unambiguous; net win-win, loosing nothing with any
> demonstrable value ....

Those "presently ambiguous programs" are almost always incorrect with
respect to their designs. What's the value in making an incorrect
program unambiguous?

> unless some one somehow perceives that being able to specify a
> presently ambiguous program has value, which no one has been able to
> demonstrate)

We obviously haven't been able to demonstrate its value to you, but
please stop claiming that we haven't demonstrated it at all.

> What value is derivable from being able to "assert" I believe that the
> arguments to let or functions are evaluation order insensitive?

You can test the assertion with automatic testing tools, for one thing.

> (answer: none, as if they are, its equivalent to their sequential
> evaluation, otherwise un-diagnosably ambiguous ....)

At run time, they may be equivalent, but they're not equivalent to
reviewers, maintainers, optimizers, and other entities that read
programs. You're making the mistake of thinking that the interpreter's
view of a program is the only way of looking at it.
-- 
Bradd W. Szonye
http://www.szonye.com/bradd