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

commutative monads are the loose idiosyncratic exceptions, loose as
although they have sequential evaluation dependencies, the result of
their sequential evaluation are not specified; unlike most typical
monadic function specifications which have well defined sequential
behaviors, such as I/O, stream, counting, etc. functions do; as such
their order of evaluation should not be ambiguous by it's host language;
as by specification, the ordering of the information returned-by (or fed
into) them is as significant as the individual datum themselves.

> 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
independencies. (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.)

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,
unless some one somehow perceives that being able to specify a presently
ambiguous program has value, which no one has been able to demonstrate)

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

(answer: none, as if they are, its equivalent to their sequential
evaluation, otherwise un-diagnosably ambiguous, thereby only needlessly
preventing the programmer from being able to utilize arbitrary monadic
(or similar) functions as arguments to functions, let, etc. resulting
in their unnecessary restricted reliable use)

> From: Andre van Tonder <andre at het.brown.edu>
> Date: Tue, 27 Apr 2004 13:45:44 -0400 (EDT)
> To: Paul Schlie <schlie at comcast.net>
> Cc: plt-scheme <plt-scheme at po.cs.brown.edu>
> Subject: Re: [plt-scheme] Re: to define, or to let (last try)
> 
> On Tue, 27 Apr 2004, Paul Schlie wrote:
> 
>> - still waiting to see someone produce a explicit code fragment which
>>   demonstrates the value of unspecified evaluation order, as many counter
>>   examples have already been produced. If none can be produced, then maybe
>>   it's perceived merits should be reconsidered.
> 
> In this regard, let me quote Simon Peyton Jones "Wearing the Hair Shirt -
> A restrospective on Haskell".  I see it as somewhat relevant to the
> discussion:
> 
> SPJ:
> 
>> Which would you prefer?
>>   do a <-f x           OR       h (f x) (g y)
>>      b <-g y 
>>      h a b      
>> 
>> In a commutative monad, it does not matter whether we do (f x) first or
>> (g y).
>> Commutative monads are very common. (Environment, unique supply, random
>> number generation.)
>> For these, monads over-sequentialise. Wanted: theory
>> and notation for some cool compromise.
> 
> 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.  
> 
>      
> 
> 
> 
>