[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: NTH-VALUE (Version 4)
- To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
- Subject: Re: Issue: NTH-VALUE (Version 4)
- From: peck@Sun.COM
- Date: Fri, 13 Jan 89 13:20:35 PST
- Cc: cl-cleanup@SAIL.STANFORD.EDU
- In-reply-to: Your message of Fri, 13 Jan 89 09:02:00 -0500; <8901131737.AA17270@Sun.COM> .
>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.
Nah, it would never be *required*. p134 is talking about a "standard idiom"
for how a programmer could express the desire. A really smart compiler
that is working on an inline function that it knows a LOT about
*maybe* would make such an optimzation.
You make a good point reminding us that (VALUES (...))
is a special case of NTH-VALUE, ie (NTH-VALUE 0 (...))
Are we going to see an extension for MULTIPLE NTH-VALUES?
(multiple-value-bind (a c e)
(NTH-VALUE '(0 2 4) (...))
Equivalent to the request for NIL binding:
(multiple-value-bind (a nil c nil e) (...)
Yes, of course i just kidding... :)