I'd also like to propose the following addition:
(defun sometimes (test then &optional (else nil else-p)) "Returns a function that applies TEST on its arguments and returns either THEN or ELSE depending on the test result.
If ELSE is not provided, the arguments passed to the returned function are returned as multiple values.
Examples:
(mapcar (sometimes #'plusp 1 -1) '(1 -1 2 -2 3 -3))
==> (1 -1 1 -1 1 -1)
(mapcar (sometimes #'minusp 0) '(1 -1 2 -2 3 -3))
==> (1 0 2 0 3 0) " (flet ((%sometimes (&rest args) (if (apply test args) then (if else-p else (values-list args))))) #'%sometimes))
It's in the same spirit as CONSTANTLY, which is also the reason for its name. (SOMETIMES #'PLUSP 1 -1) can be read as
sometimes 1, sometimes -1, depending on PLUSP.
The internal FLET should probably be replaced by a call to ALEXANDRIA:NAMED-LET.
-T.
On 1/17/08, Tobias C. Rittweiler tcr@freebits.de wrote:
I'd also like to propose the following addition:
I'm still on the fence re MAYBECALL, but this one I say no to. IMO the amount of symbols already exported is possibly too large, and unless you see this regularly, this is going to be a lot slower to read then
(lambda (x) (if (test x) <then> <else>))
and not that much better to write.
I suspect there is also a stylistic issue of "when to LAMBDA and when to DEFUN a generator" here. There are already borderline items in Alexandria like OF-TYPE, which despite the amusingly punny name and hopefully obvious meaning is maybe _too_ trivial.
A word on my logic here: Alexandria wants to be widely used, and make it easier to not just write, but also to read CL programs. Hence, I strongly believe that symbols exported by Alexandria should fall into the following categories
* Traditional: ONCE-ONLY, WITH-GENSYMS, etc.
* Name is sufficient documentation for reading the code. FORMAT-SYMBOL, HASH-TABLE-ALIST, LASTCAR, REQUIRED-ARGUMENT, etc. MAYBECALL... maybe. :)
* Seldom used, but _really_ convenient when you need them. I suspect CALLF is one of these, as long as it is use pretty much only for writing modify macros, and not instead of them.
There will be exceptions, of course, but SOMETIMES seems like something that would be applicable in fairly many situations, yet no something you use _all_ the time -- so it's no something that I think we can assume the reader is already familiar with from other code, and neither is the meaning clear.
(Sorry for rambling.)
Cheers,
-- Nikodemus
alexandria-devel@common-lisp.net
-
Nikodemus Siivola -
Tobias C. Rittweiler