A Rationale for Koioslisp
As I worked on Koioslisp, I was asked the same question numerous times: why? At first, this question surprised me: lispers create new dialects rather often, and indeed it is a rite-of-passage for new converts to write a simple lisp interpreter. But such languages are usually examples to demonstrate the ease of implementing lisp within itself, and as such Koioslisp cannot be one of their fold. Neither is it a proof-of-concept as are so many research lisps: while Koioslisp acknowledges their pioneering place as playgrounds of new ideas, Koioslisp is not the successor to Scheme or Kernel—and it does not pretend to be. Indeed, its model is the big fish in the small pond: Common Lisp, and as Koioslisp aims to replace it in such a position, it requires justification. Though Common Lisp is the industrial lisp par excellence, being, at least in my own mind, superior to almost every other language, it represents the swan song of Symbolics, and as such, it has begun to show some signs of staleness, being thus in need of revitalization. This is the task Koioslisp is to accomplish. An objection is raised—what about the new industrial lisps, like Racket, Clojure, or Qi/Shen? Why not use them instead of creating yet another language? The answer is that although they are important in their innovations, they have made decisions I regard as unfortunate: Qi/Shen and Clojure have added too much syntax to respectably call themselves lisps, and Racket, being a descendant of Scheme rather than Common Lisp, is primarily a lisp for programming language theory: it’s usefulness as a powerful tool is a great benefit, but it is secondary; the same indeed can be said for Qi/Shen, which also suffers the downside of having no Free Software definition. Clojure also has several disadvantages: the reference implementation relying on Java stack traces being an example—a more serious problem being the contradiction that its first major selling point was its use of the JVM (thus allowing, at least in theory, easy use of Java libraries), but now there are implementations on different platforms which are often incompatible with Java libraries, and thus many Clojure libraries. Thus, there are no alternatives I find acceptable, and so I have decided to provide one.
Now that we have outlined the context that produced Koioslisp, we must find how it manages to resolve these problems. The first priority, of course, is filling in the crucial areas that Common Lisp missed and cleaning the parts where it got messy: standardized sockets, concurrency, and better integration with CLOS; better file, readtable, user interface, time, and package support; case-sensitivity. Upon this, new constructs from other Lisp dialects (and sometimes from other languages entirely) are added in a tasteful manner: abstract data types, monads, logic programming support, list comprehension, a saner looping mechanism, lazy evaluation with explicit annotation, hygienic macros, and several new sequence types.
