SICL – A fresh implementation of Common Lisp
github.com
github.com
For instance, I can install SBCL without already having another Common Lisp implementation right?
There are binary versions available for download, too. They've been precompiled with an existing CL compiler.
No? E.g. Clang is a C++ implementation that you can't install without an existing C++ compiler.
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!
[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.
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).
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.
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.
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?
> CLISP, SBCL, CMU-CL, GCL, ECL, ABCL, MKCL, MCL, Movitz, OpenMCL, CLiCC, Kyoto, CCL, Jatha, ThinLisp, UABCL, WCL, XCL
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.
> What do you think are the biggest problems with ASDF?
Especially when backed up by QuickLisp? Together they seem to be extremely good and quite easy to use.
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.
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.
[1] http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_p...
http://www.lispworks.com/documentation/HyperSpec/Body/f_car_...
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 ;).
I also highly recommend those lectures to everyone who haven't seen them. There's a lot of insight there (and even more in SICP book).
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.
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'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.