<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Aug 2, 2014 at 11:52 PM, Steve Haflich <span dir="ltr"><<a href="mailto:shaflich@gmail.com" target="_blank">shaflich@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">OK, now I'm sitting in front of the front end of a computer rather than the back end of a smelly wet large long-haired dog.</div>
</blockquote><div><br></div><div>Afghan?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>The restriction on "portable programs" extending (redefining, whatever) MOP functions is here:</div>

<div><br></div><div><a href="http://franz.com/support/documentation/current/doc/mop/concepts.html#portable" target="_blank">http://franz.com/support/documentation/current/doc/mop/concepts.html#portable</a><br></div><div>
<br></div><div>The motivation for this particular restriction is twofold.</div>
<div><br></div><div>First, the CL language implementation as well as the MOP itself may depend upon the MOP itself.  The intention is that the language and MOP can use CLOS and even the MOP in their own implementation, and if they do, and use only "specified" classes or classes specified on class (and operator) names in private packages or otherwise unexported and unknown to properly-written portable programs, those programs won't break the implementation or affect the efficiency of its implementation.  This is no different than the ANS prohibition against redefining cons to take its arguments in reverse order, expecting that if the portable user application code was written against this specification, the result would be harmless.  But global definitions Lisp worlds are indeed global (*).</div>

<div><br></div><div>The second reason is less obvious.  The implementation of ANS CL, CLOS, and the MOP obviously all depend upon themselves.  Thus their implementations are metacircular and need protection.  Furthermore, the full MOP protocol even where not metaciculr is expensive.  If it must be obeyed for "specified" operators on objects of "specified" classes, execution efficiency may be unacceptable.  The CLOS and MOP subcommittee of X3J13 IMO did an exquisite job making it possible to implement these subspecifications into a usable "industrial-strength language."</div>

<div><br></div><div>The CLOS subcommittee recommended that CLOS, but not MOP, be accepted into the standard, because the MOP had never yet been fully implemented, and was not yet ready for standardization.  That is exactly what we (X3J13) voted.</div>

<div><br></div></div></blockquote><div><br>It would be interesting to see if the situation has really changed by now. Is there a "full" MOP implementation now in use and what lessons has it taught?  Most implementations for which I have source code are derived from PCL for their CLOS part and I think that PCL is probably the "not yet full" implementation that was available to the committee back then, wasn't it?<br>
<br></div><div>BTW, I noticed in the clisp documentation that they <a href="http://www.clisp.org/impnotes.html#forward-referenced-class-clisp">mention</a> a problem with "forward-referenced-class", a case of misdesign they say. At first sight, they seem to have a case. Do they?<br>
</div><div>If they do then the CLOS subcommittee would be vindicated.<br><br><br></div><div><br></div></div></div></div>