Common Lisp Quick Reference (2018) | Hacker News Reader

Common Lisp Quick Reference (2018)

clqr.boundp.org

148 pointsabudabi12332 comments

Of particular interest to me is the loop facility reference. It appears to be terse, understandable, and relatively complete. I also like the notation. A subscript f to tell me it's not a macro is incredibly helpful.

Friendly reminder about printing services like this one[1] that will print and ship a PDF to you.

https://www.printme1.com/

Another fun option is to print the folios and bind them yourself. A serviceable job can be done in an afternoon with little more than a sewing kit. It’s easy, using a ruler, an awl or something similar, and a stiff piece of cardboard, to make a guide template for punching holes in the folios. After that it’s just a matter of stitching.

The book in the post is a single folio. A whole afternoon is an overstatement, I’d say.

I did it myself just now it works great.

hyperspec has a compact take on loop, which is my goto when I don't quite remember details of syntax, http://www.lispworks.com/documentation/HyperSpec/Body/m_loop.... it also has a benefit of being ascii representable

Whenever I see things like this I wish CL was available by default in more environments. It would have been the ultimate glue language also capable of growing software into medium-to-large size projects with some care.

Instead we have Perl. It's not bad and fulfills many of the same criteria, but it's also not quite as elegant.

SBCL is available to install on MacOS with brew, with apt or yum on Linux, etc. You can make small standalone applications easily. I have used it for command line utilities (I have some simple examples in my CL book that you can read online https://leanpub.com/lovinglisp/read)

The linked CL reference looks very nice, BTW.

I also recently updated the Mac install docs for Portacle for anyone looking for anyone looking to tinker with CL on newer Macs! https://portacle.github.io/

Portacle is especially nice because you bundle Emacs with it.

Who is still using Perl as a glue language? It's often Python to glue things now.

> It would have been the ultimate glue language

Interesting. Why particularly a glue language? Just because it's the ultimate language and thus by definition also the ultimate glue language or is there something more specific?

I would argue perl has a superior practical elegance

so you can write perl in a kinda-sexp style if you really want to (no one does, which tells you something)...but you get a kinda-sexp built-in syntax for hashes whereas lisps make you construct them with bolted on functions

I also like the simplified Common Lisp reference: https://jtra.cz/stuff/lisp/sclr/index.html

People who publish programming material online in PDF format should really take notice of this and the formatting. The half A4 version is skinny enough that you can stick it next to your editor/IDE window and still see the entire page even on small screens.

It is amusing that the quick reference is a densely packed "52 pages".

Common Lisp is huge because libraries were not a big thing when it was designed, so it included lots of kitchen sinks.

This has some advantages:

1. The built in functions generally are very efficient and don't have many edge-case gotchas.

2. You don't have to worry about which version of a library function to use, i.e. no dependency hell.

3. The above is true for every CL implementation, from any supplier.

It also has some disadvantages: When designing a language you can never predict all the functionality people will need. Useful things like networking and multithreading and package management were not included in the CL standard. Libraries for the missing pieces now exist to fix those shortcomings.

we need to keep in mind that many things were still emerging when the core language was designed - 1982 specs appeared with the first language book published in 1984. CLOS (the Common Lisp Object System) for example was mostly a research project, whose first spec was published in 1988, the Meta-object Protocol book was published in 1991 - which was unusual, since one would standardize on common practice. Stuff like networking and multithreading existed in very different ways or only very primitive. Networking usually meant to interface to the local platform network stacks and multithreading was still largely unsolved - parallel Lisp was still a research subject, even though thread/concurrency/parallelism support existed in very different ways - often 'green threads' (cooperatively scheduled) or for experimental machines (like the massive parallel connection machine). Now even my watch has two cpu cores and smartphones have even more cores.

Having the functions built in also allows them to be specialized at compile time. For example, if we have an operation on sequences, and we know the sequence is a particular kind (say, a list), we can invoke the method for that sequence.

It would be nice if such advantages could be ported to user defined libraries, or if built in functions could be extended (by making them generic and adding methods, say) without losing these advantages. Many of the features in Common Lisp are there because they helped implement things in the standard; it would be nice if that principle could be extended. The ultimate goal would be (in some standardized way) to expose to a library writer all the mechanisms that could make the built ins particularly effective.

define-compiler-macro handles many of the cases you describe in your first paragraph. But I agree it would be nice if more of the functions in CL were generic. I think the issue is that those functions were standardized before CLOS was added and made defgeneric/defmethod a normal mechanism for writing functions.

Compiler macros are an example of something added to make built-in functions more efficient, but they aren't going as far as I'd like. I mean, SBCL doesn't use them for specializing built-ins based on type information; it uses its own nonstandard mechanism, defknown.

I've mentioned this before, but I'd really like to see Strandh's Call-site optimization implemented, so generic functions could be both highly locally optimizable, yet retain their dynamicity.

I've always felt that Common Lisp was the Lisp family incarnation of PL/I; include everything you think might be helpful to offer a warm welcome to folks coming from FORTRAN or COBOL.

It's CL, what are you gonna do...

Will there ever be a newer edition of the Common Lisp standard to reflect the major changes in the computing landscape ?

Who knows? Currently there is no one working on a new standard. Maybe an AI will publish one in 2094, hundred years after the first standard.

For now with CL we can program in the past and reuse some code from 30 years ago. Changes will need to reflected in implementations, libraries and community standards. Some stuff would need changing the existing, others not so much. Example: Due to meta-programmability something like the Common Lisp Object System was implemented 95% in the language itself - the remaining 5% largely needed to be implementation specific things like changing the type system. Other stuff like 'threading' or 'foreign function interface' would need more work - but they exist already in implementations and libraries.

I would suggest that this is what Racket is

they don't call it Lisp because it came from Scheme but they wisely realized the first step to making changes is to stop calling it Scheme otherwise purists will just rain fire on it and insist on living in the past

from a practical perspective it seems perfectly safe and reasonable to say Racket is Lisp2023

otherwise maybe elisp? it is by far the most important thing with "lisp" in its name in 2023

I’d agree about Racket; the community and resources available for it are fantastic.

Also worth noting is Hy, a sort of alternate Lisp syntax for Python. http://hylang.org/

Wished the modern Lisp could be used to write apps for Android.

This is a great showcase not only of Common Lisp, but of (La)TeX.

This is fantastic. The way this is organized I have already found some functions I didn't realize were available. Many thanks to the author!

This is so lovely one of my main reasons to main Common Lisp is to have an excuse to use it. Not even kidding.

Is there an Emacs info mode CL manual out there?

there's dpans2texi https://github.com/rebcabin/dpans2texi, which lets you convert dpans https://github.com/xach/dpans the tex source for the Common Lisp standard to texinfo which you can open in emacs

Reply on news.ycombinator.com