See also scheme

What makes lisp special?

Starting to code in Common Lisp

CL-References

Other Lisps

T

Urn

Urn is a Lisp that compiles to Lua. Its tutorial is one of the friendliest to learn Lisp itslef.

Picolisp

uLisp

Notes

To add readline support to the SBCL REPL, use rlwrap

Use quicklisp to discover, install and manager Lisp libraries

Starting SBCL with QuickLisp pre-loaded.

$ rlwrap sbcl --load ~/quicklisp/setup.lisp

Quotes

In C, you are writing assembly constructs disguised as a high level language. In lisp, you are writing compiler constructs (abstract syntax trees) disguised as a high level language. Assembly language targets hardware-oriented geeks. Lisp targets compiler-oriented geeks. Since the two don’t (generally) understand the other’s viewpoint, each hates the other’s favorite language.

– gvb @.

Implement your own Lisp

Blogs

Videos

Algorithms

Lisp Machines

Books

IDEs

The de-facto IDE for most lisps in Emacs. Howver Portacle - A Portable Common Lisp Development Environment is a good, ready-to-go, purpose-built distribution of Eamcs for use on Windows, Mac and Linux.

Talks

People

Implementations

Distributions

Interesting programs / libraries

Discussions/ Comparisons

Understanding the words “package”, “system”, “project” .. which have different meanings than commonly understood ones.. As explained by sjl on lobste.rs:

Common Lisp’s terminology is confusing because it’s old and uses a lot of words that we use now (like “package”) to mean different things than people mean today. Things get easier once you internalize what Common Lisp means by the terms.

A package in Common Lisp is a container for symbols. They’re a way to group related names (symbols) together so you don’t have to do the miserable prefixing of every name with mylibrary-... like you do in Emacs Lisp or C to avoid name clashes.

Unlike other languages like Python/Clojure/etc, packages and files on the hard disk are not tied strongly together in Common Lisp. You can have several files that all work with the same package, a single file that switches back and forth between packages, or even write code that creates/mutates packages at runtime. Files and packages are orthogonal in Common Lisp, which gives you maximum flexibility to work however you want.

A system in Common Lisp is a collection of code (mostly) and a description of how to load that code (and some metadata like author, license, version, etc). For example: my directed graph library cl-digraph contains a system called cl-digraph. That system has a description of how to load the code, and that description lives in the cl-digraph.asd file. It creates a Common Lisp package (called digraph).

The Common Lisp language itself has no knowledge of systems. ASDF is a Common Lisp library bundled with most (all?) modern implementations that handles defining/loading systems. (The name stands for Another System Definition Facility, so as you might guess there have been several other such libraries. ASDF is the one everyone uses today.)

Systems and packages are orthogonal in Common Lisp. Some systems (like small libraries) will define exactly one package. Some systems will define multiple packages. Rarely a system might not define any new packages, but will use or add to an existing one.

A project in Common Lisp is not an official term defined anywhere that I know of, but is generally used to mean something like a library, a framework, an application, etc. It will usually define at least one system, because systems are where you define how to load the code, and if it didn’t define a system how would you know how to load the code? My cl-digraph library mentioned above is a project that defines three systems:

  • cl-digraph which contains the actual data structure and interface.
  • cl-digraph.test which contains the unit tests. This is a separate system because it lets users load the main code without also having to load the unit test framework if they’re not going to be running the tests.
  • cl-digraph.dot which contains code for drawing the directed graphs with Graphviz. This is a separate system because it lets users load the main code without also having to load the cl-dot system (the graphviz bindings) if they don’t care about drawing.

If I were writing this today I’d use ASDF’s foo/bar system naming notation instead of separating the names with a dot, because there’s some nice extra support for that. I just didn’t know about it at the time, and don’t want to break backwards compatibility now.

We saw how Common Lisp has no concept of a system — that comes from ASDF. Similarly, ASDF has no concept of the internet, or reaching out to somewhere to download things. It assumes you have somehow acquired the systems you want to load, maybe by sending a check to an address and receiving a copy of the code on floppy disk, as many of my old Lisp books offer in the back pages.

Quicklisp is another library that works on top of ASDF to provide the “download projects from the internet automatically if necessary” functionality that people want in our modern world. So when you say (ql:quickload :cl-digraph) you’re asking Quicklisp to download cl-digraph (and any dependencies) if necessary, and then hand it off to ASDF to actually load the code of the cl-digraph system. Unlike ASDF, Quicklisp is relatively new in the Common Lisp world (it’s only about eight years old) bundled with any modern Lisp implementations (that I know of) (yet?), which is why you need to install it separately.

So to summarize:

  • Files are files on your hard drive.
  • Packages are containers of symbols. They are orthogonal to files.
  • Systems are collections of code, plus instructions on how to load this code. They are orthogonal to packages.
  • Projects are high-level collections of… “stuff” (code, documentation, maybe some image assets, etc). They are (mostly) orthogonal to systems (seeing a trend here?).
  • Common Lisp knows about files and packages. ASDF adds systems. Quicklisp adds the internet.

This is a pretty high-level view that glosses over a lot, but maybe it’ll clear things up and help you dive into the details later.