Right, I should’ve looked it up on CLiki 😅Thanks for these references, you’ve helped a lot 🖤
Right, I should’ve looked it up on CLiki 😅Thanks for these references, you’ve helped a lot 🖤
Right, thanks for the gist!
I’m not yet using cl-repl because I want to have distinct tools composed to a usable whole or at least try to do that before surrendering to complete setups like cl-repl. But thanks for the recommendation anyway!
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.
Yeah, that sums it well enough. I pin my hopes on ECL and Clasp because of portability and active development.
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:
disassemble
is 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.
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:
I haven’t tried Clasp, Corman, CMUCL, and LispWorks. So no review for them. I tried GCL, but let’s not talk about that.
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”.
To add more context to this response: Java has this notion of static methods that belong to classes, compared to the regular methods that belong/act on instances. So ABCL’s jmethod
is to call a method using an instance, while jstatic
is to call a static method using a class. Math.sqrt
happens to be a static method of Math
class, so use jstatic
. Once this static/regular distinction is cleared up, ABCL interface becomes quite usable.
There’s Mal, which goes from the most basic REPL setup to more or less complete Lisp. I haven’t tried it (because the only implementation I want to make is a Brainfuck one, and that’s quite non-trivial), but it seems to be quite hackable and incremental.