Is there a reason why defun and defmethod cannot be handled
by the same macro?
e.g.
(defun x (a))
(defun x ((a integer))
I think that efficiency would not be an issue here.
p.s. This is really a clos question, but it seems that no one uses
comp.lang.clos
Someone from Franz asks this question---does it have a hidden
meaning?
I presume the question is really:
Can DEFUN be extended so that
(DEFUN FOO ((X INTEGER)) ...)
does the same as
(DEFMETHOD FOO ((X INTEGER)) ...)
I think that the most important reason is that of style.
If I use DEFUN, this means that I don't want anything
from CLOS, and my intent is clear.
There are technical issues here as well, but I'm sure
someone else can list them better than me.
Best regards,
Vassil.
Normally: ········@bgearn.acad.bg
Alex Athanasopoulos wrote:
>
> Is there a reason why defun and defmethod cannot be handled
> by the same macro?
>
> e.g.
>
> (defun x (a))
>
> (defun x ((a integer))
>
> I think that efficiency would not be an issue here.
>
> p.s. This is really a clos question, but it seems that no one uses
> comp.lang.clos
--
Vassil Nikolov, visitor at LRI:
Laboratoire de Recherche en Informatique, Universite Paris-Sud
Until 9 July 1997: ··············@lri.fr
Normally: ········@bgearn.acad.bg
Alex Athanasopoulos wrote:
>
> Is there a reason why defun and defmethod cannot be handled
> by the same macro?
>
> e.g.
>
> (defun x (a))
>
> (defun x ((a integer))
>
> I think that efficiency would not be an issue here.
>
> p.s. This is really a clos question, but it seems that no one uses
> comp.lang.clos
I understand that in Dylan, there is only one operation defining form
(equivalent to defmethod). Perhaps some Dylan people can tell us if
they feel they gave anything up?
I do believe that efficiency IS an issue for CLOS. In Dylan, there are
other mechanism to gain efficiency (sealing, etc.), that are not in CL.
(By the way, comp.lang.clos is used, and the discussions tend to be more
free from verbal battery.)
"Howard R. Stearns" <······@elwoodcorp.com> writes:
> Alex Athanasopoulos wrote:
> >
> > Is there a reason why defun and defmethod cannot be handled
> > by the same macro?
> >
> > e.g.
> >
> > (defun x (a))
> >
> > (defun x ((a integer))
> >
> > I think that efficiency would not be an issue here.
> >
> > p.s. This is really a clos question, but it seems that no one uses
> > comp.lang.clos
>
> I understand that in Dylan, there is only one operation defining form
> (equivalent to defmethod). Perhaps some Dylan people can tell us if
> they feel they gave anything up?
Dylan used to have only "define method" but by now a proposal to add
a "define function" macro to the language has been accepted. (I don't
know whether this means that define function is now in the "Dylan
Language Standard", whatever that is, but I suspect that the all
Dylan implementations will provide "define function".) The rationale
given in the proposal is:
Many programmers desire a way to define a function that clearly
says to other programmers that the function is not part of any
generic operation; furthermore, the function won't be extended as a
generic function, and calling it need not involve any generic
dispatch. The two main choices in current practice are:
define constant cube = method (x) x * x * x end;
define method cube (x) x * x * x end;
The first choice is clumsy because it makes it hard to distinguish
function constants from non-function constants. The second choice
does not make it clear that this is the only method for the
function. The "define function" proposal gives everybody one
simple way to express their intent. The expansion of the macro is
left unspecified so that Dylan implementations have latitude to
support it in the best way suited to the implementation.
[...]
In my opinion having this distinction available renders programs more
readable, especially if the source code is divided among several files.
Matthias