[plt-scheme] Please help test version 359.100

Hi,
My humble opinion:

A distinction must be made between the freedom and restrictions R5RS gives to cq imposes upon implementors (of a scheme interpreter/compiler) and the freedom and restrictions for programmers (i.e. the users of an implementation). For programmers, the report specifies the maximimum programmers may rely on and the minimum implementors must provide. That is to say, responsibilities are imposed both upon implementors and upon programmers. R5RS clearly states that call-by-values is the one and only context in which the implementor MUST provide a continuation accepting a multiple value. Hence this is the only context in which programmers MAY expect EVERY implementation to do the right thing. Implementors are free to provide more contexts in which multiple values are accepted. Programmers MUST NOT expect that every implementation accepts multiple values in any other context.

In PLT scheme much more contexts are provided in which multiple values can be handled. (and am I glad that PLT does) This is not against R5RS, because the report only claims to be a minimal requirement imposed on implementors.

To be more practical: (set! global-variable 3) --> unspecified.
It is obvious that R5RS intentions are that the side effect is accomplished. At least this expression should give no problems at top level. For example 'unspecified' cannot mean that an implementor may choose never to return. But R5RS does not specify what an implementor should do in case the expr (set! global-variable 3) occurs in a context whose continuation expects a value (or multiple value). Therefore we must distinguish expressions that are evaluated for side effects only and those that are expected to transmit a value or multiple value to a continuation.

Therefore:
1: at top level the production of an unspecified value must not cause problems.
2: In a body (of a lambda, let or letrec expression or something similar) an expr producing an unspecified value must not cause problems if it is not the last expression of the body.
3: If an expression is the last one of a body, things depend on the continuation of the form the body is part of.

Conclusion
1: An implementor is free to do what she wishes (even hang up the program) if an unspecified value is produced in a context with a continuation that expects a value (or multiple value),
2: where the continuation of a body expression that is not the last one in its body must accept unspecified values and ignore them.
3: and the top level must accept unspecified values too.

To go into extremes, I think that an implementor is free to produce never returning code for the expr (let ((a (set! global-var 3))))

Or to put it in other words: a programmer producing an unspecified value should not be punished immediately, but the implementor is free to do what she wishes in case a programmer tries to use an unspecified value for further computations.

As for for-each: an implementor can return whatever she wishes, but a programmer should not place a for-each call in a context that is going to use the result (unless the programmer specifically wants her programs to run with one specific implementation only)

Therefore I think an implementor may return a multiple value as the result of a for-each call, provided this gives no problems at top level or in a body whre the expr is not the last one of the body.

Best wishes, Jos Koot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20061114/d1c8565c/attachment.html>