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

Re: 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.


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

       (lambda ()

   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)

   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.