That reminds me of the time I did

  (trace format)

That _did_ crash the LispM, very, very hard.

-- Scott


On Sat, Aug 2, 2014 at 8:52 PM, Steve Haflich <shaflich@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.

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@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@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@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/pro



--
Kenneth Tilton
Fort Lauderdale, FL
"In a class by itself." -Macworld



_______________________________________________
pro mailing list
pro@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/pro



_______________________________________________
pro mailing list
pro@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/pro