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

For heaven's sake, don't you guys have any useful work to do? Write a 
new collects for PLT? Build a killer-app in Scheme?

-- Matthias


On Apr 27, 2004, at 3:32 PM, Joe Marshall wrote:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> 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)
>
>
>
>