This disables keyword arguments checking. It's effectively a "subclause" of &key. It can appear in any lambda list that can accept &key. It's often useful in combination with &rest (and &key) to receive arbitrary keyword arguments for the purpose of forwarding them to a function with APPLY.

If a generic-function specifies &allow-other-keys, then none of its methods needs to. This is very convenient for INITIALIZE-INSTANCE and friends, for instance.

Many effectively treat this as deprecated, though it's still useful in some cases. Most notably in BOA lambda lists, where it can "internally" initialize a slot according to a computation which may involve previous arguments that were supplied or defaulted. It can also conveniently save a level of indentation compared to using a LET, which is sometimes worthwhile in complex code.

Conceptually, &aux is not part of the public interface of a lambda list.

It's a bit of a shame that &aux can't appear before &key because it could be useful in some cases. Fortunately, such a feature can be emulated like this (contrived example):

(defun slot-value-if-bound
    (object &key ((#:aux boundp) (slot-boundp object 'slot))
              (value (when boundp (slot-value object 'slot))))
  (values value bound))

This is safe because #:aux is an uninterned symbol and thus it's impossible to accidentally supply the keyword argument so the associated default form will always be evaluated to initialize the boundp variable.

One minor inconvenience for the user of such a function is that the argument hints will be cluttered with the fake &aux argument. Support could theoretically be added to tools such as Slime so that they wouldn't show any keyword arguments using an uninterned symbol named "AUX" as keyword-name.

The above is equivalent to the following hypothetical code (that doesn't work):

(defun slot-value-if-bound
    (object &aux (boundp (slot-boundp object 'slot))
     &key (value (when boundp (slot-value object 'slot))))
  (values value boundp))

This is effectively the same as &rest except it requests an indentation of 2 and can only appear in macro lambda lists.

This is sometimes needed to gain access to the compile-time lexical environment in which a macro call appears for the purpose of forwarding it to functions invoked during macroexpansion which need this information such as (from the HyperSpec) macro-function, get-setf-expansion, compiler-macro-function or macroexpand.

lisptip: "Binding keyword arguments"

lisptip: "Duplicated keyword arguments"

Processing of &key arguments is generally slower than for other kinds of arguments, due to somewhat more complex processing most of which may well happen at runtime, but unless you're dealing with performance-critical code there usually isn't cause for concern.

Use &allow-other-keys to disable keyword arguments checking from the callee side.

My nomination for "weirdest Common Lisp feature": the caller can always disable keyword arguments checking in any &key arguments context by passing :allow-other-keys t. It's sometimes convenient to use this feature to capture a few arguments explicitly and then forward the rest to another function with apply, sidestepping the need to explicitly remove unwanted keyword arguments from the list.

Use &rest to capture a list of all keyword arguments in the order they appear in the call.

Can be used with &key to capture all keyword arguments (even those not known in advance but allowed by &allow-other-keys or :allow-other-keys t) in the order they appear in the call. This order is of particular interest for macros that need to ensure that keyword arguments are evaluated in the same order that the caller intended. This is an often overlooked issue. The easiest way to arrange for a macro to evaluate keyword arguments in the right order is to expand to a function call.

apply is very related.

The captured macro call form includes the macro operator itself, not just the (unevaluated) arguments.

lisptip: "A simple REPL"

Primary value only. Use / to get all values.

ASDF is the de-facto standard replacement for "modules".

lisptip: "Printing package-qualified symbols"

lisptip: "Printing package-qualified symbols"

lisptip: "Slow pretty-printing"

lisptip: "Reading floats"

lisptip: "Redirecting output"

lisptip: "Evaluating the last expression" ("#.+")

Many programming languages support two kinds of division operations, both of which are imprecise:

(/ 1.0 3) → 0.33333334

One of the many features that sets Common Lisp apart from other languages is that it supports true fractions directly:

(/ 3 9) → 1/3

(/ 20 15) → 4/3

The usual way of adding a method to a generic-function is with defmethod.

lisptip: "Using an adjustable displaced array as a cursor on another array."

This is a very complex function.

You can't just guess at what it does from the arguments' names. I recommend reading the specification carefully before using it.

Tests whether an array is actually adjustable, which is necessarily the case if it's expressly adjustable and may or may not be the case if it isn't so.

lisptip: ""How do I apply AND?""

All arguments are copied except the last one. The result shares structure with the last argument.

If you need to ensure that all arguments are copied including the last one, use (concatenate 'list ...).

Yes, this is just a function!

Note that beyond simple cases, apply often prevents many optimizations due to its dynamic nature.

If the number of arguments is known in advance, then funcall usually suffices.

Little-known array functions: array-total-size, array-rank, array-dimension, row-major-aref, array-row-major-index, array-in-bounds-p.

lisptip: "Un-displacing an array"

See also: row-major-aref

Newbies sometimes have difficulty locating this function.
It's basically a superset of "<<" and ">>" in many languages such as C.

Everything that is not a cons is an atom, including nil.

atom is one of the very few predicate functions in Common Lisp that doesn't follow the usual naming convention for predicates (ending in "p").

atom is not a "perfect dual" to cons because it's just a type so you can't dispatch on it.

This is specified to be a type, not a class, so you can't portably dispatch on it.

Informally, this is the static, lexical counterpart of catch.

Most code definition constructs such as defun are wrapped in an implicit block of the same name as the unit being defined.

Most iteration constructs are wrapped in an implicit (block nil) which you can return from.

I must say I'm puzzled by this function.

Returns an object of implementation-dependent nature.

Normally accesses the car slot of a cons, but (car nil) → nil.

One of my nominations for "most glaring X3J13 concession": Besides t, case also accepts otherwise to designate the "otherwise" clause. (Does anyone use the otherwise notation??)

This doesn't really have anything to do with exception handling.

This is the most useful of the operators in the "CXR" family besides car and cdr. Its primary utility is helping to traverse plists, most commonly with loop or do. It would be less useful if more direct support for iteration over plists was added...

Personally I don't use operators in the "CXR" family besides car, cdr and cddr. You might also prefer the arguably more "modern" alternatives I like to use.

I guess the multiple "CXR" variations must have been a more important convenience shortcut notation when list processing had a much bigger role in Lisp...

Normally accesses the "cdr" slot of a cons, but (cdr nil) → nil.

Many assume at least ASCII but the standard offers no such guarantee.

The MOP extends this to return any kind of object, not necessarily a symbol.

Might return nil.

One of the great distinguishing features of Common Lisp is that the compiler is available at runtime!

Here's a simplistic function that attempts to determine if a certain generic-function is capable of accepting some specific arguments, with many caveats (TODO: explain the assumptions and caveats):

(defun supports-operation-p (generic-function &rest args)
  (member nil (compute-applicable-methods generic-function args)
          :key #'method-qualifiers))

Differs from copy-seq with a list argument only in that it correctly handles dotted lists.

lisptip: ":initform and :default-initargs"

Each of the :initarg, :reader, :writer and :accessor slot options can be specified multiple times for a single class slot. The "sum" of the options will take effect.

User constants should always use the +naming-convention+ for constants (starting and ending the symbol's name with "+") even though none of the standard constants do so.

defgeneric expands to a call to ensure-generic-function.

Compiler macros really help obeying the mantra of "never use a macro if a function will do".

My nomination for most complex (though justified) syntax in Common Lisp. It's truly breathtaking!

This is the most general and powerful way to make new kinds of setfable places, but also the most complex.

In simple cases, defining a setf-function or using the simple form of defsetf often suffices.

It's also possible to make local setf functions with flet or labels.
Just use (setf name) as function name.

If even that is not powerful enough for you, you might like setf-expanderlet.

DSL tip: Don't build thick macro layers. Instead, start by building a solid foundation of functions and objects, then add a thin layer of syntactic sugar with macros at the end. Your system will be much more flexible and well-considered this way.

It's almost never a good idea to generate user-visible symbols as part of macroexpansions (like defstruct does). Make the user pass a symbol explicitly instead. (TODO: explain why doing the former leads to problems and doing the latter averts them and is much cleaner.)

Correct handling of all declarations in macros usually doesn't happen by accident. You'll often have to parse them and carefully put the right declarations in the right places in the expansion. This is an often overlooked macro quality issue.

I dislike macros that expand to calls to themselves, as interactive macroexpansion might not reveal all the work of the macro at once. The user might then feel compelled to manually expand the result recursively, which can be a pretty annoying thing to do.

Macro design: Full code walking implies full macroexpansion of all macros, which almost guarantees an ugly, unreadable macroexpand result. In addition, full code walking is a conceptually and implementationally complex approach fraught with perils.

I like to design the semantics of my macros which would otherwise require full code walking such that simply including calls to flet, macrolet and symbol-macrolet in the expansion suffices.

lisptip: "Referring to method parameters" (explicit VS implicit specializer)

lisptip: "Multiple export clauses in defpackage"

lisptip: "The four causes of symbol conflicts"

There's no portable way to directly instantiate a DEFSTRUCT structure using a (:constructor nil) option (unless a non-nil :constructor option is also specified), but doing it can still be useful to declare "abstract structures" that another DEFSTRUCT can then "inherit" from with the :include option.

lisptip: "The optional arguments of deftype"

Note that the first argument is a "function name", which includes not only symbols but also lists of the form (setf name), used to define setf functions.

If you need to actually use (and not just refer to) the function you're defining at compile-time (including at macroexpansion-time) in the same file, you'll need to wrap your defun with eval-when.

You can think of this as "nremove".