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.