[ANN] Filtered functions
Pascal Costanza
I am very excited that I can finally annouce a public release of
'filtered functions', an extension of generic functions that Charlotte
Herzeel, Jorge Vallejos, and myself have developed some time ago and
that we are very excited about because it seems to be quite powerful in
a number of very different scenarios. It took a while to release
filtered functions, because it is a quite non-trivial extension of
generic functions and requires a CLOS MOP implementation that is
compliant with the AMOP specification to quite a deep level. Therefore,
this required some serious preparation in the form of a much improved
Closer to MOP library, that I released today as well.
You can find filtered functions at the Closer project website at
http://common-lisp.net/project/closer/ - below you will find a general
overview of the concept.
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.
Here are some examples to illustrate the expressive power of filtered
functions.
Factorial
=========
In order to be able to use filtered functions, we need to have filter
functions that map received arguments to values that we actually want to
base our dispatch on. For the factorial function, we want to distinguish
between negative and positive numbers, and the number zero. For that we
can just use the Common Lisp function SIGNUM that returns +1 for
positive numbers, -1 for negative numbers, and just 0 for the number 0.
The filtered function FAC can thus be defined as follows.
(define-filtered-function fac (n)
(:filters (:sign #'signum)))
DEFINE-FILTERED-FUNCTION is exactly like DEFGENERIC, except that it can
also define one or more filters. Here, it defines a filter with the name
:SIGN wich specifices that the function SIGNUM is to be used for filtering.
We can now define methods for FAC:
(defmethod fac :filter :sign ((n (eql +1)))
(* n (fac (- n 1))))
(defmethod fac :filter :sign ((n (eql 0)))
1)
(defmethod fac :filter :sign ((n (eql -1)))
(error "Fac not defined for negative numbers."))
Here, we use the qualifiers :FILTER :SIGN in the method definitions to
indicate that we indeed want to use the :SIGN filter for method
selection. We then use EQL specializers to ensure that the method
definitions are applicable for the three different cases that SIGNUM
yields. Remember that the method bodies always see the original
arguments, not the filtered ones, and this is why the FAC methods can do
the correct computations.
State pattern
=============
Filtered functions can be used to dispatch methods based on the state of
an argument passed to a filtered function, which enables expressing
State-like idioms. Assume the following simple CLOS class is defined for
implementing a stack.
(defconstant +stack-size+ 10)
(defclass stack ()
((contents :initform (make-array +stack-size+)
:reader stack-contents))
(index :initform 0
:accessor stack-index)))
Instances of this class have three different states: Such a stack can
either be empty, or full, or anywhere in between (in 'normal' state). We
can express this as a function that recognizes the state of a stack.
(defun stack-state (stack)
(cond ((<= (stack-index stack) 0) 'empty)
((>= (stack-index stack) +stack-size+) 'full)
(t 'normal)))
It is now straightforward to use stack-state in a filter named :state
for the typical stack operations.
(define-filtered-function stack-push (stack value)
(:filters (:state #'stack-state)))
(define-filtered-function stack-pop (stack)
(:filters (:state #'stack-state)))
(define-filtered-function stack-emptyp (stack)
(:filters (:state #'stack-state)))
We can now group the behavior of a stack according to its different
states. Note that for 'normal' state, we do not need to mention the use
of any filter here, because the methods are not specialized on anything
specific anyway. (Filtered functions always allow for 'regular' methods
alongside the filtered methods.)
;;; Normal state
(defmethod stack-push (stack value)
(setf (aref (stack-contents stack)
(stack-index stack))
value)
(incf (stack-index stack)))
(defmethod stack-pop (stack)
(decf (stack-index stack))
(aref (stack-contents stack)
(stack-index stack)))
(defmethod stack-emptyp (stack)
nil)
;;; Empty state
(defmethod stack-pop :filter :state ((stack (eql 'empty)))
(error "Stack is empty."))
(defmethod stack-emptyp :filter :state ((stack (eql 'empty)))
t)
;;; Full state
(defmethod stack-push :filter :state ((stack (eql 'full)) value)
(error "Stack is full."))
Note that we used a derived state function here, that determines the
state of the stack based on some of its other properties. Since filter
functions can be any functions, we could also use the reader of a slot
as a filter function, and thus have the behavior of a filtered function
depend on the explicit state of an object.
Filtered functions can do a lot more: As already mentioned, they can use
more than one filter; filter functions can see all the arguments a
generic function receives; and filters can be guarded, which means that
methods that use a particular filter may be completely ignored if the
arguments don't fulfil a certain predicate. You can read the paper
"Filtered Dispatch" at http://p-cos.net/documents/filtered-dispatch.pdf
that I co-authored with Charlotte Herzeel, Jorge Vallejos and Theo
D'Hondt for a more thorough introduction, background information and
semantics, and which also includes an extensible metacircular Lisp
interpreter as an example, based on implementing EVAL as a filtered
function.
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/
Raffael Cavallaro
> I am very excited that I can finally annouce a public release of
> 'filtered functions'
This is excellent news! predicate dispatch portable across 6
implementations - amazing!
thanks for sharing this
--
Raffael Cavallaro
Pillsy
> I am very excited that I can finally annouce a public release of
> 'filtered functions', an extension of generic functions that Charlotte
> Herzeel, Jorge Vallejos, and myself have developed some time ago and
> that we are very excited about because it seems to be quite powerful in
> a number of very different scenarios.
This looks really impressive.
Cheers,
Pillsy
vanekl
Where did you read six? I thought his paper said it's only fully
implemented on one, SBCL.
Kenneth Tilton
What was wrong with COND? ie, Where is the productivity advantage of
chopping code up into methods? One starts with a step backward: the code
is now spread all over the map. The failure of OO to provide more than a
marginal boost to programming productivity exposed the absence of
emperor clothes in this case. ie, It is great fun to have different
parameters produce different results according to their type, it just
turned out not to solve any real problem with software development.
Taking that further just means even more spaghettish dispatch.
Filed under "Stupid CLOS Tricks".
kt
ps. Hoping you at least got a paper out of this. k
pps. Factorial as a use case? Plz tell me that was a joke. k
--
http://thelaughingstockatpngs.com/
http://www.facebook.com/pages/The-Laughingstock/115923141782?ref=nf
Slobodan Blazeski
> Hi,
>
> I am very excited that I can finally annouce a public release of
> 'filtered functions', an extension of generic functions that Charlotte
> Herzeel, Jorge Vallejos, and myself have developed some time ago and
> that we are very excited about because it seems to be quite powerful in
> a number of very different scenarios. It took a while to release
> filtered functions, because it is a quite non-trivial extension of
> generic functions and requires a CLOS MOP implementation that is
> compliant with the AMOP specification to quite a deep level. Therefore,
> this required some serious preparation in the form of a much improved
> Closer to MOP library, that I released today as well.
>
> that I co-authored with Charlotte Herzeel, Jorge Vallejos and Theo
> D'Hondt for a more thorough introduction, background information and
> semantics, and which also includes an extensible metacircular Lisp
> interpreter as an example, based on implementing EVAL as a filtered
> function.
>
> Pascal
never figured a natural problem where to use it.
Bobi
Pascal Costanza
Back when we published the paper, it ran indeed only on 1.5
implementations. ;) (SBCL, and to a certain extent LispWorks.)
I have put quite some effort into Closer to MOP to make this work well
in other implementations as well. Filtered functions now work on Allegro
Common Lisp, CLisp, Clozure Common Lisp, Embeddable Common Lisp,
LispWorks and SBCL.
It's still likely that the performance is not as good as it could be,
but I have some ideas for that...
Pascal Costanza
> 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?
An extensible code walker could be a nice application. (That's like the
interpreter, except that it doesn't interpret. ;)
Jim Newton also described a code walker as a motivation for a similar
extension of a CLOS-style object system he described earlier...
Pascal Costanza
> What was wrong with COND?
It's not extensible.
Kenneth Tilton
> Kenneth Tilton wrote:
>
>> What was wrong with COND?
>
> It's not extensible.
>
I was going to concede a good use case for even type-dispatched methods,
namely the draw method of GUI program, where one would not want to
have to pile all the code for drawing into one huge typecase, but then I
remembered what happened with my Cello GUI: without ever intending to, a
little data-driven hack for custom rendering of widget backgrounds grew
to the point where new widgets were created and their rendering
expressed entirely by the "background" list of rendering specs (the
"layers" slot for Cello fans).
And data-driven beats the crap out of type-driven code dispatch when it
comes to extensibility.
Ironically, GFs drag us away from data-orientation and into
code-orientation. Where lies object orientation? Lisp is cool in that
one can use objects without using GFs, while other object models lump
those together. The good news for other object models is that GFs offer
so little even as they come with a price of scattering one's code all
over the map, and object models can still use data-driven techniques.
data-driven will always win because this is Lisp where code can be data,
so stand back Argentina.
kt
Kenneth Tilton
Good Q. A more telling question would be, what natural problem were you
working on when you saw the need for this (and what alternative
solutions were considered, and why did this seem best). I am a little
suspicious of post hoc use cases to justify SPT (stupid pet tricks).
Cells arose as a solution to automatic layout of GUI elements. The
"layers" slot of Cello widgets arose as a way of customizing widget
backgrounds/decoration without forever adding more and more slots to the
base widget class (before taking over rendering almost entirely, and a
complete takeover is a logical next step should I ever resume Cello
development).
I am guessing they were not working on factorials when they spotted the
need for filtered dispatch.
Pascal Costanza
>
> I am guessing they were not working on factorials when they spotted the
> need for filtered dispatch.
>
Indeed.
Pascal Costanza
Do you realize that you're revolving only around yourself? Hint: Not
everything is a "GUI program".
We had a couple of good use cases for filtered functions, and were happy
with them to the extent that we wanted to make them available to others,
also because we have the strong gut feeling that it could be useful for
other purposes as well.
Yes, we got a paper out of it, but we could have left it at that,
without even releasing the implementation that ran on only 1.5 CL
implementations. Instead, we decided to invest some time to make it work
well on a broader range of implementations. If now other people pick it
up, that's good. If not, that's also fine.
Raffael Cavallaro
> Filed under "Stupid CLOS Tricks".
Kenny's rant filed under "sour grapes."
--
Raffael Cavallaro
Ron Garret
Pascal Costanza <p...@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.
rg
Kenneth Tilton
In your haste to go ugly/personal you missed that the origins cited were
only the origins. In fact, the application that broke Cells2 and forced
the data integrity of Cells3 was a Robocup client (text commands one
way, sensory data the other way, all encoded as sexpers and shunted over
a socket).
Meanwhile, the point of the origins cited was that there /were/ origins
other than a desire to do something clever or come up with a paper. The
latter is fine because we all have to eat and I understand fully that in
academia actual value is not required to make a good paper. You just
have to use TeX, IIUC.
We now return you to your regularly scheduled unpleasantness.
Kenneth Tilton
> On 2009-12-05 01:05:42 -0500, Kenneth Tilton <kent...@gmail.com> said:
>
>> Filed under "Stupid CLOS Tricks".
>
> Kenny's rant filed under "sour grapes."
Because you established somehow that I wished I had written Filtered
Functions? Or do you not know the term "sour grapes"?
God, I hope it's the latter.
kt
Pascal Costanza
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.
Raffael Cavallaro
> Because you established somehow that I wished I had written Filtered
> Functions? Or do you not know the term "sour grapes"?
Because I established through reading both Pascal's paper and the
documentation for cells, and by noting the underwhelming reception
cells has received over the years, that Pascal C. has written a very
useful, well documented, widely portable CLOS extension for which he
will be justly praised, and your CLOS extension, cells, uh, not so
much...
IOW, you don't wish that you had written filtered-functions, but rather
that cells were as well documented and well received as
filtered-functions will be.
Finally, if the two of you (i.e., Kenny and Pascal C.) can stop
bickering for a moment, you'd realize that a dataflow framework and a
predicate dispatch framework together (with a little macro syntactic
sugar) would allow completely declarative programming.
--
Raffael Cavallaro
Ron Garret
Pascal Costanza <p...@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <7ntfj7F...@mid.individual.net>,
> > Pascal Costanza <p...@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?
rg
Pascal Costanza
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. In fact, what ContextL already provides is
implemented by creating now class metaobjects on the fly internally, but
I don't you'd want to create the resulting hierarchy by hand.
I cannot prove at the moment that filtered functions are strictly more
convenient than manual class hierarchies, but please read on...
Pascal Costanza
>
> Finally, if the two of you (i.e., Kenny and Pascal C.) can stop
> bickering for a moment, you'd realize that a dataflow framework and a
> predicate dispatch framework together (with a little macro syntactic
> sugar) would allow completely declarative programming.
>
I'm curious: How do you see them used in combination?
Ron Garret
Pascal Costanza <p...@p-cos.net> wrote:
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.
rg
Pascal Costanza
Can you provide a definition for def-subclass?
Do you need to use change-class? When is change-class triggered?
Pascal Costanza
How does the factorial function know which def-subclass definitions to
take into account? Should it try all of them? A subset? Based on what
criteria? What does it do with the ones where the predicate fails (by
signaling an error)?
If several of the def-subclass forms apply, which one is selected? Are
they all selected? In what order? What is the most specific one, what is
the last specific one, and so on?
These are the typical issues you have to solve when designing
predicate-dispatch-style systems, and they are not trivial to solve
(basically because of the halting problem).
Filtered functions solve this by defining the acceptable filters along
with the filtered function definition, and by defining an order among
filters along the way that can be chosen per filtered function.
The idea to specify an order between custom filters (specializers) was
first described by Jim Newton, and is described in more detail in a
paper by Jim Newton and Christophe Rhodes. The difference between their
approach and ours is that in their approach, the order is defined at the
meta-level (as part of the MOP), whereas here it is defined at the
base-level (as part of the define-filtered-function form). I think the
latter is more convenient, since the orders tend to be ad hoc anyway, as
far as I can tell.
Having per-function orders seems to have been adopted by now in Clojure
as well.
Raffael Cavallaro
> I'm curious: How do you see them used in combination?
First, apologies if the parens or syntax are a bit off - I'm just
typing this into a newsreader, not a lisp editor.
I'm thinking of a language construct like "whenever"
(whenever :any foo (bar :newval-even (evenp newval))
(do-something-in-response ...))
;; where foo is a class, bar is a slot, and *my-foo*
;; is a particular instance of class foo.
;; the formal parameters newval, oldval,
;; and obj (i.e., self), would be available
;; in the whenever macro
(whenever :any foo (bar :newval-greater-than-3 (> newval 3)
(do-something-in-response ...))
(whenver *my-foo* (bar :oldval-even (evenp oldval))
(do-something-uniquely-my-foo-in-response))
This would be translated to something like:
(define-filtered-function
modify-bar-of-foo (obj newval oldval)
(:filters
(:bar-newval-even (when (evenp newval) t))
(:bar-oldval-even (when (evenp oldval) t))
(:bar-newval-greater-than-3 (when (> 3 newval) t))))
(defmethod modify-bar-of-foo :filter :bar-newval-even (obj newval oldval)
(do-something-in-response...))
...
(defmethod modify-bar-of-foo
:filter :bar-oldval-even ((obj (eql (*my-foo*))) newval oldval)
(do-something-uniquely-my-foo-in-response))
which would be updated with new :filters and defmethods for each such
rule added.
The function modify-bar-of-foo would be called by a cells-like dataflow
framework. Each time round, any slot modification would trigger the
corresponding modify-slot-of-class method, and that would be dipatched
on filtered values which were determined by the "whenever" rules.
By combining the two, (dataflow and predicate-dispatch) you would have
a purely declarative lisp dsl where you could program in "rules"
expressed as "whenever" clauses.
warmest regards,
Ralph
P.S. I know that something like this could be done in cells alone, and
that this is just a matter of surface syntax (i.e., the cells forms
would contain big case or cond expressions) but, when all is said and
done, in a lanaguage with minimal syntax like lisp, every mode of
expression is mostly just a matter of surface syntax...
--
Raffael Cavallaro
Slobodan Blazeski
> 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?
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. ;)
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?
>
> Jim Newton also described a code walker as a motivation for a similar
> extension of a CLOS-style object system he described earlier...
>
> 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/
(*)http://www.htdp.org/2003-09-26/Book/curriculum-Z-
H-6.html#node_chap_3
Raffael Cavallaro
<raffaelc...@pas.espam.s.il.vous.plait.mac.com> said:
> I'm thinking of a language construct like "whenever"
>
> (whenever :any foo (bar :newval-even (evenp newval))
> (do-something-in-response ...))
You could also add :priority which would be used to order the filter
specifications:
(whenever :any foo (bar :newval-even (evenp newval) :priority high)
(...))
--
Raffael Cavallaro
Kenneth Tilton
> On 2009-12-05 14:32:05 -0500, Kenneth Tilton <kent...@gmail.com> said:
>
>> Because you established somehow that I wished I had written Filtered
>> Functions? Or do you not know the term "sour grapes"?
>
OK, now let's see your hasty retreat:
>
> IOW, you don't wish that you had written filtered-functions, but rather
> that cells were as well documented and well received as
> filtered-functions will be.
Oh, good! You don't know what "sour grapes" means!
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.
Slobodan Blazeski
wrote:
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.
Raffael Cavallaro
> 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
Pascal Costanza
> On Dec 5, 4:28 pm, Pascal Costanza <p...@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.
Ron Garret
Pascal Costanza <p...@p-cos.net> wrote:
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
Madhu
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
Pascal Costanza
It may look cleaner (not sure about that), but I don't know how this
should work...
You seem to want to have a global space for defining potential filters,
and then somehow infer from the defined methods which of them are used
for a particular generic function. But that leaves the question open
which one is the most specific one if several of them apply.
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?
Ron Garret
Pascal Costanza <p...@p-cos.net> wrote:
> Ron Garret wrote:
> > In article <7ntfj7F...@mid.individual.net>,
> > Pascal Costanza <p...@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.
>
> How does the factorial function know which def-subclass definitions to
> take into account?
The same way it knows which methods to take into account. (Maybe I
don't understand the question.)
> Should it try all of them? A subset? Based on what criteria?
I'm not sure what you mean by "try" in this context. It should proceed
in the same way as any method application, by assembling a set of
applicable methods and combining them according to the appropriate
method combination. Implementing this efficiently could be tricky, but
I don't see why this should be at all problematic on a conceptual level.
> What does it do with the ones where the predicate fails (by
> signaling an error)?
Of course not. Why would you think that would even be a reasonable
possibility?
> If several of the def-subclass forms apply, which one is selected? Are
> they all selected? In what order? What is the most specific one, what is
> the last specific one, and so on?
I presume you mean something like this:
(def-subclass positive-integer 'integer 'plusp)
(def-subclass odd-integer 'integer 'oddp)
(defmethod m1 ((x positive-integer)) 'positive)
(defmethod m1 ((x odd-integer)) 'odd)
(m1 3) --> ???
This situation is completely analogous to:
(defclass c1 () ())
(defclass c2 () ())
(defclass c3 (c1 c2) ())
(defmethod m1 ((x c1)) 1)
(defmethod m1 ((c c2)) 2)
(m1 (make-instance 'c3)) --> ???
In the latter case the ambiguity is resolved because the superclasses of
C3 are listed in order. A similar solution could be applied to
sub-classes, i.e. a total order could be imposed on all sub-classes of a
given class. Exactly how this would be done is TBD, but surely you
don't dispute that it could be done this way?
> These are the typical issues you have to solve when designing
> predicate-dispatch-style systems, and they are not trivial to solve
> (basically because of the halting problem).
I don't see why. Certainly there are designs that would run afoul of
the halting problem, but I don't see that this is necessarily so. So
all you have to do is pick a design that doesn't, like imposing a total
order on all the subclasses of a given class, and then making the rest
of the design analogous to what already exists in CLOS.
> Filtered functions solve this by defining the acceptable filters along
> with the filtered function definition, and by defining an order among
> filters along the way that can be chosen per filtered function.
>
> The idea to specify an order between custom filters (specializers) was
> first described by Jim Newton, and is described in more detail in a
> paper by Jim Newton and Christophe Rhodes. The difference between their
> approach and ours is that in their approach, the order is defined at the
> meta-level (as part of the MOP), whereas here it is defined at the
> base-level (as part of the define-filtered-function form). I think the
> latter is more convenient, since the orders tend to be ad hoc anyway, as
> far as I can tell.
>
> Having per-function orders seems to have been adopted by now in Clojure
> as well.
I have still not had a chance to actually read your paper (and probably
won't until tomorrow at the earliest) so I may well be missing something
really important. But based on your responses so far I can't imagine
what that might be.
rg
Kenneth Tilton
> On 2009-12-05 17:52:27 -0500, Kenneth Tilton <kent...@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."
Sour grapes is about pooh-poohing something I cannot have. I can have
filtered functions*. QED.
Don't feel bad, your english is way better than my spanish.
* I would not blame Pascal for modifying the license to exclude me.
>> 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.
Oy, vey. The proof is in the pudding, aka the application, not some
abstract guess about "shaping". I have developed hundreds of application
KLOC with Cells during which (to my surprise) I honestly lost interest
in GFs as anything more than incrementally nice.
Sorry to keep dragging the discussion back to the value of GFs, I know
you want to make me feel bad about some unrelated software.
kt
Ron Garret
Ron Garret <rNOS...@flownet.com> wrote:
> > What does it do with the ones where the predicate fails (by
> > signaling an error)?
>
> Of course not. Why would you think that would even be a reasonable
> possibility?
Oops, I just realized I parsed that question completely wrong.
> I have still not had a chance to actually read your paper (and probably
> won't until tomorrow at the earliest) so I may well be missing something
> really important. But based on your responses so far I can't imagine
> what that might be.
I've now had a chance to skim the paper, and so I think I now understand
the motivation behind doing it the way you did.
FWIW, I still think I would personally prefer a dispatch system which
leaves it up to me (the programmer) to insure that the predicates I use
halt, don't raise errors, and have some kind of total ordering defined
on them. But I now see how a reasonable person could disagree, and how
filtered functions solve certain problems that dispatch has to either
punt on or fob off onto the programmer.
rg
Ron Garret
Pascal Costanza <p...@p-cos.net> wrote:
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.)
rg
Pascal Costanza
...but then it will end up as being more or less the same, except for
difference in surface syntax. That's not that interesting.
Pascal Costanza
> FWIW, I still think I would personally prefer a dispatch system which
> leaves it up to me (the programmer) to insure that the predicates I use
> halt, don't raise errors, and have some kind of total ordering defined
> on them.
Er. That's what you actually get with filtered functions.
Raffael Cavallaro
> Sour grapes is about pooh-poohing something I cannot have. I can have
> filtered functions*. QED.
What you can't have is *to be the author* of a *publication quality*
*well documented* *well received* extension to CLOS. That is what you
cannot have; that is what you are pooh-poohing.
Once again, I understand what "sour grapes" means perfectly. It is you
who are failing to understand what the metaphorical "grapes" are. Think
"publication," "acceptance," "approval," etc, not the thing being
published, accepted or approved. Your "critique" of filtered-functions
is just you saying "publication, or acceptance of a CLOS extension is
not worth having for it would be publication or acceptance of a mere
'sillly-clos-trick'." I.e., that which I, Ken Tilton cannot have,
acceptance of my clos extension, is not worth having. (a.k.a., "sour
grapes.")
Saying that being a rock star isn't all it's cracked up to be is sour
grapes. Saying that it isn't sour grapes because you can listen to an
mp3 of the Rolling Stones any time you like is just silly.
You can download and use filtered-functions any time you like. But that
will not make you the author of a publication-quality, well-documented,
well-received extension to CLOS.
>
> Don't feel bad, your english is way better than my spanish.
Not in any way relevant since I am a fourth generation (at least)
native speaker of english, and my surname, Cavallaro, is italian, not
spanish.
> Oy, vey. The proof is in the pudding, aka the application, not some
> abstract guess about "shaping". I have developed hundreds of
> application KLOC with Cells during which (to my surprise) I honestly
> lost interest in GFs as anything more than incrementally nice.
Good thing your personal taste/interest/analysis isn't binding on others.
>
> Sorry to keep dragging the discussion back to the value of GFs, I know
> you want to make me feel bad about some unrelated software.
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.
--
Raffael Cavallaro
Ron Garret
Pascal Costanza <p...@p-cos.net> wrote:
Um, yeah. That was kind of my point.
> That's not that interesting.
Well, interesting is in the eye of the beholder. But I believe I did
say early on in this discussion that the two approaches seemed
equivalent, and that it was just a question of API design; the
underlying functionality is the same.
Speaking only as a potential user, I find thinking about this in terms
of subclasses more intuitive than thinking about it in terms of filtered
functions. FWIW, YMMV and all that.
rg
Lars Rune Nøstdal
> ..
> 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. Also, I'm wondering if pcos has hit
this problem wrt. EQL-specialization and whether there might be some
way to work around this, or something. :)
--
Lars Rune Nøstdal
Juanjo
> > Pascal Costanza <p...@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".
Lars Rune Nøstdal
..or well, the problem does seem SBCL specific in that it does not
happen in CLISP.
Alessio Stalla
<raffaelcavall...@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
Lars Rune Nøstdal
> ..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..
Kenneth Tilton
> On 2009-12-05 19:18:30 -0500, Kenneth Tilton <kent...@gmail.com> said:
>
>> Sour grapes is about pooh-poohing something I cannot have. I can have
>> filtered functions*. QED.
>
> What you can't have is *to be the author* of a *publication quality*
> *well documented* *well received* extension to CLOS. That is what you
> cannot have; that is what you are pooh-poohing.
In situations like this you do much better by just conceding you misused
the phrase. Nothing wrong with that at all. The more you thrash about
trying to find some grapes the sillier you look. Case in point:
http://brianjosephdavis.files.wordpress.com/2009/05/rosemary_woods.jpg
>
> Once again, I understand what "sour grapes" means perfectly. It is you
> who are failing to understand what the metaphorical "grapes" are. Think
> "publication," "acceptance," "approval," etc, not the thing being
> published, accepted or approved. Your "critique" of filtered-functions
> is just you saying "publication, or acceptance of a CLOS extension is
> not worth having for it would be publication or acceptance of a mere
> 'sillly-clos-trick'." I.e., that which I, Ken Tilton cannot have,
> acceptance of my clos extension, is not worth having. (a.k.a., "sour
> grapes.")
http://www.alittleredhen.com/photos/uncategorized/2007/07/18/rose_mary_woods.jpg
>
> Saying that being a rock star isn't all it's cracked up to be is sour
> grapes. Saying that it isn't sour grapes because you can listen to an
> mp3 of the Rolling Stones any time you like is just silly.
>
> You can download and use filtered-functions any time you like. But that
> will not make you the author of a publication-quality, well-documented,
> well-received extension to CLOS.
>
>>
>> Don't feel bad, your english is way better than my spanish.
>
> Not in any way relevant since I am a fourth generation (at least) native
> speaker of english, and my surname, Cavallaro, is italian, not spanish.
Man, I thought you would at least get /that/ joke. We'll work on your
sense of humor as well.
> 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.
This thread is trying to discuss filtered functions. I appreciate all
the advertising for:
http://smuglispweeny.blogspot.com/2008/02/cells-manifesto.html
...but I really think you should take it to a new thread (where I will
crush you like a bug on the question of Cells's uptake).
kt
ps. Filtered functions have been well-received? It's been three days,
what are you babbling about? k
Pascal Costanza
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...
Kenneth Tilton
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
Kenneth Tilton
> On Dec 6, 4:06 am, Raffael Cavallaro
> <raffaelcavall...@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
Ron Garret
Pascal Costanza <p...@p-cos.net> wrote:
No worries. I mostly just wanted to get the idea on your radar screen.
rg
Pascal Costanza
None of this has anything to do with the topic of the thread, right?
Ron Garret
<e5e844ff-c527-4aba...@31g2000vbf.googlegroups.com>,
Juanjo <juanjose.g...@googlemail.com> wrote:
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
Lars Rune Nøstdal
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
Kenneth Tilton
Did you miss the part where Lars argued for GF dispatch as a good way to
handle variable on-click handling? This in reply to my bemoaning your
software's attempt to beat the GF horse even deader with f/fn?
Perhaps you are distracted by Raffy's insistence on deflecting this
worthy discussion into a debate over my motivation. What Raffy does not
know is that I just happen to be looking thru a bit of GF-heavy code and
am especially sensitive these days to the issue.
Poor guy. He does not know English, he does not know humor, he cannot
apply an analogy to save his life, and he does not know what I am
thinking. The latter may be a blessing, tho: it's not pretty in here.
Lars Rune Nøstdal
Whops, that should have been:
(defgeneric on-event (event widget &rest args)
(:method-combination progn :most-specific-last))
..so in that the order of output becomes:
A
B
BULK OP.
..and the not shown here "Cellsy" callbacks last.
Lars Rune Nøstdal
Actually, make that the way it was, then instead replace the "top
level" PROGN ON-EVENT method with:
(defmethod on-event :around (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)))
(call-next-method))
..giving the same updated output:
A
B
BULK OP.
This isn't very important for this particular example, but it might
make a bit more sense in that ON-EVENT methods will be handled in a
more natural order as a "category or group" of callbacks.
Kenneth Tilton
> 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. :)
Oh, for the love of G*d, please never do that again. Programming
solutions have more than a little to do with the problem being solved,
so don't offer problem X to ask about problem Y.
As for problem Y, your problem is meta-problem J: you have decided that
the solution involves GF method dispatch, witness your fallback now to
various method-combination hacks. Here is a Sacred Trick From Kenny:
when solution basis Q has you tied in knots, ask yourself how much Q is
helping. The best way to find other letters of the alphabet is to write
out your problem in a free-writing session and turn off your upper
cortex, see what your navel says. Sorry I cannot be less specific*.
kt
* I am reminded however (somewhat fascinatingly) of how that Cello
rendering got handled: data. Instead of a function or GF, a widget
specifies a list of rendering commands which get executed in that order.
End of problem. And this is what I mean by, f*ck Gfs, give me
data-driven programming. k
ps. Your case is like Prolog. You know in each case what you want to
happen and in what order, you just can't get it out of GFs without
ending up on Usenet pissing off Costanza by discussing something more
interesting than his paper. k
Pascal Costanza
As long as you're not missing anything, everything is fine, right?
Kenneth Tilton
Pascal Costanza
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?
Kenneth Tilton
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?
Pascal J. Bourguignon
> 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__
Pascal Costanza
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 Costanza
I think it's actually important that we do this, but it's true, not
everybody thinks so...
Ron Garret
Pascal Costanza <p...@p-cos.net> wrote:
Thanks! You are welcome to co-opt my phraseology :-)
rg
Kenneth Tilton
> Kenneth Tilton <kent...@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...
>
>
You wuss! C'mon, (declare (ignore.... wait... pwahahahhaah!!!... that's
it!! You dopes can't bring yourselves not to read me! I am like a
terrible traffic accident, we have to look!
I fell better now.
Raffael Cavallaro
> The more you thrash about trying to find some grapes the sillier you look.
Only in your head does your failure to understand a perfectly simple
metaphor make someone else look silly. Your attempted to misdirect
readers from your jealous spite of Pascal C. is weak.
You piss on Pascal's parade and pretend that it was some sort of
rational "anaysis" when called on your spite. What goes around, comes
around, Kenny. Oh, wait, you're a Buddhist - "karma's a bitch."
--
Raffael Cavallaro
Ron Garret
Kenneth Tilton <kent...@gmail.com> wrote:
> I am like a terrible traffic accident,
You got that right.
rg
Pascal Costanza
Otto: Apes don't read philosophy.
Wanda: Yes they do, Otto. They just don't understand it. Now let me
correct you on a couple of things, OK? Aristotle was not Belgian. The
central message of Buddhism is not "Every man for himself." And the
London Underground is not a political movement. Those are all mistakes,
Otto. I looked them up.
;)
Kenneth Tilton
No, no, no. Now you have to add something to my wisecrack.
I thought you wanted to be a writer!
Kenneth Tilton
That's better!
kt
Kenneth Tilton
Raffael Cavallaro wrote:
> On 2009-12-06 07:54:13 -0500, Kenneth Tilton <kent...@gmail.com> said:
>
>> The more you thrash about trying to find some grapes the sillier you
>> look.
>
> Only in your head does your failure to understand a perfectly simple
> metaphor make someone else look silly.
Look, you used it wrong, get over it. My joke about your English was
just a joke and you have now magnified your ignorance wonderfully. Your
mad search for grapes gone sour was fun, though.
> Your attempted to misdirect
> readers from your jealous spite of Pascal C. is weak.
And I hope you know sour grapes is not about jealousy. We won't argue
the merits of your jealousy charge, except to note that even if he turns
out a better version of dataflow than Cells I will not be jealous, I
will be happy because -- and here is your problem -- I really do take
software seriously, probably much more so than do you (since I seem to
take it more seriously than all but about 0.1% of you jerks).
>
> You piss on Pascal's parade and pretend that it was some sort of
> rational "anaysis" when called on your spite.
I have mentioned a couple of times and you are desperately ignoring that
not only have I lost interest in CLOS generally but I happen also to be
wrestling with some CLOS-intense code now so, sorry Charlie, my pissing
was bladder-felt. The fact that I got to torture Pascal at the same time
was just a bonus.
> What goes around, comes
> around, Kenny. Oh, wait, you're a Buddhist - "karma's a bitch."
>
It would seem that all the negative, hostile, vituperation is in your
heart. Pascal and I cross swords on c.l.l all the time and it is
eminently consensual. I do not know if you follow hockey, but you are
"the third man in". They really hate those.
Ron Garret
Kenneth Tilton <kent...@gmail.com> wrote:
> OK, now it's my turn.
>
> Raffael Cavallaro wrote:
> > On 2009-12-06 07:54:13 -0500, Kenneth Tilton <kent...@gmail.com> said:
> >
> >> The more you thrash about trying to find some grapes the sillier you
> >> look.
> >
> > Only in your head does your failure to understand a perfectly simple
> > metaphor make someone else look silly.
>
> Look, you used it wrong, get over it. My joke about your English was
> just a joke and you have now magnified your ignorance wonderfully. Your
> mad search for grapes gone sour was fun, though.
>
> > Your attempted to misdirect
> > readers from your jealous spite of Pascal C. is weak.
>
> And I hope you know sour grapes is not about jealousy.
Of course sour grapes is about jealousy:
http://www.google.com/dictionary?aq=f&langpair=en%7Cen&hl=en&q=jealousy
"Jealousy is the feeling of anger or BITTERNESS which someone has when
they wish that they could have the qualities or possessions that another
person has."
The first synonym listed is "envy".
http://en.wikipedia.org/wiki/Sour_grapes
"Sour grapes is an expression originating from the Aesop Fable The Fox
and the Grapes. It always refers to an unattainable goal and human
reaction to it. It can mean to deny desire for the unattainable item.
More often, it refers to the nature of humans to rationalize why they
wouldn't want it anyway. The phrase has come to be synonymous with
BITTERNESS in most modern contexts."
(Emphasis added.)
You must not have been paying attention in elementary school. That
would explain a lot.
rg
Kenneth Tilton
> In article <4b1f0e8f$0$4982$607e...@cv.net>,
> Kenneth Tilton <kent...@gmail.com> wrote:
>
>> OK, now it's my turn.
>>
>> Raffael Cavallaro wrote:
>>> On 2009-12-06 07:54:13 -0500, Kenneth Tilton <kent...@gmail.com> said:
>>>
>>>> The more you thrash about trying to find some grapes the sillier you
>>>> look.
>>> Only in your head does your failure to understand a perfectly simple
>>> metaphor make someone else look silly.
>> Look, you used it wrong, get over it. My joke about your English was
>> just a joke and you have now magnified your ignorance wonderfully. Your
>> mad search for grapes gone sour was fun, though.
>>
>>> Your attempted to misdirect
>>> readers from your jealous spite of Pascal C. is weak.
>> And I hope you know sour grapes is not about jealousy.
>
> Of course sour grapes is about jealousy:
Oh, goody! Let's try redefining the phrase!(But I thought you wanted to
be a writer!)...
>
> http://www.google.com/dictionary?aq=f&langpair=en%7Cen&hl=en&q=jealousy
>
> "Jealousy is the feeling of anger or BITTERNESS which someone has when
> they wish that they could have the qualities or possessions that another
> person has."
>
> The first synonym listed is "envy".
>
> http://en.wikipedia.org/wiki/Sour_grapes
>
> "Sour grapes is an expression originating from the Aesop Fable The Fox
> and the Grapes. It always refers to an unattainable goal and human
> reaction to it. It can mean to deny desire for the unattainable item.
> More often, it refers to the nature of humans to rationalize why they
> wouldn't want it anyway. The phrase has come to be synonymous with
> BITTERNESS in most modern contexts."
>
> (Emphasis added.)
"The phrase HAS COME TO BE..." emphasis added.
I think that is what I meant by "use it wrong" and "not know what it
means". As in, some day "nuclear" will come to be pronounced "nucular".
But language do change and I will cut Raffy some slack if we can find a
dictionary that accepts that new, looser meaning.
My OED still has just "resentful disparagement of something one cannot
personnally acquire". Google offers wordnet with "disparagement of
something that is unattainable" and the wiktionary as "A putting down or
expression of disdain about something that one desires but cannot have."
Over to you, oh grand twister of words! (You are the master.)
>
> You must not have been paying attention in elementary school. That
> would explain a lot.
You paid attention in school? Oh my.
Kenneth Tilton
More emphasis added: "It ALWAYS refers to an unattainable goal and human
reaction to it."
But what do you think about this?: "It CAN mean to deny desire for the
unattainable item." emphasis added. Only "can"? So I can fail to hit a
Mariano Rivera cutter and fall over laughing and it would be "sour
grapes"? Well, that is just plain wrong.
Looks like your only source has sour grapes over accuracy.
Try again?
kt
Ron Garret
Kenneth Tilton <kent...@gmail.com> wrote:
"... in most modern contexts."
If you want to live in the past be my guest. But you have no grounds
for saying that other people have got it wrong simply because they
follow contemporary usage. (And you certainly don't have grounds to be
snarky about it.)
rg
Raffael Cavallaro
> My OED still has just "resentful disparagement of something one cannot
> personnally acquire".
And, for the 5th time now, that which you, ken tilton, cannot
personally acquire is acceptance of *your* library, cells, as a
publication quality, well documented, extension to clos.
So when Pascal C. announces the release of a publication quality, well
documented, extension to clos, you disparage it as a "stupid clos
trick," i.e., being the author of an extension to clos is something not
worth having.
This is sour grapes - you disparage something you can't have -
acceptance of your clos extension by the lisp community - as something
not worth having.
Then you go on to repeated attempts at deflection by irrelevantly
criticising my use of the term "sour grapes." Anyting to distract from
your obvious motive for attacking Pascal C. - his clos extension is
publication quality, well documented, and will be well received, and
your clos extension is not.
--
Raffael Cavallaro
Nicolas Neuss
writes:
> On 2009-12-09 10:54:58 -0500, Kenneth Tilton <kent...@gmail.com> said:
>
>> My OED still has just "resentful disparagement of something one cannot
>> personnally acquire".
>
> And, for the 5th time now, that which you, ken tilton, cannot personally
> acquire is acceptance of *your* library, cells, as a publication quality,
> well documented, extension to clos.
>
> So when Pascal C. announces the release of a publication quality, well
> documented, extension to clos, you disparage it as a "stupid clos trick,"
> i.e., being the author of an extension to clos is something not worth
> having.
>
> This is sour grapes - you disparage something you can't have -
> acceptance of your clos extension by the lisp community - as something not
> worth having.
I don't think that that you are wrong, but please note:
1. In contrast to Kenny Tilton, Pascal Costanza is (as an academic,
arguably) paid for providing high-quality and well-documented code.
Thus, IMO this comparison is very unfair. Thanks to Ken for
providing Cells!
2. You omit that Ken may have a valid point in his rant. Although I
like CLOS very much, I am in doubt if it would not be more profitable
for me to learn using dataflow programming correctly (maybe even with
Cells) compared with learning yet another CLOS enhancement.
Nicolas
Kenneth Tilton
That's funny, you did not respond to the other post about your only
supporting source being clearly wrong on the phrase. Oh, wait...it's
Erann!!!
kt
Kenneth Tilton
Now where is that Rosemary Wood photo when I need it....
I denigrated defmethod-if*. I can have defmethod-if. QED.
I never denigrated something being well-documented, I never denigrated
something getting a lot of uptake. Oops. You missed that, right? Feel
the walls closing in?
Hey, how do you feel about Erann's attempt elsewhere to redefine the
phrase to mean "bitter"? The metaphor there is hitting the silk.
You, know, Raf, it is OK to use a phrase loosely. I was being silly
picking on your flawed application of sour grapes. The more important
thing is what a huge ass you are for telling someone else why they do
not like a software library.
If you think defmethod-if is a good idea, you should be able to defend
it on its merits, prolly by pointing out a good use-case for it. You
might even change my mind. We haven't heard a word of that. Curious.
Instead you attack me (based on guesswork) and then worry about other
people's karma. Hoo boy. So I sucked you down this silly flamehole. You
should stick to painting, your flame fu is no match for mine.
hth, kt
* Better name.
Pascal Costanza
Without noticing it yourself, you're actually hinting here at an
underlying issue: There is no opposition between (variations of)
dataflow programming approaches and (variations of) object-oriented
programming approaches. The only reason why there seems to be an
opposition is because Kenny always shoots at CLOS whenever possible, and
abuses unrelated threads to push his particular dataflow programming
approach to the fore. If he wouldn't do that, there would never be a
discussion whether "either" is better than the other, or any such nonsense.
I am offering filtered functions as a library, because people at my lab
and I myself found them useful in some contexts, and it seems that other
people find them useful as well. At least, I got a surprising number of
responses from people who want to try them.
If you want to use them, that's fine with me. If you don't want to use
them, that's also fine with me. I am not trying to advocate or sell
anything here.
What this has to do with Cells or dataflow programming is beyond me.
Kenneth Tilton
Yes, OO and CLOS in particular are excellent tools to have lying about
but not magic bullets like dataflow so give the latter a try, whether it
be with Cells or one of the many alternatives out there or one you write
yourself.
Dataflow's a blast. It even makes OO better, by delivering on the
promise of reuse. I happen to be playing these days with some software I
use to run the comedy open mic mentioned in my sig and am reminded again
how much damn fun is programming this way. The declarative thing utterly
rocks. Speaking of which, this guy is the latest to "discover" dataflow:
http://coherence-lang.org/Onward09.pdf
On a blog somewhere he whines about the cold reception that paper got
and quoted one of the peer reviewers as saying something to the effect
that manually managing the dataflow is not all that hard and
"programmers do it every day". The funny thing being the unspoken
questions: at what cost in time and drudgery, and how reliably? Suddenly
this reviewer is living in a universe where software development is
going just great.
But I understand the reviewer's problem. Programmers have indeed always
managed dataflow manually and, never having programmed using dataflow
(as is clearly the case with this reviewer), they have no idea how much
of their work goes into manual dataflow management.
Raffael Cavallaro
> I never denigrated something being well-documented, I never denigrated
> something getting a lot of uptake. Oops. You missed that, right? Feel
> the walls closing in?
So you never explicitly revealed your true motives for dumping on
Pascal. and? My whole point is that your true motives were *not* the
ones you gave. The fact that you chose to piss on his release
announcement for a well documented, publication quality, extension to
clos says everything.
> Instead you attack me (based on guesswork) and then worry about other
> people's karma. Hoo boy. So I sucked you down this silly flamehole. You
> should stick to painting, your flame fu is no match for mine.
Born and bred in the briar patch, oh faux-zen-master kenzo. Instead of
letting go, you've restarted a discussion where your spitefulness is
broadcast over and over. Well if anyone missed it, you're sure to show
them again and again by keeping this thread going. You're providing
yourself a karmic lesson, not me.
Here's a crazy idea - why not just apologise to Pascal C. for wizzing
on his parade. Isn't that what the compassionate Buddha would do?
--
Raffael Cavallaro
Pascal Costanza
Note how Kenny posts a whole article about dataflow programming under a
subject about filtered functions, while he could have opened a new
thread as well.
Nicolas Neuss
Please note: I am no idiot and noticed that myself.
> only reason why there seems to be an opposition is because Kenny
> always shoots at CLOS whenever possible, and abuses unrelated threads
> to push his particular dataflow programming approach to the fore. If
> he wouldn't do that, there would never be a discussion whether
> "either" is better than the other, or any such nonsense.
>
> I am offering filtered functions as a library, because people at my
> lab and I myself found them useful in some contexts, and it seems that
> other people find them useful as well. At least, I got a surprising
> number of responses from people who want to try them.
>
> If you want to use them, that's fine with me. If you don't want to use
> them, that's also fine with me. I am not trying to advocate or sell
> anything here.
Yes, thank you very much also for your many contributions as CloserMOP,
ContextL and filtered functions. I have noted those, and hope to
remember them when I need it.
> What this has to do with Cells or dataflow programming is beyond me.
Please note, that it was not me who started to compare Kenny Tilton's
with your contributions. You should have replied in this sense
immediately to Raffael.
Nicolas
Pascal Costanza
It wasn't obvious from your posting that you noticed this yourself. It
gave a different appearance. (Of course, I _don't_ think you're an
idiot, and I am sorry if my post suggested otherwise.)
>> What this has to do with Cells or dataflow programming is beyond me.
>
> Please note, that it was not me who started to compare Kenny Tilton's
> with your contributions. You should have replied in this sense
> immediately to Raffael.
It wasn't Raffael either, it was actually Kenny who started this kind of
nonsensical comparison (once again). Both Raffael and I replied in this
sense to Kenny. It's Kenny who cannot deal with the consequences of his
inappropriate postings. (Raffael actually didn't only avoid to create a
competition between dataflow programming and filtered functions, but
even tried to point out a potential synergy between the two.)
Kenneth Tilton
> Note how Kenny posts a whole article about dataflow programming under a
> subject about filtered functions, while he could have opened a new
> thread as well.
Note that I changed the subject to Raffy's Karma. Damn, all those
degrees and you can't read? Did you go to an American school?
kt
Nicolas Neuss
> Pascal Costanza <p...@p-cos.net> writes:
>
>> On 10/12/2009 10:00, Nicolas Neuss wrote:
[...]
>>> 2. You omit that Ken may have a valid point in his rant. Although I
>>> like CLOS very much, I am in doubt if it would not be more profitable
>>> for me to learn using dataflow programming correctly (maybe even with
>>> Cells) compared with learning yet another CLOS enhancement.
>>
>> Without noticing it yourself, you're actually hinting here at an
>> underlying issue: There is no opposition between (variations of)
>> dataflow programming approaches and (variations of) object-oriented
>> programming approaches.
>
> Please note: I am no idiot and noticed that myself.
To clarify:
It is obvious that dataflow and OO are not really antagonistic - even Cells
is a CLOS extension!
I think the valid point in Kenny's rant is the following:
There are several important programming paradigms which are rather
imperfectly(!) represented in CL at the moment. Examples are dataflow,
parallel programming, and maybe type-safe programming which exists only
in a form which is not standard CL (Qi).
In contrast, I consider the OO paradigm to be represented very well in
CL (at least in comparison with other languages' OO). Now, since FF is
an extension in the OO direction it draws attention from other places
where work might be much more urgent.
Nicols
Kenneth Tilton
[Oh, good! You are catching on to the game!]
Going back, this says it all:
> So you never explicitly revealed your true motives for dumping on
> Pascal.
I feel a naggum coming on. There was no attack on Pascal, but you saw one:
"What was wrong with COND? ie, Where is the productivity advantage of
chopping code up into methods? One starts with a step backward: the code
is now spread all over the map. The failure of OO to provide more than a
marginal boost to programming productivity exposed the absence of
emperor clothes in this case. ie, It is great fun to have different
parameters produce different results according to their type, it just
turned out not to solve any real problem with software development.
Taking that further just means even more spaghettish dispatch.
Filed under \"Stupid CLOS Tricks\"."
Wow, a dead serious criticism of the library and only on grounds related
to programming power, not the library itself which I am sure is
technically sound.
Looks like Raffy's Karma needs a time out.
kt
Raffael Cavallaro
> here was no attack on Pascal, but you saw one:
There was; *everyone* saw it.
Pascal C. took the effort to do this and share it with everyone:
1. extend CLOS generic functions to dispatch on arbitrary predicates
2. Provide publication quality documentation
3. make it portable across 6 implementations
You called it a "stupid CLOS trick."
That is an attack.
--
Raffael Cavallaro
Kenneth Tilton
> It's Kenny who cannot deal with the consequences of his
> inappropriate postings.
<sob> Yes, I am tormented by having caused a Usenet thread to branch,
<sniffle><honk> by having made a comparison. <sob>
I haven't had this much fun in a while on c.l.l, tho I must say it is
getting a little old not getting any support on the cleverness side from
my antagonists.
Where's that famous Italian sense of humor?
Kenneth Tilton
> On 2009-12-10 11:21:46 -0500, Kenneth Tilton <kent...@gmail.com> said:
>
>> here was no attack on Pascal, but you saw one:
>
> There was; *everyone* saw it.
Talk about hand-waving! The seriousness (and accuracy) of my critique
puts the lie to that guesswork, regardless how many shared it with you.
Speaking of which, at long last don't you have one word to say to answer
the critique about defmethod-if offering no more than spaghetti-ish
code? Not one?
The sad thing is how you have blown this up into something personal when
you could have talked about programming and CLOS.
>
> Pascal C. took the effort to do this and share it with everyone:
>
> 1. extend CLOS generic functions to dispatch on arbitrary predicates
> 2. Provide publication quality documentation
> 3. make it portable across 6 implementations
>
> You called it a "stupid CLOS trick."
>
> That is an attack.
Interesting that you tried getting away with an implied object to that
transitive verb, when the object is the question at hand. Here, let me
help: it was an attack on the idea of defmethod-if.
Should I post it again?
vippstar
<raffaelcavall...@pas.espam.s.il.vous.plait.mac.com> wrote:
> Pascal C. took the effort to do this and share it with everyone:
>
>
> That is an attack.
That is a stupid trolling trick.
Ron Garret
Kenneth Tilton <kent...@gmail.com> wrote:
> Dataflow's a blast. It even makes OO better, by delivering on the
> promise of reuse.
If that were true it would be a major breakthrough. Do you have any
evidence to support this claim?
rg
Kenneth Tilton
Pretty much. As I said elsewhere, my critique was bladderfelt*, the
chance to torture Pascal just a bonus and a payback he had to expect
after publicly saying Cells was so bad he "would not trust it". In fact,
his saying the latter at a time when I had him in my killfile for his
own protection made it clear that au contraire he wanted to play.
So I wrote a serious critique and then threw in a dig just to liven
things up and hopefully provoke a stupid thread about grapes. Raffy was
a champ in that regard.
Pascal Costanza
> Pascal Costanza wrote:
>> Note how Kenny posts a whole article about dataflow programming under
>> a subject about filtered functions, while he could have opened a new
>> thread as well.
>
> Note that I changed the subject to Raffy's Karma.
Sure. Why did dataflow programming enter this thread again in the first
place?
Pascal Costanza
> Nicolas Neuss<last...@math.uni-karlsruhe.de> writes:
>
>> Pascal Costanza<p...@p-cos.net> writes:
>>
>>> On 10/12/2009 10:00, Nicolas Neuss wrote:
> [...]
>>>> 2. You omit that Ken may have a valid point in his rant. Although I
>>>> like CLOS very much, I am in doubt if it would not be more profitable
>>>> for me to learn using dataflow programming correctly (maybe even with
>>>> Cells) compared with learning yet another CLOS enhancement.
>>>
>>> Without noticing it yourself, you're actually hinting here at an
>>> underlying issue: There is no opposition between (variations of)
>>> dataflow programming approaches and (variations of) object-oriented
>>> programming approaches.
>>
>> Please note: I am no idiot and noticed that myself.
>
> To clarify:
>
> It is obvious that dataflow and OO are not really antagonistic - even Cells
> is a CLOS extension!
>
> I think the valid point in Kenny's rant is the following:
>
> There are several important programming paradigms which are rather
> imperfectly(!) represented in CL at the moment. Examples are dataflow,
> parallel programming, and maybe type-safe programming which exists only
> in a form which is not standard CL (Qi).
[Parallel programming is actually starting to look good for Common Lisp...]
> In contrast, I consider the OO paradigm to be represented very well in
> CL (at least in comparison with other languages' OO). Now, since FF is
> an extension in the OO direction it draws attention from other places
> where work might be much more urgent.
Different people have different priorities. I'm quite happy about the
fact that they are not forced to work on things they don't want to work
on. I don't think why they should.
Lisp is about freedom in expression and programming style. Live and let
live, and all that.
[I think Kenny's rant was much stronger than what you make of it, by the
way.]