Re: Issue: NTH-VALUE (Version 4)

["Steve Bacher (Batchman)" <SEB1525@draper.com>]

re: Message from KMP of 12 Jan 89, 14:22 EST
 
I don't recall from the proposal, but is it true that the syntax of NTH-VALUE
is (NTH-VALUE value-returning-form index), rather than
(NTH-VALUE index value-returning-form)?  Why isn't it the latter, a la NTH
and NTHCDR?  Not only is it more consistent with NTH and NTHCDR that way, but
it is much easier to eyeball-parse (NTH 2 (big hairy expression)) than
(NTH (big hairy expression) 2).
 
Btw. ZIL supports destructuring in the argument list of MULTIPLE-VALUE-BIND, 
and thus handles NIL in place of an argument as a degenerate case thereof.
(It doesn't support NIL in MULTIPLE-VALUE-SETQ, though I probably could create
a MULTIPLE-VALUE-DESETQ macro a la DESETQ if I wanted to bother.)
  
Apropos of multiple-value issues, shouldn't there be a portable way for a
function that is about to return multiple values to be able to determine 
whether or not all of those values were actually going to be used, so it 
could bypass computation of extra values if they weren't going to be needed?
Refer to CLtL, p. 134:
  
"It may be that...for efficiency reasons it is desired not to compute the
second value." - this from a discussion of why you might want to code
(values (floor x y)), for example.  Well, if FLOOR doesn't know that only
its first value is being used, how can it take advantage of this and not
compute the second value, unless it uses some underlying low-level mechanism
to find this out?
 
If NTH-VALUE passes, this could get interesting.  FLOOR would have to be able
to tell, for example, that only its second value was going to get used, and
avoid computing the first value.  This may not make a lot of sense for FLOOR,
but there may be other functions where it does.