[Larceny-users] writing values writes the first value only

[Felix Klock]

Will (cc'ing Marco and larceny-users)-

On Jun 3, 2009, at 11:06 PM, will at ccs.neu.edu wrote:

> Marco Maggi wrote:
>>  using Larceny checkout 6282 on i686-pc-linux-gnu I see:
>>
>> (write (values 123 456))
>> => 123
>
> That is correct behavior for Larceny, whose semantics for
> multiple values is mostly compatible with Common Lisp, which
> provided the original model for Scheme's multiple values.
>
>> while Ikarus raises an  "incorrect number of values returned
>> to single value context" error, and Ypsilon prints "#<values
>> 123 456>".   Larceny's behaviour is confusing  when WRITE is
>> used for debugging purposes.  Can something be done?
>
> Ikarus and some other systems are incompatible with both
> Ypsilon and Larceny in this respect.  Similarly, Ypsilon's
> behavior is incompatible with both Ikarus and with Larceny.
> All of those behaviors are permitted by both the R5RS and by
> the R6RS.  The bottom line is that passing zero values or more
> than one value to an ordinary continuation (which expects one
> value) has undefined semantics.  (As of the R6RS, command
> continuations are no longer ordinary continuations, but R5RS
> command continuations are ordinary, so there is a definite
> incompatibility between the R5RS and R6RS here also.)

So I was just musing... if we throw portability across different  
schemes out the window, but still wish to retain backwards  
compatibility with past variants of Larceny... how hard do you think  
it would be to make procedure-arity "work" on first class  
continuations in Larceny?

Right now:

   > (call-with-values (lambda () (call-with-current-continuation
                                    (lambda (k) (values (procedure- 
arity k) 'ignored))))
       (lambda (x y) (list x y)))
   (0.0 ignored)

But I do not see an immediate reason why the continuation could not  
sometimes stash away the number of values it expects (particularly for  
the case when that information is directly derivable from the  
procedure-arity of the second argument to call-with-values).

If procedure-arity (or really, call-with-current-continuation, right?)  
were thus enhanced, one could then write a (slower, variant)  
replacement for the values procedure that attempts to check for when  
the wrong number of values are passed in.

Thoughts?

-Felix