Have they said whether it's a complete CL implementation or just a subset? I have the impression that it gets asymptotically more difficult as you approach the finish line.
Assuming you aren't just talking about how any project becomes harder to fix bugs in once you've fixed the easy bugs, it only gets more difficult as your approach the finish line if you don't plan on making a CL implementation from the start.
It's really easy to make something that kind-of looks like CL by use of clever smoke and mirrors, and many "Lisp in X" projects do so. See e.g. parenscript's LOOP implementation.
Other notes:
- Implementing CLOS is a massive undertaking, but there are two reasonably good portable implementations of it (Closette and PCL).
- The numeric tower is sufficiently loosely specified that you can typically get away with using any existing bignum library.
- LOOP and FORMAT are annoying to implement just because they are big DSLs. I'm also not aware of any portable implementations of them (though SICL might have one).
- Most of the rest of the effort will be spent on implementing things that interact with the system. Streams/files/pathnames are all annoying
LOOP can be cheated a bit with, as it originated in separate semi-portable package AFAIK, just like for CLOS you can use PCL for heavy lifting. Specifically there was MIT LOOP package that wasn't exactly ANSI compliant but got you significant portion of the way there.
Also, if you're willing, it's possible to just lift a bunch of code from SBCL/CMUCL due to permissive license.
I meant implementing CLOS in any language is a large undertaking, but then pointed out two portable implementations in CL one could use, to save that work.
