defmethod vs defun
Marcel van gerven
I'd like to know if its a good idea to use defmethod instead of
defun for any function for which the argument types are known at
compile time.... so
(defmethod is-string ((thestring string)) (stringp thestring))
instead of
(defun is-string (thestring) (stringp thestring))
Cheers,
Marcel van Gerven
Marc Battyani
"Marcel van gerven" <marc...@cs.kun.nl> wrote
> Hi there,
> I'd like to know if its a good idea to use defmethod instead of
> defun for any function for which the argument types are known at
> compile time.... so
>
> (defmethod is-string ((thestring string)) (stringp thestring))
As you know it's a string, just do this:
(defmethod is-string ((thestring string))
t)
I use-it like this:
(defmethod white-space-p (box)
nil)
(defmethod white-space-p ((box glue))
t)
(defmethod white-space-p ((box spacing))
t)
Marc
Raymond Wiker
Try instead
(defmethod is-string (var) nil)
(defmethod is-string ((var string)) t)
--
Raymond Wiker Mail: Raymon...@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Frank A. Adrian
> I'd like to know if its a good idea to use defmethod instead of
> defun for any function for which the argument types are known at
> compile time.... so
Since others have commented on the actual code, my take on the original
question is that you should use defmethod (a) when you're already using
CLOS constructs and (b) you have functional behavior that will (or is
likely in the future to) vary with the type of parameter(s). Otherwise use
defun. The fact that you know what the types are at compile time has very
little to do with the decision because you can just as easily use declare
to put information about known parameter types into defun bodies.
faa
Barry Margolin
Frank A. Adrian <fad...@ancar.org> wrote:
>Marcel van gerven wrote:
>
>> I'd like to know if its a good idea to use defmethod instead of
>> defun for any function for which the argument types are known at
>> compile time.... so
>
>Since others have commented on the actual code, my take on the original
>question is that you should use defmethod (a) when you're already using
>CLOS constructs and (b) you have functional behavior that will (or is
>likely in the future to) vary with the type of parameter(s). Otherwise use
>defun.
I agree with this. My reasoning is twofold:
1. No matter how good the method caching is, method dispatching is always
likely to be slower than normal function calling, because method
dispatching involves figuring out what to call and then calling it.
That second step is essentially what happens in a normal function call,
and it's unlikely that the overhead of "figuring out what to call" can
be reduced to zero. Unless someone implements a Lisp that's CLOS all
the way down, I don't expect them to optimize things so that method
dispatch is equal to or faster than ordinary function calls.
2. When you use DEFMETHOD, other programmers reading the code will assume
that this is a generic function, which is intended to be called with
objects of various types. They may try to write methods of their own,
or they'll be on the lookout for other methods. Or it may just seem
strange that this particular function would be generic, and it will
make it harder for them to understand the design of your application.
I actually consider 2 the more significant reason.
--
Barry Margolin, barry.m...@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Kenny Tilton
Marcel van gerven wrote:
I have nothing to add to those who have said 'just use stringp', and
that otherwise DEFUN is faster and better self-documenting. I just
wanted to <pounce> advertise my Road to Lisp Survey </pounce>.
With ILC out of the way I am going to try to do a little more with that,
and it would be fun to have more newie stories to work with. We are
approaching one hundred (with a relatively few old-timers in the mix).
Ran into some folks who had just found The Road and had paid their way
into a pricey show, which was cool.
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Christophe Turle
> I use-it like this:
>
> (defmethod white-space-p (box)
> nil)
>
> (defmethod white-space-p ((box glue))
> t)
>
> (defmethod white-space-p ((box spacing))
> t)
>
> Marc
>
>
why not have a "white-space-box" class from which "glue" and "spacing"
inherit ?
"white-space-p" is a sort of type-checking. But in object-oriented
software you don't need this anymore.
_____________________________________________
cturle @ free fr
Steven M. Haflich
I'm unimpressed by the practicality of the various answers to this
question.
There is a very important difference between defmethod and defun.
Execution of a defun form states that the content of this form translates
in an obvious way into the _entire_ definition of the named function,
completely redefining any previous definition. Execution of a defmethod
form states that the content of the form translates into a method function
that applies in potentially-complicated and potentially-limited ways to the
growing ball of mud that is the complete generic function. In particular,
issues of lambda-list congruence may throw an unexpected error when you try
to redefine a (method of) a generic function that has a different lambda
list. No such problems are likely with defuns.
Now, generic functions are a good thing, and they should be used when
appropriate. But if you have a function that doesn't have good reason
top be generic, you are better off for reasons of performance and reasons
of redefinition flexibility by using defun. Further, when someone else
needs to read and learn your code and sees a call to is-string, if he
finds a defun he knows that it does. If he sees a defmethod he has to do
a lot more complicated thinking and source-burrowing.
Generic fucntions should be used when they are useful, because they are a
truly wonderful construct. But they shouldn't be used merely for
codelegance. Code elegance is usually inelegant.
By the way, if performance were really important, your function could
be defined this way
(defun is-string (thestring) (stringp thestring))
(define-compiler-macro is-string (thestring)
`(stringp ,thestring))
but of course, that reveals that the definition of is-string is not
necessary and impedes the readability of the code rather than enhances
it. Higher-level code should leave more-primitive code alone.
Finally, the symbol "thestring" suggest you might be a converted Java
programmer. A Native Lisp speaker would have used "the-string".