This got me thinking: is there any implementation guide on how a Common Lisp is/should be implemented?
SICL is probably the best modern version of CL written in CL from a design standpoint, even if it's not taking over SBCL's role anytime soon: https://github.com/robert-strandh/SICL It uses some fancy bootstrapping to have the whole language available early, e.g. their definition of class 'symbol is:
(defclass symbol (t)
((%name :reader symbol-name)
(%package :reader symbol-package))
(:metaclass built-in-class))
(define-primitive-object
(symbol :lowtag other-pointer-lowtag
:widetag symbol-header-widetag
:alloc-trans %make-symbol
:type symbol)
...
(name :ref-trans symbol-name :init :arg)
(package :ref-trans symbol-package
:set-trans %set-symbol-package
:init :null)
...)
There are quite a few open source Lisp implementations in addition to SBCL that you can peruse [2] (follow links to CL's supported by Quicklisp). If you are targeting a specific platform (JVM or embedded), then ABCL/ECL; see Clasp for using LLVM.
To reuse modules for writing your own lisp, see SICL [3]
[1] http://t3x.org
Depending on the design, macros may also be expanded already; the compiler works with macro-expanded code.
The easiest approach, from a boostrapping point of view, is to write an interpreter in some host language. Get macro expansion and read macros working in the interpreter, and then add a compiler.
If you are thinking of a Common Lisp compiler as working on a text file, you're thinking about it wrong. In Common Lisp, you can invoke the COMPILE function on a lambda expression that you cons up at runtime and that never is in a textual representation.
As a general rule, don't reimplement a Lisp except as a learning exercise (in which case, you're not going to reimplement Common Lisp; it's too big.)
It implements everything down to assembler on bare metal.
You can easily analyze what is going on by disassembling the code:
> (disassemble car)
Disassembly for #
entry:
2073E8 83F8F8 (cmp eax #xFFFFFFF8)
2073EB 0F8506000000 (jnz L0)
; (set! rax (car rdi))
2073F1 488B47FE (mov rax (mem64+ rdi #x-2))
2073F5 F8 (clc)
2073F6 C3 (ret)
L0:
2073F7 E9749CFFFF (jmp (+ rip #x-638C))
> 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.
Anatomy of LISP - John Allen https://archive.org/details/anatomyoflisp0000alle/
*Includes the classic mark-sweep GC from McCarthy 1960
Nolan: That's the neat thing -- you don't.
Lisp compilers operate on Lisp data structures -- generally speaking, mostly lists and atoms. The 'read' function is what turns text into these data structures; reader macros alter how this function operates and control what data structures will be emitted by the reader. This really is the neat part about Lisp -- it's much simpler to write a compiler that consumes an AST directly than one that consumes text, and the AST is expressed directly in terms of Lisp's primitive data structures which you can easily write your own functions over. And it's a relative doddle to write a reader for s-expressions compared to other expression formats. Join these two relatively simple pieces together and you have a complete Lisp compiler system.
As for regular macros, they transform the AST before it's evaluated or compiled. So they come into play after the reader has consumed the source and produced an AST, but before the evaluator or compiler can work.
Make a Lisp is more Clojure-flavored than Common Lisp, but it might still be nice to examine because of how many different implementation languages it has been done in by various authors.
It also breaks down the implementation process into 11 distinct steps which are easy to understand.
That might be a way to start.
Or not.
Good luck.