On Sun, Dec 9, 2012 at 6:45 PM, Pascal Costanza <span dir="ltr"><<a href="mailto:pc@p-cos.net" target="_blank">pc@p-cos.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

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.<br></blockquote><div><br></div><div>Thanks, Pascal, for your help, your time and your efforts.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br>

</blockquote><div><br></div><div>It is great to hear that. As usual, there is room for improvement, specially in the field of optimizations.</div><div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Two issues still remain, on top of the ones I already reported before:<br>
<br>
1) The documentations for slot definition metaobjects add parentheses, which shouldn't be necessary. </blockquote><div><br></div><div>Will look into that</div><div><a href="https://sourceforge.net/p/ecls/bugs/228/">https://sourceforge.net/p/ecls/bugs/228/</a> </div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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. <br>

</blockquote><div><br></div><div>This too</div><div><a href="https://sourceforge.net/p/ecls/bugs/229/">https://sourceforge.net/p/ecls/bugs/229/</a></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


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,</blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.<br>

</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Juanjo</div><div><br></div>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a><br>


</div>