Shouldn't you be using define-modify-macro and/or setf-macro-expander for that?

e.g. (define-macro-expander ensure-functionf/1 (x) ensure-function) (defmacro ensure-functionf (&rest places) `(progn ,@(mapcar (lambda (x) `(ensure-functionf/1 ,x)))))

good point! so, i'll push this eventually in the absent of other comments. -- attila

"Knut Olav Bøhmer" <bohmer@gmail.com> writes:

"ensure-function" is best defined like this: (defun coerce-function (sym) (coerce sym 'function))

No, it's not. (COERCE ... 'function) takes literal lambda expressions, but ENSURE-FUNCTION should not. -T.

"Knut Olav Bøhmer" <bohmer@gmail.com> writes:

...

No, it's not. (COERCE ... 'function) takes literal lambda expressions, but ENSURE-FUNCTION should not.

I have probably not understood how to use ensure-function. So I looked in to the functions.lisp file to check it out. But, I'm still not sure what would be wrong about sending ensure-function a literal-lambda expression. Explain please :) It would fit it's name better if it took a lambda list, though.

ENSURE-FUNCTION's purpose is to normalize a function designator (or actually an /extended/ function designator) to a function object. A lambda expression is not a valid function designator. (And a lambda list is something else entirely.)

Another function I found is disjoint. And according to google: Two sets are disjoint if they have no element in common. To me, that is like XOR, while Alexandrias definition of disjoint, is more like OR. Am I wrong again?

It's "disjoin", not "disjoint"; look for inclusive disjunction, and compare it to exclusive disjunction. Also notice that Dylan (the historical, and in some respects a content-wise successor of Common Lisp) defines CONJOIN, and DISJOIN. -T.

2008/11/17 Knut Olav Bøhmer <bohmer@gmail.com>:

2008/11/16 Attila Lendvai <attila.lendvai@gmail.com>:

...

dear list,

i've got this patch pending:

(defmacro ensure-functionf (&rest places) "Call ENSURE-FUNCTION for each place in PLACES and store back the results." `(progn ,@(mapcar (lambda (place) `(setf ,place (ensure-function ,place))) places)))

it might be controversial, so i'll first send it here. if noone complains for a week or two, then i'll push it eventually.

How about makeing ensure-functionf with define-modify-macro

(define-modify-macro ensure-functionf x (ensure-function x))

ok, that was wrong. Sorry. "Think before act"... (define-modify-macro ensure-functionf x ensure-function x) As I can see someone else also wrote..

then

(defun map-ensure-functionf (list) (mapl (lambda (fnames) (ensure-functionf (first fnames))) list))

I did not understand how you plan to use this macro. Maybe there is a reason you made it a macro, and not a function. Can you explain?

-- Knut Olav Bøhmer

-- Knut Olav Bøhmer

On Mon, Nov 17, 2008 at 1:46 PM, Attila Lendvai <attila.lendvai@gmail.com> wrote:

...

I did not understand how you plan to use this macro. Maybe there is a reason you made it a macro, and not a function. Can you explain?

the typical use-case is a mapping function that accepts various function designators like &key (test 'eq) (key 'identity).

if it loops a lot and it's supposed to run fast, then one should look up the functions before looping:

(ensure-functionf test key) (do-the-looping)

i'm open for suggestions for different naming, but i don't think that the cl spec is so much more important than the english language and the meaning of the "ensure" word. also, if you look at it from a different POV, the primary feature of e.g. ENSURE-SYMBOL is to return a symbol designated by its argument, and it's secondary that it may need to do some sideffects to achieve that. also note that there are already ENSURE-LIST, ENSURE-CONS, etc that do not have any sideffects.

I see Kevin's concern, though I think that "ENSURE" functions are the sort with "allowed accidental side-effects", whereas the important thing is that certain things hold true about the return value. I am personally ok with ENSURE- naming as it stands, but if there is a concern about diluting an existing naming convention, and a better name comes up -- I can live with the change as well.

although i would be happy if we could settle on acceptable names, because otherwise these oneliners will end up in my duplicates.lisp files all around in different projects.

Well, maybe we need to open Babylon. :) (A subproject which collects things which might be in Alexandria, but for one reason or another aren't -- too controversial, too different, not sufficiently commonplace, etc.) Re. CALLF: I'll think about it properly sometime during next week. (I am torn about it: half the time I can't remember why I like it, and half the time I can't remember why I *don't* like it.) Cheers, -- Nikodemus

Re. CALLF: I'll think about it properly sometime during next week. (I am torn about it: half the time I can't remember why I like it, and half the time I can't remember why I *don't* like it.)

i'm also torn about it, but after re-reading the thread i think the consensus leans towards that ensure-functionf is ok, so for now i've pushed it without using CALLF. later this could use CALLF, or it can even be moved into another sister package of alexandria... -- attila