[Ecls-list] Closer to MOP updated...

[Juan Jose Garcia-Ripoll]

On Sun, Dec 9, 2012 at 6:45 PM, Pascal Costanza <pc at p-cos.net> wrote:

> I have now pushed support for ECL 12.12.1 to the Closer to MOP repository
> and updated the website. I hope I didn't make any mistakes.
>

Thanks, Pascal, for your help, your time and your efforts.


> Congratulations for the new release of ECL. The MOP implementation has
> improved substantially, and I would now consider it one of the best
> implementations of the CLOS MOP, together with clisp and sbcl.
>

It is great to hear that. As usual, there is room for improvement,
specially in the field of optimizations.

This reminds me of a question I have. The MOP does not specify how the
protocols of dispatch, slot access, etc, are done internally. In particular
it does not define whether those functions call method accessors or just
use slot-value to retrieve things like the list of methods, the list of
slots, etc. I am saying this because, since we cannot inline slot
accessors, I might just replace, in the ECL library at least, all uses of
them with slot-value, which I am allowed to inline. Of course, in practice
I would just define a few compiler macros that are used only at boot time,
but you probably get the idea.


> Two issues still remain, on top of the ones I already reported before:
>
> 1) The documentations for slot definition metaobjects add parentheses,
> which shouldn't be necessary.


Will look into that
https://sourceforge.net/p/ecls/bugs/228/

2) What would be really sweet is if the list of next methods that are
> passed to method functions is actually a list of method metaobjects, not
> method functions.
>

This too
https://sourceforge.net/p/ecls/bugs/229/


> However, on top of that it would also be good if call-next-method would
> not rely on a special variable holding the next methods anymore,


There is a reason for using a special variable, which is that the functions
that form a method currently take a number of arguments equal to the number
of arguments of an ordinary function. Say (defmethod foo ((a t) b) ...)
Here the method function in ECL is of the form (lambda (a b) ...) and the
next method and the list of arguments are kept in global variables which
are set by the method combination.

Probably the unoptimized dispatch in MOP (i.e. the one that relies on
make-method-lambda) could do without defining the special variable. I will
look into that.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20121209/461dbabb/attachment.html>