On 09/06/2011 01:01 PM, John Cowan wrote:
> This exercise flushed out two bugs in Kawa 1.11 (revision 6811M)::
>
> 1) Display suppresses printing #!void at all levels, not just the top
> level, so typing (list #!void) to the REPL prints (), although calling
> length on this result confirms that it contains one element.

This gets into a dilemma I haven't definitely resolved yet.
How should zero or multiple values be handled in a single-value context such
as function arguments?  I.e. what is the best behavior of:
   (list (values 3 4) 10)
I see 3 plausible options:

(A) Multiple values are real data values that can be passes as arguments
and stores in variables.  They're basically a "tuple" type, in that
(values x) is equivalent to plain x, and so they're like a non-nestable
list.
The XQuery "sequence" type behaves like this, and it is quite useful.
This is fairly easy to implement, at least in an implementation that
doesn't optimize multiple values much.

(B) Multiple values are "spliced" in the argument list, thus
(list (values 3 4) 10) is the same as (list 3 4 10).  I've long been
attracted to this functionality, but I'm now concerned that it may be both
too error-prone (too easy to write hard-to-catch bugs) as well has being
difficult to optimize,  I'm now thinking an explicit splicing operator
(possibly @ for consistency with quasi-quoting) is probably better.

(C) Multiple values in argument position (or assigned to a variable) is
an error.  This can help catch what are likely to be errors.

> 2) Procedures which are Kawa types are not acceptable as either the
> producer or consumer argument of call-with-values, so passing the R5RS
> procedures list, vector, and string to call-with-values crashes with:

call-with-values was fixed to allow these types for the consumer
in revision 6848 (2010-12-27).

I just checked in a fix to do the same for the producer (though I can't
imagine
anyone wanting that ...).  Thanks for the report!

>> Kawa doesn't complain about (define x (set! y 32)) but it probably
>> should.
>
> A warning might be appropriate, but not an error, as x should be bound
> to something (in this case #!void) in accordance with R5RS.

But R5RS doesn't allow these to return zero values, so conformance
with R5RS is moot.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/

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