On Sat, Aug 2, 2014 at 11:52 PM, Steve Haflich <shafl...@gmail.com> wrote:
> 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. > Afghan? > > The restriction on "portable programs" extending (redefining, whatever) > MOP functions is here: > > > http://franz.com/support/documentation/current/doc/mop/concepts.html#portable > > The motivation for this particular restriction is twofold. > > 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 (*). > > 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." > > 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. > > 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? BTW, I noticed in the clisp documentation that they mention <http://www.clisp.org/impnotes.html#forward-referenced-class-clisp> a problem with "forward-referenced-class", a case of misdesign they say. At first sight, they seem to have a case. Do they? If they do then the CLOS subcommittee would be vindicated.
_______________________________________________ pro mailing list pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro