Does anyone -- probably one of the "I was there" people -- know why
only specializing on EQL is allowed?
For example, it would be nice to be able to specialize on, say, a less
than relation.
Or even better, specializing on specific list elements:
(defmethod eat ((eql (car food-chain) 'SHARK)))
I wonder whether this was due to complexity or performance reasons.
Leslie
Leslie P. Polzer wrote:
> Does anyone -- probably one of the "I was there" people -- know why
> only specializing on EQL is allowed?
>
> For example, it would be nice to be able to specialize on, say, a less
> than relation.
>
> Or even better, specializing on specific list elements:
>
> (defmethod eat ((eql (car food-chain) 'SHARK)))
>
> I wonder whether this was due to complexity or performance reasons.
You might have the wrong question. Mine would be why you would want
generic dispatch to do such a thing. My answer would be that you have
fallen in love with the mechanism, and now want to use it for everything
in sight.
I wonder if I am turning into a Schemer.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On 28 Dez., 21:49, Ken Tilton <···········@optonline.net> wrote:
> You might have the wrong question. Mine would be why you would want
> generic dispatch to do such a thing. My answer would be that you have
> fallen in love with the mechanism, and now want to use it for everything
> in sight.
I think my proposal has its place, within certain limits.
And the reflection on your identity probably has its place as well :)
Leslie P. Polzer wrote:
> On 28 Dez., 21:49, Ken Tilton <···········@optonline.net> wrote:
>
>
>>You might have the wrong question. Mine would be why you would want
>>generic dispatch to do such a thing. My answer would be that you have
>>fallen in love with the mechanism, and now want to use it for everything
>>in sight.
>
>
> I think my proposal has its place, within certain limits.
The question remains, why do you think gf dispatch is now the only way
CL could handle the general problem of dispatch, such that rather than
just get on with it and handle this kind of dispatch some other way you
feel compelled to squeeze it out of GF dispatch. I am reminded of the
everything-is-an-object or everything-is-a-constraint or
everything-is-a-logic-rule category of error. Language mechanics somehow
begin to wag the dog, and all is lost.
> And the reflection on your identity probably has its place as well :)
I am ripping out CLOS and defstruct as we speak.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Dec 28, 11:06 pm, Ken Tilton <···········@optonline.net> wrote:
> The question remains, why do you think gf dispatch is now the only way
> CL could handle the general problem of dispatch, such that rather than
> just get on with it and handle this kind of dispatch some other way you
> feel compelled to squeeze it out of GF dispatch. I am reminded of the
> everything-is-an-object or everything-is-a-constraint or
> everything-is-a-logic-rule category of error. Language mechanics somehow
> begin to wag the dog, and all is lost.
The guardian of the inner sanctum is exaggerating, as usual. I wasn't
saying "I don't know how to solve this any other way." but "I'd like
to know whether I could solve it that way.".
;) Leslie
Leslie P. Polzer wrote:
> On Dec 28, 11:06 pm, Ken Tilton <···········@optonline.net> wrote:
>
>
>>The question remains, why do you think gf dispatch is now the only way
>>CL could handle the general problem of dispatch, such that rather than
>>just get on with it and handle this kind of dispatch some other way you
>>feel compelled to squeeze it out of GF dispatch. I am reminded of the
>>everything-is-an-object or everything-is-a-constraint or
>>everything-is-a-logic-rule category of error. Language mechanics somehow
>>begin to wag the dog, and all is lost.
>
>
> The guardian of the inner sanctum is exaggerating, as usual. I wasn't
> saying "I don't know how to solve this any other way." but "I'd like
> to know whether I could solve it that way.".
Possibly a language barrier? To think that something is the only way
does not mean one thinks there is no other way, it means one thinks it
is the best way, by such a margin that it is the prohibitive choice and
can effectively be considered "the only way", or at least "only" is used
hyperbolically to suggest how great the superiority. eg, "The only way
to fly", a trademark of Western Airlines, did not mean there were no
other airlines.
Sadly, you leave unanswered the vital question: how did GF dispatch
become your only branching mechanism? IF, COND, CASE.. right out the
window! First-class functions? Rip 'em out, or at least limit them to
the specializer of a method!
You might be looking for Cells. Cells let one go beyond types to
instances and arbitrary code in compartmentalizing functionality.
Maybe it is time the group heard your use case?
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Dec 29, 3:17 pm, Ken Tilton <···········@optonline.net> wrote:
> Sadly, you leave unanswered the vital question: how did GF dispatch
> become your only branching mechanism? IF, COND, CASE.. right out the
> window! First-class functions? Rip 'em out, or at least limit them to
> the specializer of a method!
Seems like you asked the right question here.
I'm using the Weblocks framework with my project, and it lets one
specialize its rendering by dispatching on CLOS slot types.
So this is how I got pushed into that corner ;)
IIRC I had several slots of type CONS in my model and wanted to
dispatch on something like (typep (car slot) 'foo).
But the problem is already solved, since I can specialize on the slot
name as well.
In fact, I wasn't desperate or anything. I was just curious to know
whether and why the dispatch mechanism has those limits.
Leslie
Ken Tilton <···········@optonline.net> writes:
> You might have the wrong question. Mine would be why you would want
> generic dispatch to do such a thing. My answer would be that you have
> fallen in love with the mechanism, and now want to use it for
> everything in sight.
The very experience of learning CLOS quickly results in unrealistic
expectations. People learn the basics, start using CLOS for practical
things, and eventually run into a situation where they want to do
something special. They search a little, and find to their delight
that they can extend/customize CLOS with fairly little effort to do
exactly what they want. Rinse and repeat, a number of times.
Sooner or later they run into an aspect of CLOS that cannot be easily
customized (of course this happens later rather than sooner because
MOP addresses most things people want to do). At that point the idea
that CLOS cannot be bent to the will of the programmer is impossible
to swallow. So people try to put square pegs through round holes (and
often succeed).
Once you let us customize class composition and discriminating
functions, can you really blame us for wanting ML-style pattern
matching in method specializers? :)
--
Regards,
Slava Akhmechet.
Slava Akhmechet wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>You might have the wrong question. Mine would be why you would want
>>generic dispatch to do such a thing. My answer would be that you have
>>fallen in love with the mechanism, and now want to use it for
>>everything in sight.
>
> The very experience of learning CLOS quickly results in unrealistic
> expectations. People learn the basics, start using CLOS for practical
> things, and eventually run into a situation where they want to do
> something special.
Like someone just learning to play the piano who falls in love with D
minor, the saddest of all keys, and wants to play nothing else. This we
call a disease, as in to be cured.
> They search a little, and find to their delight
> that they can extend/customize CLOS with fairly little effort to do
> exactly what they want. Rinse and repeat, a number of times.
That is the disease. We call it lock-in, as in, oh, crap this is the
first thing I thought of, I must make it work, I must not think of
anything else, no matter how many ways there are to solve this problem
with a big ball of mud.
>
> Sooner or later they run into an aspect of CLOS that cannot be easily
> customized (of course this happens later rather than sooner because
> MOP addresses most things people want to do). At that point the idea
> that CLOS cannot be bent to the will of the programmer is impossible
> to swallow. So people try to put square pegs through round holes (and
> often succeed).
Encouraged and supported by the Syntax-Obsessed Bots of c.l.l
>
> Once you let us customize class composition and discriminating
> functions, can you really blame us for wanting ML-style pattern
> matching in method specializers? :)
For discovering a language with a thousand-page spec and then obsessing
over feature X like some moth beating its head against the first bright
bulb it finds until it gets fried to a crisp? I think I just did.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton <···········@optonline.net> writes:
> Like someone just learning to play the piano who falls in love with D
> minor, the saddest of all keys, and wants to play nothing else. This
> we call a disease, as in to be cured.
Not a natural part of a learning process?
--
Regards,
Slava Akhmechet.
Slava Akhmechet wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>Like someone just learning to play the piano who falls in love with D
>>minor, the saddest of all keys, and wants to play nothing else. This
>>we call a disease, as in to be cured.
>
> Not a natural part of a learning process?
>
Non sequitor. A natural part of a learning process /is/ getting stuck in
false minima, and indeed one of the biggest contributions of a coach is
spotting and, um, curing these blocks.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton wrote:
>
>
> Slava Akhmechet wrote:
>> Ken Tilton <···········@optonline.net> writes:
>>
>>
>>> Like someone just learning to play the piano who falls in love with D
>>> minor, the saddest of all keys, and wants to play nothing else. This
>>> we call a disease, as in to be cured.
>>
>> Not a natural part of a learning process?
>>
>
> Non sequitor. A natural part of a learning process /is/ getting stuck in
> false minima, and indeed one of the biggest contributions of a coach is
> spotting and, um, curing these blocks.
What if the coach is wrong? Or is that blasphemy?
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/
Pascal Costanza <··@p-cos.net> wrote:
> Ken Tilton wrote:
> >
> >
> > Slava Akhmechet wrote:
> >> Ken Tilton <···········@optonline.net> writes:
> >>
> >>
> >>> Like someone just learning to play the piano who falls in love with D
> >>> minor, the saddest of all keys, and wants to play nothing else. This
> >>> we call a disease, as in to be cured.
> >>
> >> Not a natural part of a learning process?
> >>
> >
> > Non sequitor. A natural part of a learning process /is/ getting stuck in
> > false minima, and indeed one of the biggest contributions of a coach is
> > spotting and, um, curing these blocks.
>
> What if the coach is wrong? Or is that blasphemy?
>
The trick is in knowing how to know that the coach is wrong.
Bob Felts wrote:
> Pascal Costanza <··@p-cos.net> wrote:
>
>
>>Ken Tilton wrote:
>>
>>>
>>>Slava Akhmechet wrote:
>>>
>>>>Ken Tilton <···········@optonline.net> writes:
>>>>
>>>>
>>>>
>>>>>Like someone just learning to play the piano who falls in love with D
>>>>>minor, the saddest of all keys, and wants to play nothing else. This
>>>>>we call a disease, as in to be cured.
>>>>
>>>>Not a natural part of a learning process?
>>>>
>>>
>>>Non sequitor. A natural part of a learning process /is/ getting stuck in
>>>false minima, and indeed one of the biggest contributions of a coach is
>>>spotting and, um, curing these blocks.
>>
>>What if the coach is wrong? Or is that blasphemy?
It is not clear that the poster boy for CLOS obsession can offer much
when CLOS obsession itself is the topic. Write applications (if you know
what they are and/or can think of one to write) for a year without the
CLOS package and get back to us.
Meanwhile, I am amused to recall that deftype accepts arbitrary forms,
and typecase branches on these types even if GF method specialization
will not, so the OPs RFE was not all that whacky. Maybe it /did/ come
down to the issue of coming up with an ordering, as someone else pointed
out.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton <·········@gmail.com> wrote:
+---------------
| Slava Akhmechet wrote:
| > Ken Tilton <···········@optonline.net> writes:
| >>Like someone just learning to play the piano who falls in love with D
| >>minor, the saddest of all keys, and wants to play nothing else. This
| >>we call a disease, as in to be cured.
| >
| > Not a natural part of a learning process?
|
| Non sequitor. A natural part of a learning process /is/ getting stuck in
| false minima, and indeed one of the biggest contributions of a coach is
| spotting and, um, curing these blocks.
+---------------
An even better coach is one who teaches you to recognize for yourself
when you're blocked, when you're looping, when you're thrashing[1], or
when you're self-deadlocked. Once one has learned this, then one can
recognize such situations and "uplevel" oneself to a higher level of
abstraction/cognition when such a problem arises.
-Rob
[1] Which used to be called "pink scheduling" on the DEC PDP-10,
because it made the Interrupt Service Level 7 light bulb
glow a constant pink. [Level 7 was where the scheduler ran.]
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Fri, 28 Dec 2007 12:28:12 -0800 (PST), "Leslie P. Polzer" <·············@gmx.net> wrote:
> Does anyone -- probably one of the "I was there" people -- know why
> only specializing on EQL is allowed?
>
> For example, it would be nice to be able to specialize on, say, a
> less than relation.
AFAIU, SBCL can do that:
http://www.doc.gold.ac.uk/~mas01cr/papers/ecoop2007/abstract.pdf
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On Fri, 28 Dec 2007 12:28:12 -0800 (PST), "Leslie P. Polzer" <·············@gmx.net> wrote:
>
> > Does anyone -- probably one of the "I was there" people -- know why
> > only specializing on EQL is allowed?
> >
> > For example, it would be nice to be able to specialize on, say, a
> > less than relation.
>
> AFAIU, SBCL can do that:
>
> http://www.doc.gold.ac.uk/~mas01cr/papers/ecoop2007/abstract.pdf
While SBCL does allow defining new CLOS specializers, it's probably
not for the faint of heart.
Basically it's very hard to define a new specializer that's an equal
citizen to the standard ones, without copy-pasting large chunks of PCL
internals. The exact protocols needed to make user-defined specializer
really useful (e.g. for somehow hooking into the existing
discriminating function framework) are still an area of research.
--
Juho Snellman
From: Richard M Kreuter
Subject: Re: RFC: Extending method specializers
Date:
Message-ID: <87tzm24847.fsf@progn.net>
"Leslie P. Polzer" <·············@gmx.net> writes:
> Does anyone -- probably one of the "I was there" people -- know why
> only specializing on EQL is allowed?
There's discussion of this in "CLOS in Context: The Shape of the
Design Space".
http://www.dreamsongs.com/Files/clos-book.pdf
> For example, it would be nice to be able to specialize on, say, a less
> than relation.
>
> Or even better, specializing on specific list elements:
>
> (defmethod eat ((eql (car food-chain) 'SHARK)))
>
> I wonder whether this was due to complexity or performance reasons.
Also semantic reasons. The CLOS class hierarchy has constraints that
ensure a well-ordering of classes, so that if there are any methods,
there's always a most-specific method. But arbitrary predicates
aren't well-orderings; for example, how would you order the
specificity of a trio of methods that called CAR, CADR, CADDR on a
list argument? Further, can such methods call CALL-NEXT-METHOD, and
if so, what method gets run? Can you also add methods that have EQL
specializers on the elements of vectors? If so, what are the
semantics of a generic function with specializers some of which call
CAR (which works only on conses and NIL), some of which call ELT
(which can apply to a list or a vector), some of which call AREF
(which works only on arrays)?
I don't think there can't be useful answers to such questions for
specific problems, but I'd bet that specializers of this sort would
require custom method combinations in practically every case.
--
RmK
On Dec 29, 2:12 am, Richard M Kreuter <·······@progn.net> wrote:
> There's discussion of this in "CLOS in Context: The Shape of the
> Design Space".
>
> http://www.dreamsongs.com/Files/clos-book.pdf
I need to read that real soon.
> Also semantic reasons. The CLOS class hierarchy has constraints that
> ensure a well-ordering of classes, so that if there are any methods,
> there's always a most-specific method. But arbitrary predicates
> aren't well-orderings; for example, how would you order the
> specificity of a trio of methods that called CAR, CADR, CADDR on a
> list argument? Further, can such methods call CALL-NEXT-METHOD, and
> if so, what method gets run? Can you also add methods that have EQL
> specializers on the elements of vectors?
That's a very good argument. I don't think I could come up with a
sensible way to do this, either. Thanks, Richard.
Leslie
Leslie P. Polzer wrote:
> Does anyone -- probably one of the "I was there" people -- know why
> only specializing on EQL is allowed?
>
> For example, it would be nice to be able to specialize on, say, a less
> than relation.
>
> Or even better, specializing on specific list elements:
>
> (defmethod eat ((eql (car food-chain) 'SHARK)))
>
> I wonder whether this was due to complexity or performance reasons.
>
> Leslie
What happens if more than one of those predicates turns
out to be true? How would it pick?
I was not in the inner circle of CLOS design but I would
guess that you just have to draw the line somewhere, and
avoid complexity of the sort that my above paragraph
represents. There are probably even deeper issues that
I have not thought of, I bet.
Leslie P. Polzer wrote:
> Does anyone -- probably one of the "I was there" people -- know why
> only specializing on EQL is allowed?
>
> For example, it would be nice to be able to specialize on, say, a less
> than relation.
>
> Or even better, specializing on specific list elements:
>
> (defmethod eat ((eql (car food-chain) 'SHARK)))
>
> I wonder whether this was due to complexity or performance reasons.
Complexity, like in "yes it's possible, if you first solve the halting
problem." ;)
Method dispatch can be understood as predicate dispatch, and CLOS
defines two predicates for method dispatch from the start, the
predicates the instance test and the eql test.
To better understand this, let's assume that you had to write methods
like this:
(defmethod foo ((x (typep integer)) (y (eql 0))) ...)
The idea is that this method applies when x is of type integer and y is
eql to 0. In CLOS it's actually written like this:
(defmethod foo ((x integer) (y (eql 0))) ...)
...but the semantics are the same.
What you're asking is: Why not allow other predicates there, like:
(defmethod foo ((x (primep)) (y (oddp)) (z (member 2 3 4))) ...)
...and so on.
The question is: How do we order applicable methods, when more than one
method is applicable? When you have a class hierarchy, that's easy to
answer - the most specific class determines the most specific method,
and the most specific method is the method that is executed (first).
Likewise, for eql specializers: They are defined on single objects,
which are always considered more specific than the classes which they
are instances of. This gives you a natural ordering.
However, what about this?
(defmethod bar ((x (primep))) ...)
(defmethod bar ((x (oddp))) ...)
If you call (bar 3), both methods match. So which one is the most
specific one? It's not possible to answer this, because neither
predicate specifies a subset of the other. (Not all prime numbers are
odd, and not all odd numbers are prime.)
You could start by restricting the predicates to the kinds of predicates
that describe strict subset relationships, and for example, reject a
method on oddp when a method on primep already exists, or vice versa.
But this requires you to (a) either analyze the predicate to find out
what it does, or (b) restrict the predicates to a fixed set of
predefined ones.
Option (a) means that you have to solve the halting problem. Assume a
predicate 'forever that never returns, but just indefinitely loops. So
what do you do when you define a method like this?
(defmethod baz ((x (forever))) ...)
Your predicate analyzer will fail in the general case, because of the
halting problem.
Option (b) means that you select a number of predicates, and allow
programmers to use them and only them. Here comes the kicker: That's
what CLOS already does, the two predicates are typep and eql.
There are several approaches for predicate dispatch, you may want to
google for them. But none of them go substantially beyond option (b),
they only provide different predefined sets of predicates...
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/
Pascal Costanza <··@p-cos.net> writes:
> You could start by restricting the predicates to the kinds of
> predicates that describe strict subset relationships, and for example,
> reject a method on oddp when a method on primep already exists, or
> vice versa. But this requires you to (a) either analyze the predicate
> to find out what it does, or (b) restrict the predicates to a fixed
> set of predefined ones.
That's a false dilemma. For situations where priority cannot be
clearly determined you could keep track of the method definition order
and evaluate the predicates in that order, selecting the first one
that passes (ML-style). You could add a protocol step and require the
programmer to specify the priority explicitly. You could even pick a
predicate based on the alphabetical order of its name :)
With a little thought, I'm sure it's possible to come up with a
practical and theoretically sound solution. This doesn't have to be
reduced to the halting problem :)
--
Regards,
Slava Akhmechet.
Slava Akhmechet wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> You could start by restricting the predicates to the kinds of
>> predicates that describe strict subset relationships, and for example,
>> reject a method on oddp when a method on primep already exists, or
>> vice versa. But this requires you to (a) either analyze the predicate
>> to find out what it does, or (b) restrict the predicates to a fixed
>> set of predefined ones.
> That's a false dilemma. For situations where priority cannot be
> clearly determined you could keep track of the method definition order
> and evaluate the predicates in that order, selecting the first one
> that passes (ML-style). You could add a protocol step and require the
> programmer to specify the priority explicitly. You could even pick a
> predicate based on the alphabetical order of its name :)
>
> With a little thought, I'm sure it's possible to come up with a
> practical and theoretically sound solution. This doesn't have to be
> reduced to the halting problem :)
Maybe. But in general, the order in which methods are added to a generic
function is not well defined, except for the methods which are part of a
defgeneric form itself.
An important benefit of CLOS-style generic functions is that you can
define methods for generic functions in several places of your program,
and they all become potentially applicable. Applicability remains
stable, no matter in which order the various parts of the program are
loaded. (To a certain degree, that's even true for class definitions,
thanks to forward-referenced classes.)
Among other things, this enables you to integrate different methods from
different parties. Now, if you want to specify priorities by, say,
specifying numbers (which is relatively straightforward to do in method
combinations), the problem is that in the general case, you don't know
what numbers the other parties (other programmer teams, other library
extensions, etc.) have used. Same for alphabetical order or, I'm pretty
sure, any other scheme you may come up with. That's again a consequence
that you're actually trying to solve the halting problem in disguise:
You need some form of global knowledge (by knowing all program parts, or
by restricting what the different program parts can say).
If you insist on having global knowledge, you might as well use simple
cond or typecase forms, because there would be no real benefit in terms
of independent extensibility anymore anyway.
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/