
CLisp needs maintainers - ghostDancer
http://article.gmane.org/gmane.lisp.clisp.general/14256
======
616c
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.

[https://www.common-lisp.net/~bmastenbrook/new-
sbcl/porting.h...](https://www.common-lisp.net/~bmastenbrook/new-
sbcl/porting.html)

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

~~~
jordigh
Thanks, I was looking for an excuse to try to help CLisp. This might be it.

~~~
616c
Cool. And that is coming from me, someone who knows like %1 of anything
CL/Lisp related.

Unrelated side bar for initiated: is the actual capitalization of this thing
(beyond the terminal of course) CLisp or CLISP?

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

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 can someone chime in and tell us?

------
jordigh
Well, I just started reading Land of Lisp a few weeks ago. It recommends
CLisp. I'm quite new to all of lisp, so, let's take a look:

    
    
        $ hg clone http://hg.code.sf.net/p/clisp/clisp
    

Wow, that took a long time to clone. How big is the thing?

    
    
        $ du -hs clisp
        147M        clisp
    
        $ cd clisp
        $ hg branches
        default                    15611:5c63938ef493
    

Hm, a moderate-sized repo, only 15611 commits and no branching to speak of.
Let's look at the latest commits,

    
    
        $ hg heads
        changeset:   15611:5c63938ef493
        tag:         tip
        user:        Sam Steingold <sds@podval.org>
        date:        Wed Oct 22 12:04:12 2014 -0400
        summary:     Fix bug#668 posix:file-state always return NIL for :rdev
    

What! Last commit was from October last year? Clearly development has slowed
to a standstill. Who is generally in charge around here nowadays?

    
    
        $ hg churn -r "date('2010 to today')"
    
        sds                        313529 **************************************
        sds@podval.org             194383 ********************
        vtz                          2723 *
        ampy                          801 
        haible                        758 
        elliottslaughter@gmail.com    627 
        vtzankov@gmail.com            279 
        bruno@clisp.org               239 
        cvs2hg                         46 
    

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

What? Didn't I just do that?

    
    
        $ apt-cache policy libsigsegv-dev
        libsigsegv-dev:
          Installed: 2.9-4
          Candidate: 2.9-4
          Version table:
             2.10-4+b1 0
                 -1 http://ftp.ca.debian.org/debian/ unstable/main amd64 Packages
         *** 2.9-4 0
                500 http://ftp.ca.debian.org/debian/ wheezy/main amd64 Packages
                100 /var/lib/dpkg/status
    

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.

~~~
rjsw
And that is why people shouldn't use configure [1].

[1] [https://www.varnish-
cache.org/docs/2.1/phk/autocrap.html](https://www.varnish-
cache.org/docs/2.1/phk/autocrap.html)

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

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

~~~
taylanub
Late reply but:

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.

------
edem
I'm a bit confused. What is the relationship between CLisp and ANSI Common
Lisp?

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

~~~
zachbeane
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".

CMUCL is not popular any more.

SBCL is popular, and so is Clozure CL.

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

~~~
kazinator
CLISP, historically (which takes us back to 1987), did not start out as GPL-ed
software, and certainly wasn't part of the GNU Project.

First it became GPLed, over a heated dispute with Stallman w.r.t. its use of
the GNU Readline library.

Evidently, it is now part of the GNU Project. (So there is justification in
referring to it as "GNU CLISP".)

Programs aren't going to switch their coding style just because they join the
GNU Project.

~~~
aidenn0
Yes, that was the thread where RMS argued straight-faced that having optional
readline support made CLISP a derivative work of readline.

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

