[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Returning zero values is problematic
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.
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
SRFI-14 has a similar problem, in the documentation for
I assume that these specifications were written in the belief
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
(char-set-for-each proc cs)
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
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.