> StumpWM was running on Common Lisp, now it is running
> on one implementation, specifically. Does it deviate from standard or> what is the technical reason behind it, that I may understand?
The standard doesn't specify specify how a lot of things that we need work, ej pipes, accessing a file's atime. Implementations do. StumpWM was never written in portable Common Lisp, so it is inaccurate to say to say it was 'running on Common Lisp'. There were always unsupported implementations. We just dropped support for all implementations except SBCL. I supported their David's decision because SBCL provides easy access to OS functionality through sb-posix and sb-unix which is something we need if we are to improve the event-loop. Also having several implementations of the same feature (ej the io-loop had an SBCL implementation and a fallback one) makes maintenance harder.
I could see the case for preferring ECL or CCL, due to binary size or a superior garbage collector but, CLISP is an abandoned implementation. Supporting it was becoming harder. For example, recently Joram took an inordinate amount of time to track where an error that only occurred on CLISP[0] was occurring on CLISP as Pressing V on the frame didn't work on CLISP. Granted the error was on our part for not writing the loop in a portable manner.
I hope CLISP development resumes as it provides a nice shelll experience for Common Lisp which may help newbies.
> SBCL cannot implement
> the readline due to licensing issues, and so many other> implementations.
SBCL cannot use readline[2] but it can certainly implement its functionality. See linedit[2] as an example. Although it is unmantained, mainly because as Loke said, most people don't use Common Lisp from the shell.That is incorrect. see. for a readline
[1]: If you agree with Stallman's ridiculous interpretation of what constitutes derived work.