You will see that a few people ask: why care in the face of such impressive native code compilers: Steel Bank, Clozure, and Embedded (although maybe ECL is short for something else; ironically they also needed a new maintainer as the previous guy became busy): porting and bootstrapping.
With CLISP that worked on ARM, I am not sure how much slower it would have been to port SBCL to ARM architectures, which is less <1 year of usable, even though CCL had it for years (and why I started compiling CCL using the AUR mechanism on Arch Linux prior to using SBCL in the official repos, for later playing with RPi stuff).
So, thanks for the awesome Lisp, and thanks to you guys specifically because it is niche and thankless with so many jokes about the Lisp/CL community. Even on HN, you can hear the mumbling when people post Lisp articles.
So I noticed that the original title of this link (at least when I started reading) was CLisp, and it had not even occurred to me it was C( language) Lisp maybe, but still I though the caps must br wrong. On their site it is full CAPS, even though that peeves a lot of Lispers who will tell you that is like original Lisp Lisps (or LISP Lisp family languages, to be funny).
So for the past 5 years, it's been almost all the work of sds, Sam
Steingold. Huh. I was expecting Bruno Haible to still be involved, but he seems to be doing almost nothing nowadays. Well, it's not unusual for a free project to be the labour of only a single person, but it's typical to have a lot of small drive-by contributions. Almost nobody except sds has done anything for CLISP for the last five years, which could explain why there have been no releases. But there's been a lot of work being done! Look at all those lines of code that have been modified! Maybe all they really need is a release manager.
Well, does the thing build right now?
$ ./configure
...
./configure: libsigsegv was not detected, thus some features, such as
generational garbage collection and
stack overflow detection in interpreted Lisp code
cannot be provided.
Please install libsigsegv like this:
...
Okay, fine, I'll install it. Let me try again,
$ ./configure
...
./configure: libsigsegv was not detected, thus some features, such as
generational garbage collection and
stack overflow detection in interpreted Lisp code
cannot be provided.
Please install libsigsegv like this:
...
Okay, maybe my version of libsigsegv is too old. But a version newer than Debian's oldstable is mighty demanding of a package whose development has slowed down to nothing. So at this point I'm considering if I want to debug their build system or not. I might. Or perhaps someone else will. My conclusion is that CLisp development is almost dead, yet there certainly is something worthwhile releasing here since the last release in 2010.
>Some day when I have the time, I will rip out all the autocrap stuff and replace it with a 5 line shellscript that calls uname -s.
And packagers will everywhere will hate you for it.
I've recently written many GNU Guix package recipes, and packages using Autotools are the ones I tend to have the least headaches with. CMake and Waf are so-so I think, perhaps lacking in maturity, but I didn't have that much experience with them. Custom/hand-written Makefiles and ./configure scripts are the worst.
Just learn Autotools, get over the fact that they contain backwards-compatibility crud (that you can just ignore, or how does it hurt you?), and stop the FUD. Even if only targeting GNU and BSD systems, there is already enough diversity and library detection boilerplate to make it worth using a proper build system, and Autotools is the most mature one out of the bunch.
It's even more important for unconventional systems like Nix/Guix where software is to be built in very special ways, where hard-coded assumptions in build systems hurt, especially if a custom one; if it's a known one then even if hard-coded it will probably conform to some typical pattern of use of that build system so one can use tooling to automatically fix packages using that build system, and in the case of Autotools that isn't necessary in first place because everything is parameterized and flexible to hell and back.
Also please do use pkg-config. Like Autotools, it's not perfect either, but I could write another two paragraphs on how helpful it is in bringing consistency, toolability, etc. into build/packaging systems...
My entire build can run in less time than a ./configure script.
It doesn't require developers to run ./autogen.sh, or to have autotools installed (in their correct versions).
It doesn't contain obscene amounts of indirection, where the actual libraries live in a hidden directory called .libs (looking at you, libtool).
It doesn't make you write m4, or Makefile.am files with all these magic incantations. It doesn't make you delve into the guts of these crufty systems when things don't work the way you expect.
If you want build systems to satisfy your use cases, publish some doc of best practices and capabilities that all build system interfaces should provide. If I'm convinced I'll be happy to conform to the interface you need. But there is no way you're going to convince me that everyone needs to just keep using autotools (a specific implementation) forever. I hate them.
I mean, by that logic, why are you doing something new like GNU Guix when everybody already knows/uses APT, RPM, BSD ports, etc? "Just learn [them], get over the fact that they contain backwards-compatibility crud (that you can just ignore, or how does it hurt you?), and stop the FUD."
Or maybe it is worth breaking with the past sometimes, when you think you can do better.
All of the things you list are annoyances with crud that exists to satisfy this or that use-case which I suppose you personally don't need, which doesn't mean they don't have purposes. I would also say they are all minor annoyances. Your builds run faster than a ./configure script? Not building particularly large projects I suppose. Installing autotools? Big deal! I don't know when one needs to write m4, but the Makefile.am format looks rather clean and minimal to me; I don't see how you could have something much cleaner without losing a lot of generality. And having to delve into the guts of some obscure system is exactly what I had to do a few times because some piece of software refuses to keep with the convention and just use Autotools.
The documentation you ask for is idealistic and unrealistic. GNU Autotools are free software, and with decades-old proven maturity; I see no reason not to use them. The only pseudo-reasons I see are NIH, FUD, etc.; the usual.
GNU Guix (and before that, Nix) is fundamentally different from all other package managers, so that analogy makes no sense here unless you have some radically different innovative build system.
Turns out that configure was just caching the past test for libsigsegv. I cleared the cache and was able to build. The test suite ran for a good chunk of time but segfaulted.
So it doesn't look like CLisp is beyond all hope, just a little lonely.
> So for the past 5 years, it's been almost all the work of sds, Sam Steingold. Huh. I was expecting Bruno Haible to still be involved, but he seems to be doing almost nothing nowadays. Well, it's not unusual for a free project to be the labour of only a single person, but it's typical to have a lot of small drive-by contributions. Almost nobody except sds has done anything for CLISP for the last five years
This is how you smell a future dead project.
If only one person has done anything significantly, with nobody around to "pick up the chops" and learn the code-base, chances of anyone willing to pick up 147MB of sources and claiming responsibility for it is pretty slim.
On the flip side, we do have a gazillion free Common Lisp implementations around. If this one falls dead, will the Common Lisp community have lost anything of significance?
From what I can tell, the only ones "losing" something here would be GNU losing a thing they can claim being made by them, a feather from their highly featured hat.
But my general impression is that GNU is already critically understaffed anyway, so it might actually do them some good, and avoid having dead-weight like this steal resources from their remaining projects.
GNU CLISP does not get any resources, human or otherwise, from the GNU project. If Sam stops working on CLISP, he's not going to start working on GNU Emacs or gdb instead.
>But my general impression is that GNU is already critically understaffed anyway, so it might actually do them some good, and avoid having dead-weight like this steal resources from their remaining projects.
GNU is not an organization that employs or assigns people to work on specific projects (with very few exceptions).
Don't know about libsigsegv. configure mumbles something about needing libsigsegv-2.10, but I've got 2.10-2 installed all right. To be fair, configure also suggests a very special installation procedure, which I haven't tried.
Anyway, the configure script succeeds with "./configure --ignore-absence-of-libsigsegv", a subsequent make, too. This is on Trusty.
CLisp is a GNU implementation of common lisp. Other popular free implementations include SBCL and CMUCL, both of which have made recent releases. GCL is the other GNU common lisp, which also made a release more recently than CLisp.
This is true in the same sense that the GIMP is the "GNU Image Manipulation Program". It's just a label, and a license choice, without much real meaning behind it. GCL is also called "GNU Common Lisp".
Hm, indeed, I was expecting to see CLisp follow the GNU coding standards, but it doesn't seem to. I know GIMP does, though, and it consistently uses GNU terminology (free software, not open source, etc). Being GNU does mean something for most GNU packages. In Octave we also follow most of the GNU coding standards, for example, and we benefit from FSF and GNU infrastructure.
I sent a bug report to the clisp-list mailing list just days ago, but it didn't come through.
Date: Mon, 04 May 2015 07:20:34 -0700
To: Clisp list <clisp-list@lists.sourceforge.net>
Subject: Invalid backquote reduction: ,',@x
Hi all,
I've discovered that (admittedly, an old version) of CLISP is
reducing a certain backquote syntax according to a hare-brained
user expectation instead of diagnosing en error.
Pardon me if this has been fixed more recently.
In a double backquote, if you quote a splice, and then unquote
the quote, the unquote and quote cancel out naively.
(Is that, by chance, my doing???)
CLISP:
[1]> (let ((a '(1 2 3))) ``(a b c ,',@a))
'(A B C 1 2 3)
Of course the above quote form then eval-s to (A B C 1 2 3).
Clozure CL:
? (let ((a '(1 2 3))) ``(a b c ,',@a))
(LIST* 'A (LIST* 'B (LIST* 'C (LIST (QUOTE 1 2 3)))))
? (eval *)
> Error: Too many arguments in form (QUOTE 1 2 3) .
The Clozure output (IMO correct) illustrates precisely what
wrong, so I almost don't have to say anything more.
The construct ',@a is (QUOTE ,@A) which stuffs zero or more
things into the QUOTE syntax where there should be exactly
one, potentially resulting in an incorrect quote syntax.
So given (UNQUOTE (QUOTE (SPLICE A))), then only if A
generates exactly one item, are we justified in
"canceling" the QUOTE and UNQUOTE! In other cases,
it is invalid and should be diagnosed as an abuse of
QUOTE.
* * *
Is there a possibility that this could be documented
as an extension? I think it's too much of a special case
in its present form, because it only works when the
QUOTE form is an immediate argument of the UNQUOTE,
as seen from this CLISP output:
[2]> (let ((a '(1 2 3))) ``(a b c ,(list ',@a)))
(LIST 'A 'B 'C (LIST (QUOTE 1 2 3)))
We might imagine that a possibly meaningful
extension (which swiftly reveals itself to be otherwise)
along these lines:
"If a splice is the child, direct or indirect,
of an unquote, then the unquote *and all
intervening syntax* distributes over the splice,
as if by replication over the elements. That
is to say ,(syntax ,@form) is treated as if
it were ,(syntax ,(first form)) ,(syntax ,(second form))
and so on, where form is evaluated only once,
and the number of unquotes depends on the size of
the output of form.
According to the above rule, we would then expect:
[2]> (let ((a '(1 2 3))) ``(a b c ,(list ',@a)))
;; FANTASY:
(LIST 'A 'B 'C (LIST (QUOTE 1)) (LIST (QUOTE 2)) (LIST (QUOTE 3)))
The problem is that this interferes with existing semantics;
the structure ,(syntax ,@form) already has firm meaning,
which is that form is evaluated to create arguments which
are substituted into SYNTAX, and then this is unquoted, leading
to the evaluation a single instance of SYNTAX as an operator.
When SYNTAX is QUOTE, no special exception can be made;
,(quote ,@form) must also mean "zero or more arguments
into quote which is then evaled in the next round, possibly
leading to a quoting error".
https://www.common-lisp.net/~bmastenbrook/new-sbcl/porting.h...
With CLISP that worked on ARM, I am not sure how much slower it would have been to port SBCL to ARM architectures, which is less <1 year of usable, even though CCL had it for years (and why I started compiling CCL using the AUR mechanism on Arch Linux prior to using SBCL in the official repos, for later playing with RPi stuff).
So, thanks for the awesome Lisp, and thanks to you guys specifically because it is niche and thankless with so many jokes about the Lisp/CL community. Even on HN, you can hear the mumbling when people post Lisp articles.
(hail (clisp))