[R6RS] summary of decisions regarding multiple values

[William D Clinger]

Mike wrote:
> Now, looking at the ANF paper, I would think that I could just modify
> CPS(CS) to have
>
> P ::=3D ... | (W (\lambda x_1 ... x_n.P) W_1 ... W_n)
>     | ... | (O (\lambda x_1 ... x_n.P) W_1 ... W_n)
>
> ... carry that change over to the C_cpsE machine (extending the
> closure machine values, go from there to C_cpsEK machine (extending
> the continuation values there), and then applying an inverse
> transformation into an ANF with a multiple-value LET.  Does this fall
> down anywhere?

Your ANF would then have a multiple-value LET at its core.
You would have to take that multiple-value LET as primitive
syntax in your ANF, because macro-expanding it into Scheme
would give you something that no longer resembles ANF.

In one of my previous messages, I acknowledged that Kent's
preferred semantics can be accomodated by adding new
syntactic primitives to your ANF.  If that new construct
is multiple-value LET, then it can replace the traditional
single-value LET/LET*, but the traditional LET/LET* is
just syntactic sugar for lambda expressions and procedure
calls, not a real primitive.

The drawback of your ANF is that it no longer explains
everything in terms of lambda expressions and procedure
calls.

Kent wrote:
> If the transform of f and g were to discard extra arguments and use
> #!unspecified if there are none, then they wouldn't signal an error when
> given too many or two few arguments, which they are required to do
> in your proposal.

I apologize for getting that wrong.  The point is that
Scheme's variable-arity procedures require arguments
to be passed as sequences, not single arguments, and
Scheme's multiple return values require the return
values to be written as sequences also.  If you want
to express the number-of-argument checking, I think the
proper translation into Scheme would be something like

    (lambda (k v)
      (if (null? v)
          (g (lambda v (f k (list (first v)))) '())
          (error "wrong number of arguments")))

One question then is what first means, and reasonable
people can differ about that.  Whatever it means,
though, it has to mean the same thing wherever it
is written.  That implies that, if you want begin
continuations to behave differently from argument
continuations, you cannot allow begin expressions
to macro-expand into lambda expressions and calls.

According to R5RS section 7.3, a begin expression
(but not a begin definition) is allowed to expand
according to the traditional equivalence for which
I have been arguing.

As a point of order, I note that the editors have
never voted to revoke that part of R5RS section 7.3.
Unless and until the editors vote to remove that
permitted macro expansion from the R6RS, our earlier
decision that begin continuations accept any number
of arguments will continue to imply that argument
continuations do also.

If someone wants to propose that the second macro
definition for begin expressions be removed in the
R6RS, I suggest they do that before our conference
call on Tuesday.

Will