* genman.txr: TXR is now bolded in the title.

* txr.1: More formatting and wording fixes.

3 files changed, 415 insertions, 349 deletions

diff --git a/ChangeLog b/ChangeLog
index d98754ff..84c6f424 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2014-09-30  Kaz Kylheku  <kaz@kylheku.com>
+
+	* genman.txr: TXR is now bolded in the title.
+
+	* txr.1: More formatting and wording fixes.
+
 2014-09-26  Kaz Kylheku  <kaz@kylheku.com>
 
 	* lib.c (do_and): Fix andf again: (andf) not producing
diff --git a/genman.txr b/genman.txr
index 2f225743..5c4510e1 100644
--- a/genman.txr
+++ b/genman.txr
@@ -16,11 +16,11 @@ Content-type: text/html
 @(collect)
 @PREAMBLE
 @(until)
-txr - text processing language @(skip)
+<B>TXR</B> - text processing language @(skip)
 @(end)
 @(bind lookup @[orf txrhash txlhash])
 @(all)
-txr - text processing language @VERSION
+<B>TXR</B> - text processing language @VERSION
 @  (and)
 @  (collect :vars (BODY LOOKUP))
 @    (some)
diff --git a/txr.1 b/txr.1
index d75894d6..9b3efbe0 100644
--- a/txr.1
+++ b/txr.1
@@ -256,6 +256,8 @@
 .de mets
 .  nr fsav \\n[.f]
 .  getm \\$*
+.  \"workaround for man2html:
+.  as s \\f\\n[fsav]
   \\*s
 .  ft \\n[fsav]
 ..
@@ -263,6 +265,8 @@
 .de meti
 .  nr fsav \\n[.f]
 .  getm \\$*
+.  \"workaround for man2html:
+.  as s \\f\\n[fsav]
 \\*s
 .  ft \\n[fsav]
 ..
@@ -270,6 +274,8 @@
 .de meIP
 .  nr fsav \\n[.f]
 .  getm \\$*
+.  \"workaround for man2html:
+.  as s \\f\\n[fsav]
 .coIP \\*s
 .  ft \\n[fsav]
 ..
@@ -333,49 +339,49 @@
 .  gets \\$*
 .  IP "\\*s"
 ..
+.\" TXR name
+.ds TX \f[B]TXR\f[]
+.ds TL \f[B]TXR Lisp\f[]
 .\" Start of man page:
-.TH "TXR" 1 2014-09-26 "Utility Commands" "TXR Data Processing Language" "Kaz Kylheku"
+.TH TXR 1 2014-09-26 "Utility Commands" "TXR Data Processing Language" "Kaz Kylheku"
 .SH* NAME
-txr \- text processing language (version 98)
+\*(TX \- text processing language (version 98)
 .SH* SYNOPSIS
-.code txr [ options ] query-file { data-file }*
+.cblk
+.meti txr >> [ options ] < query-file < data-files ..
+.cble
 .sp
 .SH* DESCRIPTION
-.B TXR
-is a language oriented toward processing text from files or streams, using
+\*(TX is a language oriented toward processing text from files or streams, using
 multiple programming paradigms.
 
-A
-.B TXR
-script is called a query, and it specifies a pattern which matches (a prefix
-of) an entire file, or multiple files.  Patterns can consists of large
-chunks of multi-line free-form text, which is matched literally
-against material in the input sources. Free variables occurring in the pattern
+A \*(TX script is called a query, and it specifies a pattern which matches (a
+prefix of) an entire file, or multiple files.  Patterns can consists of large
+chunks of multi-line free-form text, which is matched literally against
+material in the input sources. Free variables occurring in the pattern
 (denoted by the
 .code @
 symbol) are bound to the pieces of text occurring in the
-corresponding positions. If the overall match is successful, then
-.B TXR
+corresponding positions. If the overall match is successful, then \*(TX
 can do one of two things: it can report the list of variables which were bound,
 in the form of a set of variable assignments which can be evaluated by the
 .B eval
 command of the POSIX shell language, or generate a custom report according
 to special directives in the query. Patterns can be arbitrarily complex,
 and can be broken down into named pattern functions, which may be mutually
-recursive. TXR patterns can work horizontally (characters within a line)
+recursive. \*(TX patterns can work horizontally (characters within a line)
 or vertically (spanning multiple lines). Multiple lines can be treated
 as a single line.
 
 
-In addition to embedded variables which implicitly match text, the
-.B TXR
+In addition to embedded variables which implicitly match text, the \*(TX
 query language supports a number of directives, for matching text using regular
 expressions, for continuing a match in another file, for searching through a
 file for the place where an entire sub-query matches, for collecting lists, and
 for combining sub-queries using logical conjunction, disjunction and negation,
-and numerous others.  
+and numerous others.
 
-Furthermore, embedded within TXR is a powerful Lisp dialect.  TXR Lisp supports
+Furthermore, embedded within \*(TX is a powerful Lisp dialect.  \*(TL supports
 functional and imperative programming, and provides data types such as symbols,
 strings, vectors, hash tables with weak reference support, lazy lists, and
 arbitrary-precision (bignum integers).
@@ -396,11 +402,11 @@ and
 options are also mutually exclusive; if both are specified,
 it is a fatal error.
 
-.coIP -Dvar=value
+.meIP >> -D var=value
 Bind the variable
-.IR var
+.meta var
 to the value
-.IR value
+.meta value
 prior to processing the query. The name is in scope over the entire
 query, so that all occurrence of the variable are substituted and
 match the equivalent text.  If the value contains commas, these
@@ -417,9 +423,9 @@ match. That is to say, if a list variable occurs in a query, a successful
 match occurs if any of its values matches the text. If more than one
 value matches the text, the first one is taken.
 
-.coIP -Dvar
+.meIP >> -D var
 Binds the variable
-.IR var
+.meta var
 to an empty string value prior to processing the query.
 
 .coIP -q
@@ -431,39 +437,53 @@ of the query, only during its execution.
 .coIP -d
 .coIP --debugger
 
-Invoke the interactive txr debugger. See the DEBUGGER section.
+Invoke the interactive \*(TX debugger. See the DEBUGGER section.
 
 .coIP -v
 Verbose operation. Detailed logging is enabled.
 
 .coIP -b
-This is a deprecated option, which is silently ignored. In TXR versions
-prior to 90, the printing of variable bindings (see -B option) was
+This is a deprecated option, which is silently ignored. In \*(TX versions
+prior to 90, the printing of variable bindings (see
+.code -B
+option) was
 implicit behavior which was automatically suppressed in certain situations.
 The -b option suppressed it unconditionally.
 
 .coIP -B
 If the query is successful, print the variable bindings as a sequence
-of assignments in shell syntax can be eval-ed by a POSIX shell.
-If the query fails, print the word "false". Evaluation of this word
+of assignments in shell syntax that can be
+.IR eval -ed
+by a POSIX shell.
+II the query fails, print the word "false". Evaluation of this word
 by the shell has the effect of producing an unsuccessful termination
-status from the eval command.
+status from the shell's
+.I eval
+command.
 
 .coIP "-l or --lisp-bindings"
-This option implies -B. Print the variable bindings in Lisp syntax instead of
+This option implies
+.codn -B .
+Print the variable bindings in Lisp syntax instead of
 shell syntax.
 
-.coIP "-a num"
-This option implies -B. The decimal integer argument specifies the maximum
+.meIP -a < num
+This option implies
+.codn -B .
+The decimal integer argument
+.meta num
+specifies the maximum
 number of array dimensions to use for list-valued variable bindings.
 The default is 1. Additional dimensions are expressed using numeric suffixes
 in the generated variable names.
 For instance, consider the three-dimensional list arising out of a triply
-nested collect: 
+nested collect:
 .cblk
 ((("a" "b") ("c" "d")) (("e" "f") ("g" "h"))).
 .cble
-Suppose this is bound to a variable V.  With -a 1, this will be
+Suppose this is bound to a variable V.  With
+.codn -a 1 ,
+this will be
 reported as:
 
 .cblk
@@ -477,16 +497,31 @@ reported as:
   V_1_1[1]="h"
 .cble
 
+With
+.codn -a 2 ,
+it comes out as:
+
+.cblk
+  V_0[0][0]="a"
+  V_1[0][0]="b"
+  V_0[0][1]="c"
+  V_1[0][1]="d"
+  V_0[1][0]="e"
+  V_1[1][0]="f"
+  V_0[1][1]="g"
+  V_1[1][1]="h"
+.cble
+
 The leftmost bracketed index is the most major index. That is to say,
 the dimension order is:
 .codn "NAME_m_m+1_..._n[1][2]...[m-1]" .
 
-.coIP "-c query"
+.meIP -c < query
 Specifies the query in the form of a command line argument. If this option is
 used, the query-file argument is omitted. The first non-option argument,
 if there is one, now specifies the first input source rather than a query.
 Unlike queries read from a file, (non-empty) queries specified as arguments
-using -c do not have to properly end in a newline. Internally, TXR
+using -c do not have to properly end in a newline. Internally, \*(TX
 adds the missing newline before parsing the query. Thus
 .code -c
 .str @a
@@ -494,9 +529,7 @@ is a valid query which matches a line.
 
 Example:
 
-Shell script which uses
-.B TXR
-to read two lines
+Shell script which uses \*(TX to read two lines
 .str 1
 and
 .str 2
@@ -540,49 +573,54 @@ comment syntax can be used for better formatting:
 .cble
 .RE
 
-.coIP "-f query-file"
+.meIP -f < query-file
 Specifies the file from which the query is to be read, instead of the
-query-file argument. This is useful in
+.meta query-file
+argument. This is useful in
 .code #!
 ("hash bang") scripts. (See Hash Bang Support below).
 
-.coIP "-e expression"
-Evaluates a TXR Lisp expression for its side effects, without printing
+.meIP -e < expression
+Evaluates a \*(TL expression for its side effects, without printing
 its value. Can be specified more than once. The
-.code query-file
+.meta query-file
 argument becomes optional if
 .code -e
 is used at least once.
 
-.coIP "-p expression"
-Evaluates a TXR Lisp expression and prints its value.  Can be specified more
-than once. The query-file argument becomes optional if
+.meIP -p < expression
+Evaluates a \*(TL expression and prints its value.  Can be specified more
+than once. The
+.meta query-file
+argument becomes optional if
 .code -p
 is used at least once.
 
-.coIP "-C number"
-.coIP "--compat=number"
+.meIP -C < number
+.meIP >> --compat= number
 
-Requests TXR to behave in a manner that is compatible with the specified
-version of TXR. This makes a difference in situations when a release of
-TXR breaks backward compatibility. If some version N+1 deliberately introduces
+Requests \*(TX to behave in a manner that is compatible with the specified
+version of \*(TX. This makes a difference in situations when a release of
+\*(TX breaks backward compatibility. If some version N+1 deliberately introduces
 a change which is backward incompatible, then
 .code -C N
 can be used to request the old behavior.
 
-The requested value of N can be too low, in which case TXR
+The requested value of N can be too low, in which case \*(TX
 will complain and exit with an unsuccessful termination status. This indicates
-that TXR refuses to be compatible with such an old version. Users requiring
-the behavior of that version will have to install an older version of TXR which
+that \*(TX refuses to be compatible with such an old version. Users requiring
+the behavior of that version will have to install an older version of \*(TX which
 supports that behavior, or even that exact version.
 
 If the option is specified more than once, the behavior is not specified.
 
 For more information, see the COMPATIBILITY section.
 
-.coIP "--gc-delta=number"
+.meIP >> --gc-delta= number
 
-The argument to this option must be a decimal integer. It represents
+The
+.meta number
+argument to this option must be a decimal integer. It represents
 a megabyte value, the "GC delta": one megabyte is 1048576 bytes.  The "GC
 delta" controls an aspect of the garbage collector behavior.
 See the
@@ -595,16 +633,18 @@ Prints usage summary on standard output, and terminates successfully.
 .coIP --license
 Prints the software license. This depends on the software being
 installed such that the LICENSE file is in the data directory.
-Use of txr implies agreement with the liability disclaimer in the license.
+Use of \*(TX implies agreement with the liability disclaimer in the license.
 
 .coIP --version
 Prints program version standard output, and terminates successfully.
 
 .coIP --args
-The --args option provides a way to encode multiple arguments as a single
+The
+.code --args
+option provides a way to encode multiple arguments as a single
 argument, which is useful on some systems which have limitations in
-their implementation of the "hash bang" mechanism. See Hash Bang Support
-below.
+their implementation of the "hash bang" mechanism. For details about
+its special syntax, See Hash Bang Support below.
 
 .coIP --
 Signifies the end of the option list.
@@ -613,9 +653,11 @@ Signifies the end of the option list.
 This argument is not interpreted as an option, but treated as a filename
 argument. After the first such argument, no more options are recognized. Even
 if another argument looks like an option, it is treated as a name.
-This special argument - means "read from standard input" instead of a file.
+This special argument
+.code -
+means "read from standard input" instead of a file.
 The query file, or any of the data files, may be specified using this option.
-If two or more files are specified as 
+If two or more files are specified as
 .codn - ,
 the behavior is system-dependent.
 It may be possible to indicate EOF from the interactive terminal, and
@@ -631,8 +673,7 @@ a shell command which is to be run as a coprocess, and its output read like a
 file.
 
 .PP
-.B TXR
-begins by reading the query. The entire query is scanned, internalized
+\*(TX begins by reading the query. The entire query is scanned, internalized
 and then begins executing, if it is free of syntax errors.  The reading of
 data, on the other hand, is lazy.  A file isn't opened until the query demands
 material from that file, and then the contents are read on demand, not all at
@@ -646,43 +687,34 @@ prior to attempting to make a match. If a query attempts to match text,
 but has run out of files to process, the match fails.
 
 .SH* STATUS AND ERROR REPORTING
-.B TXR
-sends errors and verbose logs to the standard error device. The following
-paragraphs apply when
-.B TXR
-is run without enabling verbose mode with
+\*(TX sends errors and verbose logs to the standard error device. The following
+paragraphs apply when \*(TX is run without enabling verbose mode with
 .codn -v ,
 or the printing of variable
 bindings with
 .code -B
 or
-codn -a .
+.codn -a .
 
 If the command line arguments are incorrect, or the query has a malformed
-syntax,
-.B TXR
-issues an error diagnostic and terminates with a failed status.
+syntax, \*(TX issues an error diagnostic and terminates with a failed status.
 
-If the query fails due to a mismatch,
-.B TXR
+If the query fails due to a mismatch, \*(TX
 terminates with a failed status. No diagnostics are issued.
 
-If the query is well-formed, and matches, then
-.B TXR
+If the query is well-formed, and matches, then \*(TX
 issues no diagnostics, and terminates with a successful status.
 
 In verbose mode (option
 .codn -v ),
-.B TXR
-issues diagnostics on the standard error device even in situations which are
-not erroneous.
+\*(TX issues diagnostics on the standard error device even in situations which
+are not erroneous.
 
 In bindings-printing mode (options
 .code -B
 or
 .codn -a) ,
-.B TXR
-prints the word
+\*(TX prints the word
 .code false
 if the query fails, and exits with a failed
 termination status. If the query succeeds, the variable bindings, if any,
@@ -697,7 +729,7 @@ and extend to the end of the line. No whitespace can occur between the
 and
 .codn ; .
 A comment which begins on a line swallows that entire line, as well as the
-newline which terminates it. In essence, the entire comment disappears.
+newline which terminates it. In essence, the entire comment line disappears.
 If the comment follows some material in a line, then it does not consume
 the newline. Thus, the following two queries are equivalent:
 .IP 1.
@@ -729,21 +761,19 @@ character, the
 character can be used. This is an obsolescent feature.
 
 .SS* Hash Bang Support
-TXR has several features which support use of the "hash bang" convention
+\*(TX has several features which support use of the "hash bang" convention
 for creating apparently stand-alone executable programs.
 
 If the first line of a query begins with the characters
 .codn #! ,
 that entire line is deleted from the query. This allows
-for TXR queries to be turned into standalone executable programs in the POSIX
+for \*(TX queries to be turned into standalone executable programs in the POSIX
 environment.
 
 Shell example: create a simple executable program called
 .str "twoline.txr"
 and
-run it. This assumes
-.code txr
-is installed in
+run it. This assumes \*(TX is installed in
 .codn /usr/bin .
 
 .cblk
@@ -758,22 +788,22 @@ is installed in
   Hello, world!
 .cble
 
-When this plain hash bang line is used, txr receives the name of the script
+When this plain hash bang line is used, \*(TX receives the name of the script
 as an argument.  Therefore, it is not possible to pass additional options
-to txr.  For instance, if the above script is invoked like this
+to \*(TX.  For instance, if the above script is invoked like this
 
 .cblk
   $ ./hello.txr -B
 .cble
 
-the -B option isn't processed by txr, but treated as an additional argument,
+the -B option isn't processed by \*(TX, but treated as an additional argument,
 just as if
 .cblk
 .meti txr < scriptname -B
 .cble
 had been executed directly.
 
-This behavior is useful if the script author wants not to expose the txr
+This behavior is useful if the script author wants not to expose the \*(TX
 options to the user of the script.
 
 However, the hash bang line can use the
@@ -786,8 +816,8 @@ option:
 
 Now, the name of the script is passed as an argument to the
 .code -f
-option, and TXR will look for more options after that, so that the resulting
-program appears to accept TXR options. Now we can run
+option, and \*(TX will look for more options after that, so that the resulting
+program appears to accept \*(TX options. Now we can run
 
 .cblk
   $ ./hello.txr -B
@@ -807,7 +837,7 @@ not work.
   #!/usr/bin/txr -B -f
 .cble
 
-To support systems like this, TXR supports the special argument
+To support systems like this, \*(TX supports the special argument
 .codn --args .
 With
 .codn --args ,
@@ -841,7 +871,7 @@ is split into the two arguments
 .codn "-B -f" .
 
 .SS* Whitespace
-Outside of directives, whitespace is significant in TXR queries, and represents
+Outside of directives, whitespace is significant in \*(TX queries, and represents
 a pattern match for whitespace in the input.  An extent of text consisting of
 an undivided mixture of tabs and spaces is a whitespace token.  
 
@@ -857,7 +887,7 @@ Thus, the query line
 (one space between
 .code a
 and
-codn b )
+.codn b )
 matches
 .str "a b"
 with any number of spaces between the two letters.
@@ -866,7 +896,7 @@ For matching a single space, the syntax
 .code "@\e "
 can be used (backslash-escaped space).
 
-It is more often necessary to match multiple spaces, than to exactly
+It is more often necessary to match multiple spaces than to exactly
 match one space, so this rule simplifies many queries and adds inconvenience
 to only few.
 
@@ -894,8 +924,12 @@ tolerated, and are treated as if they had the terminator.
 Text which follows a variable has special semantics, discussed in the
 section Variables below.
 
-A query may not leave unmatched material in a line which is covered by the
-query.  However, a query may leave unmatched lines.
+A query may not leave a line of input partially matched. If any portion of a
+line of input is matched, it must be entirely matched, otherwise a matching
+failure results. However, a query may leave unmatched lines. Matching only
+four lines of a ten line file is not a matching failure. The
+.code eof
+directive can be used to explicitly match the end of a file.
 
 In the following example, the query matches the text, even though
 the text has an extra line.
@@ -916,7 +950,7 @@ the text has an extra line.
 In the following example, the query
 .B fails
 to match the text, because the text has extra material on one
-line.
+line that is not matched:
 .IP code:
 .cblk
 \ I can carry nearly eighty gigs
@@ -971,11 +1005,11 @@ that indentation can be introduced to show the continuation without appearing
 in the data.
 .meIP >> @\e  space
 A backslash followed by a space encodes a space. This is useful in line
-continuations when it is necessary for leading spaces to be preserved.
-For instance the two line sequence
+continuations when it is necessary for some or all of the leading spaces to be
+preserved.  For instance the two line sequence
 
 .cblk
-  abcd@\
+  abcd@\e
     @\e  efg
 .cble
 
@@ -985,8 +1019,9 @@ is equivalent to the line
   abcd  efg
 .cble
 
-The two spaces before the @\e in the second line are consumed. The
-spaces after are preserved.
+The two spaces before the
+.code @\e
+in the second line are consumed. The spaces after are preserved.
 
 .coIP @\ea
 Alert character (ASCII 7, BEL).
@@ -1005,17 +1040,18 @@ kinds of terminals, or ejects a page of text from a line printer.
 Carriage return (ASCII 13, CR).
 .coIP @\ee
 Escape (ASCII 27, ESC)
-.coIP @\exHEX
+.meIP @\ex < hex-digits
 A
 .code @\ex
-followed by a sequence of hex digits is interpreted as a hexadecimal
+immediately followed by a sequence of hex digits is interpreted as a hexadecimal
 numeric character code. For instance
 .code @\ex41
 is the ASCII character A.
-.coIP @\eOCTAL
+.meIP @\e < octal-digits
+
 A
 .code @\e
-followed by a sequence of octal digits (0 through 7) is interpreted
+immediately followed by a sequence of octal digits (0 through 7) is interpreted
 as an octal character code. For instance
 .code @\e010
 is character 8, same as
@@ -1035,20 +1071,17 @@ in
 
 .SS* Character Handling and International Characters
 
-.B TXR
-represents text internally using wide characters, which are used to represent
-Unicode code points. The query language, as well as all data sources, are
-assumed to be in the UTF-8 encoding.  In the query language, extended
+\*(TX represents text internally using wide characters, which are used to
+represent Unicode code points. The query language, as well as all data sources,
+are assumed to be in the UTF-8 encoding.  In the query language, extended
 characters can be used directly in comments, literal text, string literals,
 quasiliterals and regular expressions.  Extended characters can also be
 expressed indirectly using hexadecimal or octal escapes.
 On some platforms, wide characters may be restricted to 16 bits, so that
-.B TXR
-can only work with characters in the BMP (Basic Multilingual Plane)
+\*(TX can only work with characters in the BMP (Basic Multilingual Plane)
 subset of Unicode.
 
-.B TXR
-does not use the localization features of the system library;
+\*(TX does not use the localization features of the system library;
 its handling of extended characters is not affected by environment variables
 like
 .code LANG
@@ -1057,9 +1090,8 @@ and
 The program reads and writes only the UTF-8 encoding.
 
 If
-.B TXR
-encounters an invalid bytes in the UTF-8 input, what happens depends on the
-context in which this occurs. In a query, comments are read without regard
+\*(TX encounters an invalid bytes in the UTF-8 input, what happens depends on
+the context in which this occurs. In a query, comments are read without regard
 for encoding, so invalid encoding bytes in comments are not detected. A comment
 is simply a sequence of bytes terminated by a newline.  In lexical elements
 which represent text, such as string literals, invalid or unexpected encoding
@@ -1078,12 +1110,12 @@ mapping it to the Unicode character range U+DC00 through U+DCFF.  The decoding
 resumes afresh at the following byte, expecting that byte to be the start
 of a UTF-8 code.
 
-Furthermore, because TXR internally uses a null-terminated character
+Furthermore, because \*(TX internally uses a null-terminated character
 representation of strings which easily interoperates with C language
-interfaces, when a null character is read from a stream, TXR converts it to
+interfaces, when a null character is read from a stream, \*(TX converts it to
 the code U+DC00. On output, this code converts back to a null byte,
 as explained in the previous paragraph. By means of this representational
-trick, TXR can handle textual data containing null bytes.
+trick, \*(TX can handle textual data containing null bytes.
 
 .SS* Regular Expression Directives
 
@@ -1125,7 +1157,7 @@ the input is empty, or has run out of data. For instance suppose the third line
 of the query is the regular expression
 .codn @/.*/ ,
 but the input is a file which has
-only two lines. This will fail: the data has line for the regular expression to
+only two lines. This will fail: the data has no line for the regular expression to
 match. A line containing no characters is not the same thing as the absence of
 a line, even though both abstractions imply an absence of characters.
 
@@ -1160,13 +1192,14 @@ ways:
 The forms with an
 .code *
 indicate a long match, see Longest Match below.
-The last two forms with the embedded regexp
+The last two three forms with the embedded regexp
 .cblk
 .meti <> / regex /
 .cble
 or
 .meta number
-have special semantics, see Positive Match below.
+or function
+have special semantics; see Positive Match below.
 
 The identifier
 .code t
@@ -1212,7 +1245,7 @@ which are not allowed in a
 .metn sident :
 
 .cblk
- ! $ % & * + - < = > ? \e ^ _ ~
+ ! $ % & * + - < = > ? \e _ ~
 .cble
 
 The rule still holds that a name cannot look like a number so
@@ -1493,7 +1526,9 @@ ends up bound to the empty string.
 
 Example 1:
 .code b
-matches at position 0 and a gets nothing:
+matches at position 0 and
+.code a
+binds the empty string:
 .IP code:
 .cblk
 \ @a@(all)@b@(end)
@@ -1511,7 +1546,7 @@ matches at position 0 and a gets nothing:
 
 Example 2:
 .code *a
-specifies longest match (see Longest Match below), and so a gets
+specifies longest match (see Longest Match below), and so it takes
 everything:
 .IP code:
 .cblk
@@ -1559,6 +1594,7 @@ and the variable, e.g:
 \ FOO="b "
  b=""
 .cble
+.PP
 
 In the former example, the match extends to the rightmost occurrence of
 .strn "cd" ,
@@ -1577,7 +1613,7 @@ occurrence.
 
 .SS* Positive Match
 
-There are syntax variants of variable syntax which have an embedded expression
+There are syntactic variants of variable syntax which have an embedded expression
 enclosed with the variable in braces:
 
 .cblk
@@ -1623,7 +1659,7 @@ form, the match processes a field of text which
 consists of the specified number of characters, which must be non-negative
 number.  If the data line doesn't have that many characters starting at the
 current position, the match fails. A match for zero characters produces an
-empty string.  The text which is actually matched by this construct
+empty string.  The text which is actually bound to the variable
 is all text within the specified field, but excluding leading and
 trailing whitespace. If the field contains only spaces, then an empty
 string is extracted.
@@ -1632,7 +1668,7 @@ This syntax is processed without consideration of what other
 syntax follows.  A positive match may be directly followed by an unbound
 variable.
 
-.coSS* Special Symbols @ nil and @ t
+.coSS Special Symbols @ nil and @ t
 
 Just like in the Common Lisp language, the names
 .code nil
@@ -1649,13 +1685,13 @@ which may be used interchangeably with
 .code nil
 in most constructs.
 
-In TXR Lisp,
+In \*(TL,
 .code nil
 and
 .code t
 cannot be used as variables. When evaluated, they evaluate to themselves.
 
-In the TXR pattern language,
+In the \*(TX pattern language,
 .code nil
 can be used in the variable binding syntax, but does not create a binding;
 it has a special meaning.  It allows the variable matching syntax to be used to
@@ -1667,7 +1703,7 @@ The
 .code nil
 symbol is also used as a
 .code block
-name, both in the TXR pattern language and in TXR Lisp.
+name, both in the \*(TX pattern language and in \*(TL.
 A block named
 .code nil
 is considered to be anonymous.
@@ -1684,8 +1720,7 @@ useful for labeling information and situations.
 Regular expressions are a language for specifying sets of character strings.
 Through the use of pattern matching elements, regular expression is
 able to denote an infinite set of texts.
-.B TXR
-contains an original implementation of regular expressions, which
+\*(TX contains an original implementation of regular expressions, which
 supports the following syntax:
 .coIP .
 (period) is a "wildcard" that matches any character.
@@ -1695,7 +1730,7 @@ special syntax written between the square brackets.
 This supports basic regexp character class syntax. POSIX
 notation like
 .code [:digit:]
-is nto supported.
+is not supported.
 The regex tokens
 .codn \es ,
 .code \ed
@@ -1712,7 +1747,7 @@ means match a digit or
 a lowercase letter; the class
 .code [^0-9]
 means match a non-digit, and so forth.
-There are no locale-specific behaviors in TXR regular expressions;
+There are no locale-specific behaviors in \*(TX regular expressions;
 .code [A-Z]
 denotes an ASCII/Unicode range of characters.
 The class
@@ -1779,7 +1814,7 @@ The
 .code \ed
 token matches a digit, and is equivalent to
 .codn [0-9] .
-.dcoIP "\eS, \eW and \eD"
+.coIP "\eS, \eW and \eD"
 These regex tokens are the complemented counterparts of
 .codn \es ,
 .code \ew
@@ -1800,8 +1835,7 @@ matches nondigits.
 An empty expression is a regular expression. It represents the set of strings
 consisting of the empty string; i.e. it matches just the empty string. The
 empty regex can appear alone as a full regular expression (for instance the
-.B TXR
-syntax
+\*(TX syntax
 .code @//
 with nothing between the slashes)
 and can also be passed as a subexpression to operators, though this
@@ -2008,9 +2042,8 @@ where the trailing
 behaves like a postfix operator.
 
 In
-.B TXR,
-regular expression matches do not span multiple lines. The regex language has
-no feature for multi-line matching. However, the
+\*(TX, regular expression matches do not span multiple lines. The regex
+language has no feature for multi-line matching. However, the
 .code @(freeform)
 directive
 allows the remaining portion of the input to be treated as one string
@@ -2170,7 +2203,7 @@ and
 are the same
 character. The
 .code #\epnul
-character is specific to TXR and denotes the
+character is specific to \*(TX and denotes the
 .code U+DC00
 code in Unicode; the name stands for "pseudo-null", which is related to
 its special function. For more information about this, see the section
@@ -2320,8 +2353,8 @@ There is no
 .code \e@
 escape.  Quasiliterals support the full output variable
 syntax. Expressions within variables substitutions follow the evaluation rules
-of TXR Lisp when the quasiliteral occurs in TXR Lisp, and the rules of
-the TXR pattern language when the quasiliteral occurs in the pattern language.
+of \*(TL when the quasiliteral occurs in \*(TL, and the rules of
+the \*(TX pattern language when the quasiliteral occurs in the pattern language.
 
 Quasiliterals can be split into multiple lines in the same way as ordinary
 string literals.
@@ -2375,7 +2408,7 @@ merged into the surrounding syntax.
 
 .SS* Numbers
 
-TXR supports integers and floating-point numbers. 
+\*(TX supports integers and floating-point numbers. 
 
 An integer constant is made up of digits
 .code 0
@@ -2469,7 +2502,7 @@ Examples which are not floating-point constant tokens:
   .e     ;; consing dot followed by symbol e
 .cble
 
-In TXR there is a special "dotdot" token consisting of two consecutive periods.
+In \*(TX there is a special "dotdot" token consisting of two consecutive periods.
 An integer constant followed immediately by dotdot is recognized as such; it is
 not treated as a floating constant followed by a dot. That is to say,
 .code 123..
@@ -2617,7 +2650,7 @@ first successful clause.
 
 .coIP @(require)
 The require directive is similar to the do directive: it evaluates one or more
-TXR Lisp expressions.  If the result of the rightmost expression is nil,
+\*(TL expressions.  If the result of the rightmost expression is nil,
 then require triggers a match failure.  See the TXR LISP section far below.
 
 .ccIP @, @(if) @, @(elif) and @ @(else)
@@ -2792,10 +2825,10 @@ The filter directive passes one or more variables through a given
 filter or chain or filters, updating them with the filtered values.
 
 .coIP @(load)
-The load directive loads another TXR file and interprets its contents.
+The load directive loads another \*(TX file and interprets its contents.
 
 .coIP @(do)
-The do directive is used to evaluate TXR Lisp expressions, discarding their
+The do directive is used to evaluate \*(TL expressions, discarding their
 result values. See the TXR LISP section far below.
 
 .PP
@@ -2825,9 +2858,8 @@ and takes various arguments, according to these possibilities:
 The lone
 .code @(next)
 without arguments switches to the next file in the
-argument list which was passed to the
-.B TXR
-utility. However, "switch to the next file" means in a pattern matching
+argument list which was passed to the \*(TX utility.
+However, "switch to the next file" means in a pattern matching
 way, not in an imperative way. It is possible for the pattern matching
 logic to implicitly backtrack to the previous file.
 
@@ -2849,8 +2881,7 @@ means to switch to the file
 .strn "data.txt" .
 
 If the input source cannot be opened for whatever reason,
-.B TXR
-throws an exception (see EXCEPTIONS below). An unhandled exception will
+\*(TX throws an exception (see EXCEPTIONS below). An unhandled exception will
 terminate the program.  Often, such a drastic measure is inconvenient;
 if
 .code @(next)
@@ -3213,7 +3244,7 @@ can consume considerable CPU time when multiple skips are nested.  Consider:
 .cble
 
 This is actually nesting: the second a third skips occur within the body of the
-first one, and thus this creates nested iteration. TXR is searching for the
+first one, and thus this creates nested iteration. \*(TX is searching for the
 combination of skips which find match the pattern of lines
 .codn A ,
 .code B
@@ -3346,10 +3377,9 @@ iteration, only consumes the lines matched prior to
 The
 .code freeform
 directive provides a useful alternative to
-.B TXR's
-line-oriented matching discipline. The freeform directive treats all remaining
-input from the current input source as one big line. The query line which
-immediately follows freeform is applied to that line.
+\*(TX's line-oriented matching discipline. The freeform directive treats all
+remaining input from the current input source as one big line. The query line
+which immediately follows freeform is applied to that line.
 
 The syntax variations are:
 
@@ -3767,7 +3797,7 @@ is:
 .mets @(require << lisp-expression )
 .cble
 
-The require directive evaluates a TXR Lisp expression. (See TXR LISP far
+The require directive evaluates a \*(TL expression. (See TXR LISP far
 below.) If the expression yields a true value, then it succeeds, and matching
 continues with the directives which follow. Otherwise the directive fails.
 
@@ -3825,7 +3855,7 @@ after any
 .code @(elif)
 clauses. Any of the clauses may be empty.
 
-See the TXR Lisp section about TXR Lisp expressions. In this directive, TXR Lisp
+See the \*(TL section about \*(TL expressions. In this directive, \*(TL
 expressions are not introduced by the
 .code @
 symbol, just like in the
@@ -5356,7 +5386,7 @@ is:
 .mets @(do << lisp-expression )
 .cble
 
-The do directive evaluates a TXR Lisp expression. (See TXR LISP far
+The do directive evaluates a \*(TL expression. (See TXR LISP far
 below.) The value of the expression is ignored, and matching continues
 continues with the directives which follow the
 .code do
@@ -5389,7 +5419,7 @@ useful for simplifying the semantics of certain pattern matches,
 but also an optimization tool.
 
 Judicious use of blocks and escapes can reduce or eliminate the amount of
-backtracking that TXR performs.
+backtracking that \*(TX performs.
 
 .dir block
 
@@ -5843,42 +5873,33 @@ have no such special interaction with accept.
 
 .SH* FUNCTIONS
 .SS* Overview
-.B TXR
-functions allow a query to be structured to avoid repetition.
+\*(TX functions allow a query to be structured to avoid repetition.
 On a theoretical note, because
-.B TXR
-functions support recursion, functions enable TXR to match some
+\*(TX functions support recursion, functions enable \*(TX to match some
 kinds of patterns which exhibit self-embedding, or nesting,
 and thus cannot be matched by a regular language.
 
-Functions in
-.B TXR
-are not exactly like functions in mathematics or functional languages, and are
-not like procedures in imperative programming languages. They are not exactly
-like macros either. What it means for a
-.B TXR
-function to take arguments and produce a result is different from
+Functions in \*(TX are not exactly like functions in mathematics or functional
+languages, and are not like procedures in imperative programming languages.
+They are not exactly like macros either. What it means for a
+\*(TX function to take arguments and produce a result is different from
 the conventional notion of a function.
 
-A
-.B TXR
-function may have one or more parameters. When such a function is invoked, an
-argument must be specified for each parameter.  However, a special behavior is
-at play here. Namely, some or all of the argument expressions may be unbound
-variables.  In that case, the corresponding parameters behave like unbound
-variables also.  Thus
-.B TXR
-function calls can transmit the "unbound" state from argument to parameter.
+A \*(TX function may have one or more parameters. When such a function is
+invoked, an argument must be specified for each parameter.  However, a special
+behavior is at play here. Namely, some or all of the argument expressions may
+be unbound variables.  In that case, the corresponding parameters behave like
+unbound variables also.  Thus \*(TX function calls can transmit the "unbound"
+state from argument to parameter.
 
 It should be mentioned that functions have access to all bindings that are
 visible in the caller; functions may refer to variables which are not
 mentioned in their parameter list.
 
-With regard to returning,
-.B TXR
-functions are also unconventional. If the function fails, then the function
-call is considered to have failed. The function call behaves like a kind of
-match; if the function fails, then the call is like a failed match.
+With regard to returning, \*(TX functions are also unconventional. If the
+function fails, then the function call is considered to have failed. The
+function call behaves like a kind of match; if the function fails, then the
+call is like a failed match.
 
 When a function call succeeds, then the bindings emanating from that function
 are processed specially. Firstly, any bindings for variables which do not
@@ -6488,20 +6509,18 @@ In the future, additional suffixes may be searched (compiled versions
 of a file).
 
 Loading is performed at evaluation time; it is not a source file inclusion
-mechanism.  A TXR script is read from beginning to end and parsed prior to
+mechanism.  A \*(TX script is read from beginning to end and parsed prior to
 being evaluated.
 
 See also: the
 .code *self-path*
-variable in TXR Lisp.
+variable in \*(TL.
 
 .SH* OUTPUT
 
 .SS* Introduction
 
-A
-.B TXR
-query may perform custom output. Output is performed by
+A \*(TX query may perform custom output. Output is performed by
 .code output
 clauses,
 which may be embedded anywhere in the query, or placed at the end.  Output
@@ -6513,10 +6532,9 @@ An
 .code output
 clause specifies that its output goes to a file, pipe, or (by
 default) standard output. If any output clause is executed whose destination is
-standard output,
-.B TXR
-makes a note of this, and later, just prior to termination, suppresses the
-usual printing of the variable bindings or the word false.
+standard output, \*(TX makes a note of this, and later, just prior to
+termination, suppresses the usual printing of the variable bindings or the word
+false.
 
 .dir output
 
@@ -6648,7 +6666,7 @@ their contents are output.
 A variable being output can be any object. If it is of a type other
 than a list or string, it will be converted to a string as if by the
 .code tostring
-function in TXR Lisp.
+function in \*(TL.
 
 A list is converted to a string in a special way: the elements are
 individually converted to a string and then they are catenated together.
@@ -6962,7 +6980,7 @@ are to be iterated. This syntax is needed for situations in which
 .code @(repeat)
 is not able to deduce the existence of a variable in the block.
 It does not dig very deeply to discover variables, and does not "see"
-variables that are referenced via embedded TXR Lisp expressions.
+variables that are referenced via embedded \*(TL expressions.
 For instance, the following produces no output:
 
 .cblk
@@ -6975,7 +6993,7 @@ For instance, the following produces no output:
 .cble
 
 Although the list variable appears in the repeat block, it is embedded
-in a TXR Lisp construct. That construct will never be evaluated because
+in a \*(TL construct. That construct will never be evaluated because
 no repetitions take place: the repeat construct doesn't find any variables
 and so doesn't iterate. The remedy is to provide a little help via
 the :vars parameter:
@@ -7191,10 +7209,9 @@ and
 .codn &gt; .
 This is what filtering is for.  Filtering is applied to the contents of output
 variables, not to any template text.
-.B TXR
-implements named filters.  Built-in filters are named by keywords,
-given below. User-defined filters are possible, however.  See notes on the
-deffilter directive below.
+\*(TX implements named filters.  Built-in filters are named by keywords, given
+below. User-defined filters are possible, however.  See notes on the deffilter
+directive below.
 
 Instead of a filter name, the syntax
 .cblk
@@ -7634,14 +7651,13 @@ to upper case and HTML encode:
 
 .SS* Introduction
 
-The exceptions mechanism in
-.B TXR
+The exceptions mechanism in \*(TX
 is another disciplined form of non-local transfer, in addition to the blocks
 mechanism (see BLOCKS above).  Like blocks, exceptions provide a construct
 which serves as the target for a dynamic exit.  Both blocks and exceptions
 can be used to bail out of deep nesting when some condition occurs.
 However, exceptions provide more complexity. Exceptions are useful for
-error handling, and TXR in fact maps certain error situations to exception
+error handling, and \*(TX in fact maps certain error situations to exception
 control transfers. However, exceptions are not inherently an error-handling
 mechanism; they are a structured dynamic control transfer mechanism, one
 of whose applications is error handling.
@@ -8537,7 +8553,7 @@ supertype, while retaining
 .code gorilla
 as a subtype.  This situation could be diagnosed as an
 error, forcing the programmer to reorder the statements, but instead
-TXR obliges. However, there are limitations.  It is an error to define a
+\*(TX obliges. However, there are limitations.  It is an error to define a
 subtype-supertype relationship between two types if they are already connected
 by such a relationship, directly or transitively. So the following
 definitions are in error:
@@ -8621,17 +8637,16 @@ followed by a successful match for
 or else an exception is thrown.
 
 .SH* TXR LISP
+The \*(TX language contains an embedded Lisp dialect called \*(TL.
 
-The TXR language contains an embedded Lisp dialect called TXR Lisp.
-
-This language is exposed in TXR in several ways.
+This language is exposed in \*(TX in several ways.
 
 Firstly, in any situation that calls for an expression, a Lisp 
 expression can be used, if it is preceded by the
 .code @
 character. The Lisp expression
 is evaluated and its value  becomes the value of that expression.
-Thus, TXR directives are embedded in literal text using
+Thus, \*(TX directives are embedded in literal text using
 .codn @ ,
 and Lisp expressions
 are embedded in directives using
@@ -8648,12 +8663,12 @@ updating a hash table, et cetera.
 Thirdly, the
 .code @(require)
 directive can be used to evaluate Lisp expressions
-as part of the matching logic of the TXR pattern language. The return value
+as part of the matching logic of the \*(TX pattern language. The return value
 of the rightmost expression is examined. If it is nil, then the
 .code @(require)
 directive triggers a match failure. Otherwise, matching proceeds.
 
-Lastly, TXR Lisp expressions can be evaluated via the
+Lastly, \*(TL expressions can be evaluated via the
 command line, using the
 .code -e
 and
@@ -8703,7 +8718,7 @@ is greater than 42:
 
 .SS* Overview
 
-TXR Lisp is a small and simple dialect, like Scheme, but much more similar to
+\*(TL is a small and simple dialect, like Scheme, but much more similar to
 Common Lisp than Scheme. It has separate value and function binding namespaces,
 like Common Lisp (and thus is a Lisp-2 type dialect), and represents boolean
 .B true
@@ -8718,18 +8733,56 @@ identifiers denoting symbols!) Furthermore, the symbol
 .code nil
 is also the empty list, which terminates nonempty lists.
 
-Function and variable bindings are dynamically scoped in TXR Lisp. However,
-closures do capture variables.
+\*(TL has lexically scoped local variables and dynamic global variables,
+similarly to Common Lisp, including the convention that
+.code defvar
+marks symbols for dynamic binding in local scopes. Lexical closures
+are supported.  Funtions are lexically scoped in \*(TL; they can be
+defined in pervasive global environment using
+.code defun
+or in local scopes using
+.code flet
+and
+.codn labels .
 
 .SS* Additional Syntax
 
-Much of the TXR Lisp syntax has been introduced in the previous sections of the
+Much of the \*(TL syntax has been introduced in the previous sections of the
 manual, since directive forms are based on it. There is some additional syntax
-that is useful in TXR Lisp programming.
+that is useful in \*(TL programming.
+
+.SS* Symbol Tokens
+
+The symbol tokens in \*(TL,
+called a
+.meta lident
+(Lisp identifier) has a similar syntax to the
+.meta bident
+(braced identifier) in the \*(TX pattern language. It may consist of
+all the same characters, as well as the
+.code /
+(slash) character which may not be used in a
+.metn bident .
+Thus a
+.meta lident
+may consist of these characters, in addition to letters and numbers:
+
+.cblk
+ ! $ % & * + - < = > ? \e _ ~ /
+.cble
+
+and of course, may not look like a number. A lone
+.code /
+is a symbol in \*(TL. The token
+.code /abc/
+is also a symbol, and not a regular expression, like it is in the braced
+variable syntax. Within \*(TL, regular expressions are written with
+a leading
+.codn # .
 
 .SS* Consing Dot
 
-Unlike other major Lisp dialects, TXR Lisp allows a consing dot with no forms
+Unlike other major Lisp dialects, \*(TL allows a consing dot with no forms
 preceding it. This construct simply denotes the form which follows the dot.
 That is to say, the parser implements the following transformation:
 
@@ -8842,7 +8895,7 @@ Dialect note: in Common Lisp and Scheme,
 is written
 .codn `form ,
 and
-quasiquotes are also informally known as backquotes.  In TXR, the backquote
+quasiquotes are also informally known as backquotes.  In \*(TX, the backquote
 character
 .code `
 used for quasi string literals.
@@ -8910,7 +8963,7 @@ object, for instance:
 
 The
 .code #(1 2 3)
-literal is turned into a vector atom right in the TXR parser,
+literal is turned into a vector atom right in the \*(TX parser,
 and this atom is being quoted: this is
 .cblk
 .meti (quote << atom )
@@ -9033,7 +9086,7 @@ hash table based on the
 function, with no weak semantics.
 
 .coSS The @ .. notation
-In TXR Lisp, there is a special "dotdot" notation consisting of a pair of dots.
+In \*(TL, there is a special "dotdot" notation consisting of a pair of dots.
 This can be written between successive atoms or compound expressions, and is a
 shorthand for cons.
 
@@ -9080,7 +9133,7 @@ is invalid. The dotdot operator can only be used between the non-dot-position
 elements of a list.
 
 .SS* The DWIM Brackets
-TXR Lisp has a square bracket notation. The syntax
+\*(TL has a square bracket notation. The syntax
 .code [...]
 is a shorthand
 way of writing
@@ -9113,7 +9166,7 @@ More details are given in the documentation for the
 operator.
 
 .SS* Compound Forms
-In TXR Lisp, there are two types of compound forms: the Lisp-2 style
+In \*(TL, there are two types of compound forms: the Lisp-2 style
 compound forms, denoted by ordinary lists that are expressed with parentheses.
 There are Lisp-1 style compound forms denoted by the DWIM Brackets, discussed
 in the previous section.
@@ -9122,7 +9175,7 @@ The first position of an ordinary Lisp-2 style compound form, is expected to
 have a function or operator name.  Then arguments follow. There may
 also be an expression in the dotted position, if the form is a function call.
 
-The following are Lisp functions and variables built-in to TXR.
+The following are Lisp functions and variables built-in to \*(TX.
 
 If the form is a function call then the arguments are evaluated. If any of the
 arguments are symbols, they are treated according to Lisp-2 namespacing rules.
@@ -9171,7 +9224,7 @@ the expression which gives the trailing arguments is a symbol. Moreover,
 applying sequences other than lists is not supported.
 
 .SS* Regular Expressions
-In TXR Lisp, the
+In \*(TL, the
 .code /
 character can occur in symbol names, and the
 .code /
@@ -9204,7 +9257,7 @@ exists an object which is not a cons, yet which takes
 and
 .codn cdr .
 
-In TXR Lisp, this relaxation is extended further. For the sake of convenience,
+In \*(TL, this relaxation is extended further. For the sake of convenience,
 the operations
 .code car
 and
@@ -9294,7 +9347,7 @@ they produce lazy lists.
 
 .SS* Callable Objects
 
-In TXR Lisp, sequences (strings, vectors and lists) and hashes can be used
+In \*(TL, sequences (strings, vectors and lists) and hashes can be used
 as functions everywhere, not just with the DWIM brackets. Sequences work
 as one or two-argument functions. With a single argument, an element is
 selected by position and returned. With two arguments, a range is extracted and
@@ -9361,7 +9414,7 @@ select function, as if
 were called.
 
 .SS* Special Variables
-Similarly to Common Lisp, TXR Lisp is lexically scoped by default, but
+Similarly to Common Lisp, \*(TL is lexically scoped by default, but
 also has dynamically scoped (a.k.a "special") variables.
 
 When a variable is defined with defvar, it is introduced as a global
@@ -9386,7 +9439,7 @@ used as the name of a global variable, a good practice is to make global
 variables have visually distinct names via the "earmuffs" convention:
 beginning and ending the name with an asterisk.
 
-Certain variables in TXR's library break this convention; however, they at
+Certain variables in \*(TX's library break this convention; however, they at
 least have distinct prefixes, examples being example s-ifmt, log-emerg and
 sig-hup.
 
@@ -9435,7 +9488,7 @@ phase, but that is not considered macroexpansion, but rather an adjustment
 of the representation of the operator into an required executable form.)
 
 The following sections list all of the special operators, macros
-and functions in TXR Lisp.
+and functions in \*(TL.
 
 In these sections Syntax is indicated using these conventions:
 
@@ -9958,7 +10011,7 @@ and
 A block named by the symbol nil is slightly special: it is
 understood to be an anonymous block.
 
-Blocks in TXR Lisp have dynamic scope. This means that the following
+Blocks in \*(TL have dynamic scope. This means that the following
 situation is allowed:
 
 .cblk
@@ -9974,13 +10027,13 @@ block
 does not lexically surround
 .codn foo .
 
-Thus blocks in TXR Lisp provide dynamic non-local returns, as well
+Thus blocks in \*(TL provide dynamic non-local returns, as well
 as returns out of lexical nesting.
 
 .TP* "Dialect Note:"
 In Common Lisp, blocks are lexical. A separate mechanism consisting of
 catch and throw operators performs non-local transfer based on symbols.
-The TXR Lisp example:
+The \*(TL example:
 
 .cblk
   (defun func () (return-from foo 42))
@@ -10127,8 +10180,16 @@ a
 form. Symbol macros are expanded without any consideration for the
 .code dwim
 operator, which is not treated specially by the expansion phase.
-(Interaction between dwim and macros may become more sophisticated in the
-future.)
+
+Thus, the following is invalid:
+
+.cblk
+[let ((f (+ 2 2))) f]
+.cble
+
+the expression looks for a function or variable called
+.codn let ,
+which does not exist.
 
 How many arguments are required by the
 .code dwim
@@ -10300,18 +10361,20 @@ always means the first element, so that
 refers to all the elements except for the last one.
 
 .TP* Notes:
-The dwim operator allows for a Lisp-1 flavor of programming in TXR Lisp,
-which is normally Lisp-2, with some useful extensions.
+The dwim operator allows for a Lisp-1 flavor of programming in \*(TL,
+which is principally a Lisp-2 dialect.
 
 A Lisp-1 dialect is one in which an expression like
 .code (a b)
 treats both a and b
-as expressions subject to the same evaluation rules. This means that the symbols
+as expressions subject to the same evaluation rules\(emat least, when
+.code a
+isn't an operator or an operator macro. This means that the symbols
 .code a
 and
 .code b
-are resolved to values in the same namespace. The form denotes a  function call
-occurs if the value of variable
+are resolved to values in the same namespace. The form denotes a function call
+if the value of variable
 .code a
 is a function object.  Thus in a Lisp-1, named functions do not exist as
 such: they are just variable bindings.  In a Lisp-1
@@ -10331,32 +10394,6 @@ which holds a cons cell object, rather than the
 .code car
 function.
 
-The Lisp-1 design has a certain disadvantage, namely that it does not integrate
-cleanly with macros.  Macros break the Lisp-1 concept that all elements of a
-form are evaluated in the same way.  For instance, typical Lisp-1 dialects like
-Scheme have a
-.code let
-operator. So that
-.code (let ((a 1)) ...)
-has the expected meaning. But this expected meaning means that we must
-consider the first position of a compound form specially by checking
-whether it or not it is an operator. In TXR Lisp, this issue is avoided
-entirely, because Lisp-1 semantics are implemented in the
-square bracket notation corresponding to the
-.code dwim
-operator. This notation does not support operators in the leftmost
-position, period: all the positions in the notation are evaluated
-equally, just like the Lisp-1 mantra promises.
-
-Symbol macros do not pose a problem, and so if a symbol macro occurs in the
-first position of a square bracket form, it is treated the same way as in any
-other position.
-
-A "best of both worlds" situation is achieved with the the square brackets.
-They are just as convenient as parentheses and at the same time visually
-distinct, making it clear that different rules apply. Lisp-1 convenience
-is attained, minus the Lisp-1 conceptual problems with macro namespaces.
-
 The Lisp-1 approach is useful for functional programming, because it eliminates
 cluttering occurrences of the call and fun operators.  For instance:
 
@@ -10376,6 +10413,32 @@ and the
 .code dwim/[...]
 syntax does exactly this.
 
+However, Lisp-2 also has its advantages, whereas Lisp-1 also has disadvantages.
+Lisp-2 integrates with macros and operators more naturally than Lisp-1. Macros
+come in two flavors: symbol macros and operator macros. This distinction
+integrates better into a two namespace model, in which an operator macro is
+recognized in the first position of a form, and a symbol macro in other
+positions. Moreover, operators and operator macros are not functions; they
+cannot work by reducing a symbol to a macro function under ordinary
+evaluation rules. A Lisp-1 implementation must inspect the leftmost expression
+to determine whether or not it is an operator, which breaks the principle
+that all expressions are to be evaluated in the same way. Moreover, macros
+and operators are never indirected upon. If
+.code x
+is an operator or macro, it never makes sense for
+.code x
+to occur other than in the leftmost position of a form. In Lisp-1 dialects,
+the situation of using the name of an operator as a variable other than
+in the first position, as in
+.code (list let if)
+has no meaning, indicating that the single namespace model serves no purpose
+for macros and operators.
+
+\*(TL banishes operators and macros (except symbol macros) from Lisp-1
+evaluation, thereby achieving a more pure model of Lisp-1 evaluation than
+actual Lisp-1 languages, while retaining all the advantages of Lisp-2.
+In short, a "best of both worlds" situation is achieved in \*(TL.
+
 .coNP Function @ identity
 .synb
 .mets (identity << value )
@@ -10996,7 +11059,7 @@ A function may call itself by name, allowing for recursion.
 The
 .code lambda
 operator produces a value which is a function.  Like in most other
-Lisps, functions are objects in TXR Lisp.  They can be passed to functions as
+Lisps, functions are objects in \*(TL.  They can be passed to functions as
 arguments, returned from functions, aggregated into lists, stored in variables,
 et cetera.
 
@@ -11178,7 +11241,7 @@ retrieve a global macro expander using
 .codn symbol-function .
 
 .TP* "Dialect Note:"
-A lambda expression is not a function name in TXR Lisp. The
+A lambda expression is not a function name in \*(TL. The
 syntax
 .code (fun (lambda ...))
 is invalid.
@@ -11225,7 +11288,7 @@ printed representation looks like:
   #<cptr: 808be4f>
 .cble
 
-These details may change in future version of TXR.
+These details may change in future version of \*(TX.
 
 .TP* "Dialect note:"
 Forms which call
@@ -11413,7 +11476,7 @@ Cons cell.
 String.
 
 .coIP lit
-Literal string embedded in the TXR executable image.
+Literal string embedded in the \*(TX executable image.
 
 .coIP chr
 Character.
@@ -12013,7 +12076,7 @@ and
 functions return
 .metn cons .
 
-Note: TXR versions 89 and earlier, these functions returned the new value.
+Note: \*(TX versions 89 and earlier, these functions returned the new value.
 The behavior was undocumented.
 
 .coNP Functions @, second @, third @, fourth @ fifth and @ sixth
@@ -13777,14 +13840,14 @@ These functions are useful for simulating the
 .code maplist
 function found in other dialects like Common Lisp.
 
-TXR Lisp's
+\*(TL's
 .code (conses x)
 can be expressed in Common Lisp as
 .codn (maplist #'identity x) .
 
 Conversely, the Common Lisp operation
 .code (maplist function list)
-can be computed in TXR Lisp as
+can be computed in \*(TL as
 .codn (mapcar function (conses list)) .
 
 More generally, the Common Lisp operation
@@ -13893,7 +13956,7 @@ with an improper argument list.
 
 .TP* "Dialect Note:"
 Note that some uses of this function that are necessary in other Lisp dialects
-are not necessary in TXR Lisp. The reason is that in TXR Lisp, improper list
+are not necessary in \*(TL. The reason is that in \*(TL, improper list
 syntax is accepted as a compound form, and performs application:
 
 .cblk
@@ -16127,8 +16190,8 @@ If there is no such character, then
 is returned.
 
 .SS* Lazy Strings
-Lazy strings are objects that were developed for the TXR pattern matching
-language, and are exposed via TXR Lisp. Lazy strings behave much like strings,
+Lazy strings are objects that were developed for the \*(TX pattern matching
+language, and are exposed via \*(TL. Lazy strings behave much like strings,
 and can be substituted for strings. However, unlike regular strings, which
 exist in their entirety, first to last character, from the moment they are
 created, lazy strings do not exist all at once, but are created on demand.  If
@@ -18129,7 +18192,7 @@ to
 .desc
 This variable holds an integer representing the number of decimal digits
 in a decimal floating-point number such that this number can be converted
-to a TXR floating-point number, and back to decimal, without a change in any of
+to a \*(TX floating-point number, and back to decimal, without a change in any of
 the digits. This holds regardless of the value of the number, provided that it
 does not exceed the floating-point range.
 
@@ -18145,7 +18208,7 @@ approximations are accurate to
 decimal digits.
 
 .SS* Bit Operations
-In TXR Lisp, similarly to Common Lisp, bit operations on integers are based
+In \*(TL, similarly to Common Lisp, bit operations on integers are based
 on a concept that might be called "infinite two's-complement".  
 Under infinite two's complement, a positive number is regarded as having
 a binary representation prefixed by an infinite stream of zero digits (for
@@ -18184,7 +18247,7 @@ the value
 Hence, the infinite digit concept corresponds to an arithmetic
 interpretation.
 
-In fact TXR Lisp's bignum integers do not use a two's complement
+In fact \*(TL's bignum integers do not use a two's complement
 representation internally. Numbers are represented as an array which holds a
 pure binary number. A separate field indicates the sign, positive or
 non-negative.  That negative numbers appear as two's-complement under the bit
@@ -18820,7 +18883,7 @@ function parses a character string which contains a regular expression
 The regular expression syntax
 .code #/RE/
 produces the same structure, but as a
-literal which is processed at the time TXR source code is read; the
+literal which is processed at the time \*(TX source code is read; the
 .code regex-parse
 function performs this parsing at run-time.
 
@@ -20245,7 +20308,7 @@ macro.
 .cble
 
 .SS* Input and Output (Streams)
-TXR Lisp supports input and output streams of various kinds, with
+\*(TL supports input and output streams of various kinds, with
 generic operations that work across the stream types.
 
 In general, I/O errors are usually turned into exceptions. When the description
@@ -20444,7 +20507,7 @@ Prints any object in an aesthetic way, as if by the
 .code pprint
 function.
 The aesthetic notation violates read-print consistency: this notation
-is not necessarily readable if it is implanted in TXR source code.
+is not necessarily readable if it is implanted in \*(TX source code.
 The field width specifier is honored, including the left-right adjustment
 semantics.
 
@@ -20464,7 +20527,7 @@ printed without a trailing
 .coIP s
 Prints any object in a standard way, as if by the print function.  Objects for
 which read-print consistency is possible are printed in a way such that
-if their notation is implanted in TXR source, they are readable.
+if their notation is implanted in \*(TX source, they are readable.
 The field width specifier is honored, including the left-right adjustment
 semantics. The precision field is treated very similarly to the
 .code ~a
@@ -20567,7 +20630,7 @@ variable. The
 .code print
 function renders in a way which strives for read-print
 consistency: an object is printed in a notation which is recognized as
-a similar object of the same kind when it appears in TXR source code.
+a similar object of the same kind when it appears in \*(TX source code.
 The
 .code pprint
 function ("pretty print") does not strive for read-print consistency.
@@ -20766,7 +20829,7 @@ function is used to retrieve the accumulated string.
 
 If the null character is written to a string output stream, either via
 a character output operation or as a byte operation, the resulting string
-will appear to be prematurely terminated. TXR strings cannot contain null
+will appear to be prematurely terminated. \*(TX strings cannot contain null
 bytes.
 
 .coNP Function @ get-string-from-stream
@@ -21332,7 +21395,7 @@ Examples of strings which are not absolute paths.
 .desc
 The
 .code read
-function converts text denoting TXR Lisp structure, into the
+function converts text denoting \*(TL structure, into the
 corresponding data structure. The
 .meta source
 argument may be either a character
@@ -21340,7 +21403,7 @@ string, or a stream.  If it is omitted, then
 .code *stdin*
 is used as the stream.
 
-The source must provide the text representation of one complete TXR Lisp object.
+The source must provide the text representation of one complete \*(TL object.
 
 Multiple calls to read on the same stream will extract successive objects
 from the stream. To parse successive objects from a string, it is necessary
@@ -21596,7 +21659,7 @@ A failure results in an exception of type
 .syne
 .desc
 These functions spawn external programs which execute concurrently
-with the TXR program. Both functions return a unidirectional stream for
+with the \*(TX program. Both functions return a unidirectional stream for
 communicating with these programs: either an output stream, or an input
 stream, depending on the contents of
 .metn mode-string .
@@ -21706,7 +21769,7 @@ to exist until the program loses the last reference to that package.
 These variables hold predefined packages. The
 .code *user-package*
 is the one
-in which symbols are read when a TXR program is being scanned.
+in which symbols are read when a \*(TX program is being scanned.
 The
 .code *keyword-package*
 holds keyword symbols, which are printed with
@@ -21962,7 +22025,7 @@ interfere with each other. For instance objects or modules in a program can
 have their own independent streams of random numbers which are repeatable,
 independently of other modules making calls to the random number functions.
 
-When TXR starts up, the
+When \*(TX starts up, the
 .code *random-state*
 variable is initialized with
 a newly created random state object, which is produced as if by
@@ -22206,8 +22269,7 @@ savings time).
 The
 .code *args*
 variable holds a list of strings representing the remaining
-arguments which follow any options processed by the
-.code txr
+arguments which follow any options processed by the \*(TX
 executable, and the script name.
 
 The
@@ -22220,7 +22282,7 @@ Note: the
 variable is
 .code nil
 during the processing of the command line,
-so TXR Lisp expressions invoked using the
+so \*(TL expressions invoked using the
 .code -p
 or
 .code -e
@@ -22282,7 +22344,7 @@ The value returned is the prior value.
 .desc
 The
 .code exit
-function terminates the entire process (running TXR image), specifying
+function terminates the entire process (running \*(TX image), specifying
 the termination status to the operating system. Values of
 .meta status
 may be
@@ -22549,7 +22611,7 @@ searching for it using the
 system PATH.  Using either method, the executed process receives environment
 variables from the parent.
 
-TXR blocks until the process finishes executing. If the program terminates
+\*(TX blocks until the process finishes executing. If the program terminates
 normally, then its integer exit status is returned. The value zero indicates
 successful termination.
 
@@ -22570,20 +22632,20 @@ attempt.
 .SS* Unix Signal Handling
 
 On platforms where certain advanced features of POSIX signal handling are
-available at the C API level, TXR exposes signal-handling functionality.
+available at the C API level, \*(TX exposes signal-handling functionality.
 
-A TXR program can install a TXR Lisp function (such as an anonymous.
-codn lambda ,
+A \*(TX program can install a \*(TL function (such as an anonymous.
+.codn lambda ,
 or the function object associated with a named function) as the handler for
 a signal.
 
-When that signal is delivered, TXR will intercept it with its own safe,
-internal handler, mark the signal as deferred (in a TXR sense) and then
+When that signal is delivered, \*(TX will intercept it with its own safe,
+internal handler, mark the signal as deferred (in a \*(TX sense) and then
 dispatch the registered function at a convenient time.
 
-Handlers currently are not permitted to interrupt the execution of most TXR
+Handlers currently are not permitted to interrupt the execution of most \*(TX
 internal code.  Immediate, asynchronous execution of handlers is currently
-enabled only while TXR is blocked on I/O operations or sleeping.
+enabled only while \*(TX is blocked on I/O operations or sleeping.
 Additionally, the
 .code sig-check
 function can be used to dispatch and clear deferred
@@ -22729,8 +22791,8 @@ The
 .code sig-check
 function tests whether any signals are deferred, and for each
 deferred signal in turn, it executes the corresponding handler.  For a signal to
-be deferred means that the signal was caught by an internal handler in TXR and
-the event was recorded by a flag.  If a handler function is removed while a
+be deferred means that the signal was caught by an internal handler in \*(TX
+and the event was recorded by a flag.  If a handler function is removed while a
 signal is deferred, the deferred flag is cleared for that signal.
 
 Calls to the
@@ -22806,8 +22868,8 @@ which is given by the two arguments, expressed in microseconds.
 
 .SS* Unix Syslog
 
-On platforms where a Unix-like syslog API is available, TXR exports this
-interface. TXR programs can configure logging via the
+On platforms where a Unix-like syslog API is available, \*(TX exports this
+interface. \*(TX programs can configure logging via the
 .code openlog
 function,
 control the logging mask via
@@ -23007,7 +23069,7 @@ C function. The
 formatting capabilities of the function are not used;
 the
 .meta format
-argument follows the conventions of the TXR Lisp
+argument follows the conventions of the \*(TL
 .code format
 function instead. Note in particular that
 the
@@ -23405,7 +23467,7 @@ and the result of that is returned.
 .desc
 The
 .code match-fun
-function invokes a TXR pattern function whose name is
+function invokes a \*(TX pattern function whose name is
 given by
 .metn name ,
 which must be a symbol.
@@ -23415,7 +23477,7 @@ The
 argument is a list of expressions. The expressions may be symbols
 which will be interpreted as pattern variables, and may be bound or unbound.
 If they are not symbols, then they are treated as expressions (of the
-pattern language, not TXR Lisp) and evaluated accordingly.
+pattern language, not \*(TL) and evaluated accordingly.
 
 The
 .meta inpu
@@ -23425,7 +23487,7 @@ lines of the text stream to be processed.
 The
 .meta file
 argument is a list of filename specifications, which follow
-the same conventions as files given on the TXR command line. If the pattern
+the same conventions as files given on the \*(TX command line. If the pattern
 function uses the
 .code @(next)
 directive, it can process these additional files.
@@ -23703,7 +23765,7 @@ say, that for instance the read syntax
 is expected translated to
 .codn (qquote b (unquote c)) .
 
-In TXR Lisp, this is not true! Although
+In \*(TL, this is not true! Although
 .code ^(b b ,c)
 is translated to a
 quasiquoting macro, it is an internal one, not based on the public
@@ -23761,7 +23823,7 @@ macro and its associated
 .code sys:unquote
 and
 .code sys:splice
-operators work exactly like their ordinary counterparts. So in effect, TXR has
+operators work exactly like their ordinary counterparts. So in effect, \*(TX has
 two nearly identical, independent quasi-quote implementations, one of which is
 tied to the read syntax, and one of which isn't. This is useful for writing
 quasiquotes which write quasiquotes.
@@ -23837,10 +23899,10 @@ must evaluate to a list. That list is
 integrated into the surrounding list.
 
 .SS* Macros
-TXR Lisp supports structural macros. TXR's model of macroexpansion is that TXR
-Lisp code is processed in two phases: the expansion phase and the evaluation
-phase. The expansion phase is invoked on Lisp code early during the processing
-of source code. For instance when a TXR File containing a
+\*(TL supports structural macros. \*(TX's model of macroexpansion is that
+\*(TL code is processed in two phases: the expansion phase and the
+evaluation phase. The expansion phase is invoked on Lisp code early during the
+processing of source code. For instance when a \*(TX file containing a
 .code @(do ...)
 directive
 is loaded, expansion of the Lisp forms are its arguments takes place during the
@@ -23850,7 +23912,7 @@ that file is executed. If the
 form is later executed,
 the expanded forms are then evaluated.
 
-TXR Lisp also supports symbol macros, which are symbolic forms that stand
+\*(TL also supports symbol macros, which are symbolic forms that stand
 for forms, with which they are replaced at macro expansion time.
 
 When Lisp data is processed as code by the
@@ -23861,7 +23923,7 @@ in the evaluation phase.
 
 .coNP Macro parameter lists
 
-TXR macros support destructuring, similarly to Common Lisp macros.
+\*(TX macros support destructuring, similarly to Common Lisp macros.
 This means that macro parameter lists are like function argument lists,
 but support nesting. A macro parameter list can specify a nested parameter
 list in every place where a function argument list allows only a parameter
@@ -24489,7 +24551,7 @@ or
 .mets (source-loc-str << form )
 .syne
 .desc
-These functions map an expression in a TXR program to the file name and
+These functions map an expression in a \*(TX program to the file name and
 line number of the source code where that form came from.
 
 The
@@ -24506,7 +24568,7 @@ function formats the information as a string.
 If
 .meta form
 is not a piece of the program source code that was constructed by the
-TXR parser, then
+\*(TX parser, then
 .code source-loc
 returns
 .codn nil ,
@@ -24534,7 +24596,7 @@ Note: the function is intended to be used in macros. If a macro transforms
 to
 .metn dest-form ,
 this function can be used to propagate the
-source code location info also, so that when the TXR Lisp evaluator
+source code location info also, so that when the \*(TL evaluator
 encounters errors in transformed code, it can give diagnostics which refer
 to the original untransformed source code.
 
@@ -24574,7 +24636,7 @@ or
 if there are no forms,
 .meta malloc-bytes
 is the total number of bytes of all memroy allocation
-requests (or at least those known to the TXR runtime, such as those of all
+requests (or at least those known to the \*(TX runtime, such as those of all
 internal objects),
 .meta gc-bytes
 is the total number of bytes drawn from the
@@ -24654,7 +24716,7 @@ The
 .code gc-set-delta
 function sets the GC delta parameter.
 
-Note: This function may disappear in a future release of TXR or suffer
+Note: This function may disappear in a future release of \*(TX or suffer
 a backward-incompatible change in its syntax or behavior.
 
 When the amount of new dynamic memory allocated since the last garbage
@@ -24675,19 +24737,18 @@ when working with small objects, such as conses, to prevent runaway allocation
 of memory. It is for this reason that the garbage collector uses the GC delta.
 
 There is a default GC delta of 64 megabytes. This may be overridden in
-special builds of TXR for small systems.
+special builds of \*(TX for small systems.
 
 .SS* Modularization
 .coNP Special variable @ *self-path*
 .desc
-This variable holds the invocation path name of the TXR program.
+This variable holds the invocation path name of the \*(TX program.
 
 .SS* Debugger
-.B TXR
-has a simple, crude, built-in debugger. The debugger is invoked by adding
+\*(TX has a simple, crude, built-in debugger. The debugger is invoked by adding
 the
 .code -d
-command line option to an invocation of txr.
+command line option to an invocation of \*(TX.
 In this debugger it is possible to step through code, set breakpoints,
 and examine the variable binding environment.
 
@@ -24722,7 +24783,7 @@ directive, whereas the surface syntax appears flat.
 Here is an example of the debugger being applied to a web scraping program
 which connects to a US NAVY clock server to retrieve a dynamically-generated
 web page, from which the current time is extracted, in various time zones.
-The handling of the web request is done by the wget command; the txr
+The handling of the web request is done by the wget command; the \*(TX
 query opens a wget command as and scans the body of the HTTP response containing
 HTML. This is the code, saved in a file called navytime.txr:
 
@@ -24929,26 +24990,26 @@ Then a continue command, which finishes the program, whose output appears:
 
 .SS* Compatibility
 
-New TXR versions are usually intended to be backward-compatible with prior
+New \*(TX versions are usually intended to be backward-compatible with prior
 releases in the sense that documented features will continue to work in
-the same way. Due to new features, new versions of TXR will supply new
-behaviors where old versions of TXR would have produced an error, such as a
+the same way. Due to new features, new versions of \*(TX will supply new
+behaviors where old versions of \*(TX would have produced an error, such as a
 syntax error. Though, strictly speaking, this means that something is working
 differently in a new version, replacing an error situation with functionality
 is usually not considered a deviation from backward-compatibility.
 
-When a change is introduced which is not backward compatible, TXR's 
+When a change is introduced which is not backward compatible, \*(TX's 
 .code -C
 option can be used to request emulation of old behavior.
 
-The option was introduced in TXR 98, and so the oldest TXR version which
-can be emulated is TXR 97.
+The option was introduced in \*(TX 98, and so the oldest \*(TX version which
+can be emulated is \*(TX 97.
 
 Here are values which have a special meaning as arguments to the
 .code -C
 option, along with a description of what behaviors are affected:
 .IP 97
-Up to TXR 97, the error exception symbols such as
+Up to \*(TX 97, the error exception symbols such as
 .code file-error
 were named with underscores, as in
 .codn file_error .
@@ -25035,9 +25096,8 @@ This
 idiom is also called set
 difference, sometimes notated with a minus sign:
 .code A-B
-(which is not supported in
-.B TXR
-regular expression syntax).  Elements which are in the set
+(which is not supported in \*(TX regular expression syntax).  Elements which
+are in the set
 .codn A ,
 but not
 .codn B ,