A few days ago I got a reply from Kent Pitman to my previous request.
For some reason, I lost his reply (my server must be written in C), but
I want to thank him anyway. =
First, you are right: I meant position-if.
Second, I didn't quite follow your answer. My impression is that
position-if must be implemented more or less like this:
(defun position-if (test sequence)
(do* ((position 0 (1+ position))
(item sequence (cdr item))
(res (if item (funcall test (car item)))))
((or res (null item)) (if res position))))
I know, it's not the cleanest code you can write,but it's only for the
sake of explaining my point.
What I think is that if you replace the last line by:
((or res (null item)) (if res (values position res)))))
this doesn't add almost any overhead, and it can be very useful.
As you can see, I=B4m simply adding the values call at the end of the
loop, which doesn't affect the rest of it at all. =
You might argue that "most" of the times you don't need that, but isn't
it the same with many of the functions returning multiple values, like =
truncate?
Marisa <······@kabelfoon.nl> writes:
> You might argue that "most" of the times you don't need that, but
> isn't it the same with many of the functions returning multiple
> values, like truncate?
Right. I understood your suggestion and the code looked fine.
My question was philosophical more than technical.
The problem I was getting at is that suppose the function
you were using was
(position-if #'(lambda (x) (if (numberp x) (truncate x)))
'(nil a 3.2))
You want it to return 0, 3 and I'm saying why not 0, 3, 0.2 for
pretty much the same reason--i.e., most of the time you probably don't
want the "inner" multiple values but sometimes you might. :-)
This issue comes up every time a multi-valued function wants to pass
its return values back up through another multi-valued function.
Sometimes, just appending the values works because one or the other
is a fixed number and you can sort them back out. Sometimes, it
doesn't work. Here it would work, so the question is why not do it?
Personally, I don't like functions that pass through "THE return value"
without passing all the values. To me, that's half a service. I can
see how often it would be enough--and it might make a good engineering
choice in an application, but it makes me more queasy at the language level
when we're trying to create the fiction that multiple return values aren't
second class to single return values. (Mostly, I think we did a bad job
of this already--things like MULTIPLE-VALUE-PROG1 bug me--I want PROG1 to
do that job and PRIMARY-VALUE-ONLY-PROG1 would be a better name for what is
presently PROG1.)
I don't know if this makes my comment any clearer. It's not at all like
I'm the law on these matters either. Sometimes I have as much as one
vote among many. Sometimes I'm just a voice in the crowd. I just
have a lot of opinions 'cuz I've thought about this stuff for a long
time, and I like to share the concerns with others so they'll be "on the
record" for others to think about, too. There aren't exactly right and
wrong answers but there are "guiding theories" of various kinds
(that often conflict :-).