[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Returning zero values is problematic

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.



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