3 ms·

> SBCL is mostly written without CLOS and then brings in a CLOS implementation late into bootstrapping; that of course prevents you from using CLOS in some plac

> SBCL is mostly written without CLOS and then brings in a CLOS implementation late into bootstrapping; that of course prevents you from using CLOS in some places, so you may not want to do that though. This is one of the things that makes Common Lisp implementations tricky. Because the error handling system in CL is based on CLOS, it means you have to build the base system with a crippled error handler and then at some point replace the whole thing with the proper error handler atomically and pray you don't get an error during the switchover.

pfdietz 3y ago
> Because the error handling system in CL is based on CLOS This is not the case. CONDITION objects don't have to be CLOS objects (although they are allowed to be).
lispm 3y ago
See here why Conditions is not defined in terms of CLOS: https://www.lispworks.com/documentation/HyperSpec/Issues/iss048_w.htm https://www.lispworks.com/documentation/HyperSpec/Issues/iss... > The condition system should not be too tightly integrated into CLOS, for two reasons: Some implementations already have a native condition system that is not based on CLOS, and it should be possible to integrate the native conditions and the ANSI CL conditions. Some people would like to define an ANSI Common Lisp subset that does not contain CLOS but does contain conditions.
- phoe-krk 3y ago
  Both of those reasons are pretty much stale nowadays. Contemporary implementation where conditions are standard objects are CCL, ECL, Clasp, ABCL, CLISP, SICL, LispWorks, and Allegro, leaving out pretty much only SBCL (which does this for bootstrapping reasons, such as having errors much earlier than CLOS) and probably Genera (which is hard to call contemporary). And AFAIK there are no alive subsets of CL whatsoever, let alone those which have a condition system but do not have CLOS.

pfdietz 3y ago

> Because the error handling system in CL is based on CLOS This is not the case. CONDITION objects don't have to be CLOS objects (although they are allowed to be).

lispm 3y ago

See here why Conditions is not defined in terms of CLOS: https://www.lispworks.com/documentation/HyperSpec/Issues/iss048_w.htm https://www.lispworks.com/documentation/HyperSpec/Issues/iss... > The condition system should not be too tightly integrated into CLOS, for two reasons: Some implementations already have a native condition system that is not based on CLOS, and it should be possible to integrate the native conditions and the ANSI CL conditions. Some people would like to define an ANSI Common Lisp subset that does not contain CLOS but does contain conditions.

phoe-krk 3y ago
Both of those reasons are pretty much stale nowadays. Contemporary implementation where conditions are standard objects are CCL, ECL, Clasp, ABCL, CLISP, SICL, LispWorks, and Allegro, leaving out pretty much only SBCL (which does this for bootstrapping reasons, such as having errors much earlier than CLOS) and probably Genera (which is hard to call contemporary). And AFAIK there are no alive subsets of CL whatsoever, let alone those which have a condition system but do not have CLOS.