Returning zero values is problematic

[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