Hacker News Reader

Comment by hayley-patton | Hacker News Reader

> but I find it hard to understand how Common Lisp compilers work – what with their readtables and read macros and normal macros

Read tables and reader macros are used in the reader, which is separate from the compiler. The compiler macroexpands normal macros though.

> what subsets are implemented before the rest

There are no obvious subsets in Common Lisp - see Baker on the matter <https://www.plover.com/~mjd/misc/hbaker-archive/MetaCircular...>.

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.

> is there any implementation guide on how a Common Lisp is/should be implemented?

You could do a lot better than the existing Common Lisp implementations, especially in compilers and GC, but the issues there are not specific to Common Lisp.

View on HN

> There are no obvious subsets in Common Lisp - see Baker

i think baker's point, and i'm sure you know it's also been discussed to death on #lisp at some point, that you can't choose one obvious set of fundamental special forms, in terms of which you can express a common lisp, because some of those forms can be in various ways expressed in terms of each other. his other point is that spec's special forms are underspecified. but i don't think that he's making a point that one can't take spec's special forms, treat that set of special forms as arbitrary, but working, and implement a common lisp with them. i've not given this subject enough thought, but do you by any chance have links to somebody making that point, that you can't in fact implement a common lisp using just special forms.

> 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.

> 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).

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.

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.

Reply on news.ycombinator.com