Filtered functions
in [Lisp]
|
Prev: [ANN] Filtered functions
Next: Filtered functions.
From: Kenneth Tilton on 6 Dec 2009 12:35 Alessio Stalla wrote: > 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. ....and this is Lisp so Cells is even more plagiarized than used: Mr. Burdick's C4, Mr. Eby's Trellis (for Python), Mr. Jain's incipient Formulate, and this: http://common-lisp.net/project/computed-class/. > 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. Man, documentation is hard, unrewarding work. And I do admire good doc, such as the Postgres doc and the old Inside Mac books (and the doc for the Apple II Basics and for VAX/VMS). The CLHS is OK, tho it will be named in my upcoming carpal tunnel class action. > 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. And they shouldnt, it's a PITA. Cells runs everywhere, and Celtk and Cells-GTk do not do too badly. Cello has been observed at different times in its life on Linux and the Mac as well as Windows. Lisp implementation does not matter if it is conformant CL. But my experience with the above confirms the experience of many others: doing X for open source is 27 times harder than doing it for oneself, with documentation being part of the burden, portability being another. I'd rather /use/ X (http://www.theoryyalgebra.com/) to make money so I can hire all you deadbeats than spend hundreds of hours working on casting pearls before you swine. But the important thing is getting Raffy to see how he misapplied "sour grapes"! There are so many other insults he fairly could have switched to once his gaffe was exposed. Ah, the vanity of the Usenet denizen, never able to publicly concede a mistake, digging deeper and deeper. Especially those Mexicans. Anyway, I finally persuaded GraphicsMagick to not require separate installation (after belatedly discovering NSIS would support nested installs, but this is still nicer) so I should be able to put together an installer for Stuck On Algebra (the new name) and start my Algebra empire in short order. Get your resumes ready. kt
From: Ron Garret on 6 Dec 2009 12:38 In article <7o1qrfF3i0m5pU1(a)mid.individual.net>, Pascal Costanza <pc(a)p-cos.net> wrote: > 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... No worries. I mostly just wanted to get the idea on your radar screen. rg
From: Pascal Costanza on 6 Dec 2009 12:41 Kenneth Tilton wrote: > Alessio Stalla wrote: >> 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. > > ...and this is Lisp so Cells is even more plagiarized than used: Mr. > Burdick's C4, Mr. Eby's Trellis (for Python), Mr. Jain's incipient > Formulate, and this: http://common-lisp.net/project/computed-class/. > >> 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. > > Man, documentation is hard, unrewarding work. And I do admire good doc, > such as the Postgres doc and the old Inside Mac books (and the doc for > the Apple II Basics and for VAX/VMS). The CLHS is OK, tho it will be > named in my upcoming carpal tunnel class action. > >> 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. > > And they shouldnt, it's a PITA. Cells runs everywhere, and Celtk and > Cells-GTk do not do too badly. Cello has been observed at different > times in its life on Linux and the Mac as well as Windows. Lisp > implementation does not matter if it is conformant CL. But my experience > with the above confirms the experience of many others: doing X for open > source is 27 times harder than doing it for oneself, with documentation > being part of the burden, portability being another. > > I'd rather /use/ X (http://www.theoryyalgebra.com/) to make money so I > can hire all you deadbeats than spend hundreds of hours working on > casting pearls before you swine. > > But the important thing is getting Raffy to see how he misapplied "sour > grapes"! There are so many other insults he fairly could have switched > to once his gaffe was exposed. Ah, the vanity of the Usenet denizen, > never able to publicly concede a mistake, digging deeper and deeper. > Especially those Mexicans. > > Anyway, I finally persuaded GraphicsMagick to not require separate > installation (after belatedly discovering NSIS would support nested > installs, but this is still nicer) so I should be able to put together > an installer for Stuck On Algebra (the new name) and start my Algebra > empire in short order. Get your resumes ready. None of this has anything to do with the topic of the thread, right? 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 12:59 In article <e5e844ff-c527-4aba-b861-fbe2653ae0d7(a)31g2000vbf.googlegroups.com>, Juanjo <juanjose.garciaripoll(a)googlemail.com> wrote: > 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". Hm, that's a good point. I had it tacitly in my mind that there would be only one global ordering for the subclasses of any single class (with the default being the order in which they were defined) but that does seem like it could be overly constraining. Of course, nothing prevents you from designing an API that allows you to define different orderings for different methods, or even for each individual argument for a method, but I don't see offhand how to do that without losing the elegant simplicity that made subclasses attractive (to me) in the first place. So I guess that's the answer: the reason filtered functions are cool is that they solve (or at least side-step) the problem of having to define a total order on non-disjoint subclasses for every argument of every generic function that uses them. rg
From: Lars Rune Nøstdal on 6 Dec 2009 14:15
On Dec 6, 6:06 pm, Kenneth Tilton <kentil...(a)gmail.com> wrote: > 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) Hm. Yeah, but now I've lost the ability to add further callbacks to the ON-CLICK slot. Well, at least while at the same time controlling order when that is needed for a group/sub-set of the callbacks -- sometimes on a pr. instance basis, sometimes not. .... or something. I keep losing track of what the problem actually is/ was, but something _is_ wrong with what I'm currently doing here, and it is remarkably hard coming up with a small test-case or example to illustrate the problem .. gah. Ok, again, some order is needed in _some_ cases, but at the same time I don't want external or unrelated code to have to worry about stuff like a MY-SUPER-ON-CLICK-HANDLER being around. Experimenting here; so perhaps multiple ways ("categories") of adding callbacks, then? I don't know: (defgeneric on-event (event widget &rest args) (:method-combination progn)) (defgeneric on-click (widget &rest args)) (defmethod on-event progn (event widget &rest args) #| Forward to something that might want to use another method-combination than the "brute force" PROGN used here. |# (let* ((gf-name (intern (format nil "ON-~A" event))) (gf (and (fboundp gf-name) (fdefinition gf-name)))) (when gf (apply gf widget args)))) (let ((x (list "some-button-widget")) (logged-in-p nil)) (defmethod on-click ((widget (eql x)) &key) (assert logged-in-p) (write-line "B")) (defmethod on-click :before ((widget (eql x)) &key) (setf logged-in-p t) (write-line "A")) (defmethod on-event progn ((event (eql 'click)) (widget (eql x)) &key) (write-line "BULK OP.")) (on-event 'click x)) ==> BULK OP. A B ...and in addition there are "Cells-like" callbacks which are sort of like the "bulk operations" in that they fire in a "non-user controllable order". Aka., not possible to specify custom method- combinations for these as is the case for e.g. the more specific ON- CLICK methods here. So, 3 ways of dealing with or adding callbacks then (?) ... *sigh*. Perhaps I'm just nuts. > Based on your discussion of the GC issue, I can tell your example is > real world. Yup. Well, I construct a new LIST on each iteration in this test-case to make sure that there really is something to GC. By making the LIST (in the SBCL bug report) very large I make sure that I run out of memory (confirm the leak) fast. That is, a literal string on its own might be "inlined" or stored in some static storage or similar by the compiler. I suspect something would _still_ leak internally though, but I would not see things crash- and-burn as quickly. The LIST is just a replacement or "dummy" for what really is a normal class (WIDGET) instance. > 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. Yeah, I don't know yet. > 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? Hm, nope. (LIST "<some widget>") is really just a dummy version of what in real code is an instance of a widget class; nothing fancy here. :) (.. perhaps this discussion belongs in a new thread, but yeah, seeing EQL-specialization used above triggered a post from my end :P ..) -- Lars Rune Nøstdal |