[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: NTH-VALUE (Version 4)
- To: CL-Cleanup@SAIL.Stanford.EDU
- Subject: Issue: NTH-VALUE (Version 4)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 12 Jan 89 14:22 EST
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Some additional data on this topic, based on practical experience with
people using multiple values over the past year.
Since there is no convention for use of IGNORE or NIL in multiple-value
argument lists in Common Lisp, it is a common complaint that Cloe gets
from users of Genera that they must rewrite:
(MULTIPLE-VALUE-BIND (IGNORE Y)
(SEND FROB :READ-CURSORPOS)
...)
to do
(MULTIPLE-VALUE-BIND (IGNORE Y)
(SEND FROB :READ-CURSORPOS)
(DECLARE (IGNORE IGNORE))
...)
I usually tell them that Common Lisp is considering an NTH-VALUE
primitive so they could write
(LET ((Y (NTH-VALUE (SEND FROB :READ-CURSORPOS) 1)))
...)
and they are mostly appeased.
Recently, however, someone asked me how he could do what in
Symbolics Lisp would be written as:
(MULTIPLE-VALUE-SETQ (IGNORE Y) (SEND FROB :READ-CURSORPOS))
The only rewrites I could think of for this were much yuckier, so I
thought I'd raise the issue. With NTH-VALUE it would be
(SETQ Y (NTH-VALUE (SEND FROB :READ-CURSORPOS) 1))
but without it, all I could come up with were:
(MULTIPLE-VALUE-BIND (XX YY)
(SEND FROB :READ-CURSORPOS)
(DECLARE (IGNORE XX))
(SETQ Y YY))
or
(SETQ Y (MULTIPLE-VALUE-BIND (XX YY)
(SEND FROB :READ-CURSORPOS)
(DECLARE (IGNORE XX))
YY))
or
(SETQ Y (CADR (MULTIPLE-VALUE-LIST (SEND FROB :READ-CURSORPOS))))
I consider this case to be much yuckier than previous examples I've
seen, and it strengthens my belief in the need for NTH-VALUE.
In the absence of NTH-VALUE, we should consider the possibility
of permitting NIL in the argument list to MULTIPLE-VALUE-BIND and
MULTIPLE-VALUE-SETQ to denote an argument which is not to be assigned.
The good points of that would be
- it is fairly concise syntactically.
- it doesn't accomodate a variable index like NTH-VALUE does.
Some implementors might prefer not to have to write that code.
The bad points of that would be
- NIL can fall through from lots of places in macros, etc. so error
checking is reduced.
- it's a special case, and so aesthetically ugly to some.
- it doesn't accomodate a variable index like NTH-VALUE does.
Some users might prefer not to have to write that code.