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.
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.
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)))))
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Suicidal terrorists may have short shelf lives. -- John McCarthy
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 Lendvai" attila.lendvai@gmail.com writes:
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.
It's leaky.
Better consider adopting CALLF &c
http://common-lisp.net/pipermail/alexandria-devel/2007-September/000259.html
You'd then write ENSURE-FUNCTIONF as
(defmacro ensure-functionf (&rest places) (loop for place in places collect `(CALLF #'ENSURE-FUNCTION ,place)))
-T.
PS: Available in my alexandria branch.
On Nov 16, 2008, at 7:52, Attila Lendvai wrote:
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.
For what little it's worth: I think this and ENSURE-FUNCTION are abuse of the naming conventions employed by the CL specification.
"ensure" is a mutating concept: see cl:ensure-generic-function, cl:ensure-directories-exist. These potentially mutate a function slot and the filesystem, respectively. (alexandria:ensure-symbol is an example of correct usage.)
That is, this proposed operator should be called ENSURE-FUNCTION and the current ENSURE-FUNCTION should be called something else. (Perhaps ACTUALLY-FUNCTION or AS-FUNCTION or some sort of name expressing de- indirection?)
Also, I think "f" doesn't mean "in-place version of other operator", but only "operates on a place"; e.g. PUSH is not CONSF, INCF is not 1+F, and SETF is not, uh, NTH-VALUES-2F? The CLHS examples for DEFINE- MODIFY-MACRO arguably disagree with me, though. I don't feel this is nearly as important as preserving what ENSURE means.
2008/11/17 Kevin Reid kpreid@mac.com:
On Nov 16, 2008, at 7:52, Attila Lendvai wrote:
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.
For what little it's worth: I think this and ENSURE-FUNCTION are abuse of the naming conventions employed by the CL specification.
Agree. ensure-generic-function creates a generic function. ensure-directory-exist creates a directory if it does not exsist ensure-class, is used to define or redefine a class.
"ensure-function" is best defined like this: (defun coerce-function (sym) (coerce sym 'function))
"ensure" is a mutating concept: see cl:ensure-generic-function, cl:ensure-directories-exist. These potentially mutate a function slot and the filesystem, respectively. (alexandria:ensure-symbol is an example of correct usage.)
That is, this proposed operator should be called ENSURE-FUNCTION and the current ENSURE-FUNCTION should be called something else. (Perhaps ACTUALLY-FUNCTION or AS-FUNCTION or some sort of name expressing de- indirection?)
Also, I think "f" doesn't mean "in-place version of other operator", but only "operates on a place"; e.g. PUSH is not CONSF, INCF is not 1+F, and SETF is not, uh, NTH-VALUES-2F? The CLHS examples for DEFINE- MODIFY-MACRO arguably disagree with me, though. I don't feel this is nearly as important as preserving what ENSURE means.
-- Kevin Reid http://homepage.mac.com/kpreid/
alexandria-devel mailing list alexandria-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/alexandria-devel
"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.
2008/11/17 Tobias C. Rittweiler tcr@freebits.de:
"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.
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.
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?
"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/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))
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?
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
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.
but i'm also fully aware of the possible veto rights, so please do live with it if anyone feels so, because otherwise the project won't work as it was intended to...
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.
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
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've been thinking about this for the past few days and tend to agree with you. The important thing about ENSURE- is making sure of something with the possibility that this is already the case.
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.)
That's a good idea, although Babylon rather sounds like a name for a translation library.
Leslie
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...
alexandria-devel@common-lisp.net
-
Attila Lendvai -
Faré -
Kevin Reid -
Knut Olav Bøhmer -
Leslie P. Polzer -
Nikodemus Siivola -
Tobias C. Rittweiler