Filtered functions
in [Lisp]
|
Prev: [ANN] Filtered functions
Next: Filtered functions.
From: Kenneth Tilton on 6 Dec 2009 16:40 Pascal Costanza wrote: > Kenneth Tilton wrote: >> Pascal Costanza wrote: >>> 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? >>> >> >> Did you miss the part [...] > > As long as you're not missing anything, everything is fine, right? > I think it is time for me to go back in your killfile. kt -- http://www.theoryyalgebra.com/
From: Pascal Costanza on 6 Dec 2009 16:51 Kenneth Tilton wrote: > Pascal Costanza wrote: >> Kenneth Tilton wrote: >>> Pascal Costanza wrote: >>>> 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? >>>> >>> >>> Did you miss the part [...] >> >> As long as you're not missing anything, everything is fine, right? >> > > I think it is time for me to go back in your killfile. > I will surely ignore you again soon enough. In the meantime, you can look up your very first entry in this thread, and ask yourself the question: Was this really necessary? 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 18:27 Pascal Costanza wrote: > Kenneth Tilton wrote: >> Pascal Costanza wrote: >>> Kenneth Tilton wrote: >>>> Pascal Costanza wrote: >>>>> 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? >>>>> >>>> >>>> Did you miss the part [...] >>> >>> As long as you're not missing anything, everything is fine, right? >>> >> >> I think it is time for me to go back in your killfile. >> > > I will surely ignore you again soon enough. This would be a non-ignoring ignore according to group terminology. > > In the meantime, you can look up your very first entry in this thread, > and ask yourself the question: Was this really necessary? Necessary? That's a rather high bar. Relevant sure, and heartfelt, absolutely: I am working on GF-heavy code and the idea of GFs Gone Mad provoked my honest reaction. What is needed first with a swiss army knife is knowing all the blades and tools available. What is needed second is knowing when to use them. What is needed rarely with a language the size of CL is more blades and tools. /Now/ can I go back in your killfile? kt -- http://thelaughingstockatpngs.com/ http://www.facebook.com/pages/The-Laughingstock/115923141782?ref=nf
From: Pascal J. Bourguignon on 6 Dec 2009 19:07 Kenneth Tilton <kentilton(a)gmail.com> writes: > Pascal Costanza wrote: >> I will surely ignore you again soon enough. > > This would be a non-ignoring ignore according to group terminology. Or (declare (ignorable kenny)) as we say here... -- __Pascal Bourguignon__
From: Pascal Costanza on 6 Dec 2009 19:19
Ron Garret wrote: > 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. Indeed, that's a very excellent summary. (I wish I could have worded it this way myself.) The major problem of object-oriented programming is that you have to build a global 'ontology' of concepts that all participating generic functions and methods agree about. But this is unfortunately a necessary ingredient, because it is the only non-ambiguous way to drive method selection in generic functions (and other forms of OOP as well). You can look at generic functions as a way to express extensible COND forms, where different parties in different parts of a program can contribute to one and the same COND. What makes COND a particularly expressive construct is that it is always precise in its choice: You define an order in which cases are tested, and the first that succeeds 'wins'. If you need some cases to 'dominate' others, you just have to put them in the right order. However, if you want to make a COND form extensible, the different parties have to agree on some form of ordering of the respective cases they add. In the ideal case, every party would be able to contribute arbitrary predicates. However, since we cannot decide which predicates are more general than others in the general case, we have to restrict what the different contributors can add. So by introducing generic functions, we both win and lose: We win by potentially improving the structure of a program, but we lose because we have to restrict ourselves to a certain set of predicates to use, which in the case of class hierarchies is particularly weak, but fortunately non-ambiguous, because which classes are more general than others can naturally be derived from those hierarchies in a non-ambiguous way. An interesting case is, for example, Clojure: Until end of last year, its multi-method feature had only a very weak notion of coordinating the contributing methods: You basically had to write a dispatch function (discriminating function) yourself. This is in the meantime replaced by a notion of hierarchies again, with the somewhat interesting flexibility that the hierarchy can be determined per function (which can probably be achieved by way of method combination in CLOS as well). I'm convinced that filtered functions are more powerful, just because they allow you to get rid of such hierarchies, at least to some extent, but instead you can define an ad-hoc ordering of filters per functions without much extraneous effort. My hope is that this gets us closer to get back some of the lost advantage of COND, namely to be precise about the order in which predicates are tested, but still be able to contribute from different parts of a program to the same single COND form. Of course, we can only tell in the long run whether this really pays off or not. However, it is the case that Jim Newtons "custom specializers", which I consider a precursor to filtered functions, is indeed used in practice at his group at Cadence Design Systems, so this seems to be a worthwhile path to explore. 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/ |