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

[Steve Haflich]

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.

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.

(*) Back around 1986 just before I intended to reboot my Lisp Machine
anyway I redefining car and cdr with the other's definition.  I expected an
immediate flaming crash, however, the machine kept running just fine.  This
is because the implementation had already compiled all the important
functions that called csr and cdr, and those calls obviously would be
inlined, making my redefinitions ineffectual.  I'm sure if I had searched
for some code that passed #'car or #'cdr as a :key argument to some other
function, I might have provoked some failure, but otherwise the machine and
OS didn't care.



On Sat, Aug 2, 2014 at 2:59 PM, Kenneth Tilton <ken at tiltontec.com> wrote:

> Note that the MOP is not part of the spec. They explicitly punted on
> making it so. Ergo, you are likely fishing in unspecified waters, or dog
> parks as the case may be.
>
> Note also that no one has asked you what problem you are trying to solve.
>
> Until now.
>
> hth, hk
>
>
> On Sat, Aug 2, 2014 at 5:26 PM, Attila Lendvai <attila.lendvai at gmail.com>
> wrote:
>
>> > I got different results in pretty much each CL implementation on the
>> > tracing of calls to slot-value-using-class.
>>
>> make sure you're not using CL:TRACE for this because it may not work
>> on SVUC due to various optimizations.
>>
>> --
>> • attila lendvai
>> • PGP: 963F 5D5F 45C7 DFCD 0A39
>> --
>> “A true intellectual is a man who, after reading a book and being
>> convinced by its arguments, will shoot someone or, more likely, order
>> someone shot.”
>>         — John McCarthy
>>
>> _______________________________________________
>> pro mailing list
>> pro at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/pro
>>
>
>
>
> --
> Kenneth Tilton
> Fort Lauderdale, FL
> http://tiltontec.com
> "In a class by itself." *-Macworld*
>
>
>
> _______________________________________________
> pro mailing list
> pro at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/pro
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20140802/dbbcf4a6/attachment.html>