In statically typed languages, you would have to predefine the output type. Such a function as bar couldn’t be written.

Make a better type system - number -> (nil | number) should do the trick to type bar. SBCL can infer that one.

It was introduced in SBCL 2.3.7 as (= *gc-real-time* *gc-run-time*) (approximately, timer precision is weird) holds for serial GC, but not for parallel GC.

What I am talking about is the general design of Lisp-based OSes, such as OpenGenera and Medley, or indeed Smalltalk, as compared to OSes built from statically-compiled languages such as C, C++, Modula-2, Oberon, and so on.

The following is kinda preaching to the choir, but no disagreements there. My point is that Interlisp and Lisp Machines have Common Lisp support, so CL programs don’t necessarily run on static OSes.

But the thing that unites these tools is that they are grafts: they are Lisp tools that run inside C-based OSes which come from a profoundly different school of computer design.

Please stop with this rubbish narrative - you even say later that Medley supports Common Lisp, and the Maclisp Lisp machine lineage did too. They’re all von Neumann, so not that profoundly different either. (See prior on RISC and high level languages too.)

While not a library, you may find Baker’s Metacircular semantics for Common Lisp special forms useful. There isn’t a particular “core” of Common Lisp, so there are a few inverses, e.g. implementing tagbody/go with catch/throw and the reverse.

Behold, a Lisp:

(identification-division
 (program-id :hello-world))
(procedure-division
 (main
  (display "Hello, world!")
  (stop run)))

ISWIM

Without type declarations I have CCL computing (fib 39) in 0.365 seconds and (fib 39) in 0.743 seconds. This is because CCL inlines the fixnum case for generic addition, and SBCL does not.