This page is part of the web mail archives of SRFI 13 from before July 7th, 2015. The new archives for SRFI 13 contain all messages, not just those from before July 7th, 2015.
Argh! Thank you for catching this, Will. I will remove the broad license to return multiple values. This is very annoying. R5RS is wrong. Command continuations should be indifferent to the number of values passed to them. -Olin Date: Mon, 18 Dec 2000 17:58:55 -0500 From: Will Clinger - Sun Microsystems <william.clinger@xxxxxxxxxxxx> SRFI-13 says that If a procedure is said to return "unspecified," this means that nothing at all is said about what the procedure returns, not even the number of return values. Such a procedure is not even required to be consistent from call to call in the nature or number of its return values. It is specifically permitted for such a procedure to return zero values, e.g., by calling (values). SRFI-14 has a similar problem, in the documentation for CHAR-SET-FOR-EACH. I assume that these specifications were written in the belief that (lambda () (values) #t) is legal R5RS Scheme, but it is not. The R5RS description of the VALUES procedure says that Except for continuations created by the call-with-values procedure, all continuations take exactly one value. Nothing in the R5RS requires continuations that were not created explicitly by CALL-WITH-VALUES to accept zero values. Hence (lambda () (char-set-for-each proc cs) #t) would not be portable; implementations are allowed to report an error when zero values are returned to a command continuation. I am sorry that the R5RS does not allow zero values to be returned to a command continuation. I am also sorry that the R5RS is not more explicit about the fact that doing so is, in effect, an error. I did not agree with the editorial decision not to describe this as an error. I recommend that SRFI-13 and SRFI-14 be revised to require these procedures to return a single unspecified value. Otherwise SRFI-13 and SRFI-14 should be revised to point out that portable code must call these possibly-zero-value-returning procedures only with a continuation created by CALL-WITH-VALUES. Will