Has someone extended the 'parameter-specializer-name' of defmethod to
general type specifiers ?
I would be happy to do :
(defmethod m () ((x (list string))) ...)
which is a method specializing on lists of strings.
This raises an other problem : defining a compound type 'list' which can
specialize ?
___________________________________________________________
Christophe Turle.
(format nil ···@~S.~S" 'c.turle 'wanadoo 'fr)
sava preview : http://perso.wanadoo.fr/turle/lisp/sava.html
Christophe Turle wrote:
> Has someone extended the 'parameter-specializer-name' of defmethod to
> general type specifiers ?
>
> I would be happy to do :
>
> (defmethod m () ((x (list string))) ...)
>
> which is a method specializing on lists of strings.
>
> This raises an other problem : defining a compound type 'list' which can
> specialize ?
The bigger problem is that it's hard to determine an order between
arbitrary types. Consider:
(defmethod m () ((n (satisfies oddp)))
(print 'odd))
(defmethod m () ((n (satisfies primep)))
(print 'prime))
Which method should be executed by (m 7)?
Other problems: '(list string) would be a subtype of '(sequence string)
and of '(list t). (Would it?) What's the type precedence list for '(list
string)?
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> Christophe Turle wrote:
>> Has someone extended the 'parameter-specializer-name' of defmethod to
>> general type specifiers ?
>> I would be happy to do :
>> (defmethod m () ((x (list string))) ...)
>> which is a method specializing on lists of strings.
>> This raises an other problem : defining a compound type 'list' which
>> can
>> specialize ?
>
> The bigger problem is that it's hard to determine an order between
> arbitrary types. Consider:
>
> (defmethod m () ((n (satisfies oddp)))
> (print 'odd))
>
> (defmethod m () ((n (satisfies primep)))
> (print 'prime))
>
> Which method should be executed by (m 7)?
I'd think that primep is more specific than oddp....
Joe Marshall wrote:
> Pascal Costanza <········@web.de> writes:
>
>>Christophe Turle wrote:
>>
>>>Has someone extended the 'parameter-specializer-name' of defmethod to
>>>general type specifiers ?
>>>I would be happy to do :
>>>(defmethod m () ((x (list string))) ...)
>>>which is a method specializing on lists of strings.
>>>This raises an other problem : defining a compound type 'list' which
>>>can
>>>specialize ?
>>
>>The bigger problem is that it's hard to determine an order between
>>arbitrary types. Consider:
>>
>>(defmethod m () ((n (satisfies oddp)))
>> (print 'odd))
>>
>>(defmethod m () ((n (satisfies primep)))
>> (print 'prime))
>>
>>Which method should be executed by (m 7)?
>
> I'd think that primep is more specific than oddp....
So your test suite doesn't include (oddp 2)? ;)
(Yes, there could be better examples...)
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
i've wanted the same type of construct... dispatching on some
predicates. The basic idea makes a lot of sense, however, what
should happen if more than one method matches the
criteria? Potentially, a generic function could
register the allowed predicates and specify their order...
just a thought....
Has anyone implemented such a thing?
My case is that i have a built in type in my
lisp system, the type is called dbobject. The class
of a dbobject is also dbobject. every object of class
dbobject knows ist objType. I'd love to dispatch
on objType, rather than having to put a case
statement in every function that needs to do a different
thing depending on if it is a "label" or a "net" or a
"terminal" etc....
(defgeneric my-method ( arg1 ...)
:method-class method-dispatch-on-predicate
:generic-function-class generic-function-dispatch-on-predicate
:predicate-precedence ( net-p label-p terminal-p oddp primep ))
(defmethod my-method (( arg1 (predicate pred1-p)) ...)
...)
the most specific should be (eql ...)
next would come the predicates
next would come the class specifications
any thoughts?
-jim
Pascal Costanza wrote:
> Joe Marshall wrote:
>
>> Pascal Costanza <········@web.de> writes:
>>
>>> Christophe Turle wrote:
>>>
>>>> Has someone extended the 'parameter-specializer-name' of defmethod to
>>>> general type specifiers ?
>>>> I would be happy to do :
>>>> (defmethod m () ((x (list string))) ...)
>>>> which is a method specializing on lists of strings.
>>>> This raises an other problem : defining a compound type 'list' which
>>>> can
>>>> specialize ?
>>>
>>>
>>> The bigger problem is that it's hard to determine an order between
>>> arbitrary types. Consider:
>>>
>>> (defmethod m () ((n (satisfies oddp)))
>>> (print 'odd))
>>>
>>> (defmethod m () ((n (satisfies primep)))
>>> (print 'prime))
>>>
>>> Which method should be executed by (m 7)?
>>
>>
>> I'd think that primep is more specific than oddp....
>
>
> So your test suite doesn't include (oddp 2)? ;)
>
> (Yes, there could be better examples...)
>
>
> Pascal
>
"Jim Newton" <·····@rdrop.com> a �crit dans le message de
····················@uni-berlin.de...
> i've wanted the same type of construct... dispatching on some
> predicates. The basic idea makes a lot of sense, however, what
> should happen if more than one method matches the
> criteria? Potentially, a generic function could
> register the allowed predicates and specify their order...
> just a thought....
>
> Has anyone implemented such a thing?
>
> My case is that i have a built in type in my
> lisp system, the type is called dbobject. The class
> of a dbobject is also dbobject. every object of class
> dbobject knows ist objType. I'd love to dispatch
> on objType, rather than having to put a case
> statement in every function that needs to do a different
> thing depending on if it is a "label" or a "net" or a
> "terminal" etc....
perhaps you may define your objTypes as classes, all deriving from the same
source dbObject. This way you can dispatch.
___________________________________________________________
Christophe Turle.
(format nil ···@~S.~S" 'c.turle 'wanadoo 'fr)
sava preview : http://perso.wanadoo.fr/turle/lisp/sava.html
that is one of the reasons i want to specialize on something
other than the class.
Jim Newton wrote:
> the class of the dbobjects is not under my control.
> they are all of class dbobject. :-(
>
> Christophe Turle wrote:
>
>> "Jim Newton" <·····@rdrop.com> a �crit dans le message de
>> ····················@uni-berlin.de...
>>
>>> i've wanted the same type of construct... dispatching on some
>>> predicates. The basic idea makes a lot of sense, however, what
>>> should happen if more than one method matches the
>>> criteria? Potentially, a generic function could
>>> register the allowed predicates and specify their order...
>>> just a thought....
>>>
>>> Has anyone implemented such a thing?
>>>
>>> My case is that i have a built in type in my
>>> lisp system, the type is called dbobject. The class
>>> of a dbobject is also dbobject. every object of class
>>> dbobject knows ist objType. I'd love to dispatch
>>> on objType, rather than having to put a case
>>> statement in every function that needs to do a different
>>> thing depending on if it is a "label" or a "net" or a
>>> "terminal" etc....
>>
>>
>>
>> perhaps you may define your objTypes as classes, all deriving from the
>> same
>> source dbObject. This way you can dispatch.
>>
>> ___________________________________________________________
>> Christophe Turle.
>> (format nil ···@~S.~S" 'c.turle 'wanadoo 'fr)
>>
>> sava preview : http://perso.wanadoo.fr/turle/lisp/sava.html
>>
>>
>
Jim Newton <·····@rdrop.com> writes:
> that is one of the reasons i want to specialize on something
> other than the class.
>
> Jim Newton wrote:
>> the class of the dbobjects is not under my control.
>> they are all of class dbobject. :-(
This is not object-oriented programming, then. OOP is about behavior
depending on the classes of the objects interacting. What you should do
is come up with a way to do the dispatch on the criteria and in the
fashion you want. For exampe, the prolog-like compiler in PAIP. It
dispatches on whether the lists match in structure using wildcards
instead of on the class information.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
does dispatching on eql qualify as OOP?
to me (lambda ( x ) (eql x some-target-val)) is just a predicate.
-jim
Rahul Jain wrote:
> Jim Newton <·····@rdrop.com> writes:
>
>
>>that is one of the reasons i want to specialize on something
>>other than the class.
>>
>>Jim Newton wrote:
>>
>>>the class of the dbobjects is not under my control.
>>>they are all of class dbobject. :-(
>
>
> This is not object-oriented programming, then. OOP is about behavior
> depending on the classes of the objects interacting. What you should do
> is come up with a way to do the dispatch on the criteria and in the
> fashion you want. For exampe, the prolog-like compiler in PAIP. It
> dispatches on whether the lists match in structure using wildcards
> instead of on the class information.
>
Jim Newton <·····@rdrop.com> writes:
> does dispatching on eql qualify as OOP?
> to me (lambda ( x ) (eql x some-target-val)) is just a predicate.
(subtypep x 'some-class) is also just a predicate. You are dispatching
on this in the "normal" OOP case.
The key is that the predicate's truth is directly tied to the object
itself, not to something that it might happen to contain a (possibly
indirect) reference to. CHANGE-CLASS makes it a bit more complex, but
the object is still of some specific class that describes how it
intrinsically works.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Jim Newton <·····@rdrop.com> writes:
> does dispatching on eql qualify as OOP?
> to me (lambda ( x ) (eql x some-target-val)) is just a predicate.
Yes.
A class is an object (instance of a meta-class).
A meta-class is a class (therefore an object).
So, why should we distinguish objects and classes? Let's create new
objects on the model of existing objects. This is the
prototype-instance model of object programming. See for an example KR
from http://sourceforge.net/projects/garnetlisp/ There, you can
easily add methods specific to an object.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
Jim Newton wrote:
> i've wanted the same type of construct... dispatching on some
> predicates. The basic idea makes a lot of sense, however, what
> should happen if more than one method matches the
> criteria? Potentially, a generic function could
> register the allowed predicates and specify their order...
> just a thought....
>
> Has anyone implemented such a thing?
There exist work (mainly papers) on the notion of "predicate
dispatching". See http://c2.com/cgi/wiki?PredicateDispatching
It should be possible to implement this as a user-defined method
combination and probably some MOP hacking. It's very likely that there
are some devils in the details, though.
The basic idea is that they order boolean expressions according to
statically decidable implications, and they reject everything that is
not statically decidable. The set of possible predicates may or may not
be useful. I think the idea is good, but I don't know enough about the
details.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Christophe Turle wrote:
> An "Exclusive" one should print 'odd' or 'prime'.
Which one?
> I would say (list t) then (sequence string).
Why?
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
"Pascal Costanza" <········@web.de> a �crit dans le message de
·················@f1node01.rhrz.uni-bonn.de...
> Christophe Turle wrote:
>
> > An "Exclusive" one should print 'odd' or 'prime'.
>
> Which one?
one or the other. implementation dependent, random ...
Just like asking for a set member. (set-member '(a b)) may return a or b.
The two are valid answers.
> > I would say (list t) then (sequence string).
>
> Why?
>
my policy is : "if type1 is a subtype of type2, then (type1 *anything*) is a
subtype of (type2 *anything*)"
--
___________________________________________________________
Christophe Turle.
(format nil ···@~S.~S" 'c.turle 'wanadoo 'fr)
sava preview : http://perso.wanadoo.fr/turle/lisp/sava.html
Christophe Turle wrote:
> Has someone extended the 'parameter-specializer-name' of defmethod to
> general type specifiers ?
>
> I would be happy to do :
>
> (defmethod m () ((x (list string))) ...)
The reason methods discriminate only on classes, and the reason the
set of required classes is so carefully defined by the ANS, is that
extensions like this have _huge_ potential performance costs.
Discrimination by the proposed method requires traversal of the
entire list in order to guarantee all elements are strings. And
don't even think about the case of a circular list...
The designers of CLOS were careful that extremely efficient
implementation be possible -- otherwise, CLOS would not have been
extensively used in production code. Most Lisp developers of the
period were surprised by the efficiency achieved for gf dispatch,
once they had time to play with it for a while and experiment with
clever design and optimization and caching.
Paul Dietz <············@motorola.com> writes:
> "Steven M. Haflich" wrote:
>
> > The designers of CLOS were careful that extremely efficient
> > implementation be possible -- otherwise, CLOS would not have been
> > extensively used in production code. Most Lisp developers of the
> > period were surprised by the efficiency achieved for gf dispatch,
> > once they had time to play with it for a while and experiment with
> > clever design and optimization and caching.
>
> It would have been nice if many of the generic-like standardized
> functions (for example, the sequence functions) were actual
> generic functions (although perhaps not standard-generic-functions),
> and if the standard types they dispatch off of could be extended.
Yes, it would be nice.
> I can think of many places where there'd be essentially no performance
> penalty for preexisting code caused by this extension, since the
> standardized functions have to do the equivalent of dispatching
> on argument type anyway, and the extensions would add an
> extra check where the previous code would just throw an error.
No, it would be worse for performaces. The dispatch can be done at
compilation time!
(concatenate 'list '(a b c) '(1 2 3))
may be generated by the compiler as:
(append '(a b c) '(1 2 3))
While:
(concatenate 'string "abc" "123")
would be generated by the compiler as:
(smart-compiler-internals::%strcat "abc" "123")
No dispatch at run time!
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
Pascal Bourguignon wrote:
> No, it would be worse for performaces. The dispatch can be done at
> compilation time!
>
> (concatenate 'list '(a b c) '(1 2 3))
> may be generated by the compiler as:
> (append '(a b c) '(1 2 3))
>
> While:
> (concatenate 'string "abc" "123")
> would be generated by the compiler as:
> (smart-compiler-internals::%strcat "abc" "123")
>
> No dispatch at run time!
Ah, but section 11.1.2.1.2, point 19 would save you!
This compile time determination could still be done
even if the functions were extensible; they'd just
have to be extensible on user-defined classes only
(and those classes would have to be subclasses
of SEQUENCE but not of VECTOR or LIST, for example.)
Paul
"Christophe Turle" <······@nospam.com> writes:
> (gen-concatenate '(a b c) '(1 2 3))
> (gen-concatenate "abc" "123")
(gen-concatenate var-1 var-2) is the more interesting case.
--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org
Steven M. Haflich wrote:
> Dispatch? This needs no execution at all at run time...
Before everyone jumps all over this statement, I should clarify.
A call to concatenate with manifest literal arguments requires
runtime fresh consing of the returned value unless the compiler
can determine that the conses in the result will not be directly
visible to the user code. Unless the conses themselves are
visible, there can be no mutation of the returned list nor any
comparision on sublista of the returned value:
(dolist (x (concatenate 'list '(a b c) '(1 2 3))) ...)
is an example of such a call form that could be eliminated at
compile time.
But all this is distant from the original question, whether
all types, including user-defined types, should be valid for
gf discrimination. In a theoretical, acedemic language, the
answer might erasonably be yes. In a production language for
performance-critical real-world applications, I maintain the
answer is no.
"Steven M. Haflich" <·················@alum.mit.edu> writes:
> Pascal Bourguignon wrote:
>
> > Paul Dietz <············@motorola.com> writes:
> >
> >>I can think of many places where there'd be essentially no performance
> >>penalty for preexisting code caused by this extension, since the
> >>standardized functions have to do the equivalent of dispatching
> >>on argument type anyway, and the extensions would add an
> >>extra check where the previous code would just throw an error.
> > No, it would be worse for performaces. The dispatch can be done at
> > compilation time!
> > (concatenate 'list '(a b c) '(1 2 3))
> > may be generated by the compiler as:
> > (append '(a b c) '(1 2 3))
>
> Why bother compiling it at all? This form (absent notinline declarations)
> is completely safe to treat bvy compile-time constant folding. It is
> equivalent to the constant '(a b c 1 2 3).
No it is not!
If it's not obvious for you, just try this:
(defun f () (append '(a b c) '(1 2 3)))
(setf (second (f)) :second)
(f)
(defun g () '(a b c 1 2 3))
(setf (second (g)) :second)
(g)
Which leads me to correct:
(concatenate 'list '(a b c) '(1 2 3))
may be generated by the compiler as:
(append '(a b c) (copy-seq '(1 2 3)))
> > No dispatch at run time!
>
> Dispatch? This needs no execution at all at run time...
You're wrong.
> The case of function calls where all arguments are manifest constants is
> the simple case. The more interesting case occurs where one or more
> arguments are not knowable at compile time. Why not think about that
> situation a little?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
Pascal Bourguignon wrote:
> "Steven M. Haflich" <·················@alum.mit.edu> writes:
>> Why bother compiling it at all? This form (absent notinline
>> declarations)
>> is completely safe to treat bvy compile-time constant folding. It is
>> equivalent to the constant '(a b c 1 2 3).
>
> No it is not!
>
> If it's not obvious for you, just try this:
>
> (defun f () (append '(a b c) '(1 2 3)))
> (setf (second (f)) :second)
> (f)
> (defun g () '(a b c 1 2 3))
> (setf (second (g)) :second)
> (g)
>
> Which leads me to correct:
> (concatenate 'list '(a b c) '(1 2 3))
> may be generated by the compiler as:
> (append '(a b c) (copy-seq '(1 2 3)))
I don't see why you can't have it generate
(copy-seq '(a b c 1 2 3)), though. Same effect, less time/space.
"Pascal Costanza" <········@web.de> a �crit dans le message de
·················@f1node01.rhrz.uni-bonn.de...
> Christophe Turle wrote:
>
> > What do you believe people do when a feature, they think important, is
not
> > there ? They forget about it ? no, they try to implement it. And what is
the
> > result ? a home-design thing. With performance issue surely more bad
than it
> > should be.
>
> Learn something about the metaobject protocol and try to implement your
> ideas with it. As soon as you have a working design, you can think about
> optimizing things, which should also be possible with the help from the
MOP.
Yes, i'm afraid it's the road to take.
- but MOP is not ANSI.
- It is a long & big job, i think. It's why i was asking if someone else
have done it or find an other way.
___________________________________________________________
Christophe Turle.
(format nil ···@~S.~S" 'c.turle 'wanadoo 'fr)
sava preview : http://perso.wanadoo.fr/turle/lisp/sava.html
"Pascal Costanza" <········@web.de> a �crit dans le message de
·················@f1node01.rhrz.uni-bonn.de...
> Christophe Turle wrote:
>
> > Yes, i'm afraid it's the road to take.
> >
> > - but MOP is not ANSI.
>
> ...but it's still widespread enough that every major Common Lisp
> implementation implements it. I have been able to implement AspectL on
> five different implementations, including some that I didn't expect to
> be compatible enough, and I have plans to port it to even more
> implementations. Most of the existing incompatibilities can easily be
> worked around. The MOP is really not just an academic exercise, but a
> concept that works in practice. AspectL is a stress test of MOP
> features, it implements features that some people have claimed not to be
> implementable, so I am confident by now that you can implement pretty
> much anything that comes to mind.
>
> (BTW, AspectL includes a package aspectl.clos-mop that includes some
> utility functions for working around some of the incompatibilities.)
I will keep the reference.
> > - It is a long & big job, i think. It's why i was asking if someone else
> > have done it or find an other way.
>
> I can assure you that you will learn a lot by going that path.
For sure.
Just an other task on my stack !
___________________________________________________________
Christophe Turle.
(format nil ···@~S.~S" 'c.turle 'wanadoo 'fr)
sava preview : http://perso.wanadoo.fr/turle/lisp/sava.html