[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
MULTIPLE-VALUES, consing, and clarity
- To: COMMON-LISP@SAIL.STANFORD.EDU
- Subject: MULTIPLE-VALUES, consing, and clarity
- From: goldman@VAXA.ISI.EDU
- Date: Tue, 21 Apr 1987 16:04:00 -0000
- Cc: goldman@VAXA.ISI.EDU
I'm sure this must have been suggested long ago, but I'd at least like
to know why it is not part of common lisp:
From the point of view of writing clear code, as well as just good old
symmetry, it seems unfortunate that we have the richness of LAMBDA-LISTs
to pass information from calling environments into functions, but
only the impoverished
(MULTIPLE-VALUE-BIND Var* values-form ...) for communication in
the reverse direction. I have found numerous cases where my code
would be much clearer if I could write
(MULTIPLE-VALUE-BIND LAMBDA-LIST values-form ...), using
&rest, &key, and &optional receive parameters to help me "destructure"
the information coming back from values-form -- including default
values for optional parameters.
I bring this up (again?) now only because of recent discussions
about multiple values and consing. If I could write
(multiple-value-bind (&rest values) values-producer
(cond ((test values) (values-list values))
...))
a good compiler could recognize that there was no need to cons up a list
of values only to spread (a tail of) the list back onto the stack.
[Of course, this is NOT upward compatible with the current
multiple-value-bind, since the current one allows a mismatch
between the number of variables being bound and the number of
values being returned. How did THAT find its way into the specification,
anyway? I suppose its an attempt to reduce the need for
multiple-value-list when you don't know how many values might come back?]
The main objection I see to allowing a lambda list is with maintenance --
adding additional return values from a function F could invalidate calls
on F that were not prepared to accept (even if only to ignore) them.