[pro] AMOP question: When and where is slot-value-using-class called?

[Jean-Claude Beaudoin]

On Sat, Aug 2, 2014 at 11:52 PM, Steve Haflich <shaflich at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20140803/ccf64f16/attachment.html>