1. Define, or create, a package all in one place. Avoid having incremental pieces of the package definition distributed throughout several files.
2. A package definition should consist of some subset of calls to the following functions, in the order indicated, with no intervening computations that could affect the outcome:
in-package(or an equivalent use of
As a mnemonic device, you might try "I remember six user interface expressions."
Note that this list is slightly different from the suggestion found on page 280 of CLtL2. The
use-package statement should precede the
import statements, since it might affect the way in which arguments to these later statements are read in. The
export statement should come last so that it can refer to inherited, imported, or shadowing symbols specified by statements preceding it. In some circumstances it might be necessary for
shadowing-import to precede
use-package to prevent name conflicts from multiple inheritance.
require statement should precede
use-package so that it can refer to a file that creates the used packages. The
provide statement should be placed elsewhere; see item 7 below.
If you create packages with the Common Lisp macro
defpackage, the order of package operations is handled correctly and automatically.
userpackage, you could type
lisp::car, but you should use the unqualified form:
4. Avoid the use of double-colon qualification in files under almost all circumstances; certainly do not use it where any other qualification specifies the same symbol.
For example, assume that the
ace package uses the
dud package, that
ring is an external symbol of
dud, and that
song is present as an internal symbol of
acepackage and need to refer to
ring, you should not use any colon qualifiers because
ringis available by inheritance.
dud, you could access the symbol
ace::ring, since it is available in the
acepackage by inheritance; use
(import 'dud::song), you can use
(import (intern "SONG" "DUD")).
ace::spades, or merely
spades. Thus, Lisp reading is inherently an information-losing operation.
6. Whenever possible, use strings as names rather than symbols. Thus, say
(in-package "RABBIT") rather than
(in-package 'rabbit). The functions
shadowing-import require an explicit symbol rather than a name, so you cannot use strings for them.
Note: Liquid Common Lisp permits
shadow to take a string as an argument.
7. Define a file to be all in one package; avoid multiple
in-package statements. Put a
provide statement at the very end of the last file defining a module, rather than at the beginning of a file as suggested by CLtL2. The facilities of a module are not truly "provided" until after the file or files defining it have been fully and successfully loaded.
These rules are described in detail in the following sections.
Generated with Harlequin WebMaker