\( \newcommand\D{\mathrm{d}} \newcommand\E{\mathrm{e}} \newcommand\I{\mathrm{i}} \newcommand\bigOh{\mathcal{O}} \newcommand{\cat}[1]{\mathbf{#1}} \newcommand\curl{\vec{\nabla}\times} \newcommand{\CC}{\mathbb{C}} \newcommand{\NN}{\mathbb{N}} \newcommand{\QQ}{\mathbb{Q}} \newcommand{\RR}{\mathbb{R}} \newcommand{\ZZ}{\mathbb{Z}} \)
UP | HOME

Packages - Lisp

Table of Contents

When writing code, it's natural to organize them by modules or packages. Common Lisp has packages. Packages are namespaces for symbols.

1. Conventions

1.1. Use Uninterned Symbols

Convention: Use uninterned symbols for package names and exports.

Rationale: We do this because, otherwise, we would have the following:

[1]> *package*
#<PACKAGE COMMON-LISP-USER>
[2]> (defpackage bar)
#<PACKAGE BAR>
[3]> (find-symbol "BAR")
BAR ;
:INTERNAL

But using uninterned symbols:

;; Uninterned symbols don't cause symbol pollution:
[4]> (defpackage #:foo)
#<PACKAGE FOO>
[5]> (find-symbol "FOO")
NIL ;
NIL

We could use strings, too, but in that case we would have to use SCREAMING CASE.

1.2. One Package May Have Many Files

Convention: One package may have many files.

Rationale: Java required 1 class per file, and organized classes into packages and subpackages. Many languages copied this convention, and it seems to have become a ubiquitous convention.

Common Lisp doesn't quite follow this pattern. But it may be useful to have 1 file per class (so as to quickly find relevant code). In that case, we would have a package generically look like:

  • class_1.lisp
  • class_N.lisp
  • package.lisp lists the defpackage declarations

Examples of this:

2. References

Last Updated 2022-04-28 Thu 09:09.