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 <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. > > 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 <k...@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.lend...@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 >> http://tiltontec.com >> "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 > >
_______________________________________________ pro mailing list pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro
