Sources

https://github.com/robert-strandh/SICL

Description

Quoting Robert Strandh from IRC:

Basically, I think of SICL as a collection of modules, implementing various parts of the Common Lisp standard. The difference between those modules and existing modules in other implementations has to do with modern programming practice, test, documentation, and especially implementation-independence. The `modern programming practice' part involves using the full Common Lisp language, and especially more generic functions that most equivalent existing modules do. Now, some people have interpreted this collection of "modules" to mean that they can write a primitive Common Lisp in (say) C, and then start loading SICL modules to obtain a complete implementation. That is not the case.

A large part of SICL is Cleavir, an implementation-independent framework for writing Common Lisp compilers. It uses CLOS to allow implementations to customize it for their needs. And I plan to implement a bunch of standard compiler-optimization techniques on intermediate code, plus some of my own. I don't think it has ever been attempted before to write an implementation-independent compiler for Common Lisp. The compiler is a big, customizable module though. The word "framework" is more appropriate. And it exists. Clasp is using it for its good compiler.

So, one example that appears to baffle people is that SICL LOOP uses LOOP for its implementation. But there is no contradiction here, because the LOOP macroexpander runs at, well, macroexpansion time, which will happen in the host Common Lisp system during bootstrapping. After that, there is no trace of the LOOP macro.

One of the first modules I started was the "sequence functions" module. It has taken me three attempts to finally have an acceptable strategy for how to do it. And I haven't even finished implementing the module according to that strategy (which is in the ELS paper this year).

My secret hope is that the SICL modules will be better than the native ones in many respects, so that implementations would prefer the SICL ones. The net result would be that we can cut down on total maintenance of all Common Lisp implementations. The only remaining part is that, once I have all the modules (I pretty much do), there would be no reason to refrain from creating a complete Common Lisp implementation out of them.

I think in SICL, because I have faster generic dispatch, fewer things would be made out of ordinary functions and built-in classes, and more things out of generic functions and standard classes. That way, it would be easier to create subclasses, or entirely different classes participating in the same protocol.