[whartung]

At what point does a CL implementation need to be before it can start hoovering up the available library code from other implementations (license permitting).

How many LOOP macros does the community need, particularly when bootstrapping an implementation, as an example.

Similarly with, arguably 70-80% of the runtime. The CL spec is dominated by the large library which, ideally, should be mostly portable CL, at least I would think.

[klibertp]

You're not the first one to think so: https://github.com/robert-strandh/SICL

I'm unsure how complete it is, but it seems to cover much of the standard.

[v9v]

Here's a recently-written summary of the different libraries in SICL (including each library's purpose and status) http://metamodular.com/SICL-related-libraries/sicl-related-l...

[g2963]

a hypothetical portable layer exists, but it starts diverging once deployed, because of cleanups, refactoring, or implementation specific hacks.

LOOP is a great example, because all loop is just MIT LOOP version 829, originally cleaned up by burke. but nobody can resist deploying their personal architectural touch, so while the basic framework of loop remains identical across impelementations, there's superficial refactoring done by pretty much everyone. if you take SBCL and franz lisp as state of the art in free software and commercial respectivaly, they have equally solid improvements on original loop, that actually produce incompatible behavior in underspecified corners of spec. respective developer communities are very defensive about their incompatible behavior being the correct behavior of course. beach's SICL from sibling comment is the xkcd joke about standards "20 standards? we need a new standard the unifies them all! -- now we have 21 standards"

LOOP in this case is a very simple example, but for example CLOS was originally implemented on top of PCL, Portable CommonLoops, an interlisp system, that was massaged into being compliant CLOS over years. for example sbcl uses a ship of theseus PCL, but franz lisp did from scratch rewrite. the hypothetical portability of that layer is significantly trickier than LOOP since clos is is deeply tied to the type system, and the boundary between some hypothetical base system common lisp and its clos layer becomes complicated during system bootstrapping. but that's not all! of course clos has to be deeply tied to the compiler, the type system, all kinds of things, to provide optimizations. discovering the appropriate slicing boundary is difficult to say the least.