Re: Returning zero values is problematic

[shivers@xxxxxxxxxxxxx]

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