[R6RS] summary of decisions regarding multiple values

[William D Clinger]

Kent wrote:
> > > Not exactly.  The traditional CPS form of (lambda () (f (g))) is
> > > (lambda (k) (g (lambda (v) (f v k)))).
> >
> > The proper translation of that CPS-transform into
> > Scheme is (lambda (k) (g (lambda v (apply f k v)))).
>
> Under your proposal, this won't toss the extra values returned by g, will
> it?  Won't f complain about receiving the wrong number of arguments?

Had you stated the traditional CPS transform correctly,
the transformed version would have used the transformed
f and g instead of the original.  (Notice, for example,
that g takes zero arguments in the original but one in
the transform.  That's because they're really two
different functions.)  The transforms of f and g would
include an analogue of your wrapper that discards extra
arguments and uses #!unspecified if there are none.

(Since the unspecified value is not a datum, I can write
it however I want [1].)

To be fair, the wrapper could be made to check for
exactly one argument, and do something really weird
if that is not the case.

The problem Twobit would have with Kent's preferred
semantics is that Kent's semantics breaks the usual
equivalences between begin expressions and CPS or
A-normal forms.  Wrapping wrappers around the right
hand sides of an A-normal form's let bindings gives
you a result that is no longer in A-normal form, and
converting that result into A-normal form a second
time would unwrap all the calls you were trying to
wrap.  The bottom line is that begin expressions
would have to handled as a core form, or every
expression of a begin except its last would have to
be wrapped by a call to call-with-values, or something
else just as unpleasant.

Adding begin expressions to Twobit's A-normal form would
add considerable complexity to every optimization that
uses A-normal form, and some of them are pretty hairy
already, so I'm not going to do that.

Wrapping a call to call-with-values around every expression
that appears in a command context is a practical solution
for most compiler writers, but would encourage routine use
of unsafe mode, which would in turn lead to more widespread
use of the semantics several of us prefer anyway.

Will

[1] R6RS status report, section 4.4.  21 June 2006.