This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: Multiple values
Jocelyn Paine wrote:
If one wants to pass around multiple values from function to function,
does Kawa actually make it more efficient to use 'values' and 'let-values'
for this than to pack the values into lists and then unpack again?
I have no numbers, but my guess is it depends. I owuld expect using
values would be more efficient for larger number of values, or if
using --full-tailcalls. It may be faster or slower in other cases.
It hasn't been optimized as much as it could be.
Two disadvantages of 'values' and its helpers that occur to me are that:
1) You can't declare the return types expected, so you lose on type
security.
The same applies to lists, except thta you declare a <list>.
Since a multiple-value is just a product type, one could imagine
a return-type specification such as
(define (sum-and-difference (x <int>) (y <int>)) <int> * <int>
(values (+ x y) (- x y))
)
That would be syntactially problemtical. A Common Lisp-inspired
syntax might be:
(define (sum-and-difference (x <int>) (y <int>))
:: (values <int? <int>) ...)
(Since you _can_ pack values into lists, which are product types anyway,
one might ask how it benefits the semantics of Scheme to have 'values' as
well, which does the same thing in a different way but without any extra
type security.)
Well, there is extra type security, at least in terms of the *number*
of results.
One reason is that values can be implemented more efficiently than
heap-allocating lists. Values can be stack-allocated, at least on
machines where you can manipulate teh stack directly. Even in Kawa,
we sort of stack-allocated values, using a thread-specific CallContext.
I presume that making BigFn return via a 'values' and then doing a
'let-values' on the accumulation argument to the lambda function would not
work - or would it?
Not portably, at least. You might get away with it in Kawa, which
sort-of allowes variables and parameters to be bound to multiple
values, partly accidentally and partly to implement XQuery sequences.
--
--Per Bothner
per@bothner.com http://www.bothner.com/per/