Filtered functions
in [Lisp]
|
Prev: [ANN] Filtered functions
Next: Filtered functions.
From: Lars Rune Nøstdal on 6 Dec 2009 03:51 On Dec 6, 8:50 am, Lars Rune Nøstdal <larsnost...(a)gmail.com> wrote: > 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. ...or well, the problem does seem SBCL specific in that it does not happen in CLISP.
From: Alessio Stalla on 6 Dec 2009 05:02 On Dec 6, 4:06 am, Raffael Cavallaro <raffaelcavall...(a)pas.espam.s.il.vous.plait.mac.com> wrote: [snip] > Not merely related, but central to this discussion. Your "analysis" is > just spite. Since your extension to CLOS was not well received, then no > one's should be. I'm much more on Pascal's side than Kenny's in this discussion, but... why do you keep saying the Cells is not well received? I don't believe so. There are many applications and libraries that use Cells. As for it not being publication-quality and well documented... writing and documenting Cells is not Kenny's main job, while writing publications is part of Pascal's job; if his software and documentation weren't publication-quality, he wouldn't be doing a good job. The fact that he and his colleagues go to extra lengths to make their software publicly available and running on multiple CL implementations is of course very appreciated, not everyone would do such a thing. Alessio Stalla
From: Lars Rune Nøstdal on 6 Dec 2009 05:03 > > ..or well, the problem does seem SBCL specific in that it does not > happen in CLISP. ...ahwell, no, it does seem to happen there too after a while..
From: Pascal Costanza on 6 Dec 2009 08:45 Ron Garret wrote: > 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. > Oh, ok. Then I get it. Sorry for the noise. ;) I have the strong gut feeling there is something not quite right with your alternative API proposal, but I cannot directly point at it. It has something to do with users then maybe having stronger expectations what this mechanism can do. For example, I bet people then want operators like typep and subtypep to work on these 'subclass' definitions as well, and I smell that that's no good. I would need more time to think about this in more detail, and I don't have that time at the moment. Sorry. Maybe later... 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: Kenneth Tilton on 6 Dec 2009 12:06
Lars Rune N�stdal wrote: > 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. This does not have much to do with Cells; most Lisp GUI frameworks accept callbacks as data, ie the values of slots called 'on-click: (make-instance 'button :on-click (lambda (self event) ...)) If you think you need to divide the code in two (between primary and before methods): (make-instance 'button :on-click 'my-super-on-click-handler) Based on your discussion of the GC issue, I can tell your example is real world. Otherwise I would be stumped at a list of one string being a widget. Perhaps you could: (list :type 'button :on-click (lambda (self event) ...) But seeing EQL specializers used to get a task decomposed into GF methods to achieve instance-specific handling suggests the wrong tool is being used for the wrong job. Oh, hang on. Was (list "<some widget>") the moral equivalent of a class definition, with the eql methods the equivalent of normal type-dispatched methods? Yer kinda scaring me. Are you /implementing/ an OO library? kt -- http://thelaughingstockatpngs.com/ http://www.facebook.com/pages/The-Laughingstock/115923141782?ref=nf |