variables (@pxref{Variable Scoping}). If it is omitted or @code{nil},
that means to evaluate @var{form} using the default dynamic scoping
rule. If it is @code{t}, that means to use the lexical scoping rule.
-The value of @var{lexical} can also be a non-empty alist specifying a
+
+The value of @var{lexical} can also be a non-empty list specifying a
particular @dfn{lexical environment} for lexical bindings; however,
this feature is only useful for specialized purposes, such as in Emacs
-Lisp debuggers. @xref{Lexical Binding}.
+Lisp debuggers. Each member of the list is either a cons cell which
+represents a lexical symbol-value pair, or a symbol representing a
+dynamically bound variable.
Since @code{eval} is a function, the argument expression that appears
in a call to @code{eval} is evaluated twice: once as preparation before
environment; if the variable is not specified in there, it looks in
the symbol's value cell, where the dynamic value is stored.
- (Internally, the lexical environment is a list whose members are
-usually cons cells that are symbol-value pairs, but some of its
-members can be symbols rather than cons cells. A symbol in the list
-means the lexical environment declared that symbol's variable as
-locally considered to be dynamically bound. This list can be passed
-as the second argument to the @code{eval} function, in order to
-specify a lexical environment in which to evaluate a form.
-@xref{Eval}. Most Emacs Lisp programs, however, should not interact
-directly with lexical environments in this way; only specialized
-programs like debuggers.)
-
@cindex closures, example of using
Lexical bindings have indefinite extent. Even after a binding
construct has finished executing, its lexical environment can be