I've looked into your bug comment.
The additional use case that I see is your example code:
(let ((v (values 1 2))) (call-with-values (lambda () v) cons))
It could be re-written as:
(let ((v '(1 2))) (call-with-values (lambda () (apply values v)) cons))
I don't see what a user-visible values structure provides when the user already has cons, vectors, and records.
I see the call-with-values as a way to create multi-value continuations and values as the standard way to call them. If the continuation does not accept multiple values (any continuation not created by call-with-values) then I'd like to see it behave as if you just returned one value.
Unfortunately, the only way to use the current implementation of 'values' properly is to de-structure it using call-with-values. I think that is redundant since I can perform the same with a list, vector, or record. What I would like is to forget about secondary values when I use it normally, and only care about them when I explicitly request it. The only way to achieve this is a values semantics that I'm advocating.
Some use cases (to name a few).
1. When the primary value is expensive to create and the secondary value is cheap and dependent on the primary value. 2. for table-ref, you can have a secondary value on whether the item was actually set or not.
Arthur
----- Original Message ----
I've once written a response to someone posting this as bug in bugzilla:
http://www.iro.umontreal.ca/~gambit/bugzilla/show_bug.cgi?id=63
I.e. I personally still think the "take first value if continuation only expects one value" approach is a bad idea.
If you're really wanting to see that behaviour, maybe you could describe the reasons in more detail and think about the issues I've lined out above; maybe there is a way to achieve both.
Christian.