#CommonLisp includes a number of meta-linguistic utilities vital for compiler building. Like pathname resolution (PATHNAME-MATCH-P,) or type specifier checking (SUBTYPEP,) or obvious things like READ. But this set of building blocks is incomplete. In my quest to rely on the language and compiler as much a possible in all my projects, I had this situation more than once:

• Do something manually and heuristically

• Realize there’s a utility for that in the language and use it

• And then encounter a problem that should be solvable, if only the used utility had an “obvious” counterpart/sub-utility/extension

• Go back to manual handling, because the utility set is incomplete

Happened with cl-match-patterns and pathnames, and happens now with typed-macros (TBA.) So yeah, Common Lisp lacks “obvious” meta-programming utils, and now I wonder why some were included but some weren’t.

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

This is a good exploration/explanation of #CommonLisp packages, systems, and Quicklisp. Yet I disagree on the practical matters and author’s taste.

• Package-inferred systems are bad, because they decentralize system information and make packaging a living hell. (I know it—I tried to package Lem.) Regular systems have all the system metadata in one place, which is much more processable and readable. Build metadata (systems) should not belong to code namespaces (packages)—it’s quite absurd if we frame it this way.

• Putting all of the libs into ~/common-lisp (or better suggested ~/.local/share/common-lisp/source) is a bad practice, because it pollutes every image from now on with a single version of the package, with no way to override or tweak it. Prefer isolated pinned dependencies. I, in fact, have a WIP post on that, will publish soon.

• Modules are still useful, because implementations use them for optional pre-ASDF features. So knowing about modules is useful, if only to (require "asdf").

Cees de Groot @cdegroot explains what Common Lisp library building and packaging problems ASDF and Quicklisp solve. A clear overview of these tools and what they do.

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

#asdf #quicklisp #CommonLisp #lisp

I just posted a video of solving Advent of Code 2025 day 3 in elisp/common lisp simultaneously. #emacs #elisp #commonlisp #lisp #adventofcode #adventofcode2025

https://www.youtube.com/watch?v=7ZSjwo6ohrk

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

This is a good exploration/explanation of #CommonLisp packages, systems, and Quicklisp. Yet I disagree on the practical matters and author’s taste.

• Package-inferred systems are bad, because they decentralize system information and make packaging a living hell. (I know it—I tried to package Lem.) Regular systems have all the system metadata in one place, which is much more processable and readable. Build metadata (systems) should not belong to code namespaces (packages)—it’s quite absurd if we frame it this way.

• Putting all of the libs into ~/common-lisp (or better suggested ~/.local/share/common-lisp/source) is a bad practice, because it pollutes every image from now on with a single version of the package, with no way to override or tweak it. Prefer isolated pinned dependencies. I, in fact, have a WIP post on that, will publish soon.

• Modules are still useful, because implementations use them for optional pre-ASDF features. So knowing about modules is useful, if only to (require "asdf").

"Lisp Style and Design" by Molly Miller and Eric Benson (Digital Press, 1990) is a Common Lisp book cited by Paul Graham in On Lisp which covers often overlooked topics. The book is now available at the Internet Archive:

https://archive.org/details/miller-and-benson-1990-lisp-style-design

#CommonLisp #lisp #books

Cees de Groot @cdegroot explains what Common Lisp library building and packaging problems ASDF and Quicklisp solve. A clear overview of these tools and what they do.

https://cdegroot.com/programming/commonlisp/2025/11/26/cl-ql-asdf.html

#asdf #quicklisp #CommonLisp #lisp

I just posted a video of solving Advent of Code 2025 day 3 in elisp/common lisp simultaneously. #emacs #elisp #commonlisp #lisp #adventofcode #adventofcode2025

https://www.youtube.com/watch?v=7ZSjwo6ohrk

An opinion: #Lisp, #Scheme, and #CommonLisp macros should also include type information, not only forms to process. The language(s) are typed, after all!

Luckily, this can be added on top of the existing macro system with… macros! And some compiler internals for type inference, in the order of what trivial-arguments are doing (disclosure: I’m the one that contributed type info fetching there.) With that and some syntax processing, one can infer the type of a given expression in like 80% of cases (might be less than that on non-SBCL compilers, but I have to test that.) And then act on it with a knowledge of what types there are.

I had a use-case for this when playing with CRUNCH, but it eludes me now. You have to believe me on the usefulness of types in macros.

"Lisp Style and Design" by Molly Miller and Eric Benson (Digital Press, 1990) is a Common Lisp book cited by Paul Graham in On Lisp which covers often overlooked topics. The book is now available at the Internet Archive:

https://archive.org/details/miller-and-benson-1990-lisp-style-design

#CommonLisp #lisp #books

RE: https://fosstodon.org/@metalisp/115640235844049539

A new Lisp discussion forum. Lispers hang out at various online venues but this new community effort may appeal to those who, like me, aren't into chat-based systems and prefer to stay away from Reddit and other proprietary or closed platforms.

I joined the forum, let's see how it goes.

https://community.metalisp.dev

#CommonLisp #lisp #forum

#CommonLisp includes a number of meta-linguistic utilities vital for compiler building. Like pathname resolution (PATHNAME-MATCH-P,) or type specifier checking (SUBTYPEP,) or obvious things like READ. But this set of building blocks is incomplete. In my quest to rely on the language and compiler as much a possible in all my projects, I had this situation more than once:

• Do something manually and heuristically

• Realize there’s a utility for that in the language and use it

• And then encounter a problem that should be solvable, if only the used utility had an “obvious” counterpart/sub-utility/extension

• Go back to manual handling, because the utility set is incomplete

Happened with cl-match-patterns and pathnames, and happens now with typed-macros (TBA.) So yeah, Common Lisp lacks “obvious” meta-programming utils, and now I wonder why some were included but some weren’t.

RE: https://fosstodon.org/@metalisp/115640235844049539

A new Lisp discussion forum. Lispers hang out at various online venues but this new community effort may appeal to those who, like me, aren't into chat-based systems and prefer to stay away from Reddit and other proprietary or closed platforms.

I joined the forum, let's see how it goes.

https://community.metalisp.dev

#CommonLisp #lisp #forum

An opinion: #Lisp, #Scheme, and #CommonLisp macros should also include type information, not only forms to process. The language(s) are typed, after all!

Luckily, this can be added on top of the existing macro system with… macros! And some compiler internals for type inference, in the order of what trivial-arguments are doing (disclosure: I’m the one that contributed type info fetching there.) With that and some syntax processing, one can infer the type of a given expression in like 80% of cases (might be less than that on non-SBCL compilers, but I have to test that.) And then act on it with a knowledge of what types there are.

I had a use-case for this when playing with CRUNCH, but it eludes me now. You have to believe me on the usefulness of types in macros.

🎥 Learn #lisp: 9 videos, 90 minutes, in a new chapter about #commonlisp data structures: lists, arrays an vectors, the "cons" cell, hash-tables, equality, :test and :key arguments, common errors, quality of life improvements, style discussion, exercises.

➡️ https://lisp-journey.gitlab.io/blog/learn-lisp-data-structures-9-videos-90-minutes/

The most efficient way you can learn CL. Avoid all the traps I faced during my journey!

and… thanks 😊

#programming

My main complaint about #Scheme is that it’s “not practical,” being non-portable and batteries-excluded for any sufficiently complex case. And yet my current situation (my #LambdaCalculus experiments, aspirations for the Web-resident software that’s NOT necessarily #JavaScript, and overall feeling that #CommonLisp is quite trippy when I write it) kind of nudges me towards Scheme. The appeal is real.

@Sandra is partly to blame for that, showing all these beautiful combinators off in her posts. Combinators are cool, and Scheme is (almost) a perfect language for them!

🎥 Learn #lisp: 9 videos, 90 minutes, in a new chapter about #commonlisp data structures: lists, arrays an vectors, the "cons" cell, hash-tables, equality, :test and :key arguments, common errors, quality of life improvements, style discussion, exercises.

➡️ https://lisp-journey.gitlab.io/blog/learn-lisp-data-structures-9-videos-90-minutes/

The most efficient way you can learn CL. Avoid all the traps I faced during my journey!

and… thanks 😊

#programming