Re: [Scheme-reports] Technical question

[Ray Dillinger <bear@x>]

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@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports