Returning zero values is problematic
Will Clinger - Sun Microsystems 18 Dec 2000 22:58 UTC
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