Personaly i found abcl a bad experience.
Thoughts on ecl & clisp ?
sbcl works nice & fine. But i’t’s the only lisp implementation i know.
There are good books on racket-scheme & chez-cheme.
The only book i know for lisp is, “Common lisp , a gentle introduction to symbolic computing”.
Use SBCL + QuickLisp + Emacs + Sly to follow “Practical Common Lisp” by Peter Siebel. Once you have read this book, choose whatever you like. For links, snippets and tips, look in the Common Lisp Cookbook. Happy hacking!
Personaly i found abcl a bad experience. ABCL maintainer here: Sorry to hear that you didn’t like using ABCL. I would be interested in hearing about your misery to try to improve things for others.
I use also kawa (a scheme). It has better documentation. https://www.gnu.org/software/kawa/pt01.html
The first library i tried was serapeum.
https://github.com/ruricolist/serapeum
But abcl was spitting out alot of errors.I know in general there are thing in Serapeum that don’t work properly in ABCL, but I have gotten gotten patches from ABCL users so to be fair there are definitely people using it there.
What errors do you get? ABCL successfully runs Serapeum’s full test suite on my machine (aarch64-darwin).
On my Mac with ABCL 1.9.2 I can load it via Quicklisp and get for example this error:
; Caught COMPILE-FAILED-WARNING: ; Lisp compilation failed while compiling #Program below works fine with sbcl & ccl.
For abcl i get alot of warnings, not errors,(load "~/quicklisp/setup.lisp") (declaim (optimize (speed 3) (safety 3))) (ql:quickload "serapeum") (defpackage alain (:use :cl :serapeum) (:export main));defpackage (in-package :alain) (declaim (type (integer) *anint*)) (defparameter *anint* 2) (-> addtwo ( integer ) integer ) (defun addtwo (x) ( + *anint* x )) (defun main () (print (addtwo 3)));main (in-package :cl) (defun main () (alain::main)) (main); Compilation unit finished ; Caught 22 WARNING conditions ; Caught 10 STYLE-WARNING conditions
Thanks for the feedback.
I just tried ccl on freebsd. I had only to download two files an executable fx86cl64 and an fx86cl64.image. It works nice.
I tried hy-lisp. The idea is good but it lacks features.
TL;DR: Use SBCL or CCL. Others—maybe, but likely in their own specific niches.
I want to give more chances to implementations there are, so here’s my experience, in the order of preference:
- SBCL is good. De-facto standard. The REPL experience is… not the best, but practical. Debugger loop is snappy, though.
- CCL (Clozure Common Lisp) is extremely good for development: it is attentive to style, it has exhaustive type checks, it has a nice REPL (probably the best of open-source implementations, on par with Allegro) and a debugger with actually useful stack traces.
- ECL is embeddable, and that’s its biggest value proposition: you can run it anywhere C runs and you can interact with C-based software easily. Beyond this platform-friendliness, ECL has reasonable code optimization abilities and a practical REPL.
- ABCL is useful if you interface with JVM. So if you need to work with Java in Lisp, it’s either Clojure or ABCL. Implementation and REPL experience is somewhat simplistic, but let’s give it a chance.
- CLISP is abandonware, even though the riches of the golden age when it was researched and worked on are still there.
- Allegro is proprietary, which sucks. Given that it’s proprietary, it doesn’t have as much contributors as, for instance, SBCL. So it actually is worse than open-source impls. But it has a nice inspirational REPL. If you don’t need a commercial support license for a huge company, then you likely don’t need Allegro.
I haven’t tried Clasp, Corman, CMUCL, and LispWorks. So no review for them. I tried GCL, but let’s not talk about that.
CLISP is abandonware, even though the riches of the golden age when it was researched and worked on are still there
I don’t know how much they consider it complete and how much they just don’t work on it, but there are some updates from time to time; I see the creator Bruno is pushing fixes from time to time.
I tried GCL, but let’s not talk about that.
:-) I would be interested to hear the experience. I am aware of it, but I haven’t had time to try it myself. They also seem to be on very sporadic development.
I personally haven’t tried Clasp, CMUCL, CLisp and GCL yet; I just don’t have time. It takes time to try everything properly, build it etc, so I am currently just using sbcl; but I would be interested to know how other implementations compare in terms of completeness, extras they offer, performance, correctness etc. I would even watch a YT video if some YouTuber was interested in making a review wink wink you know who you are :).
specifically, what is the diff between SBCL repl experience and CCL?
Without additional packages, the sbcl repl doesn’t support history nor sensible editing.
The best REPL is Emacs/Sly, anyways.
CCL is mostly only on life support. The native port to the Apple Silicon Macs isn’t under way. CCL isn’t making any progress.
Allegro … So it actually is worse than open-source impls.
I doubt that this is generally the case.
CCL is mostly only on life support. The native port to the Apple Silicon Macs isn’t under way. CCL isn’t making any progress.
Didn’t know it’s that bad 😢 A shame—CCL is a nice piece of work.
This is the index of the Allegro CL documentation: https://franz.com/support/documentation/10.1/doc/contents.htm
I’ve been overly generic, I guess. What I meant was answering a (supposed) OP’s request for raw implementation usability. Which is REPL, introspection facilities, SLIME/SLY integration. Allegro is not perfect when viewed from this perspective. Proprietary implementation makes it hard to inspect what’s going on in the image and optimize the code comprehensively:
-
disassembleis useless. -
Inspection is locked to what they provide—even SLIME/SLY merely uses the implementation-provided function for inspected parts. On other implementations, SLIME/SLY provides a lot of auxiliary info that implementation doesn’t explicitly provides.
-
In general, you can’t override the useful parts of the REPL easily: defining new REPL commands is a pain, building GUI tools inspecting the image is either parsing the unreliable raw output of Allegro-provided functions or giving up and using what they provide.
Given that OP likely asked about the general development experience, and that I’ve done a lot of work with basic text REPL interaction on all the implementations I listed above—Allegro is not the ideal basis, especially for learning.
The documentation and the additional products they provide is good, but that’s beyond the basics that OP is probably interested in.
I don’t know many open source Common Lisp implementations on this level.
Fair, I’ve been overly generic too. To me, the basic inspection and interaction is smoother at least on SBCL and CCL, which is, like, two out of five? somewhat maintained implementations.
Proprietary implementation makes it hard to inspect what’s going on in the image and optimize the code comprehensively
If I were a paying Franz customer and I would be interested in SLIME/SLY improvements, I would kindly ask them to provide it. Maybe they would then just do it or ask the customer to pay for it. That’s what technical support is for.
Second: as a Franz customer one could get the source code for much of the product. I’m not a customer, but I guess this possibility still exists.
Allegro is not the ideal basis, especially for learning
I think it can actually be the opposite. Among new Lisp users GNU Emacs is often cited as a hurdle.
Allegro CL comes with an GUI based IDE on Linux, Windows, and Web browsers. This makes it possible to use it without GNU Emacs + SLIME/SLY. I consider that to be a feature. The IDE of Allegro CL has a bunch of features: https://franz.com/support/documentation/10.1/doc/cgide.htm#menus-dialogs-1
Best: the stuff is written all in Allegro CL itself and can be reused.
Oh wait, it really ships with a GUI-based IDE… I’m convinced—Allegro is good, especially when paid. When talking about free version, my non-introspection comments still apply, but they are kind of implied for a free version of proprietary product.
-
CMUCL is basically a worse version of SBCL. SBCL is a fork of CMUCL with the goal of being more maintainable. Some things have been backported between the two, and there maybe a few things present in CMUCL that aren’t in SBCL, but I think most of the interesting things have been added back in.
Clasp is to C++ like what ABCL is to Java. I haven’t done much more that fire it up to see if it would run, but it’s C++ integration looks fantastic.
CMUCL is also way behind it platform support. CMUCL is mostly limited to being a 32bit application (IIRC). SBCL OTOH supports various 64bit platforms, incl. ARM64 on Linux and macOS.
It is “SBCL or proprietary” nowadays. LW and ACL are fine but are pricy and well, proprietary.
CCL is all but dead.
ECL has a kind of limited niche, and is not as advanced as SBCL(e.g.: MOP). Same goes for ABCL. Also, ABCL is kind of slow.
Clasp is somewhat interesting, but it also has a limited niche (C++ interop) and is also not as advanced as SBCL.
GNU implementations are dead(GCL, CLISP)
Everything else is as dead as GNU implementations.
Can I ask what you mean by CLISP being dead? The last stable release was 10y ago yes, but development continues to this day and beta releases are available. Nixpkgs actually ships a beta version by default now.
I maintain a Nix scope with hundreds of Common Lisp packages and I am actually about to merge a dev branch that introduces CLISP support for all packages & their tests; it holds its own pretty well: https://github.com/hraban/cl-nix-lite/tree/clisp. see the list of all packages in the lisp-packages-lite.nix file).
CLISP development: https://gitlab.com/gnu-clisp/clisp
Well, I was judging by its official page and Sourceforge activity, which seems negligible. However, Gitlab also does not seem very active (6 commits this year, despite lots of open bugs). The development is almost stalled. It is on life support, at best.
Yeah, that sums it well enough. I pin my hopes on ECL and Clasp because of portability and active development.
The only book i know for lisp is
My pet peeve: People never looking at the sidebar of this very subreddit.
People never looking at the sidebar of this very subreddit.
Welcome to Reddit :-). That is the common theme of all subreddits I am afraid.
Aah , i see to the right. But aren’t the books “OLD ?”
Isn’t common lisp old?
CL is, like, fourty? years old now. These books describe the standardized language, so most of their gotchas apply to any conforming implementation. So yes, the books are “OLD”, and yes, they are “GOOD”.