defmethod vs defun - reprised
Geoffrey King
am tempted to use defmethod over defun for those functions that are
centered around typed parameters.
A simple example are string related functions.
The prior post raised:
- Efficiency
- Programmer confusion over purpose.
If it proves in-efficient then adding a fast defun seems ok. I tend to
favour programmer efficiency over execution efficiency. I don't really
find the second confusing. Adding a string method that does something tp
strtings seems fine.
The preference for defun (in typed situations) seems like habit, but of
course i am not sure, thus the question. Any thoughts?
Thanks.
Pascal Costanza
> Being a newbie and trying to establish all my 'bad habits' up front. I
> am tempted to use defmethod over defun for those functions that are
> centered around typed parameters.
> The preference for defun (in typed situations) seems like habit, but of
> course i am not sure, thus the question. Any thoughts?
defmethod is designed to result in execution speed that is comparable to
that of functions defined with defun.
If your generic function consists of only one method and has none of its
arguments specialized, then you won't notice a difference, because the
generic function can just blindly execute that single method. If it
consists of only one method with some of its arguments specialized, then
it will merely add a type test and reject execution if the types are not
fulfilled. If you have more methods defined on a generic function, then
this can typically be compiled into what is called a discrimination net
which is an extension of that idea. (That is, the types of the arguments
are tested in a way such that the set of applicable methods, or
non-applicability of the generic function, is determined as quickly as
possible.) I think in the general case it's hard to beat this kind of
discrimination with manually coded approaches.
So the decision of whether to use defun or defmethod is mostly a matter
of taste.
It seems to me that the most reasonable options are to either go for
methods all the time, or to distinguish between generic and "ordinary"
functions in order to indicate which functions you want to be
recognizable as being extendable by other code via further specialized
methods.
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Kaz Kylheku
> Being a newbie and trying to establish all my 'bad habits' up front. I
> am tempted to use defmethod over defun for those functions that are
> centered around typed parameters.
[ snip ]
> The preference for defun (in typed situations) seems like habit, but of
> course i am not sure, thus the question. Any thoughts?
Just this: that the price for making the ``wrong'' decision too early
is not that great in Lisp compared to some other languages. You don't
have to plan that far ahead; just do what works now.
Changing something form a ``regular'' function to a ``class member''
can require a lot of refactoring in some languages, not to mention
interface changes.
With generic function, your interface stays the same. If you don't
(yet!) need the implementation to dispatch different logic based on
different types, don't bother. Later you can switch it from a DEFUN to
DEFMETHOD without altering the interface.
Or you can hack other approaches before you do that, like a TYPECASE in
the body of the regular function or whatnot.
ivant
One more thing to consider is, that many compilers signal warnings
about implicitly defining generics. That is, you should use defgeneric
first. Or you can just ignore these warnings.
Steven M. Haflich
Pascal Costanza wrote:
> defmethod is designed to result in execution speed that is comparable to
> that of functions defined with defun.
> If your generic function consists of only one method and has none of its
> arguments specialized, then you won't notice a difference, because the
> generic function can just blindly execute that single method. If it
> consists of only one method with some of its arguments specialized, then
> it will merely add a type test and reject execution if the types are not
> fulfilled. If you have more methods defined on a generic function, then
> this can typically be compiled into what is called a discrimination net
> which is an extension of that idea. (That is, the types of the arguments
> are tested in a way such that the set of applicable methods, or
> non-applicability of the generic function, is determined as quickly as
> possible.) I think in the general case it's hard to beat this kind of
> discrimination with manually coded approaches.
Tests performed long ago on the speed of gf dispatching suggested that
a clever implementation (but with no microcode support, as was available
on the Lisp Machines) could optimize normal dispatch to something
between 1.5 and 2 times the cost of a non-gf call. (It depends, of
course, on the particular architecture.) This sounds like a significant
slowdown, but remember that these measures were for functions and methods
that did nothing in the body -- if you write functions that actually do
something that takes more time than the function or gf entry and exit,
then these costs shrink inversely proportional.
> So the decision of whether to use defun or defmethod is mostly a matter
> of taste.
This is my real disagreement. Dick Gabriel pointed out something during
the X3J13 discussions on adopting CLOS: A non-generic function has an
implementation that exists as source code at some particular place in
some particular source file. But a generic function has an implementation
that exists at least potentially in many separate places possible in many
separate source files. When reading the code for a defun, the programmer
understands that the behavior of the function is defined by what he sees
immediately in the source. When reading the code for a defmethod (which
includes the methods defined by defclass :accessor/:reader/:writer
specifications) the programmer knows essentially nothing unless he can
examine the other methods on the gf. In addition to the defined behavior
of defmethod, it is also documentation that the implementation of this
particular function is distributed and cannot necessary be understood
only by examining the defmethod form.
So I propose that it is poor style to code a defmethod when defun would
be appropriate. Forty years ago there was a quip on the bulletin board
of the MIT RLE PDP-1 (where I first programmed Lisp): "Elegance is not
without its price. -- Confucius." But in the modern age it is not the
cost in machine cycles with which we should be concerned. Rather, it is
the cost in mushware -- in code readability.
Use methods only where there is the possibility of other methods.
> It seems to me that the most reasonable options are to either go for
> methods all the time, or to distinguish between generic and "ordinary"
> functions in order to indicate which functions you want to be
> recognizable as being extendable by other code via further specialized
> methods.
Java opts for methods everywhere. That's why Java code cannot be read
by humans, and that is why Java will never catch on because Java
applications beyond a certain size and age will prove unreadable and
unmaintainable.
Kenny Tilton
Steven M. Haflich wrote:
> I find I must disagree with my friend Pascal on several grounds.
>
> Pascal Costanza wrote:
>
.....
>> So the decision of whether to use defun or defmethod is mostly a
>> matter of taste.
>
>
> This is my real disagreement. Dick Gabriel pointed out something during
> the X3J13 discussions on adopting CLOS: A non-generic function has an
> implementation that exists as source code at some particular place in
> some particular source file. But a generic function has an implementation
> that exists at least potentially in many separate places possible in many
> separate source files. When reading the code for a defun, the programmer
> understands that the behavior of the function is defined by what he sees
> immediately in the source. When reading the code for a defmethod (which
> includes the methods defined by defclass :accessor/:reader/:writer
> specifications) the programmer knows essentially nothing unless he can
> examine the other methods on the gf.
Word. But I would spin it as defmethod advertises that the developer
views this function as something that is expected to vary, or better has
already varied, in implementation by class of parameter. The flipside
being that defun advertises that this bad boy is good for any class of
parameter. These are small wins in documentation, but those of us who
neither write nor read documentation take such deets seriously, just as
the blind get more from sound than do the sighted.
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Pascal Costanza
> I find I must disagree with my friend Pascal on several grounds.
Go ahead. ;)
> Pascal Costanza wrote:
>
>> defmethod is designed to result in execution speed that is comparable
>> to that of functions defined with defun.
[...]
>
> Tests performed long ago on the speed of gf dispatching suggested that
> a clever implementation (but with no microcode support, as was available
> on the Lisp Machines) could optimize normal dispatch to something
> between 1.5 and 2 times the cost of a non-gf call. (It depends, of
> course, on the particular architecture.) This sounds like a significant
> slowdown, but remember that these measures were for functions and methods
> that did nothing in the body -- if you write functions that actually do
> something that takes more time than the function or gf entry and exit,
> then these costs shrink inversely proportional.
Were these indeed generic functions with just one non-specialized
method? I am asking because in case they had several methods defined,
then you can faithfully compare them only to functions that include some
manual dispatch via COND or TYPECASE, IMHO, because that's what a
programmer has to do to achieve the same effect.
> When reading the code for a defmethod (which
> includes the methods defined by defclass :accessor/:reader/:writer
> specifications) the programmer knows essentially nothing unless he can
> examine the other methods on the gf. In addition to the defined behavior
> of defmethod, it is also documentation that the implementation of this
> particular function is distributed and cannot necessary be understood
> only by examining the defmethod form.
Well, there's at least generic-function-methods with which you can
quickly inspect whether there are methods...
> So I propose that it is poor style to code a defmethod when defun would
> be appropriate. Forty years ago there was a quip on the bulletin board
> of the MIT RLE PDP-1 (where I first programmed Lisp): "Elegance is not
> without its price. -- Confucius." But in the modern age it is not the
> cost in machine cycles with which we should be concerned. Rather, it is
> the cost in mushware -- in code readability.
>
> Use methods only where there is the possibility of other methods.
Well, at least this was one of the alternatives I suggested. (Phew. ;)
[...]
> Java will never catch on
[...]
:)
John Thingstad
> [...]
>> Java will never catch on
> [...]
>
> :)
>
and stupidity will never prevail :)
(wait a minute.. George Bush jr. Stephen Weinberg. Hidden weapons in
iraque.
I snigger and keep on looking.. Found one! infact a thousand weapons of
mass
destruction in 'God's own country' (the devils?))
>
> Pascal
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/