From d0adbcdd03739c582a78946dc1784b5b413dfb50 Mon Sep 17 00:00:00 2001 From: Kaz Kylheku Date: Tue, 27 Nov 2018 06:57:10 -0800 Subject: doc: avoid "empty lexical environment". * txr.1: Replace the term "empty lexical environment" with "global environment" in a few places. In one case, it is removed, and the surrounding wording is adjusted. The "empty lexical environment" term is poor because the situations which it describes retain visibility of the "global lexical" variables. --- txr.1 | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/txr.1 b/txr.1 index ead65a61..f0f3f54d 100644 --- a/txr.1 +++ b/txr.1 @@ -62792,7 +62792,7 @@ is supported via the function .codn compile-file . The function .code compile-toplevel -is provided for compiling expressions in an empty lexical environment. This +is provided for compiling expressions in the global environment. This function is the basis for both .code compile and @@ -62843,8 +62843,9 @@ and how that term is defined. The file compiler individually processes top-level forms; for each such form, it emits a translated image. In the context of file compilation, a top-level form isn't simply any Lisp form -which is not enclosed by another one, or evaluated in an empty lexical -environment. Rather, in this specific context, it has this specific definition: +which is not enclosed by another one. Rather, in this specific context, it has +this specific definition, which allows some enclosed forms to still be +considered top-level forms: .RS .IP 1. @@ -63615,7 +63616,7 @@ and not at compile time. In all situations, the evaluation of .meta form -takes place in an empty lexical environment. Even if the +takes place in the global environment. Even if the .code load-time form is surrounded by constructs which establish lexical bindings, those lexical bindings aren't visible to -- cgit v1.2.3