Filtered functions
in [Lisp]
|
Prev: [ANN] Filtered functions
Next: Filtered functions.
From: Pascal Costanza on 5 Dec 2009 21:17 Ron Garret wrote: > In article <7o0asgF3l7u67U1(a)mid.individual.net>, > Pascal Costanza <pc(a)p-cos.net> wrote: >> Consider: >> >> (def-subclass prime-number integer (make-filter 'primep t)) >> (def-subclass even-number integer (make-filter 'evenp t)) >> >> (defmethod foo ((n prime-number)) (do-this)) >> (defmethod foo ((n even-number)) (do-that)) >> >> (foo 2) => should this perform do-this or do-that? Neither prime-number >> is a subclass/subset of even-number, nor the other way around, so it's >> unclear what the method specificity should be. >> >> Now with filtered functions: >> >> (define-filtered-function foo (n) >> (:filters (:prime #'primep) >> (:even #'evenp))) >> >> (defmethod foo :filter :prime ((n (eql t)) >> (do-this)) >> >> (defmethod foo :filter :even ((n (eql t))) >> (do-that)) >> >> (foo) => this will perform do-that, because the filter :even comes after >> the filter :prime in the define-filtered-function form. >> >> So how do you want to specify that when using def-subclass? > > In the exact same way: by providing a mechanism to specify a total > ordering on the sub-classes of a given class, just as you provide a > mechanism to specify a total ordering on filters. (Exactly what that > mechanism would be is TBD.) ....but then it will end up as being more or less the same, except for difference in surface syntax. That's not that interesting. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Pascal Costanza on 5 Dec 2009 21:19 Ron Garret wrote: > FWIW, I still think I would personally prefer a dispatch system which > leaves it up to me (the programmer) to insure that the predicates I use > halt, don't raise errors, and have some kind of total ordering defined > on them. Er. That's what you actually get with filtered functions. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Ron Garret on 6 Dec 2009 02:38 In article <7o0ii5F3o7jgmU1(a)mid.individual.net>, Pascal Costanza <pc(a)p-cos.net> wrote: > Ron Garret wrote: > > In article <7o0asgF3l7u67U1(a)mid.individual.net>, > > Pascal Costanza <pc(a)p-cos.net> wrote: > >> Consider: > >> > >> (def-subclass prime-number integer (make-filter 'primep t)) > >> (def-subclass even-number integer (make-filter 'evenp t)) > >> > >> (defmethod foo ((n prime-number)) (do-this)) > >> (defmethod foo ((n even-number)) (do-that)) > >> > >> (foo 2) => should this perform do-this or do-that? Neither prime-number > >> is a subclass/subset of even-number, nor the other way around, so it's > >> unclear what the method specificity should be. > >> > >> Now with filtered functions: > >> > >> (define-filtered-function foo (n) > >> (:filters (:prime #'primep) > >> (:even #'evenp))) > >> > >> (defmethod foo :filter :prime ((n (eql t)) > >> (do-this)) > >> > >> (defmethod foo :filter :even ((n (eql t))) > >> (do-that)) > >> > >> (foo) => this will perform do-that, because the filter :even comes after > >> the filter :prime in the define-filtered-function form. > >> > >> So how do you want to specify that when using def-subclass? > > > > In the exact same way: by providing a mechanism to specify a total > > ordering on the sub-classes of a given class, just as you provide a > > mechanism to specify a total ordering on filters. (Exactly what that > > mechanism would be is TBD.) > > ...but then it will end up as being more or less the same, except for > difference in surface syntax. Um, yeah. That was kind of my point. > That's not that interesting. Well, interesting is in the eye of the beholder. But I believe I did say early on in this discussion that the two approaches seemed equivalent, and that it was just a question of API design; the underlying functionality is the same. Speaking only as a potential user, I find thinking about this in terms of subclasses more intuitive than thinking about it in terms of filtered functions. FWIW, YMMV and all that. rg
From: Lars Rune Nøstdal on 6 Dec 2009 02:50 On Dec 5, 7:05 am, Kenneth Tilton <kentil...(a)gmail.com> wrote: > .. > Filed under "Stupid CLOS Tricks". > .. > kt Hm, but by using EQL-specialized methods things do turn from type/ class driven dispatch to data driven, no? (defgeneric on-click (widget)) (let ((x (list "<some-button-widget>")) (logged-in-p nil)) (defmethod on-click ((button (eql x))) (assert logged-in-p) (write-line "B")) (defmethod on-click :before ((button (eql x))) (setf logged-in-p t) (write-line "A")) (on-click x)) A B There is some trouble involved with lifetime (GC) here and I'm sort of using an outer Viewport layer which when GCed will "manually" GC these methods thus freeing the widgets they in turn point to. Another possibility is weak-pointers or a weak hash-table, I think. A problem is that SB-PCL seems to have a leak at the moment: https://bugs.launchpad.net/sbcl/+bug/492851 I've tried doing stuff like (REMHASH X SB-PCL::*EQL-SPECIALIZER- TABLE*) and (REMHASH X SB-PCL::*EQL-SPECIALIZER-METHODS*) at the "right time" (helping it a bit manually) and, stuff, but it seems a reference is still being held _somewhere_. So, even if I somehow did use weak pointers the pointers _themselves_ would leak; that is, all use of EQL-specialization, even if handled "correctly from the outside" -- will have an "internal leak" AFAICT .... hm. Anyway, this is ramblish -- and the reason I posted is method combinations (even user defined ones!) seem interesting for cases like these (totally disregarding this problem for a moment), and I wonder how and perhaps why one would go about re-implementing this in something like Cells or similar. Also, I'm wondering if pcos has hit this problem wrt. EQL-specialization and whether there might be some way to work around this, or something. :) -- Lars Rune Nøstdal
From: Juanjo on 6 Dec 2009 03:06
On Dec 6, 3:17 am, Pascal Costanza <p...(a)p-cos.net> wrote: > Ron Garret wrote: > > In article <7o0asgF3l7u6...(a)mid.individual.net>, > > Pascal Costanza <p...(a)p-cos.net> wrote: > >> So how do you want to specify that when using def-subclass? > > > In the exact same way: by providing a mechanism to specify a total > > ordering on the sub-classes of a given class, just as you provide a > > mechanism to specify a total ordering on filters. (Exactly what that > > mechanism would be is TBD.) > > ...but then it will end up as being more or less the same, except for > difference in surface syntax. That's not that interesting. Ron's solution may even be _worse_. If you specify the partial order outside the filtered function definition, then that order will apply to _all_ methods that use those filters. Instead, if the order is set up in the filtered function itself, it is local and the same filters can be "recycled". |