Re:Ask HN: Guide for Implementing Common Lisp
by pfdietz on Thursday February 01, 2024 @11:33PM
(#39225058)
> 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).
Re:Ask HN: Guide for Implementing Common Lisp
by lispm on Friday February 02, 2024 @03:58AM
(#39226627)
See here why Conditions is not defined in terms of CLOS:
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.
Re:Ask HN: Guide for Implementing Common Lisp
by phoe-krk on Friday February 02, 2024 @04:16AM
(#39226749)
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.
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.