From: Slobodan Blazeski on
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
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
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
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
* 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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Prev: [ANN] Filtered functions
Next: Filtered functions.