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

Paul Schlie <schlie at comcast.net> writes:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> In turn, let me try for the final time to dispel some rumors:
>
> - all programs which abide by scheme's syntax are "correct", regardless
>   of their usefulness (and/or ambiguity under R5RS specifications).

Not true.  (car 42) is generally considered incorrect.  Some scheme
systems consider 
(call-with-current-continuation (lambda (c) (0 (c 1)))) 
to be incorrect. 

> - the present order-of-evaluation ambiguity as presently specified by
>   R5RS doesn't "assert" anything, it simply enables the specification
>   of "correct" programs which have ambiguous behaviors if any of its
>   arguments which are subject to unspecified evaluation order share
>   mutable state (such as basic as I/O functions do).

Partially true.  The unspecified order of evaluation does not `assert'
anything about a program (it does assert that no implementation is
in violation by specifying a particular order of evaluation).

One may, of course, write programs whose behavior depends on the order
of evaluation.  One may do this whether the order is specified or
not.

> - if there is a community interest in enabling scheme to specify
>   immutable functions ... then it should be addressed directly,
>   not by attempting to argue for unspecified evaluation order...

I don't argue this as a rationale.

>   which only ironically enables such function use to be
>   potentially ambiguous, but not deterministically so from implementation
>   to implementation, to no-ones benefit; nor as easily diagnosed as an
>   immutable function definition/assertion would be (which although would
>   be nice, it's not as truly as necessary as eliminating R5RS's presently
>   unspecified evaluation order ambiguity is, as mutable functions are both
>   useful and occasionally necessary, and corresponding their use should not
>   yield ambiguous results under any circumstances).

I don't understand why you call `eliminating the unspecified
evaluation order' as `necessary'. 

> - 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. 

And I'm still waiting for someone to produce an explicit code fragment
which demonstrates clear benefit to specifying an evaluation order.
And one that demonstrates a clear benefit to *one particular*
evaluation order over all others.

>   If none can be produced, then maybe it's perceived merits should
>   be reconsidered. 

Your ball.


>   For the record:
>
>    (define (first x y) x)
>
>    (first (read) (read))
>
>    is both a "correct" and needlessly ambiguous program under R5RS's
>    present specification, and not easily diagnosable as being otherwise.

It is also needlessly unambiguous under left->right evaluation as any
of these programs more clearly demonstrate:

(begin0 (read)
  (read))

(let* ((answer (read))
       (discard (read)))
   answer)