On Thu, 2011-05-26 at 23:03 -0400, Anton van Straaten wrote:
> On 05/26/2011 07:06 PM, Jay Reynolds Freeman wrote:
> > I am *not* in WG1, but Aaron has asked for comments that contrast
> > with his opinion, so I shall risk speaking up ...

> The reason the semantics lead to a single interpretation here is simple:
> continuations in the semantics involve multiple values by default.  This
> is represented by all the e* terms scattered throughout the definitions.
>   Even when a single value is passed to a function, as in the expression
> (f x), at the semantic level this corresponds to (applicate f <x>),
> where <x> is a "sequence".  Sequences have zero or more values.  It is
> then up to a called procedure to test that it receives the number of
> arguments it is expecting.  This test can be found in the semantics for
> lambda terms, as e.g. #e* = #I*.

I'm pretty strongly of the opinion that procedure calls and procedure
returns are "dual" -- that is to say, although appearing different at
first impression, they are instances of the same thing.  In fact,
call-cc works *because* a procedure return can be converted directly
into a procedure call.

In my mind, this duality forms the single strongest argument for
multiple-value returns - If a procedure call can have multiple
arguments, then logically, if the two are (or ought to be)
interconvertible, then a procedure return can return multiple
results.  In R4RS/IEEE1178 Scheme, a procedure can only return a
single value, and therefore a continuation can only be called with
a single argument.  R5RS introduced multiple-value returns (and with
them multi-argument continuations) and at least some of the arguments
in favor of doing so were about the 'symmetry' between procedure calls
and procedure returns.

But we haven't achieved symmetry yet.  Functions can report an arity
error when called with the wrong number of arguments.  According to
the formal semantics they have to wait until the arguments have been
evaluated before doing so, but one of the first things that the code
for a two-argument function does is to check and make sure that it
has two arguments.  That being the case, it seems to me that by some
kind of parallel rule, a continuation expecting a certain number of
arguments ought to report an arity error when it gets a wrong number
of arguments.

And this leads to the pragmatic question, "Well, how do we determine
how many arguments a particular continuation expects, anyway?"  In
Scheme, there are procedures that expect exactly N arguments, and
procedures that expect at least N arguments (for various nonnegative
integers N).

Because we have a longstanding tradition of simply ignoring the
single result of procedures called for side effects, the logical
generalization seems to be that continuations require "N or
more" arguments, with "extra" arguments ignored.  A 4-value return
from a procedure, in a context that requires 2 arguments is like

((lambda (a b . c) (+ a b)) 1 2 3 4), and evaluates without a problem.

((lambda (a b . c) (+ a b) 1), however, should report an arity error
when the anonymous function gets control (and not before), and
therefore I believe that for consistency, continuations requiring
some positive number of arguments should report an arity error
on gaining control (and not before) when called with less than
that number of arguments.

What do I mean when I say "and not before"? I mean that the
system is not allowed to throw an error without evaluating the
return expressions based on the arity of the return context.
It may turn out that one of the return expressions is a continuation
that does a non-local exit, or has a visible side effect, and in
that case an "eager" arity error would break program semantics.

Under my language-design hat, I think that we should consider
ways to create continuations with a definite (maximum) number
of required arguments and enable too-many-returns arity
errors, fleshing out the parallelism with function calls.
Under my language-standardization hat, I note that no such
work is now tested or implemented, and that therefore
standardization of such a thing would be premature.

				Bear

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports