This looks cool enough but it would need a big community to really change the common lisp landscape (in my opinion). I wonder how the lazy sequence support stacks up to Clojure, Haskell, etc. support.<p>One difficulty with promoting a more modern layer to common lisp is that Clojure is already such a productive and practical language. I have written a few common lisp books, and remain a fan of the language, and an upgrade does sound good.<p>I am curious to hear the opinions of the heavy hitters in the common lisp world.
One of the things I don't like about Common Lisp is the unusual names. Just on the basis of the linked page, CL21 doesn't fix that.<p>Take princ #"Hello, ${name}\n". Why not just use print like the rest of the programming world. Okay, some languages use writeln, etc. But princ? Why not print?<p>A little further down, we see while-let1. Why the number? If you want to call it "Common Lisp in the 21st Century" you need to clean up the syntax.
As a former common lisper, I don't see the point. Clojure is better in pretty much every respect and incorporates many fresh ideas (such as excellent concurrency support). Syntax is the least of CL's limitations. I didn't switch to Clojure because it was "easy" (quite the contrary).<p>And no, I do not miss reader macros. Perhaps more surprisingly, I don't miss CLOS at all, much as I always admired its design. It's just... Unnecessary.<p>What I do enjoy is STM, good performance, Java interop, ClojureScript, core.async and lots of excellent code with fresh ideas popping up all over the landscape.
In the examples I see nothing overly compelling which would justify fragmenting the mind share.<p>Some of them could possible be considered for alexandria <a href="https://common-lisp.net/project/alexandria/" rel="nofollow">https://common-lisp.net/project/alexandria/</a>. Admittedly I am not sure how alive development is but it certainly would be worth breathing new life into as it is probably the most heavily used CL library.<p>As things like STM and lazy which Clojure has, they have been implemented at the library level for CL.<p><a href="https://common-lisp.net/project/cl-stm/" rel="nofollow">https://common-lisp.net/project/cl-stm/</a><p>The beauty about a Lisp is that you can easily add so much on top of the language that will feel as if it was always there. CLOS is a good example of this.<p>In the case of JVM with CLojure, and of course others will disagree, I don't think accessing the Java ecosystem is a good thing. The mindset there is monolith "Enterprise Solutions" "Inversion of Control frameworks" which invariable mean systems that are so complex the authors don't even understand them and lets write XML above all else.<p>Also if you want CL->Javascript; Parenscript.
Interesting, but for looping I think a better point of comparison is iterate:<p><a href="https://common-lisp.net/project/iterate/" rel="nofollow">https://common-lisp.net/project/iterate/</a><p>In my personal opinion, the iterate loops read better than the code samples of the main page.
Three things I don't like about Common Lisp.<p>1. It has CLOS but it doesn't really embrace it in standard library. You have list, vector, hash-table, each with its own iterator function. You have lots of #with-xxx macro. All modern languages utilize the idea of common interface like #iterator or #dispoable. You can clearly see CLOS library and pre-CLOS library in CL. CL needs to eat its own dog food (CLOS) more.<p>2. It lacks basic practical API library, while another containing big complicate academic functions. Its #format function is probably Turing complete. It has function to format number in Roman numeral. But it doesn't have function to deal with datetime. No networking IO function. No Threading library.<p>3. Condition and Restart could take the idea from Dylan. Tying condition to available restarts, and making class hierarchy of them, is a better idea. This problem stems from CL not actually utilizing CLOS.<p>Also, PACKAGE should take the idea of LOCALE, allowing easier local package rename, and less symbol conflicts problem.
By the way, looking at the github there are 40 open issues 5 open pull requests and no changes to master for 6 months. I think this project may be dead, or at least on hold for the time being.
Another effort along the same lines:<p><a href="https://github.com/rongarret/ergolib" rel="nofollow">https://github.com/rongarret/ergolib</a>
I've been thinking about this for a while. I've wrote some thoughts I had over the years about modernising Lisp.<p><a href="https://news.ycombinator.com/item?id=9078444" rel="nofollow">https://news.ycombinator.com/item?id=9078444</a>
I can recommend having a look at GOOPS [1] (GNU Guile's implementation of CLOS) for inspiration. It provides multiple dispatch and facilitates overloading of existing functions (such as "+").<p>[1] <a href="http://www.wedesoft.de/oop-with-goops.html" rel="nofollow">http://www.wedesoft.de/oop-with-goops.html</a>
I think this is an okay idea, but the comparison to Clojure is really lacking. Why build on CL when you can build on Clojure? I get the inter-operability, but when <i>Multi-Threading and Multi-Processing</i> is listed under <i>Deferred</i>, Clojure could provide so much of that for free. <i>On</i> Clojure, etc.