
Multiple-value-list with no values.
Quote:
> >No, it doesn't. And in the copy of CLISP I have handy (2000-03-06), I
> >get NIL. If there are any versions of CLISP that return (NIL) here,
> >that's a bug and should be reported (unless they're really really old...)
> I just tried:
> (setf x (values-list nil))
> (multiple-values-list x)
> =>(nil)
> version 2.27
[ I assume you meant multiple-value-list in the above, otherwise CLISP
should have signalled an error. ]
That is completely correct behaviour:
- (values-list nil) produces 0 values, but since the right-hand side
of the setf form will require exactly 1 value, that value is
defaulted to nil, so x gets set to nil.
- (multiple-value-list nil) must return (nil), since evaluating nil
yields exactly 1 value, namely nil, which is then returned.
To test what you wanted to test, you can do:
(multiple-value-list (values-list nil))
which yields nil, as expected.
You should be aware that multiple values deteriorate to 1 value in all
contexts other than those which are specified to handle
multiple-values specially, like e.g. m-v-bind, m-v-call, m-v-list, but
also progn, etc.
Quote:
> Actually it came about because of something different I was doing:
> (use-package "REGEXP")
> (setf s "abcdef")
> (setf reg-exp-match (multiple-value-list (match 'ghi" s)))
> (if (not (nul reg-exp-match))
> (princ (subseq s (match-begin (car reg-exp-match))
> (match-end (car reg-exp-match)))))
> where the princ crashes because (car reg-exp-match) is nil.
> Actually it turns out that reg-exp-match is (nil).
That would indicate that match returns nil, and not 0 values.
Regs, Pierre.
--
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein