Scheme language standardization process
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@x http://per.bothner.com/ _______________________________________________ Scheme-reports mailing list Scheme-reports@x http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports