From: Jed Davis
Date: Fri, 15 Jun 2007 14:21:23 -0400
Subject: [Formal] multiple values and tail contexts

      Name: Jed Davis
Issue Type: Defect
  Priority: Minor
 Component: Base Library
   Version: R5.94RS
   Summary: The interaction of multiple values and tail contexts is
            both inconsistent and counterintuitive.

The standard should specify that the continuation of an expression
evaluated in tail context (section 9.21) is equivalent -- for the
purpose of determining how many arguments it may take (section 9.16,
under the procedure "values") -- to that in which the enclosing
expression is evaluated.

1. Otherwise, the standard admits strange and unexpected behavior by the
implementation, because:

The definition of "values" claims to specify exactly those
continuations which may accept other than one argument, and -- for
example -- those in which the <consequent> and <alternate> of an "if"
form (section 9.5.3) are evaluated are not among them; thus, those
continuations must accept exactly one value, and the effect of doing
otherwise is "undefined".

The standard also does not indicate what it means for an "effect" to be
"undefined", as far as I can see; that may also need fixing.

So, from the above, it seems perfectly valid for an implementation
of "if" to destructively mark its continuation as single-value-only
before evaluating the chosen subexpression, and for the system to take
arbitrarily brutal action should such a continuation then receive
some other number of values.

I conjecture that allowing this was not intended by the editors; the
intuitive understanding of tail contexts (as I understand them) is
of extensional equivalence (for all practical purposes) between the
continuations in question, and this permits breaking that.

2. Further, the standard is not entirely self-consistent, because:

The definition of "if" says, of the <consequent> and <alternate>, "its
values are returned", which implicitly suggests that multiple values are
to be permitted.  Similar text exists for "and", "or", "begin" and the
various variants of "let".

(On the other hand, neither apply nor call/cc have such coincidental
pluralization, mainly because neither actually specifies in English that
it returns the same thing(s) as the provided procedure; that is left to
the examples and the reader's imagination.)

Those cases which do bear a plural thus contradict the (presumptively
erroneous) single-value restriction above.


RESPONSE:

The editors have attempted to clarify the wording of the report to
address the issues mentioned in the comment.