[R6RS] summary of decisions regarding multiple values

[dyb at cs.indiana.edu]

> If the editors are going to require non-checking for some
> continuations, while requiring checking for others, then
> the editors have an obligation to specify precisely which
> continuations are required to check, and which are required
> not to check.

Agreed.

> Furthermore the editors will have an obligation to explain
> why they want to require sloppiness in some contexts but
> forbid that same sloppiness in others.

Good question.  Here's my answer.  If we're going to require that a begin
continuation ignore a single, arbitrary value, it makes sense that it
ignore all of the values.  In other words, using begin is essentially a
declaration that the values don't matter and should be ignored.  For a
continuation that doesn't ignore at least one of its values, it makes
sense to require that it be passed the right number of values.

Requiring a begin continuation to accept zero values and set!, write,
etc., to return zero values might seem more consistent, but that would
break a lot of r5rs code.  Requiring a begin continuation to accept only a
specific single value, the "unspecified" value, might also seem more
consistent, but that would still break some r5rs code.

> Kent's interpretation would *require* every implementation
> to distinguish three different kinds of continuations, two
> of which are extremely common.  In many systems---probably
> most---it would add overhead to every non-tail call.  It
> would be an extremely silly thing to do for no reason at
> all, which is all the reason I've heard so far.

One reason is to detect a common programming error.  Another is to help
ensure that programs intended to be portable don't count on
implementation-specific behavior, like ignoring all but the first value
passed to a single-value continuation or manufacturing some arbitrary
single value when no values are passed to a single-value continuation.

The overhead isn't significant in Chez Scheme, so I'm not convinced by the
overhead argument, any more than I'm convinced by overhead arguments in
other situations where we've required exceptions to be raised.  I have to
admit, however, that Chez Scheme converts (let ((x e)) x) to e, which it
would have to avoid doing in some contexts, at least in safe mode.  Fixing
this would add more overhead and/or complexity, but I'm not sure if either
the additional overhead or complexity would be significant.

Incidentally, I don't think we're requiring implementations to raise an
exception when a procedure receives an incorrect number of arguments.
We should discuss that as well.

Kent