Prev: [ANN] Filtered functions
Next: Filtered functions.
From: Slobodan Blazeski on 5 Dec 2009 18:23 On Dec 5, 11:41 pm, Slobodan Blazeski <slobodan.blaze...(a)gmail.com> wrote: > On Dec 5, 4:28 pm, Pascal Costanza <p...(a)p-cos.net> wrote:> Slobodan Blazeski wrote: > > > Any ideas where those would be useful? ContextL was interesting but I > > > never figured a natural problem where to use it. > > > Did you check the paper? > > I've read your paper, the interpreter code is very cool still it > doesn't answer my question. > > > An extensible code walker could be a nice application. (That's like the > > interpreter, except that it doesn't interpret. ;) > > I know a little bit about code walkers such us cl-cont but I'm not in > that business. I work on programs that model some processes, they work > continuously instead of getting some input and spewing some output. Is > there is some interesting problem that this tool solves for me? Think > like salesman, you have this nice little widget, price tag is fine you > only need to explain to me how it improves the quality of my life. > For example if you are selling me objects you could say: > Haven't you noticed that some things always come together, like the > personal computer that is always consisted of monitor, box, keyboard > and mouse. Without objects you would always have to write monitor, > box, keyboard and mouse again and again objects allow you to group > them and just say personal computer. > Before: > monitor m, > box b, > keyboard k, > mouse m1 > repeated 100 times all over the program. > After > personal-computer pc; > > Or if you're in macros trade: > Have you noticed all that code that you write again and again macros > allows you to write that code for you and your programmers to use > their time on solving problems. > Before; > defclass ... () > ; boilerplate > some code > ; another boilerplate > > After > (defboilerplate-class some-code) > ; boilerplate and another boilerplate code are written by the macro > > So what's your commercial? BTW great example for tool usefulness is your Closer to MOP explanation: Tool vendor: You're using MOP? Me: Yes Tool vendor: Do you use it or plan to use it on different implementations? Me: Yes Tool vendor: Then you need a compatibility layer that rectifies many of the absent or incorrect MOP features across a broad range of Common Lisp implementations. Me: Bought.
From: Raffael Cavallaro on 5 Dec 2009 18:24 On 2009-12-05 17:52:27 -0500, Kenneth Tilton <kentilton(a)gmail.com> said: > Oh, good! You don't know what "sour grapes" means! I know perfectly, you're just having difficulty identifying the metaphorical grapes. They are, to spell it out in painful detail once again, writing a *publication quality* *well documented* *well received* extension to CLOS. Since you haven't done this, you're criticizing someone who *has* as performing "stupid CLOS tricks." This critique ("stupid CLOS tricks") of something you wish you had done (a *publication quality* *well documented* *well received* extension to CLOS) is crying "sour grapes." > > Meanwhile, I provided a thumbs-down analysis on the whole idea of GFs > to justify my assessment of an enhancement thereto, to which you > responded with irrelevant guesswork as to my motivation. I guess if you > have no defense of GFs to offer, that was a smart move. The only justification for any feature in an extensible language like lisp is whether or not it allows you to more easily shape the language to the way you think. I, Pascal, and others, find that GFs do precisely that by allowing individual logical clauses to be self contained textual entities. I (and presumably Pascal) do not think in giant cond expressions. GFs fit the way we think. No other "justification" is needed, your "thumbs-down analysis" notwithstanding. -- Raffael Cavallaro
From: Pascal Costanza on 5 Dec 2009 18:26 Slobodan Blazeski wrote: > On Dec 5, 4:28 pm, Pascal Costanza <p...(a)p-cos.net> wrote: >> Slobodan Blazeski wrote: >>> Any ideas where those would be useful? ContextL was interesting but I >>> never figured a natural problem where to use it. >> Did you check the paper? > I've read your paper, the interpreter code is very cool still it > doesn't answer my question. >> An extensible code walker could be a nice application. (That's like the >> interpreter, except that it doesn't interpret. ;) > I know a little bit about code walkers such us cl-cont but I'm not in > that business. I work on programs that model some processes, they work > continuously instead of getting some input and spewing some output. Is > there is some interesting problem that this tool solves for me? Think > like salesman, you have this nice little widget, price tag is fine you > only need to explain to me how it improves the quality of my life. I'm not in the selling business. If you think you can do something useful with this (like us who developed and actually use it) it's fine. If not, don't use it. 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 5 Dec 2009 18:40 In article <7o00puF3nuc41U1(a)mid.individual.net>, Pascal Costanza <pc(a)p-cos.net> wrote: > Ron Garret wrote: > > In article <7nvteeF3mopq6U1(a)mid.individual.net>, > > Pascal Costanza <pc(a)p-cos.net> wrote: > > > >> Ron Garret wrote: > >>> In article <7nvrpuF3nupc4U1(a)mid.individual.net>, > >>> Pascal Costanza <pc(a)p-cos.net> wrote: > >>> > >>>> Ron Garret wrote: > >>>>> In article <7ntfj7F3m9fjiU1(a)mid.individual.net>, > >>>>> Pascal Costanza <pc(a)p-cos.net> wrote: > >>>>> > >>>>>> Filtered functions are an extension of generic functions, extended > >>>>>> with > >>>>>> a filtering step where the arguments received by a generic function > >>>>>> are > >>>>>> mapped to other values based on user-defined mapping functions. Those > >>>>>> filtered values are then used to perform the actual selection and > >>>>>> execution of applicable methods. Nevertheless, the methods that are > >>>>>> eventually executed see the original objects as received by the > >>>>>> generic > >>>>>> function, and not the filtered ones. > >>>>> I like this concept, but is there a reason you designed the API the way > >>>>> you did instead of simply providing a facility for subclassing built-in > >>>>> classes? In other words, why not simply do: > >>>>> > >>>>> (def-subclass positive-integer integer 'plusp) > >>>>> > >>>>> (defmethod factorial ((n positive-integer)) ...) > >>>>> > >>>>> That would seem to me to provide the same functionality, and would make > >>>>> code using this feature easier to write and debug. > >>>> Maybe this would work for this particular example (but factorial is > >>>> really not that interesting now, is it? ;). > >>>> > >>>> Just check the other examples as well, I don't think you could solve > >>>> them that easily. > >>> Obviously factorial is not the definitive test case, but I'm pretty sure > >>> that the two APIs are formally equivalent. Is there a particular > >>> example that you think could not be easily rendered in terms of > >>> def-subclass? > >> Yes, the other two examples in the paper. Especially the interpreter, > >> but also the state example. I actually want to experiment with state > >> being dynamically scoped such that you can have behavior depend on > >> particular special variables. In conjunction with special slots in > >> ContextL this means that it should be possible to have context-dependent > >> object-specific behavior - something which is currently not possible > >> with ContextL. > >> > >> Maybe you can express such things with class hierarchies, but I don't > >> think that's convenient. > > > > Well, here's how I'd do it: > > > > (defun make-filter (key-function expected-result) > > (lambda (thing) (eq (funcall key-function thing) expected-result))) > > > > (def-subclass regular-stack stack (make-filter 'stack-state 'normal)) > > > > (def-subclass full-stack stack (make-filter 'stack-state 'full)) > > > > (def-subclass empty-stack stack (make-filter 'stack-state 'empty)) > > > > (defmethod stack-whatever ((stack regular-stack) ...) ...) > > (defmethod stack-whatever ((stack empty-stack) ...) ...) > > (defmethod stack-whatever ((stack full-stack) ...) ...) > > > > And the EVAL example: > > > > (defun make-form-type-checker (spec) > > (lambda (form) (eq (car form) spec))) > > > > (def-subclass quote-form cons (make-filter 'car 'quote)) > > (def-subclass lambda-form cons (make-filter 'car 'lambda)) > > etc... > > > > (defmethod eval ((form quote-form)) form) > > (defmethod eval ((form lambda-form)) (make-closure ...)) > > > > Seems pretty convenient to me. > > Can you provide a definition for def-subclass? Probably, though I might have to shadow defmethod and defgeneric. I do not posses your level of MOP guruness. But first things first: would you agree that def-subclass can do everything (or at least all the worthwhile things) that filtered functions can do and that the interface is cleaner? > Do you need to use change-class? When is change-class triggered? Do you mean: do I need to use change-class to implement def-subclass? I doubt it (but I have not read the paper in depth so I don't know how def-filtered-function is implemented yet). Or do you mean: do I as a user need to be able to call change-class on classes defined using def-subclass? The answer to that is: I sure hope not :-) rg
From: Madhu on 5 Dec 2009 18:53
* Pascal Costanza <7o08ggF3nkr1uU1(a)mid.individual.net> : Wrote on Sun, 06 Dec 2009 00:26:08 +0100: | I'm not in the selling business. Actually I think as you are an academic, you are in the business of selling your ideas, and you are precisely doing that, contrary claims notwithstanding -- Madhu |