
SICL – A fresh implementation of Common Lisp - phaer
https://github.com/robert-strandh/SICL
======
scottlocklin
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!

~~~
sedachv
> 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?

> 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.

~~~
TeMPOraL
_> > 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?_

Especially when backed up by QuickLisp? Together they seem to be extremely
good and quite easy to use.

------
616c
Cool, also of interest to people here might be cl21, a CL modernization effort
by Eitaro Fukamachi.

[http://cl21.org/](http://cl21.org/)

~~~
adwf
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.

------
_delirium
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.

------
brudgers
The author Robert Strandh is[was?] a Professor at the University of Bordeaux.

[http://dept-info.labri.u-bordeaux.fr/~strandh/index.en.html](http://dept-
info.labri.u-bordeaux.fr/~strandh/index.en.html)

~~~
Tomte
Probably best known for McCLIM, the free implementation of the Common Lisp
Interface Manager.

------
howeyc
I don't understand. This looks like an implementation of lisp functions on top
of an already existing Common Lisp implementation.

~~~
eudox
Most Common Lisp implementations are written in Common Lisp.

~~~
howeyc
Yes, but to be a new implementation shouldn't I be able to install it without
already needing Common Lisp?

For instance, I can install SBCL without already having another Common Lisp
implementation right?

~~~
rayiner
> Yes, but to be a new implementation shouldn't I be able to install it
> without already needing Common Lisp?

No? E.g. Clang is a C++ implementation that you can't install without an
existing C++ compiler.

~~~
howeyc
Right, this is what I was missing in my thought process. Thanks.

------
sedachv
An earlier project in a similar vein is Yuji Minejima's Sacla
([http://homepage1.nifty.com/bmonkey/lisp/sacla/index-
en.html](http://homepage1.nifty.com/bmonkey/lisp/sacla/index-en.html)), an
unfinished, metacircular implementation of Common Lisp in portable Common
Lisp.

------
auvi
This is a good candidate for Show HN!

~~~
phaer
I think so too, but I did not submit it as such because I am neither the
creator nor a contributor to the project, just found it on the net.

------
kjs3
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?

~~~
_delirium
It's not a new Lisp or Lisp-like language, but an implementation (in progress)
of Common Lisp, so not really comparable.

------
wirrbel
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 ;)

~~~
atratus
The lisp internet is horrific

------
jerry_ming
looks cool! I hope new impl can remove the bad parts from std. CL

~~~
brudgers
What parts of Common Lisp are bad? Wouldn't removing them require revising the
standard [ANSI INCITS 226-1994 (R2004)]?

~~~
jlarocco
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.

[1]
[http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_p...](http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_pn.htm#make-
pathname)

~~~
TeMPOraL
> _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 ;).

~~~
malisper
I recognized the talking over the phone thing from SICP.

[http://youtu.be/X21cKVtGvYk?t=22m40s](http://youtu.be/X21cKVtGvYk?t=22m40s)

~~~
TeMPOraL
Yup, that's the source, thanks :).

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).

