<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=utf-8"> <META content="MSHTML 6.00.2900.2963" name=GENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=#ffffff> <DIV><FONT face="Courier New" size=2>Hi,</FONT></DIV> <DIV><FONT face="Courier New" size=2>My humble opinion:</FONT></DIV> <DIV><FONT face="Courier New" size=2></FONT> </DIV> <DIV><FONT face="Courier New" size=2>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.</FONT></DIV> <DIV><FONT face="Courier New" size=2></FONT> </DIV> <DIV><FONT face="Courier New" size=2>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.</FONT></DIV> <DIV><FONT face="Courier New" size=2></FONT> </DIV> <DIV><FONT face="Courier New" size=2>To be more practical: (set! global-variable 3) --> unspecified.</FONT></DIV> <DIV><FONT face="Courier New" size=2>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.</FONT></DIV> <DIV><FONT face="Courier New" size=2></FONT> </DIV> <DIV><FONT face="Courier New" size=2>Therefore:</FONT></DIV> <DIV><FONT face="Courier New" size=2>1: at top level the production of an unspecified value must not cause problems.</FONT></DIV> <DIV><FONT face="Courier New" size=2>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.</FONT></DIV> <DIV><FONT face="Courier New" size=2>3: If an expression is the last one of a body, things depend on the continuation of the form the body is part of.</FONT></DIV> <DIV><FONT face="Courier New" size=2></FONT> </DIV> <DIV><FONT face="Courier New" size=2>Conclusion</FONT></DIV> <DIV><FONT face="Courier New" size=2>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),</FONT></DIV> <DIV><FONT face="Courier New" size=2>2: where the continuation of a body expression that is not the last one in its body must accept unspecified values and ignore them.</FONT></DIV> <DIV><FONT face="Courier New" size=2>3: and the top level must accept unspecified values too.</FONT></DIV> <DIV><FONT face="Courier New" size=2></FONT> </DIV> <DIV><FONT face="Courier New" size=2>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))))</FONT></DIV> <DIV><FONT face="Courier New" size=2></FONT> </DIV> <DIV><FONT face="Courier New" size=2>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.</FONT></DIV> <DIV><FONT face="Courier New" size=2></FONT> </DIV> <DIV><FONT face="Courier New" size=2>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)</FONT></DIV> <DIV><FONT face="Courier New" size=2></FONT> </DIV> <DIV><FONT face="Courier New" size=2>Therefore I think an implementor may return</FONT><FONT face="Courier New" size=2> 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.</FONT></DIV> <DIV><FONT face="Courier New" size=2></FONT> </DIV> <DIV><FONT face="Courier New" size=2>Best wishes, Jos Koot</FONT></DIV> <DIV><FONT face="Courier New" size=2></FONT> </DIV></BODY></HTML>