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

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

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

- if there is a community interest in enabling scheme to specify
  immutable functions (i.e. functions which are warranted not to be
  dependant on locally persistent, or externally mutable state) for the
  nicety of it, for which violations must be detected, then it should be
  addressed directly, not by attempting to argue for unspecified
  evaluation order 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).

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

  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.

-paul-