A specification list is required for an Edebug specification if
some arguments of a macro call are evaluated while others are not. Some
elements in a specification list match one or more arguments, but others
modify the processing of all following elements. The latter, called
specification keywords, are symbols beginning with ‘&’ (such
A specification list may contain sublists, which match arguments that are themselves lists, or it may contain vectors used for grouping. Sublists and groups thus subdivide the specification list into a hierarchy of levels. Specification keywords apply only to the remainder of the sublist or group they are contained in.
When a specification list involves alternatives or repetition, matching it against an actual macro call may require backtracking. For more details, see Backtracking.
Edebug specifications provide the power of regular expression matching, plus some context-free grammar constructs: the matching of sublists with balanced parentheses, recursive processing of forms, and recursion via indirect specifications.
Here's a table of the possible elements of a specification list, with their meanings (see Specification Examples, for the referenced examples):
&rest form. See
function, since it instruments the body of the lambda expression either way.
To make just a few elements optional, followed by non-optional elements,
...]. To specify that several
elements must all match or none, use
...]. See the
To repeat only a few elements, use
To specify several elements that must all match on every repetition, use
Each list element following
&or is a single alternative. To
group two or more list elements as a single alternative, enclose them in
&or, but if any of them match, the specification fails. If none of them match, nothing is matched, but the
&definekeyword should be the first element in a list specification.
If the symbol has an Edebug specification, this indirect
specification should be either a list specification that is used in
place of the symbol, or a function that is called to process the
arguments. The specification may be defined with
just as for macros. See the
Otherwise, the symbol should be a predicate. The predicate is called
with the argument, and if the predicate returns
specification fails and the argument is not instrumented.
Some suitable predicates include
'symbol, where the name of symbol is the string, but the string form is preferred.
A sublist specification may be a dotted list and the corresponding list
argument may then be a dotted list. Alternatively, the last cdr of a
dotted list specification may be another sublist specification (via a
grouping or an indirect specification, e.g.,
(spec . [(more
specs...)])) whose elements match the non-dotted list arguments.
This is useful in recursive specifications such as in the backquote
example. Also see the description of a
above for terminating such recursion.
Note that a sublist specification written as
(specs . nil)
is equivalent to
(sublist-elements...)) is equivalent to
Here is a list of additional specifications that may appear only after
&define. See the
A defining form is not required to have a name field; and it may have
multiple name fields.
:nameshould be a symbol; it is used as an additional name component for the definition. You can use this to add a unique, static component to the name of the definition. It may be used more than once.
body, described above, but a definition body must be instrumented with a different Edebug call that looks up information associated with the definition. Use
def-bodyfor the highest level list of forms within the definition.
def-body, except it is used to match a single form rather than a list of forms. As a special case,
def-formalso means that tracing information is not output when the form is executed. See the