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

(sorry, corrected 3rd section which previously confused im/mutable)

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 explicitly
  identify mutable functions (i.e. functions which may be dependant on
  locally persistent, or externally mutable state) for which violations
  otherwise implied by default immutable functions must be detected, then
  it should be addressed directly, but 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 violations would be (which although
  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-