Yeah, I've already decided to make my next minor project in cl21 and see how it goes. Got to be minor though as there's a fair bit of syntax still to be nailed down. But as a modernisation project it's looking promising. It's trying to remove a lot of the niggling annoyances from the CL spec like inconsistent parameter ordering on functions, whilst also adding a bit of sugar like easy hash-table definition.
Is it fresher than the other dozen or two Lisps, Lisp-likes and Lisp-ish language projects that have popped up in the last year or so? Is it more interesting?
The quite large amounts of discussion (see the .tex files in the repository) is an interesting aspect of this project. I like the approach of carefully thinking through components of a CL implementation in a modular fashion, along with documenting the rationales.
If you want to compile it, you need a Common Lisp implementation. SBCL, CLISP, and Clozure CL can usually do it, though SBCL is the most reliable and well-tested.
There are binary versions available for download, too. They've been precompiled with an existing CL compiler.
Most likely you are right that you can install without already needing Common Lisp for your particular platform, but that is not always the case. http://www.sbcl.org/porting.html
One of the tragedies of Common Lisp programming: good Lisp hackers seem more interested in writing yet another Common Lisp than extending the capabilities of existing ones.
It's not like there isn't work to be done: writing decent native array and higher order mathematical primitives in any lisp would be a huge improvement over the existing state of affairs; we know SBCL and CMU-CL have the compiler for it (Fateman wrote about this in the 80s for pete sake), but ... no such thing exists. A package management system that you don't have to invoke lucifer to use would also help (leiningen for CL). A common threading model that makes sense would also be nice. Yes, yes, you get some half assed threads on some platforms in some lisps; big deal. Make them work everywhere instead of developing ... yet another Common Lisp.
For open source, we already have: CLISP, SBCL, CMU-CL, GCL, ECL, ABCL, MKCL, MCL, Movitz, OpenMCL, CLiCC, Kyoto, CCL, Jatha, ThinLisp, UABCL, WCL, XCL.
For pay-for Common Lisp, Corman, Allegro, LispWorks and doubtless some others. Obviously, the world cries out for more Common Lisp implementations!
> A package management system that you don't have to invoke lucifer to use would also help (leiningen for CL)
What do you think are the biggest problems with ASDF?
> A common threading model that makes sense would also be nice.
Which memory model should this threading system guarantee? Which concurrency primitives? How is this going to be supported on all the different platforms the different CL implementations are available for? What do you think are the biggest problems with bordeaux-threads?
CLiCC and ThinLisp are deployment tools and not full-blown implementations. Neither of them have been actively developed in the last decade (I was the last person to touch ThinLisp about 8(?) years ago). WCL is a shared library from the 90s. Kyoto, GCL, ECL, MKCL are forks/descendants of the same implementation (in that chronological order). Corman Common Lisp hasn't been developed in years.
> good Lisp hackers seem more interested in writing yet another Common Lisp than extending the capabilities of existing ones.
If you actually look, the two sets of people (Lisp library/application hackers and Lisp implementation maintainers) are pretty distinct. If someone wants to make another Common Lisp implementation, that doesn't take resources away from Common Lisp libraries, and it doesn't fracture the community (that's why standards are a good thing). It would be great to have better array libraries and package managers and thread libraries. Saying that having less Common Lisp implementations will make those things happen is a false dichotomy.
I never said having fewer CL implementations will make these things happen. Obviously, nothing will make these things happen. I simply wonder why people want to build yet another common lisp, rather than fixing one or more of the vastly too many we have already. The world really doesn't require any more beige common lisp implementations no matter how much fun it is to write one.
SICL appears to be an effort to alleviate some of that, judging from this:
[SICL] is intentionally divided into many implementation-independent modules that are written in a totally or near-totally portable way, so as to allow other implementations to incorporate these modules from SICL, rather than having to maintain their own, perhaps implementation-specific versions.
See the issue is you and I have very different ideas of what work needs to be done:
I don't use higher-order mathematical primitives in my work, so that's out. I avoid threading like the plauge (even in non-lisp code), and I've never had to sacrifice a single goat to get quicklisp to work.
I would also add parametric types to that list. I've always found it really annoying not to be able to define a type like "array" with element-type, dimensions and things (other than the global variable hack).
Did you mean Scientific computing ? FEMLISP is refreshingly well written (and fast), and the new version Matlisp I'm writing should also be as good (if less elegant and MOP-py). See: https://github.com/enupten/matlisp/wiki .
The "einstein-sum" macro at the end actually generates code which on SBCL is about 20-40% slower than equivalent C code (but this is all naive cache-friendly loops).
FEMLISP is pretty cool. Sadly, when I need to do finite element analysis, I end up doing it in Matlab, because vastly more work has been done there. I guess the next time I have to make my own FTDT solver, I will think about doing something like this.
Thanks for working on Matlisp; it's a great idea. Have a close look at Torch7 and how they managed to bake pthreads and CUDA into their "THTensor" class (aka, the descendant of the Lush -idx- array type). I don't know if it's the best that can be done, but I trust what has been done there more than what is happening in other areas, as this ends up being used on serious problems.
I think a lot of the features Julia julialang.org has, could be implemented just as easily in Common Lisp. Macros in general are much simpler to use to generate domain specific code than templates in C++ are, yet there are tons of very high effort numerical algorithms implemented in C++ and virtually none in Common Lisp.
A CL with useful math facilities and a decent parallel model would be, like, a zillion times better than anything happening in Julia land.
It's not like there isn't a market for something like this: the existence of Incanter and the past existence of XLispStat ought to have demonstrated this. Incanter, of course, will never have adequate numerics performance because the JVM is garbage for numerics, and probably always will be.
As I said: Fateman demonstrated that this is possible using CMU-CL or Allegro or whatever it was ... decades ago. Sadly, it never happened.
Yes, maybe it wasn't clear, my comment was meant as a reinforcement of your statement. The einstein-sum example is in line with what some C++ libraries can do, but I expect the common lisp implementation to be much simpler. Even more complex libraries like deal.II for pde-solving would probably benefit immensily from a domain specific language instead of a C++ interface.
I was going to write a provocating comment on how I expected to find a repository that did not use a Markdown or restructured Text (or akin) Readme file and how ignoring advances in the open source community was a reoccuring pattern with lisp. Then I double checked clojure repository for comparison and decided that my comment was pretty nonsensical ;)
Most of the bad parts come from Lisp being so old and the standard being written at a time when nobody knew what was going to win out.
Look at "make-pathname" [1], for example. It was made as general as possible as a compromise between all the different filesystem path representations used at the time. On modern systems, several of the parameters, like the host, device, and version don't really make sense any more, but they're still there for backwards compatibility.
Another thing that bothers some people (not me) are function names like "car" and "cdr", which come from the assembly language instructions of the 1950s era computer where the first Lisp was implemented. I think most people use "first" and "rest" these days, but car, cdr, cadr, etc. are still used all over the place.
Somewhat related, there's more inconsistent naming than in most languages. The destructive form of concatenate is nconc, but the destructive form of reverse is nreverse, etc.. Most built-in predicates end with "p", but some of the older ones don't. These days there's pretty solid consensus on how things should have been done, and how they should be done in the future, but we're still stuck with the old stuff.
It's basically 60 years of backwards compatibility concessions.
You're right, removing the bad parts of Common Lisp would technically require coming out with a new version of the standard, "Common Lisp 2015" or something, but I don't think anybody has proposed doing that. My guess is it's easier to just come out with a new Lisp dialect and hope people start using it, like Clojure has done, than the massive resource sink of coming up with a revised standard.
> Another thing that bothers some people (not me) are function names like "car" and "cdr", which come from the assembly language instructions of the 1950s era computer where the first Lisp was implemented. I think most people use "first" and "rest" these days, but car, cdr, cadr, etc. are still used all over the place.
What I often see on the Internet is people complaining about car/cdr and suggesting to replace them with first/rest or equivalent. Most of the times those people don't understand why doing so is a bad idea.
Cons cells can be (and are, all the time) used to build arbitrary data structures, not just lists. "first" and "rest" or "head" and "tail" make sense if you're dealing with a linked list (and notice, that Common Lisp does provide you such named functions), but they are not right names if your structure is a tree, or a graph (yes, you can build cyclical structures with cons cells).
Sure, car/cdr terms are relicts of the old architecture, but I'm yet to see someone propose names that are agnostic to data structures constructed with cons cells. And, as some old Lisp hacker mentioned somewhere, car/cdr combinations like caaddr, etc. are easy to say over the phone ;).
The thing about revising a standard is that it's a social task and not a technical one, and the cost of getting everybody on board is accommodating differing opinions. See the sibling about nil vs '() vs #f. All this is to say, if you want to get the CL hackers on board, you need to meet their needs, at least partially, in addition to cleaning out the cruft; and your cruft might be the hill that I choose to die on.
I've got a PDF somewhere of Richard Gabriel's notes on the history of Lisp; it sheds interesting (if opinionated) light on the evolution of Common Lisp.
> Look at "make-pathname" [1], for example. It was made as general as possible as a compromise between all the different filesystem path representations used at the time. On modern systems, several of the parameters, like the host, device, and version don't really make sense any more, but they're still there for backwards compatibility.
As it happens, I'm at the beginning of writing a CL for a very constrained, very weird little environment (hope to have a Show HN about it in a few months to a year), and the host and device parameters are extremely useful to me.
They're keywords; you needn't use them if you don't want them.
> My guess is it's easier to just come out with a new Lisp dialect and hope people start using it, like Clojure has done, than the massive resource sink of coming up with a revised standard.
Which is sad, since a new standard (say, a CL-2015 package…) would be able to build on top of much of what is really good about CL.
> As it happens, I'm at the beginning of writing a CL for a very constrained, very weird little environment (hope to have a Show HN about it in a few months to a year), and the host and device parameters are extremely useful to me.
I would love to see an example of pathnames being useful today. In my experience they're the only part of Common Lisp that is an active impediment to getting work done on a Unix system. It would be awesome if we could have a generic file naming mechanism that would also represent URIs. Unfortunately Common Lisp pathnames manage to suck at both Unix filenames and URIs.
I'm in the minority, but that's something that annoys me about Scheme. Lisp-style list processing code is more concise when nil is false. I also think array-processing or Haskell list style code is better than Lisp style list code, so IMO most Scheme code ends up with the worst of both worlds.
http://cl21.org/