6 ms·

SICL – A fresh implementation of Common Lisp

77 points by phaer 12y ago

auvi 12y ago
This is a good candidate for Show HN!
- phaer 12y ago
  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.
howeyc 12y ago
I don't understand. This looks like an implementation of lisp functions on top of an already existing Common Lisp implementation.
- eudox 12y ago
  Most Common Lisp implementations are written in Common Lisp.
  - howeyc 12y ago
    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?
    - zachbeane 12y ago
      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.
    - mmphosis 12y ago
      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 http://www.sbcl.org/porting.html
    - rayiner 12y ago
      > 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 12y ago
        Right, this is what I was missing in my thought process. Thanks.
    - wcummings 12y ago
      You bootstrap it w/ a binary build, generally
    - crististm 12y ago
      It's exactly like building a C compiler if it is written in C. You just happen to have gcc around and the problem is just "invisible" in that case.
jerry_ming 12y ago
looks cool! I hope new impl can remove the bad parts from std. CL
- brudgers 12y ago
  What parts of Common Lisp are bad? Wouldn't removing them require revising the standard [ANSI INCITS 226-1994 (R2004)]?
  - jlarocco 12y ago
    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_pn.htm#make-pathname http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_p...
    - arethuza 12y ago
brudgers 12y ago
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 12y ago
  Probably best known for McCLIM, the free implementation of the Common Lisp Interface Manager.
wirrbel 12y ago
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 12y ago
  The lisp internet is horrific
616c 12y ago
Cool, also of interest to people here might be cl21, a CL modernization effort by Eitaro Fukamachi. http://cl21.org/ http://cl21.org/
- adwf 12y ago
  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.
kjs3 12y ago
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 12y ago
  It's not a new Lisp or Lisp-like language, but an implementation (in progress) of Common Lisp, so not really comparable.
_delirium 12y ago
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.
scottlocklin 12y ago
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!
- pohl 12y ago
  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.
- enupten 12y ago
  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 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).
  - orbifold 12y ago
sedachv 12y ago
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.

77 points by phaer 12y ago

auvi 12y ago

This is a good candidate for Show HN!

phaer 12y ago
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.

howeyc 12y ago

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

eudox 12y ago
Most Common Lisp implementations are written in Common Lisp.
- howeyc 12y ago
  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?
  - zachbeane 12y ago
    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.
  - mmphosis 12y ago
    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 http://www.sbcl.org/porting.html
  - rayiner 12y ago
    > 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 12y ago
      Right, this is what I was missing in my thought process. Thanks.
  - wcummings 12y ago
    You bootstrap it w/ a binary build, generally
  - crististm 12y ago
    It's exactly like building a C compiler if it is written in C. You just happen to have gcc around and the problem is just "invisible" in that case.

jerry_ming 12y ago

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

brudgers 12y ago
What parts of Common Lisp are bad? Wouldn't removing them require revising the standard [ANSI INCITS 226-1994 (R2004)]?
- jlarocco 12y ago
  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_pn.htm#make-pathname http://www.lispworks.com/documentation/HyperSpec/Body/f_mk_p...
  - arethuza 12y ago

brudgers 12y ago

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 12y ago
Probably best known for McCLIM, the free implementation of the Common Lisp Interface Manager.

wirrbel 12y ago

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 12y ago
The lisp internet is horrific

616c 12y ago

Cool, also of interest to people here might be cl21, a CL modernization effort by Eitaro Fukamachi. http://cl21.org/ http://cl21.org/

adwf 12y ago
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.

kjs3 12y ago

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 12y ago
It's not a new Lisp or Lisp-like language, but an implementation (in progress) of Common Lisp, so not really comparable.

_delirium 12y ago

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.

scottlocklin 12y ago

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!

pohl 12y ago
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.
enupten 12y ago
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 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).
- orbifold 12y ago

sedachv 12y ago

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.