summaryrefslogtreecommitdiff
path: root/support/splint/cweb
diff options
context:
space:
mode:
authorNorbert Preining <norbert@preining.info>2020-10-12 03:04:00 +0000
committerNorbert Preining <norbert@preining.info>2020-10-12 03:04:00 +0000
commit0ce40abb18ec02ec6fd6bcc5f21612c88daa7578 (patch)
tree416289fe1448873fd8ca33051f50ad85bffa8aaa /support/splint/cweb
parentfdb18507cd80dc17f5a5256153d34668b4f4e61c (diff)
CTAN sync 202010120303
Diffstat (limited to 'support/splint/cweb')
-rw-r--r--support/splint/cweb/Makefile165
-rw-r--r--support/splint/cweb/bo.w1735
-rw-r--r--support/splint/cweb/bs.w69
-rw-r--r--support/splint/cweb/checklists.w82
-rw-r--r--support/splint/cweb/common.w66
-rw-r--r--support/splint/cweb/fk.w63
-rw-r--r--support/splint/cweb/fo.w702
-rw-r--r--support/splint/cweb/lo.w242
-rw-r--r--support/splint/cweb/mkeparser.w24
-rw-r--r--support/splint/cweb/mkscanner.w11
-rw-r--r--support/splint/cweb/np.w141
-rw-r--r--support/splint/cweb/philosophy.w306
-rw-r--r--support/splint/cweb/references.w31
-rw-r--r--support/splint/cweb/so.w835
-rw-r--r--support/splint/cweb/splint.w1839
-rw-r--r--support/splint/cweb/ssffo.w25
16 files changed, 4417 insertions, 1919 deletions
diff --git a/support/splint/cweb/Makefile b/support/splint/cweb/Makefile
index ec9973fb66..1c3b4d6bc3 100644
--- a/support/splint/cweb/Makefile
+++ b/support/splint/cweb/Makefile
@@ -1,30 +1,86 @@
-SPLINT_ROOT = $(shell pwd)/..
-
-include ${SPLINT_ROOT}/makefile.inc
-
-all: ${SPLINT_PTABLES} ${SPLINT_LTABLES}
+# Copyright 2012-2020, Alexander Shibakov
+# This file is part of SPLinT
+#
+# SPLinT is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# SPLinT is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with SPLinT. If not, see <http://www.gnu.org/licenses/>.
+
+include ../makefile.inc
+
+all: ${SPLINT_PTABLES} ${SPLINT_LTABLES}
b%out: mkeparser.c b%.c
${CC} ${BISON_STATE} -DPARSER_FILE=\"$(lastword $^)\" -DYYPARSE_PARAMETERS= -o $@ $<
-b%.yy: bo.x
- ${CTANGLE} $<
+b%.yy: bo.x
+ ${CTANGLE} $<
-%yytab.tex: b%out
- ${SPLINT_DRIVER_DIR}/$< --optimize-actions $@
+%yytab.tex: b%out
+ ${SPLINT_DRIVER_DIR}/$< --optimize-actions $@
-ltab.tex: ltout
- ${SPLINT_DRIVER_DIR}/$< --optimize-actions $@
+ltab.tex: ltout
+ ${SPLINT_DRIVER_DIR}/$< --optimize-actions $@
-ltout: mkscanner.c lo_states.h lo.c
- ${CC} -DLEXER_FILE=\"$(lastword $^)\" -o $@ $<
+ltout: mkscanner.c lo_states.h lo.c
+ ${CC} -DLEXER_FILE=\"$(lastword $^)\" -o $@ $<
ssffo.ll lo.ll: \
-%.ll: %.x
- ${CTANGLE} $< && rm $(patsubst %.x, %.c, $^)
+%.ll: %.x
+ ${CTANGLE} $< && rm $(patsubst %.x, %.c, $^)
+
+fil.ll: so.x
+ ${CTANGLE} $< && rm $(patsubst %.x, %.c, $^)
+
+fip.yy rep.yy rap.yy \
+ddp.yy: fo.x
+ ${CTANGLE} $< && rm $(patsubst %.x, %.c, $^)
+
+# flex parser
+
+fil.c: fil.l
+ ${FLEX} -o $@ $<
-lo.c: lo.l
- ${FLEX} -o $@ $<
+fil_out: mkscanner.c fil_states.h fil.c
+ ${CC} -DLEXER_FILE=\"$(lastword $^)\" -o $@ $<
+
+fil_states.h: so.tex lstab.tex byytab.tex
+ ${PDFTEX} $<
+
+filtab.tex: fil_out
+ ${SPLINT_DRIVER_DIR}/$< --optimize-actions --optimize-tables $@
+
+fip.c rep.c rap.c \
+ddp.c:%.c: %.y
+ ${BISON} -o $@ $<
+
+fip_out rap_out \
+ddp_out rep_out:%_out: mkeparser.c %.c
+ ${CC} ${BISON_STATE} -DPARSER_FILE=\"$(lastword $^)\" -DYYPARSE_PARAMETERS= -o $@ $<
+
+fiptab.tex raptab.tex \
+ddptab.tex reptab.tex:%tab.tex: %_out
+ ${SPLINT_DRIVER_DIR}/$< --optimize-actions --optimize-tables $@
+
+so.tex: so.x
+ ${CWEAVE} $<
+
+fo.tex: fo.x
+ ${CWEAVE} $<
+
+fo.tok: fo.tex ltab.tex byytab.tex
+ ${TEX} ${MODEBOOTSTRAP} \\input $<
+
+lo.c: lo.l
+ ${FLEX} -o $@ $<
mkscanner.c mkeparser.c: \
%.c: %.w
@@ -35,25 +91,30 @@ mkscanner.c mkeparser.c: \
smallp_out: mkeparser.c small_parser.c
${CC} ${BISON_STATE} -DPARSER_FILE=\"$(lastword $^)\" -DYYPARSE_PARAMETERS= -o $@ $<
-smalll_out: mkscanner.c small_lexer.c
- ${CC} -DLEXER_FILE=\"$(lastword $^)\" -o $@ $<
+smalll_out: mkscanner.c small_lexer.c
+ ${CC} -DLEXER_FILE=\"$(lastword $^)\" -o $@ $<
-small_tab.tex: smallp_out
- ${SPLINT_DRIVER_DIR}/$< --optimize-actions $@
+small_tab.tex: smallp_out
+ ${SPLINT_DRIVER_DIR}/$< --optimize-actions $@
-small_dfa.tex: smalll_out
- ${SPLINT_DRIVER_DIR}/$< --optimize-actions $@
+small_dfa.tex: smalll_out
+ ${SPLINT_DRIVER_DIR}/$< --optimize-actions $@
-small_parser.yy small_lexer.ll: np.x
+small_parser.yy \
+small_lexer.ll: np.x
@${CTANGLE} $<
-bo.tex: bo.x
- ${CWEAVE} -x $<
+bo.tex: bo.x
+ -${CWEAVE} -x $<
splint.tex \
splint.idx \
-splint.scn: splint.w bo.x lo.x np.x common.w bs.w fk.w philosophy.w references.w
- ${CWEAVE} $<
+splint.scn: splint.x bo.x lo.x fo.x so.x np.x common.w bs.w \
+ fk.w philosophy.w checklists.w references.w alphas.hx
+ -${CWEAVE} $<
+
+alphas.hx:
+ ${MISCCW} --alpha-list --alpha-length=1 $@
ssffo.tex \
ssffo.idx ssffo.scn: ssffo.x
@@ -70,46 +131,56 @@ ssffo.dvi: %.dvi: ${SPLINT_DOC_PREREQS_XREF}
splint.gdx: %.gdx: ${SPLINT_DOC_PREREQS_XREF}
@echo "Making the bison and TeX indices ..."
- ${TEX} $*.tex
+ ${PDFTEX} $*.tex
+
+%.gdy: %.gdx
+
+splint.gdy: splint.gdx
+ ${BINDX} --fine $^ $@
-splint.pdf: %.pdf: ${SPLINT_DOC_PREREQS_XREF} %.gdy
+splint.xxr: %.xxr: ${SPLINT_DOC_PREREQS_XREF}
+ @echo "Generating the cross references ..."
+ ${PDFTEX} $*.tex
+
+splint.pdf: %.pdf: ${SPLINT_DOC_PREREQS_XREF} %.gdy %.xxr
${PDFTEX} \\input $*.tex && touch $*.gdy && touch $*.pdf
splint.dvi: %.dvi: ${SPLINT_DOC_PREREQS_XREF} %.gdy
- ${TEX} $*.tex && touch $*.gdy && touch $*.dvi
+ ${TEX} $*.tex && touch $*.gdy && touch $*.dvi && rm $*.xxr && rm $*.ftn
-${SPLINT_ROOT}/tex/btokenset.sty: # stupid make weirdness
- @
+${SPLINT_ROOT}tex/btokenset.sty: # stupid make weirdness
+ @
# state parsing
-lstabout: mkscanner.c ssffo.c
- ${CC} -DLEXER_FILE=\"$(lastword $^)\" -o $@ $<
+lstabout: mkscanner.c ssffo.c
+ ${CC} -DLEXER_FILE=\"$(lastword $^)\" -o $@ $<
-lstab.tex: lstabout
- ${SPLINT_DRIVER_DIR}/$< --optimize-actions $@
+lstab.tex: lstabout
+ ${SPLINT_DRIVER_DIR}/$< --optimize-actions $@
-lo.tex: lo.x
- ${CWEAVE} $<
+lo.tex: lo.x
+ ${CWEAVE} $<
-lo_states.h: lo.tex lstab.tex byytab.tex
- ${PDFTEX} $<
+lo_states.h: lo.tex lstab.tex byytab.tex
+ ${PDFTEX} $<
# clean will erase all automatically generated files in the current directory
-clean: clean_core
- -rm -f ctablesout b?out ltout smallp_out \
- smalll_out lstabout
+clean: clean_core
+ -rm -f ctablesout b?out ltout smallp_out \
+ smalll_out lstabout fil_out fip_out rep_out rap_out ddp_out
-include ${SPLINT_ROOT}/makefile.loc
+include ${SPLINT_ROOT}makefile.loc
# since bg.yy is not an intermediate file in examples/symbols/Makefile, repeated 'make all'
# remakes bg.yy thereby forcing make to update byytab.tex, etc., which results in remaking
# of bo.tok, lo.tex, eventually leading to remaking of splint.pdf;
# the special target below tells make to treat bg.yy as if it were not an intermediate file
-.PRECIOUS: bg.yy bg.y
+.PRECIOUS: %.yy bo.tok fo.tok %.ll b%.y splint.gdx splint.xxr
# the files below appear as targets but are really intermediaries for other files
-.INTERMEDIATE: smallp_out smalll_out lstabout ltout splint.gdx
+.INTERMEDIATE: smallp_out smalll_out lstabout ltout fil_out \
+ fip_out rep_out rap_out ddp_out splint.gdx
diff --git a/support/splint/cweb/bo.w b/support/splint/cweb/bo.w
index 2185f2f65e..fe7bf59f52 100644
--- a/support/splint/cweb/bo.w
+++ b/support/splint/cweb/bo.w
@@ -1,4 +1,4 @@
-% Copyright 2012-2014, Alexander Shibakov
+% Copyright 2012-2020, Alexander Shibakov
% Copyright 2002-2014 Free Software Foundation, Inc.
% This file is part of SPLinT
%
@@ -15,1433 +15,70 @@
% You should have received a copy of the GNU General Public License
% along with SPLinT. If not, see <http://www.gnu.org/licenses/>.
-\input limbo.sty
-\input frontmatter.sty
-\def\optimization{5}
-\input yy.sty
-% multi-column output
-\input dcols.sty
-
-\let\hostparsernamespace\mainnamespace % the namespace where tokens are looked up
- % for typesetting purposes
-\let\currentparsernamespace\parsernamespace
- \let\parsernamespace\mainnamespace
- \let\currenttokeneq\tokeneq
- %\def\tokeneq#1#2{\prettytoken{#1}}
- \let\tokeneq\prettywordpair@@
- \let\optstrextra\optstrextraesc
- \input bo.tok % re-use token equivalence table to set the typesetting of tokens
- \let\tokeneq\currenttokeneq
- \input btokenset.sty
- % index entries
- \let\parsernamespace\indexpseudonamespace
- \prettywordpair{emptyrhs}{$\circ$ {\rm(empty rhs)}}%
- \prettywordpair{inline_action}{$\diamond$ {\rm(inline action)}}%
- \prettywordpair{TOKEN}{{\tt TOKEN} {\rm(example)}}%
- \prettywordpair{token}{{\tt "token"} {\rm(example)}}%
-\let\parsernamespace\currentparsernamespace
-
-\immediate\openout\exampletable=\jobname.exl
-
-\def\nontitle#1{{\ttl #1}}
-\def\cite[#1]{%
- \def\next{#1}\setbox0=\hbox{l}%
- [\ifx\next\empty$\,$\hbox{\vrule width\wd0 height\ht0 depth\dp0}$\,$\else \locallink{#1bibref}#1\endlink\fi]%
-}
-
-\let\oldN\N
-\let\N\textN
-\let\M\textM
-
-\defreserved{Y}{\.{Y}}
-\showlastactiontrue
-
-@**Introduction.
-\setupfootnotes
-\splint\footnote{I was tempted to call the package {\tt ParLALRgram}
-which stands for Parsing {\sc LALR} Grammars or {\tt PinT} for
-`Parsing in \TeX' but both sounded too generic.} (Simple Parsing and
-Lexing in \TeX, or, following the great GNU
-tradition of creating recursive names, \splint\ Parses Languages
-in \TeX) is a system (or
-rather a m\'elange of systems) designed to
-facilitate developing parsing macros in \TeX\ and (to a lesser
-degree) documenting parsers written in other languages. As
-an application, a parser for \bison\ input file syntax has been
-developed, along with a macro collection that makes it possible to
-design and pretty print \bison\ grammars using \CWEB.
-
-Developing software in \CWEB\ involves two programs. The first of these is
-\CTANGLE\ that outputs the actual code, intended to be in
-\Cee. In reality, \CTANGLE\ cares very little about the language it
-produces. Exceptions are \Cee\ comments and |@[#line@]| directives that might
-confuse lesser software, although \bison\ is all too happy to swallow them
-(there are also some \Cee\ specific constructs that \CTANGLE\ tries to
-recognize). \CTANGLE's main function is to rearrange the text of the
-program as written by the programmer (in a way that, hopefully,
-emphasizes the internal logic of the code) into an appropriate
-sequence (e.g.~all variable declaration must textually precede their
-use). All that is required to adopt \CTANGLE\ to produce \bison\
-output is some very rudimentary post- and pre-processing.
-
-Our main concern is thus \CWEAVE\ that not only pretty prints the
-program but also creates an index, cross-references all the
-sections, etc. Getting \CWEAVE\ to pretty print a language other than
-\Cee\ requires some additional attention. A true digital warrior would
-probably try to decipher \CWEAVE's output `in the raw' but, alas, my
-WebFu is not that strong. The loophole comes in the form of a rarely
-(for a good reason) used \CWEB\ command: the verbatim (\.{@@=...@@>})
-output. The material to be output by this construct undergoes minimal
-processing and is put inside \.{\\vb\{}$\ldots$\.{\}}. All that is
-needed now is a way to process this virtually straight text inside \TeX.
-
-@*1 Using the \bison\ parser.
-The process of using \splint\ for writing parsing macros in \TeX\ is
-treated in considerable detail later in this document. A shorter
-(albeit somewhat outdated but still applicable) version of this
-process is outlined in \cite[Sh]. We begin,
-instead, by explaining how one such parser can be used to pretty print a
-\bison\ grammar. Following the convention mentioned above and putting
-all non-\Cee\ code inside \CWEAVE's verbatim blocks, consider the
-following (meaningless) code fragment. The fragment contains a mixture
-of \Cee\ and \bison\ code, the former appears outside of the verbatim blocks.
-\begindemo
-^@@= non_terminal: @@>
-^@@= term.1 term.2 {@@> a = b; @@=}@@>
-^@@= **H term.3 other_term {@@> $$ = $1; @@=}@@>
-^@@= **H still more terms {@@> f($1); @@=}@@>
-^@@= ; @@>
-\enddemo
-The fragment above will appear as (the output of \CTANGLE\ can be
-examined in \.{sill.y})
-@<A silly example@>=
-@G
-non_terminal:
- term.1 term.2 {@> a = b; @=}
-| term.3 other_term {@> $$ = $1; @=}
-| still more terms {@> f($1); @=}
-;
-@g
-
-@ $\ldots$ if the syntax is correct.
-In case it is a bit off, the parser will give up and
-you will see a different result. The code in the fragment below is easily
-recognizable, and some parts of it (all of \Cee\ code, in fact) are
-still pretty printed in \CWEAVE. Only the verbatim portion is left
-unprocessed.
-@<A silly example@>=
-@G
-whoops
- term.1 term.2 {@>@+ a = b; @+@=}
-| term.3 other_term {@>@+ $$ = $1; @+@=}
-| still more terms {@>@+ f($1); @+@=}
-;
-@g
-
-@ The \TeX\ header that makes such output possible is quite plain. In this case
-(i.e.\ this very file) it begins as
-\begindemo
-^\input limbo.sty
-^\input frontmatter.sty
-^\input yy.sty
-\nooutput
-\enddemo
-The first two lines are presented here merely for completeness: there is
-no parsing-relevant code in them. The line that
-follows loads the macros that implement the parsing and scanning
-machinery. This is enough to set up all the basic
-mechanisms used by the parsing and lexing macros. The rest of the header
-provides a few definitions to fine tune the typesetting of
-grammar productions. It starts with
-\begindemo
-^\let\currentparsernamespace\parsernamespace
-^ \let\parsernamespace\mainnamespace
-^ \let\currenttokeneq\tokeneq
-^ \def\tokeneq#1#2{\prettytoken{#1}}
-^ \input bo.tok % re-use token equivalence table to set the typesetting of tokens
-^ \let\tokeneq\currenttokeneq
-^ \input btokenset.sty
-\nooutput
-\enddemo
-We will have a chance to discuss all the \.{\\}$\ldots$\.{namespace}
-macros later, at this point it will suffice to say that the lines
-above are responsible for controlling the typesetting of term names. The
-file \.{bo.tok} consists of a number of lines like the ones below:
-\begindemo
-^\tokeneq {STRING}{{34}{115}{116}{114}{105}{110}{103}{34}}
-^\tokeneq {PERCENT_TOKEN}{{34}{37}{116}{111}{107}{101}{110}{34}}
-\nooutput
-\enddemo
-The cryptic looking sequences of integers above are strings of {\sc ASCII}
-codes of the letters that form the name \bison\ uses when it needs to
-refer to the corresponding token (thus, the second one is
-\toksa{}\numberstochars{34}{37}{116}{111}{107}{101}{110}{34}\end
-\.{\the\toksa} which might help explain why such an elaborate scheme
-has been chosen). The macro \.{\\tokeneq} is defined in
-\.{yymisc.sty}, which in turn is input by \.{yy.sty} but what about
-the token names themselves? In this case they were extracted
-automatically from the \CWEB\ source file by the parser during the
-\CWEAVE\ processing stage. All of these definitions can be
-overwritten to get the desired output (say, one might want to typeset
-\.{ID} in a roman font, as `identifier'; all that needs to be done is
-a macro that says \.{\\prettywordpair\{ID\}\{\{\\rm
-identifier\}\}}). The file \.{btokenset.sty} input above contains a
-number of such definitions.
-
-@ To round off this short overview, I must mention a caveat associated
-with using the macros in this collection: while one of the greatest
-advantages of using \CWEB\ is its ability to rearrange the code in a
-very flexible way, the parser will either give up or produce
-unintended output if this feature is abused while describing the
-grammar. For example, in the code below
-@<A silly example@>=
-@G
-next_term:
- stuff @> @<Rest of line@> @={@> a = f( x ); @=}
-@g
-@<A production@>@;
-
-@ the line titled |@<A production@>| is intended to be a rule defined
-later. Notice that while it seems that the parser was able to recognize
-the first code fragment as a valid \bison\ input, it misplaced the
-|@<Rest of line@>|, having erroneously assumed it to be a part of
-the action code for this grammar (later on we will go into the details of
-why it is necessary to collect all the non-verbatim output of \CWEAVE,
-even the one that contains no interesting \Cee\ code; hint: it has
-something to do with money (\.{\$}), also known as math and the way
-\CWEAVE\ processes the `gaps' between verbatim sections). The production
-line that follows did not fare as well: the parser gave up. There
-is simply no point in including such a small language fragment as a
-valid input for the grammar the parser uses to process the verbatim
-output.
-@<A production@>=
-@G
- more stuff in this line {@> @[b = g(y);@]@=}
-@g
-
-@ Finally, if you forget that only the verbatim part of the output is
-looked at by the parser you might get something unrecognizable, such
-as
-@<Rest of line@>=
- but not all of it
-
-@ To correct this, one can provide a more complete grammar fragment to
-allow the parser to complete its task successfully. In some cases,
-this imposes too strict a constraint on the programmer. Instead, the
-parser that pretty prints \bison\ grammars allows one to add {\it
-hidden context\/} to the code fragments above. The context is added
-inside \.{\\vb} sections using \CWEB's \.{@@t}$\ldots$\.{@@>} facility. The \CTANGLE\
-output is not affected by this while the code above can now be typeset as:
-@<A silly example@>=
-@G
-next_term:
- stuff @> @t}\vb{\formatlocal{\let\peekstash\stashtoterm}}{@> @<Rest of line@> @t}\vb{FAKE}{@> @={@> a = f( x ); @=}
-@g
-@<A production@>@;
-
-@ $\ldots$ even a single line can now be displayed properly.
-@<A production@>=
-@G
-@t}\vb{\formatlocal{\skipheader} FAKE:}{@>
- more stuff in this line {@> b = g( y ); @=}
-@g
-
-@ With enough hidden context, even a small rule fragment can be
-typeset as intended. The `action star' was inserted to reveal some of
-the context.
-@<Rest of line@>=
-@G
-@t}\vb{\formatlocal{\skipheader} FAKE:}{@>
- but not all of it
-@t}\vb{\{\stashed{$\star$}\}}{@>
-@g
-@ What makes all of this even more confusing is that \CTANGLE\ will
-have no trouble outputting this as a(n almost, due to the
-intentionally bad \.{whoops} production above) valid \bison\ file
-(as can be checked by looking into \.{sill.y}). The author
-happens to think that one should not fragment the software into pieces
-that are too small: \bison\ is not \Cee\ so it makes sense to write
-\bison\ code differently. However, if the logic behind your code
-organization demands such fine fragmentation, hidden context provides
-you with a tool to show it off. A look inside the source of this
-document shows that adding hidden context can be a bit ugly so it is
-not recommended for routine use. The short example above is output in
-the file below.
-@(sill.y@>=
- @<A silly example@>@;
-
-@*1 On debugging. This concludes a short introduction to the \bison\
-grammar pretty printing using this macro collection. It would be
-incomplete, however, without a short reference to debugging\footnote{Here
-we are talking about debugging the output produced by \CWEAVE\ when
-the included \bison\ parser is used, {\it not\/} debugging parsers
-written with the help of this software: the latter topic is covered in more
-detail later on}. There is a
-fair amount of debugging information that the macros can output,
-unfortunately, very little of it is tailored to the {\it use\/} of the
-macros in the \bison\ parser. Most of it is designed to help {\it
-build\/} a new parser. If you find that the parser gives up too often
-or even crashes (the latter is most certainly a bug in the parser
-itself), the first approach is to make sure that your code {\it
-compiles\/} i.e.\ forget about the printed output and try to see if
-the `real' \bison\ accepts the code (just the syntax, no need to
-worry about conflicts and such).
-
-If this does not shed any light on why the macros seem to fail, turn
-on the debugging output by saying \.{\\trace$\ldots$true} for various
-trace macros. This can produce {\it a lot\/} of output, even for
-small fragments, so turn it on only for a section at a time. If you
-need still {\it more\/} details of the inner workings of the parser
-and the lexer, various other debugging conditionals are available. For
-example, \.{\\yyflexdebugtrue} turns on the debugging output for the
-scanner. There are a number of such conditionals that are discussed in
-the commentary for the appropriate \TeX\ macros.
-
-Remember, what you are seeing at this point is the parsing process of
-the \bison\ input file, not the one for {\it your\/} grammar (which
-might not even be complete at this point). However, if this fails, you
-are on your own: drop me a line if you figure out how to fix any bugs
-you find.
-
-@*1 Terminology. We now list a few definitions of the concepts used
-repeatedly in this documentation. Most of this terminology is
-rather standard. Formal precision is not the goal here, and intuitive
-explanations are substituted whenever possible.
-{%
-\def\aterm#1{\item{\sqebullet}{\ttl #1}: \ignorespaces}%
-\setbox0=\hbox{\sqebullet\enspace}
-\parindent=0pt
-\advance\parindent by \wd0
-\smallskip
-\aterm{bison parser} while, strictly speaking, not a formally defined
-term, this combination will always stand for one of the parsers generated
-by this package designed to parse a subset of the `official' grammar for
-\bison\ input files. All of these parsers are described later in
-this documentation. The term {\it main parser\/} will be
-used as a substitute in example documentation for the same purpose.
-
-\aterm{driver} a generic but poorly defined concept. In this
-documentation it is used predominantly to mean both the \Cee\ code and
-the resulting executable that outputs the \TeX\ macros that contain the
-parser tables, token values, etc., for the parsers built by the user. It
-is understood that the \Cee\ code of the `driver' is unchanged and the
-information about the parser itself is obtained by {\it including\/} the \Cee\
-file produced by \bison\ in the `driver' (see the examples supplied
-with the package).
-
-\aterm{lexer} a synonym for {\it scanner}, a subroutine that performs the {\it
-lexical analysis\/} phase of the parsing process, i.e.\ groups various
-characters from the input stream into parser {\it tokens}.
-
-\aterm{namespace} this is an overused bit of terminology meaning a
-set of names grouped together according to some relatively
-well defined principle. In a language without a well developed type
-system (such as \TeX) it is usually accompanied by a specially designed
-naming scheme. {\it Parser namespaces\/} are commonly used in this
-documentation to mean a collection of all the data structures describing a
-parser and its state, including tables, stacks, etc., named by using the
-`root' name (say \.{\\yytable}) and adding the name of the parser (for
-example, \.{[main]}). To support this naming scheme, a number of
-macros work in unison to create and rename the `data macros' accordingly.
-
-\aterm{symbolic switch} a macro (or an associative array of macros)
-that let the \TeX\ parser generated by the package associate {\it
-symbolic term names\/} with the terms. Unlike the `real' parser, the
-parser created with this suite requires some extra setup as explained
-in the included examples (one can also consult the source for this
-documentation which creates but does not use a symbolic switch).
-
-\aterm{symbolic term name} a (relatively new) way to refer to stack
-values in \bison. In addition to using the `positional' names such as
-\.{\$}$n$ to refer to term values, one can utilize the new syntax:
-\.{\$}\.{[}{\it name\/}\.{]}. The `{\it name}' can be assigned by the
-user or can be the name of the nonterminal or token used in the
-productions.
-
-\aterm{term} in a narrow sense, an `element' of a grammar. Instead of
-a long winded definition, an example, such as \prodstyle{ID} should
-suffice. Terms are further classified into {\it terminals\/} (tokens)
-and {\it nonterminals\/} (which can be intuitively thought of as
-composite terms).
-
-\aterm{token} in short, an element of a set. Usually encoded as an
-integer by most parsers, an indivisible {\it term\/}
-produced for the parser by the scanner. \TeX's scanner uses a more
-sophisticated token classification, for example, $($character code,
-character category$)$ pairs, etc.
-
-}
-@** Languages, scanners, parsers, and \TeX. % Or $\ldots$
-$$\vbox{\halign to\hsize{\kern-1.5pt\it#\hfil\tabskip0pt plus1fil\cr
-Tokens and tables keep macros in check.\cr
-Make 'em with \bison, use \.{WEAVE} as a tool.\cr
-Add \TeX\ and \CTANGLE, and \Cee\ to the pool.\cr
-Reduce 'em with actions, look forward, not back.\cr
-Macros, productions, recursion and stack!\cr
-\noalign{\vskip2pt}
-\omit\hfil\eightpoint Computer generated (most likely)\cr}}
-$$
-\def\recount#1{${}^{(#1)}$}%
-In order to understand the parsing routines in this collection,
-it would help to gain some familiarity with the internals of the
-parsers produced by \bison\ for its intended target: \Cee. A person
-looking inside a parser delivered by \bison\ would
-quickly discover that the parsing procedure itself (|yyparse|)
-occupies a rather small portion of the file. If (s)he were to further
-reduce the size of the file by removing all the preprocessor
-directives intended to anticipate every conceivable combination of the
-operating system, compiler, and \Cee\ dialect, and various reporting
-and error logging functions it would become very clear that the most
-valuable product of \bison's labor is a collection of integer {\it
-tables\/} that control the actions of the parser routine. Moreover,
-the routine itself is an extremely concise and well-structured loop
-composed of |goto|'s and a number of numerical conditionals. If one
-were to think of a way of accessing arrays and processing conditionals
-in the language of one's choice, once the tables produced by \bison\
-have been converted into a form suitable for the consumption by the
-appropriate language engine, the parser implementation becomes
-straightforward. Or nearly so.
-
-The {\it scanning\/} (or {\it lexing\/}) step of this process---a way
-to convert a stream of symbols into a stream of integers, also
-deserves some attention here. There are a number of excellent tools
-written to automate this step in much the same fashion as \bison\
-automates the generation of parsers. One such tool, \flex, though
-(in the opinion of this author) slightly lacking in the simplicity and
-elegance as compared to \bison, was used to implement the lexer for
-this software suite. Lexing in \TeX\ will be discussed in considerable
-detail later in this manual.
-
-The language of interest in our case is, of course, \TeX, so our
-future discussion will revolve around the five elements mentioned
-above: \recount{1}data structures (mainly arrays and stacks),
-\recount{2}converting
-\bison's output into a form suitable for \TeX's consumption,
-\recount{3}processing raw streams of \TeX's tokens and converting them into
-streams of parser tokens, \recount{4}the implementation of \bison's
-|yyparse| in \TeX, and, finally, \recount{5}producing \TeX\ output via {\it
-syntax-directed translation} (which requires an appropriate
-abstraction to represent \bison's actions inside \TeX). We shall
-begin by discussing the parsing process itself.
-
-@*1 Arrays, stacks and the parser.
-Let us briefly examine the programming environment offered by \TeX.
-Designed for typesetting, \TeX's remarkable language
-provides a layer of macro processing atop of a set of commands that
-produce the output fulfilling its primary mission: delivering page
-layouts. In The \TeX book, macro {\it expansion\/} is likened to
-mastication, whereas \TeX's main product, the typographic output is the
-result of its `digestion' process. Not everything that goes through
-\TeX's digestive tract ends up leaving a trace on the final page: a
-file full of \.{\\relax}'s will produce no output, even though
-\.{\\relax} is not a macro, and thus would have to be processed by
-\TeX\ at the lowest level.
-
-It is time to describe the details of defining suitable data structures
-in \TeX. At first glance, \TeX\ provides rather standard means of
-organizing and using general memory. At the core of its generic
-programming environment is an array of \.{\\count}$\,n$ {\it
-registers\/}, which may be viewed as general purpose integer variables
-that are randomly accessible by their indices. The integer arithmetic
-machinery offered by \TeX\ is spartan but is very adequate for the sort of
-operations a parser would perform: mostly additions and
-comparisons.
-
-Is the \.{\\count} array a good way to store tables in \TeX? Probably
-not. The first factor is the {\it size\/} of this array: only 256
-\.{\\count} registers exist in a standard \TeX\ (the actual number of
-such registers on a typical machine running \TeX\ is significantly
-higher but this author is a great believer in standards, and to his
-knowledge, none of the standardization efforts in the \TeX\ world has
-resulted in anything even close to the definitive masterpiece that is
-The \TeX book). The issue of size can be mitigated to some extent by
-using a number of other similar arrays used by \TeX\ (\.{\\catcode},
-\.{\\uccode}, \.{\\dimen}, \.{\\sfcode} and others can be used for
-this purpose as long as one takes care to restore the `sane' values
-before control is handed off to \TeX's typesetting mechanisms). If a
-table has to span several such arrays, however, the complexity of
-accessing code would have to increase significantly, and the issue of
-size would still haunt the programmer.
-
-The second factor is the use of several registers by \TeX\ for special
-purposes (in addition, some of these registers can only store a
-limited range of values). Thus, the first 10 \.{\\count} registers are
-used by plain \TeX\ for (well, {\it intended\/} for, anyway) the
-purposes of page accounting: their values would have to be carefully
-saved and restored before and after each parsing call,
-respectively. Other registers (\.{\\catcode} in particular) have even
-more disrupting effects on \TeX's internal mechanisms. While all of
-this can be managed (after all, using \TeX\ as an arithmetic engine
-such as a parser suspends the need for any typographic or other
-specialized functions controlled by these arrays), the added
-complexity of using several memory banks simultaneously and the speed penalty
-caused by the need to store and restore register values make this
-approach much less attractive.
-
-What other means of storing arrays are provided by \TeX? Essentially,
-only three options remain: \.{\\token} registers, macros holding whole
-arrays, and associative arrays accessed through
-\.{\\csname}$\,\ldots\,$\.{\\endcsname}. In the first two cases if care
-is taken to store such arrays in an
-appropriate form one can use \TeX's \.{\\ifcase} primitive to access
-individual elements. The trade-off is the speed of such
-access: it is {\it linear\/} in the size of the array for most
-operations, and worse than that for others, such as removing the last
-item of an array. Using clever ways
-of organizing such arrays, one can improve the linear access time to
-$O(\log n)$ by simply modifying the access macros but at the moment, a
-straightforward \.{\\ifcase} is used after expanding a list macro or
-the contents of a \.{\\token}$\,n$ register in an {\it un\/}optimized
-parser. An {\it optimized\/} parser uses associative arrays.
-
-The array discussion above is just as applicable to {\it stacks\/}
-(indeed, an array is the most common form of stack
-implementation). Since stacks pop up and disappear frequently (what
-else are stacks to do?), list macros are usually used to store
-them. The optimized parser uses a separate \.{\\count} register to
-keep track of the top of the stack in the appropriate associative
-array.
-
-Let us now switch our attention
-to the code that implements the parser and scanner {\it functions\/}.
-If one has spent some time writing \TeX\ macros of any sophistication
-(or any macros, for that matter) (s)he must be familiar with the general
-feeling of frustration and the desire to `just call a function here and move
-on'. Macros produce {\it tokens\/}, however, and tokens must either
-expand to nothing or stay and be contributed to your input, or worse,
-be out of place and produce an error. One way to sustain a stream
-of execution with macros is {\it tail recursion\/} (i.e.~always expanding the
-{\it last token left standing}).
-
-As we have already discussed, \bison's
-|yyparse()| is a well laid out loop organized as a sequence of
-|goto|'s (no reason to become religious about structured programming
-here). This fact, and the following well known trick, make \Cee\ to \TeX\
-translation almost straightforward.
-
-% The macro mess below looks painful but this is the only place such layout is used
-% The approach can be easily generalized and put in limbo.sty but it seems
-% a bit redundant at this point.
-
-\newcount\piccount
-\newdimen\lasthsize
-
-\setbox5=\vtop{
-\demomargin=0pt
-\let\demoastyle\empty
-\begindemo
-^label A: ...
-\nooutput
-^ if**L**Krm(condition)**N
-^ goto C;
-\nooutput
-^label B: ...
-\nooutput
-^ goto A;
-\nooutput
-^label C: ...
-\nooutput
-\enddemo
-}
-\dp5=\z@@
-
-\setbox3=\vtop{
-\demomargin=0pt
-\let\demoastyle\empty
-\begindemo
-^\if**L**Krm(condition)**N
-^ \let\next=\labelC
-^\else
-^ \let\next=\labelAtail
-\enddemo
-}
-\dp3=\z@@
-
-\newdimen\lastdepth
-
-\def\startfitpar{%
- \bgroup
- \lasthsize=\hsize
- \advance\lasthsize-1.5in
- \vsize=\baselineskip
- \topskip=\z@@
- \setbox0\box2 % empty it
- % this sounds good at first but there is no good way to pull the insertions out after the
- % box manipulations that follow;
- % insertions will thus be contributed to whatever page was being worked on when the
- % picture insertions {\it started}; hence, if these happen to start at the very top of the page,
- % any insertion that follows will be contributed to the previous page; we correct this for footnotes
- % below
- % \holdinginserts=1
- \output{%
- \global\setbox2=\vbox{
- \ifvoid2
- \else
- \prevdepth=\dp2
- \unvbox2
- \fi
- \lastdepth=\dp255
- \unvbox255
- % this would be tempting, however, the \eject that follows should disappear
- % in addition, one really should not be playing with page breaking in the middle of
- % such tricky insertions
- % \penalty\outputpenalty
- % \kern-\lastdepth % to make sure \baselineskip is accounted for
- }%
- }\eject
- \output{%
- \setbox0=\vbox{%
- \unvbox255%
- }% \lastbox would almost work ... if not for insertions
- \global\advance\piccount1
- \global\setbox2=\vbox{%
- \prevdepth=\dp2 \unvbox2
- \hbox to\hsize{%
- \ifnum\piccount<15
- \hbox to1.5in{%
- \ifnum\piccount=1
- \ \box5
- \fi
- \hfill}%
- \fi
- \box0 \hfill
- \ifnum\piccount=1
- \box3 \ %
- \fi
- \ifvoid\footins % reinsert footnotes
- \else
- \insert\footins{\unvbox\footins}%
- \fi
- }%
- }%
- }%
- \parshape=15
- 0pt 2.7in
- 0pt 2.7in
- 0pt 2.7in
- 0pt 2.7in
- 0pt 2.7in
- 0pt 2.7in
- 0pt 2.7in
- 0pt \lasthsize
- 0pt \lasthsize
- 0pt \lasthsize
- 0pt \lasthsize
- 0pt \lasthsize
- 0pt \lasthsize
- 0pt \lasthsize
- 0pt \hsize
-}
-
-\def\endfitpar{%
- \par
- \eject
- \egroup
- % see the comment above
- % \holdinginserts=0
- \prevdepth=\dp2
- \unvbox2
-}
-
-\startfitpar
-\noindent Given the code on the left (where |goto|'s
-are the only means of branching but can appear inside conditionals),
-one way to translate it into \TeX\ is to define a set of macros (call
-them \.{\\labelA}, \.{\\labelAtail} and so forth for clarity) that end in
-\.{\\next} (a common name for this purpose). Now, \.{\\labelA} will
-implement the code that comes between \.{label A:} and \.{goto C;},
-whereas \.{\\labelAtail} is responsible for the code after \.{goto C;}
-and before \.{label B:}
-(provided no other |goto|'s intervene which can always be
-arranged). The conditional which precedes \.{goto C;} can now be written in
-\TeX\ as presented on the right, where (condition) is an appropriate
-translation of the corresponding condition
-in the code being translated (usually, one of `$=$' or `$\not=$'). Further
-details can be extracted from the \TeX\ code that implements these
-functions where the corresponding \Cee\ code is presented alongside
-the macros that mimic its functionality%
-\footnote{Running the risk of overloading the reader with details, the author
-would like to note that the actual implementation follows a {\it slightly\/} different
-route in order to avoid any \.{\\let} assignments or changing the
-meaning of \.{\\next}}.
-This concludes an overview of the general approach,
-It is time to consider the way characters get consumed
-on the lower levels of the macro hierarchy and the interaction between the different
-layers of the package.
-\endfitpar
-
-@*1 \TeX\ into tokens.
-Thus far we have covered the ideas
-behind items \recount{1} and \recount{4} on our list. It is time to
-discuss the lowest level of processing done by these macros:
-converting \TeX's tokens into the tokens consumed by the parser,
-i.e.\ part\recount{3} of the plan. Perhaps, it would be most appropriate
-to begin by defining the term {\it token}.
-
-As commonly defined, a token is simply an element of a set. Depending on
-how much structure the said set possesses, a token can be represented by
-an integer or a more complicated data structure. In the discussion
-below, we will be dealing with two kinds of tokens: the tokens
-consumed by the parsers and the \TeX\ tokens seen by the input
-routines. The latter play the role of {\it characters\/} that combine
-to become the former. \bison's internal representation for its tokens
-is non-negative integers so this is what a scanner must
-produce.
-
-\TeX's tokens are a good deal more sophisticated: they can be
-either pairs $(c_{\rm ch}, c_{\rm cat})$, where $c_{\rm ch}$ is the
-character code and $c_{\rm cat}$ is \TeX's category code ($1$ and $2$ for
-group characters, $5$ for end of line, etc.), or {\it control
-sequences\/}, such as \.{\\relax}. Some of these tokens (control
-sequences and {\it active}, i.e.~category~13 characters) can have
-complicated internal structure (expansion). The situation is further
-complicated by \TeX's \.{\\let} facility, which can create
-`character-like' control sequences, and the lack of conditionals
-to distinguish them from the `real' characters. Finally, not all pairs
-can appear as part of the input (say, there is no $(n, 0)$ token for
-any $n$, in the terminology above).
-
-The scanner expects to see {\it characters} in its input, which are
-represented by their {\sc ASCII} codes, i.e.~integers between $0$ and
-$255$ (actually, a more general notion of the Unicode character is
-supported but we will not discuss it further). Before character codes
-appear as the input to the scanner, however, and make its integer
-table-driven mechanism `tick', a lot of work must be done to collect
-and process the stream of \TeX\ tokens produced after \CWEAVE\ is done
-with your input. This work becomes further complicated when the
-typesetting routines that interpret the parser's output must sneak
-outside of the parsed stream of text (which is structured by the
-parser) and insert the original \TeX\ code produced by \CWEAVE\ into
-the page.
-
-\splint\ comes with a customizeable input routine of
-moderate complexity (\.{\\yyinput}) that classifies all \TeX\ tokens
-into seven categories: `normal' spaces (i.e.~category~10 tokens,
-skipped by \TeX's parameter scanning mechanism),
-`explicit' spaces (includes the control sequences \.{\\let} to \.{\ },
-as well as \.{\\\ }), groups ({\it avoid} using \.{\\bgroup} and \.{\\egroup} in
-your input but `real', \.{\{}$\ldots$\.{\}} groups are fine), active
-characters, normal characters (of all character categories that can
-appear in \TeX\ input, including \.{\$}, \.{\^}, \.{\#}, \.{a}--\.{Z},
-etc.), single letter control sequences, and multi-letter control
-sequences. Each of these categories can be processed separately to
-`fine-tune' the input routine to the problem at hand. The input
-routine is not very fast, instead, flexibility was the main
-goal. Therefore, if speed is desirable, a customized input routine
-is a great place to start. As an example, a minimalistic
-\.{\\yyinputtrivial} macro is included.
-
-When \.{\\yyinput} `returns' by calling \.{\\yyreturn} (which is a
-macro you design), your lexing routines have access to three
-registers: \.{\\yycp@@}, that holds the character value of the
-character just consumed by \.{\\yyinput}, \.{\\yybyte}, that most of
-the time holds the token just removed from the input,
-and \.{\\yybytepure}, that (again, with very few
-exceptions) holds a `normalized' version of the read character (i.e.~a
-character of the same character code as \.{\\yycp@@}, and category~11
-(to be even more precise (and to use nested parentheses), `normalized'
-characters have the same category code as the current category code of
-\.{@@})).
-
-Most of the time it is the character code one needs (say, in the case
-of \.{\\\{}, \.{\\\}}, \.{\\\&} and so on) but under some circumstances the
-distinction is important (outside of \.{\\vb\{}$\ldots$\.{\}}, the sequence
-\.{\\1} has nothing to do with the digit `\.{1}'). This mechanism
-makes it easy to examine the consumed token. It also forms
-the foundation of the `hidden context' passing mechanism described later.
-
-The remainder of this section discusses the internals of \.{\\yyinput}
-and some of the design trade-offs one has to make while working on
-processing general \TeX\ token streams. It is typeset in `small print'
-and can be skipped if desired.
-\smallskip
-\begingroup
-\abovedisplayskip=5pt%
-\abovedisplayshortskip=2pt%
-\belowdisplayskip=5pt%
-\belowdisplayshortskip=2pt%
-\fnotesstart=1
-\fnotesspan=2
-\noofcolumns=2
-\icgap=1em%
-\eightpoint
-\linecount=73
-\setmcparams
-\def\.#1{{\chardef\\=`\\\chardef\&=`\&\tt #1}}%
-\dsskip=0pt%
-\begindoublecols
-To examine every token in its path (including spaces that are easy to
-skip), the input routine uses one of the two well-known {\sc \TeX}nologies:
-\.{\\futurelet\\next\\examinenext} or equally effective
-\hbox{\.{\\afterassignment\\next\\let={\tt\char"20}}}.
-Recursively inserting one of these sequences, \.{\\yyinput} can go
-through any list of tokens, as long as it knows where to stop
-(i.e.~return an end of file character). The
-signal to stop is provided by the \.{\\yyeof}
-primitive which should not appear in any `ordinary' text
-presented for parsing, other than for the purpose of providing such a
-stop signal. Even the dependence on \.{\\yyeof} can be eliminated if
-one is willing to invest the time in writing macros that juggle \TeX's
-\.{\\token} registers and only limit oneself to input from such
-registers (which is, aside from an obvious efficiency hit, a strain on
-\TeX's memory, as you have to store multiple (3 in the general case)
-copies of your input to be able to back up when the lexer makes a
-wrong choice). There does not seem to be a way of doing it unless the
-text has been stored in a \.{\\token} register first (or storing the
-whole input as a {\it parameter\/} for the appropriate macro: this
-scheme is remarkably powerful and leads to {\it expandable\/} versions
-of very complicated macros, although the amount of effort required to
-write such macros grows at a frightening rate). All of these are
-non-issues for the text inside \.{\\vb\{}$\ldots$\.{\}} and the care that
-\.{\\yyinput} takes in processing characters inside such lists is an
-overkill. In a more `hostile' environment (such as the one encountered
-by the now obsolete \.{\\Tex} macros), this extra attention to detail pays
-off in the form of a more robust input mechanism.
-
-One subtlety deserves a special mention here, as it can be important
-to the designer of `higher-level' scanning macros. Two types of tokens
-are extremely difficult to deal with whenever \TeX's own lexing
-mechanisms are used: (implicit) spaces and even more so, braces. We
-will only discuss braces here, however, almost everything that follows
-applies equally well to spaces (category 10 tokens to be precise), with
-a few simplifications (or complications, in a couple of places). To
-understand the difficulty, let's consider one of the approaches above:
-$$
-\.{\\futurelet\\next\\examinenext}.
-$$
-The macro \.{\\examinenext}
-usually looks at \.{\\next} and inserts another macro (usually also called
-\.{\\next}) at the very end of its expansion list. This macro usually
-takes one parameter, to consume the next token. This mechanism works
-flawlessly, until the lexer encounters a \.{\{}br\.{,}sp\.{\}}ace. The \.{\\next}
-sequence, seen by \.{\\examinenext} contains a lot of information
-about the brace ahead: it knows its category code (left brace, so $1$), its
-character code (in case there was, say a \.{\\catcode`\\[=1{\tt\char`\ }}
-earlier) but not whether it is a `real' brace (i.e.\ a character
-\.{\{}$_1$) or an implicit one (a \.{\\bgroup}). There is no way to find
-that out until the control sequence `launched' by \.{\\examinenext}
-sees the token as a parameter.
-
-If the next token is a `real' brace, however,
-\.{\\examinenext}'s successor will never see the token itself: the
-braces are stripped by \TeX's scanning mechanism. Even if it finds a
-\.{\\bgroup} as the parameter, there is no guarantee that the actual
-input was not \.{\{\\bgroup\}}. One way to handle this is by using
-\.{\\string} ahead of any consumption of the next token. If prior to
-expanding \.{\\string} care has been taken to set the \.{\\escapechar}
-appropriately (remember, we know the character code in advance), as
-soon as one sees a character with \.{\\escapechar}'s character code,
-(s)he knows that an implicit brace has just been seen. One added
-complication to all this is that a very determined programmer can
-insert an {\it active\/} character (using, say, the \.{\\uccode}
-mechanism) that has the {\it same\/} character code as the {\it
-brace\/} token that it has been \.{\\let} to! Setting this possibility
-aside, the \.{\\string} mechanism (or, its cousin, \.{\\meaning}) is
-not perfect: both produce a sequence of category 12 and 10 tokens. If
-it is indeed a brace character that we just saw, we can consume the next
-token and move on but what if this was a control sequence? After all,
-just as easily as \.{\\string} makes a sequence into characters,
-\.{\\csname}$\,\ldots\,$\.{\\endcsname} pair will make any sequence of
-characters into a control sequence. Huh~$\ldots$
-
-What we need is a backup mechanism: if one has a copy of the
-token sequence ahead, one can use \.{\\string} to see if it is a real
-brace first, and if it is, consume it and move on (the active character
-case can be handled as the implicit case below, with one extra backup
-to count how many tokens have been consumed). At this point one has to {\it
-reinsert\/} the brace in case, at some point, a future `back up'
-requires that the rest of the tokens are removed from the output (to
-avoid `\.{Too many \}'s}' complaints from \TeX). This can be done by using
-the \.{\\iftrue\{\\else\}\\fi} trick but of course, some bookkeeping is
-needed to keep track of how far inside the brace groups we
-are.
-
-If it is an implicit brace, more work is needed: read all the
-characters that \.{\\string} produced (an maybe more), then remember
-the number of characters consumed. Remove the rest of the input using
-the method described above and restart the scanning from the same point
-knowing that the next token can be scanned as a parameter.
-
-Another strategy is to design a general enough macro that counts
-tokens in a token register and simply recount the tokens after every
-brace was consumed.
-
-Either way, it takes a lot of work. If anyone would
-like to pursue the counting strategy, simple counting macros
-are provided in \.{/examples/count/count.sty}.
-The macros in this example
-supply a very general counting mechanism that does not depend on
-\.{\\yyeof} (or {\it any\/} other token) being `special' and can count the
-tokens in any token register, as long as none of those tokens is an
-\.{\\outer} control sequence. In other words, if the macro is used
-immediately after the assignment to the token register, it should
-always produce a correct count.
-
-Needless to say, if such a general mechanism is desired, one has to
-look elsewhere. The added complications of treating spaces (\TeX\
-tends to ignore them most of the time) make this a torturous exercise
-in \TeX's macro wizardry. The included \.{\\yyinput} has two ways of
-dealing with braces: strip them or view the whole group as a
-token. Pick one or write a different \.{\\yyinput}. Spaces, implicit
-or explicit are reported as a specially selected character code and
-consumed with a likeness of
-$$
-\hbox{\.{\\afterassignment\\moveon\\let\\next={\tt\char`\ }}}.
-$$
-
-Now that a steady stream of character codes is arriving at \.{\\yylex}
-after \.{\\yyreturn} the job of converting it into numerical tokens
-is performed by the {\it scanner} (or {\it lexer\/}, or {\it tokenizer\/},
-or even {\it tokener}), discussed in the next section.
-\enddoublecols
-\endgroup
-
-@*1 Lexing in \TeX. In a typical system that uses a parser to process
-text, the parsing pass is usually split into several stages: the raw
-input, the lexical analysis (or simply {\it lexing}), and the parsing
-proper. The {\it lexing\/} (also called {\it scanning}, we use these
-terms interchangeably) clumps various sequences of characters into
-{\it tokens\/} to facilitate the parsing stage. The reasons for this
-particular hierarchy are largely pragmatic and are partially historic
-(there is no reason that {\it parsing\/} cannot be done in multiple
-phases, as well, although it usually isn't).
-
-If one remembers a few basic facts from the formal language theory, it
-becomes obvious that a lexer, that parses {\it regular\/} languages,
-can (theoretically) be replaced by an {\sc LALR} parser, that parses {\it
-context-free\/} ones (or some subset thereof, which is
-still a super set of all regular languages). A common justification given for
-creating specialized lexers is efficiency and speed. The
-reality is somewhat more subtle. While we do care about the efficiency of
-parsing in \TeX, having a specialized scanner is important for
-a number of different reasons.
-
-The real advantage of having a dedicated scanner is the ease with which it
-can match incomplete inputs and back up. A parser can, of course,
-{\it recognize\/} any valid input that is also acceptable to a lexer, as well
-as {\it reject\/} any input that does not form a valid token. Between
-those two extremes, however, lies a whole realm of options that a
-traditional parser will have great difficulty exploring. Thus, to
-mention just one example, it
-is relatively easy to set up a DFA\footnote{Which stands for
-Deterministic Finite Automaton, a common (and mathematically unique)
-way of implementing a scanner for regular languages. Incidentally {\sc
-LALR} mentioned above is short for Look Ahead Left to Right.}
-so that the {\it longest\/}
-matching input is accepted. The only straightforward way to do this
-with a traditional parser is to parse longer and longer inputs again
-and again. While this process can be optimized to a certain degree,
-the fact that a parser has a {\it stack\/} to maintain limits its
-ability to back up.
-
-As an aside, the mechanism by which \CWEB\ assembles its `scraps'
-into chunks of recognized code is essentially iterative lexing,
-very similar to what a human does to make sense of complicated
-texts. Instead of trying to match the longest running piece of text,
-\CWEB\ simply looks for patterns to combine inputs into larger
-chunks, which can later be further combined. Note that this is not
-quite the same as the approach taken by, say {\sc GLR} parsers, where
-the parser must match the {\it whole\/} input or declare a
-failure. Where a \CWEB-type parser may settle for the first available
-match (or the longest available) a {\sc GLR} parser must try {\it
-all\/} possible matches or use an algorithm to reject the majority of
-the ones that are bound to fail in the end.
-
-This `\CWEB\ way' is also different from a traditional `strict' {\sc
-LR} parser/scanner approach and certainly deserves serious
-consideration when the text to be parsed possesses some rigid
-structure but the parser is only allowed to process it one small
-fragment at a time.
-
-Returning to the present macro suite, the lexer produced by \flex\
-uses integer tables similar to those employed by \bison\ so the
-usual {\sc\TeX}niques used in implementing \.{\\yyparse} are fully
-applicable to \.{\\yylex}.
-
-An additional advantage provided by having a \flex\ scanner implemented
-as part of the suite is the availability of the original \bison\ scanner written
-in \Cee\ for the use by the macro package.
-
-This said, the code generated by \flex\ contains a few idiosyncrasies
-not present in the \bison\ output. These `quirks' mostly involve
-handling of end of input and error conditions. A quick glance at the
-\.{\\yylex} implementation will reveal a rather extensive collection of
-macros designed to deal with end of input actions.
-
-Another difficulty one has to face in translating \flex\ output into
-\TeX\ is a somewhat unstructured namespace delivered in the final
-output (this is partially due to the \POSIX\ standard that \flex\
-strives to follow). One consequence of this `messy' approach is that the
-writer of a \flex\ scanner targeted to \TeX\ has to declare \flex\
-`states' (more properly called {\it subautomata}) twice: first for the
-benefit of \flex\ itself, and then again, in the {\it \Cee\ preamble\/}
-portion of the code to output the states to be used by the action code
-in the lexer. \.{Define\_State($\ldots$)} macro is provided for this
-purpose. This macro can be used explicitly by the programmer or be
-inserted by a specially designed parser.
-Using \CWEB\ helps to keep these declarations together.
-
-The `hand-off' from the scanner to the parser is implemented
-through a pair of registers: \.{\\yylval}, a token register
-containing the value of the returned token and \.{\\yychar}, a
-\.{\\count} register that contains the numerical value of the
-token to be returned.
-
-Upon matching a token, the scanner passes one crucial piece of
-information to the user: the character sequence representing the token
-just matched (\.{\\yytext}). This is not the whole story
-though. There are three more token sequences that are made available
-to the parser writer whenever a token is matched.
-
-The first of these is simply a `normalized' version of
-\.{\\yytext} (called \.{\\yytextpure}). In most cases it
-is a sequence of \TeX\ tokens with the same character codes as the one
-in \.{\\yytext} but with their category codes set to 11. In
-cases when the tokens in \.{\\yytext} are {\it not}
-$(c_{\rm ch}, c_{\rm cat})$ pairs, a few simple
-conventions are followed, some of which will be explained below. This
-sequence is provided merely for convenience and its typical use is to
-generate a key for an associate array.
-
-The other two sequences are special `stream pointers' that provide
-access to the extended scanner mechanism in order to implement passing
-of `formatting hints' to the parser without introducing any changes to
-the original grammar. As the mechanism itself and the motivation
-behind it are somewhat subtle, let me spend a few moments discussing
-the range of formatting options desirable in a generic pretty-printer.
-
-Unlike strict parsers employed by most compilers, a parser designed
-for pretty printing cannot afford being too picky about the structure
-of its input (\cite[Go] calls such parsers `loose'). To provide
-a simple illustration, an isolated identifier, such as `\.{lg\_integer}'
-can be a type name, a variable name, or a structure tag (in a language like
-\Cee\ for example). If one expects the pretty printer to typeset this
-identifier in a correct style, some context must be supplied, as
-well. There are several strategies a pretty printer can employ to get
-a hold of the necessary context. Perhaps the simplest way to handle
-this, and to reduce the complexity of the pretty printing algorithm is
-to insist on the user providing enough context for the parser to do
-its job. For short examples like the one above, this is an acceptable
-strategy. Unfortunately, it is easy to come up with longer snippets of
-grammatically deficient text that a pretty printer should be expected
-to handle. Some pretty printers, such as the one employed by \CWEB\
-and its ilk (the original \.{WEB}, \.{FWEB}), use a very flexible
-bottom-up technique that tries to make sense of as large a portion of
-the text as it can before outputting the result (see also \cite[Wo],
-which implements a similar algorithm in \LaTeX).
-
-The expectation is that this algorithm will handle the majority (about
-90\%? it would be interesting to carry out a study in the spirit of
-the ones discussed in \cite[Jo] to find out) of the
-cases with the remaining few left for the author to correct. The
-question is, how can such a correction be applied?
-
-\CWEB\ itself provides two rather different mechanisms for handling
-these exceptions. The first uses direct typesetting commands (for
-example, \.{@@/} and \.{@@\#} for canceling and
-introducing a line break, resp.) to change the typographic output.
-
-The second (preferred) way is to supply {\it hidden context\/} to the
-pretty-printer. Two commands, \.{@@;} and
-\.{@@[}$\ldots$\.{@@]} are used for this purpose. The
-former introduces a `virtual semicolon' that acts in every way like a
-real one except it is not typeset (it is not output in the source file
-generated by \CTANGLE, either but this has nothing to do with pretty
-printing, so I will not mention \CTANGLE\ anymore). For
-instance, from the parser's point of view, if the preceding text was
-parsed as a `scrap' of type {\it exp}, the addition of \.{@@;}
-will make it into a `scrap' of type {\it stmt\/} in \CWEB's
-parlance. The second construct (\.{@@[}$\ldots$\.{@@]}),
-is used to create an {\it exp\/} scrap out of whatever happens to be
-inside the brackets.
-
-This is a powerful tool at the author's disposal. Stylistically,
-this is the right way to handle exceptions as it forces the writer to
-emphasize the {\it logical\/} structure of the formal
-text. If the pretty printing style is changed
-extensively later, the texts with such hidden contexts should be able to
-survive intact in the final document (as an example, using a break
-after every statement in \Cee\ may no longer be considered
-appropriate, so any forced break introduced to support this convention
-would now have to be removed, whereas \.{@@;}'s would simply
-quietly disappear into the background).
-
-The same hidden context idea has another important advantage: with
-careful grammar fragmenting (facilitated by \CWEB's or any other
-literate programming tool's `hypertext' structure) and a more diverse
-hidden context (or even arbitrary hidden text) mechanism, it is
-possible to use a strict parser to parse incomplete language
-fragments. For example, the productions that are needed to parse
-\Cee's expressions form a complete subset of the grammar. If the
-grammar's `start' symbol is changed to {\it expression\/} (instead of
-the {\it translation-unit\/} as it is in the full \Cee\ grammar), a
-variety of incomplete \Cee\ fragments can now be parsed and
-pretty-printed. Whenever such granularity is still too `coarse',
-carefully supplied hidden context will give the pretty printer enough
-information to adequately process each fragment. A number of such {\it
-sub}-parsers can be tried on each fragment (this may sound
-computationally expensive, however, in practice, a carefully chosen
-hierarchy of parsers will finish the job rather quickly) until a
-correct parser produced the desired output (this approach is similar
-to, although not quite the same one employed by the {\it General LR
-parsers}).
-
-This somewhat lengthy discussion brings us to the question directly
-related to the tools described in this article: how does one provide
-typographical hints or hidden context to the parser?
-
-One obvious solution is to build such hints directly into the
-grammar. The parser designer can, for instance, add new tokens
-(say, \.{BREAK\_LINE}) to the grammar and extend the
-production set to incorporate the new additions. The risk of
-introducing new conflicts into the grammar is low (although not
-entirely non-existent, due to the lookahead limitations of LR(1)
-grammars) and the changes required are easy, although very tedious, to
-incorporate.
-
-In addition to being labor intensive, this solution has two other
-significant shortcomings: it alters the original grammar and hides its
-logical structure; it also `bakes in' the pretty-printing conventions
-into the language structure (making `hidden' context much less
-`stealthy'). It does avoid the `synchronicity problem' mentioned
-below.
-
-A marginally better technique is to introduce a new regular expression
-recognizable by the scanner which will then do all the necessary
-bookkeeping upon matching the sequence. All the difficulties with
-altering the grammar mentioned above apply in this case, as well, only
-at the `lexical analysis level'. At a minimum, the set of tokens
-matched by the scanner would have to be changed.
-
-A much better approach involves inserting the hints at the input stage and
-passing this information to the scanner and parser as part of the token `values'. The
-hints themselves can masquerade as characters ignored by the scanner
-(white space, for example) and preprocessed by a specially designed
-input routine. The scanner then simply passes on the values to the
-parser. This makes hints, in effect, invisible.
-
-The difficulty lies in synchronizing the token production with the
-parser. This subtle complication is very familiar to anyone who has
-designed \TeX's output routines: the parser and the lexer are not
-synchronous, in the sense that the scanner might be reading several
-(in the case of the general LR$(n)$ parsers) tokens ahead of the
-parser before deciding on how to proceed (the same way \TeX\ can
-consume a whole paragraph's worth of text before exercising its page
-builder).
-
-If we simple-mindedly let the scanner return every hint it has encountered
-so far, we may end up feeding the parser the hints meant for the token
-that appears {\it after\/} the fragment the parser is currently working
-on. In other words, when the scanner `backs up' it must correctly back
-up the hints as well.
-
-This is exactly what the scanner produced by the tools in this package
-does: along with the main stream of tokens meant for the parser, it
-produces two hidden streams (called the \.{\\format} stream and
-the \.{\\stash} stream) and provides the parser with two
-strings (currently only strings of digits are used although arbitrary
-sequences of \TeX\ tokens can be used as pointers) with the promise
-that {\it all the `hints' between the beginning of the corresponding
-stream and the point labeled by the current stream pointer appeared
-among the characters up to and, possibly, including the ones matched
-as the current token}. The macros to extract the relevant parts of the
-streams (\.{\\yyreadfifo} and its cousins) are provided for the
-convenience of the parser designer. The interested reader can consult
-the input routine macros for the details of the internal
-representation of the streams.
-
-In the interest of full disclosure, let me point out that this simple
-technique introduces a significant strain on \TeX's
-computational resources: the lowest level macros, the ones that handle
-character input and are thus executed (sometimes multiple times), for
-{\it every\/} character in the input stream are rather complicated and
-therefore, slow. Whenever the use of such streams is not desired a simpler
-input routine can be written to speed up the process (see
-\.{\\yyinputtrivial} for a working example of such macro).
-
-Finally, while probably not directly related to the present
-discussion, this approach has one more interesting feature: after the
-parser is finished, the parser output and the streams exist
-`statically', fully available for any last minute preprocessing or for
-debugging purposes, if necessary. Under most circumstances, the parser
-output is `executed' and the macros in the output are the ones reading
-the various streams using the pointers supplied at the parsing stage
-(at least, this is the case for all the parsers supplied with the
-package).
-
-@*1 Inside semantic actions: switch statements and `functions' in \TeX.
-Now you have a lexer for your input, and a grammar ready to be put into
-action (we will talk about actions a bit later). It is time to discuss
-how the tables produced by \bison\ get converted into \TeX\ {\it macros\/}
-that drive the parser in {\it \TeX}.
-
-The tables that drive the \bison\ input parsers
-are collected in various \.{\{b,d,f,g,n\}yytab.tex} and \.{small\_tab.tex}. Each
-one of these files contains the tables that implement a specific parser
-used during different stages of processing.
-Their exact function is well explained
-in the source file produced by \bison\ ({\it how} this is done is
-explained elsewhere, see \cite[Ah] for a good reference). It would
-suffice to mention here that there are three types of tables in this
-file: \recount{1}numerical tables such as \.{\\yytable} and
-\.{\\yycheck} (both are either \TeX's token registers in an
-unoptimized parser or associate arrays in an optimized version of such
-as discussed below),
-\recount{2}a string array \.{\\yytname}, and \recount{3}an action
-switch. The action switch is what gets called when the parser does a
-{\it reduction}. It is easy to notice that the numerical tables come
-`premade' whereas the string array consisting of token names
-is difficult to recognize. This is intentional: this form of initialization
-is designed to allow the widest range of
-characters to appear inside names. The macros that do this reside in
-\.{yymisc.sty}. The generated table files also contain
-constant and token declarations used by the parser.
-
-The description of the process used to output \bison\ tables in an
-appropriate form continues in the section about
-\locallink{bsfile}outputting \TeX\ tables\endlink, we pick it up here
-with the description of the syntax-directed translation and the
-actions. The line
-$$
-\.{\\switchon\\next\\in\\currentswitch}
-$$
-is responsible for calling an appropriate action in the current
-switch, as is easy to infer. A {\it switch\/} is also a macro that
-consists of strings of \TeX\ tokens intermixed with \TeX\ macros
-inside braces. Each group of macros
-gets executed whenever the character or the group of characters in
-\.{\\next} matches a substring preceding the braced group. If there
-are two different substrings
-that match, only the earliest group of macros gets expanded.
-Before a state is
-used, a special control sequence,
-\.{\\setspecialcharsfrom\\switchname} can be used to put the \TeX\
-tokens in a form suitable for the consumption by \.{\\switchon}'s. The
-most important step it performs is it {\it turns every token in the
-list into a character with the same character code and category
-12\/}. Thus \.{\\\{} becomes \.{\{}$_{12}$. There are other ways of
-inserting tokens into a state: enclosing a token or a string of tokens in
-\.{\\raw...\\raw} adds it to the state macro unchanged. If you have
-a sequence of category 12 characters you want to add to the state, put
-it after \.{\\classexpand} (such sequences are usually prepared by the
-\.{\\setspecialchars} macro that uses the token tables generated by
-\bison\ from your grammar).
-
-You can give a case a readable label (say, \.{brackets}) and enclose
-this label in \.{\\raw}$\ldots$\.{\\raw}. A word of caution: an `a'
-inside of \.{\\raw}$\ldots$\.{\\raw} (which is most likely an
-\.{a}$_{11}$ unless you played with category codes before loading the
-\.{\\switchon} macros) and the one outside it are two different
-characters, as one is no longer a letter (category 11) in the eyes of
-\TeX\ whereas the other one still is. For this reason one should not
-use characters other than letters in h\.{\{}is\.{,}er\.{\}} state
-names: the way a state picks an action does not distinguish between,
-say, a `\.{(}' in `\.{(letter)}' and a stand alone `\.{(}' and may
-pick an action that you did not intend. This applies even if `\.{(}'
-is not among the characters explicitly inserted in the state macro: if
-an action for a given character is not found in the state macro, the
-\.{\\switchon} macro will insert a current \.{\\default} action
-instead, which most often you would want to be \.{\\yylex} or
-\.{\\yyinput} (i.e.\ skip this token). If `\.{(}' or `\.{)}' matches
-the braced group that follows `\.{(letter)}' chaos may ensue (most
-likely \TeX\ will keep reading past the \.{\\end} or \.{\\yyeof} that
-should have terminated the input). Make the names of character
-categories as unique as possible: the \.{\\switchon} is simply a
-string matching mechanism, with the added distinction between
-characters of different categories.
-
-Finally, the construct \.{\\statecomment}{\it
-anything\/}\.{\\statecoment} allows you to insert comments in the
-state sequence (note that the state {\it name\/} is put at the
-beginning of the state macro (by \.{\\setspecialcharsfrom})
-in the form of a special control sequence
-that expands to nothing: this elaborate scheme is needed because
-another control sequence can be \.{\\let} to the state macro which
-makes the debugging information difficult to decipher). The debugging
-mode for the lexer implemented with these macros is activated by
-\.{\\tracedfatrue}.
-
-The functionality of the \.{\\switchon} macros (for `historical'
-reasons, one can also use \.{\\action} as a synonym) has been
-implemented in a number of other macro packages (see \cite[Fi] that
-discusses the well-known and widely used \.{\\CASE} and \.{\\FIND}
-macros). The macros in this collection have the additional property
-that the only assignments that persist after the \.{\\switchon}
-completes are the ones performed by the user code inside the selected
-case.
-
-This last property of the switch macros is implemented using another
-mechanism that is part of this macro suite: the `subroutine-like'
-macros, \.{\\begingroup}$\ldots$\.{\\tokreturn}. For examples, an
-interested reader can take a look at the macros included with the
-package. A typical use is
-\.{\\begingroup}$\ldots$\.{\\tokreturn\{\}\{\\toks0 \}\{\}} which will
-preserve all the changes to \.{\\toks0} and have no other side effects
-(if, for example, in typical \TeX\ vernacular, \.{\\next} is used
-to implement tail recursion inside the group, after the
-\.{\\tokreturn}, \.{\\next} will still have the same value it
-had before the group was entered). This functionality comes at the
-expense of some computational efficiency.
-
-This covers most of the routine computations inside semantic actions,
-all that is left is a way to `tap' into the stack automaton
-built by \bison\ using an interface similar to the special
-\.{\$$n$} variables utilized by the `genuine' \bison\ parsers
-(i.e.\ written in \Cee\ or any other target language supported by
-\bison).
-
-This role is played by the several varieties of \.{\\yy$\,p$} command
-sequences (for the sake of completeness, $p$ stands for one of \.{($n$)},
-\.{[{\rm name}]}, \.{]{\rm name}[} or $n$, here $n$ is a
-string of digits, and a `name' is any name acceptable as a symbolic
-name for a term in \bison). Instead
-of going into the minutia of various flavors of \.{\\yy}-macros, let me
-just mention that one can get by with only two `idioms' and still
-be able to write parsers of arbitrary sophistication:
-\.{\\yy($n$)} can be treated as a token register containing the
-value of the $n$-th term of the rule's right hand side, $n>0$. The left
-hand side of a production is accessed through \.{\\yyval}. A
-convenient shortcut is \.{\\yy0\{{\rm \TeX\space material}\}} which
-will expand the `\TeX\ material' inside the braces. Thus, a simple way
-to concatenate the values of the first two production terms is
-\.{\\yy0\{\\the\\yy(1)\\the\\yy(2)\}}. The included \bison\
-parser can also be used to provide support for `symbolic names',
-analogous to \bison's \.{{\$}[{\rm name}]} but a
-bit more effort is required on the user's part to initialize such support.
-Using symbolic names can make the parser more readable and maintainable,
-however.
-
-There is also a \.{\\bb$\,n$} macro, that provides access to the term
-values in the `natural order' (e.g.~\.{\\bb1} is the last term read). Its
-intended use is with the `inline' rules (see the main parser for
-such examples). As of version \.{3.0} \bison\ no longer outputs
-|yyrhs| and |yyprhs|, which makes it impossible to produce the
-|yyrthree| array necessary for processing such rules in the `left to right'
-order. One might also note that the new notation is better suited for
-the inline rules since the value that is pushed on the stack is that
-of \.{\\bb0}, i.e.~the term implicitly inserted by \bison. Be aware
-that there are no \.{\\bb[$\cdot$]} or \.{\\bb($\cdot$)} versions of
-these macros, for obvious reasons. A less obvious feature of this
-macro is its `nonexpandable' nature. This means they cannot be used
-inside \.{\\edef}. Thus, the most common use pattern is
-\.{\\bb$\,n$\{\\toks$\,m$\}} with a subsequent expansion of
-\.{\\toks$\,m$}. Making these macros expandable is certainly possible
-but does not seem crucial for the intended limited use pattern.
-
-Naturally, a parser writer may need a number of other data
-abstractions to complete the task. Since these are highly dependent on
-the nature of the processing the parser is supposed to provide, we
-refer the interested reader to the parsers included in the package as
-a source of examples of such specialized data structures.
-
-One last remark about the parser operation is worth making here:
-the parser automaton itself does not make any \.{\\global}
-assignments. This (along with some careful semantic action writing)
-can be used to `localize' the effects of the parser operation and,
-most importantly, to create `reentrant' parsers that can, e.g.\ call
-{\it themselves\/} recursively.
-
-@*1 `Optimization'.
-By default, the generated parser and scanner keep all of their tables
-in separate token registers. Each stack is kept in a single macro (this
-description is further complicated by the support for parser {\it
-namespaces\/} that exists even for unoptimized parsers but this
-subtlety will not be mentioned again---see the macros in the package
-for further details). Thus, every time a table
-is accessed, it has to be expanded making the table access latency
-linear in {\it the size of the table}. The same holds for stacks and
-the action `switches', of
-course. While keeping the parser tables (which are immutable) in token
-registers does not have any better rationale than saving the control
-sequence memory (the most abundant memory in \TeX), this way of
-storing {\it stacks} does have an advantage when multiple parsers get
-to play simultaneously. All one has to do to switch from one parser to
-another is to save the state by renaming the stack control sequences
-accordingly.
-
-When the parser and scanner are `optimized', all these control
-sequenced are `spread over' appropriate associative arrays. One caveat
-to be aware of: the action switches for both the parser and the scanner
-have to be output differently (a command line option is used to
-control this) for optimized and unoptimized parsers. While it is
-certainly possible to optimize only some of the parsers (if your
-document uses multiple) or even only some {\it parts\/} of a given
-parser (or scanner), the details of how to do this are rather
-technical and are left for the reader to discover by reading the
-examples supplied with the package. At least at the beginning it is
-easier to simply set the highest optimization level and use it
-consistently throughout the document.
-
-@*1 {\it \TeX\/} with a different {\sl slant} or do you C an escape?.
-%\def\texnspace{other}
-Some \TeX\ productions below probably look like alien script.
-The authors of \cite[Er] cite a number of reasons pretty printing of
-\TeX\ in general is a nearly impossible task. The macros included with
-the package follow a very straightforward strategy and do not try to
-be very comprehensive. Instead, the burden of presenting \TeX\ code in
-a readable form is placed on the programmer. Appropriate hints can be
-supplied by means of indenting the code, using assignments ($=$) where
-appropriate, etc. If you would rather look at straight \TeX\
-instead, the line \.{\\def\\texnspace\{other\}} at the beginning of
-this section can be uncommented and
-|TeX_( "/noexpand/inmath{/yy0{/yy1{}}}" );| becomes
-\def\texnspace{other}%
-|TeX_( "/noexpand/inmath{/yy0{/yy1{}}}" );|.
-\def\texnspace{texline}%
-There is, however, more to this story. A look at the actual file will
-reveal that the line above was typed as
-$$
-\.{TeX\_( "/noexpand/inmath\{/yy0\{/yy1\{\}\}\}" );}
-$$
-The `escape character' is leaning the other way!
-The lore of \TeX\ is uncompromising: `\.{\\}' is {\it the\/} escape
-character. What is the reason to avoid it in this case?
-
-The mystery is not very deep: `\.{/}' was chosen as an escape character
-by the parser macros (a quick glance at \.{?yytab.tex} will reveal as
-much). There is, of course, nothing sacred (other than tradition,
-which this author is trying his hardest to follow) about what character code
-the escape character has. The reason to look for the alternative is straightforward: `\.{\\}' is
-a special character in \Cee, as well (also an `escape' in fact). The line
-\.{TeX\_( "..." );} is a {\it macro-call\/} but $\ldots$ in \Cee. This
-function simply prints out (almost `as-is') the line in
-parenthesis. An attempt at \.{TeX\_( "\\noexpand" );} would result in
-\numberlinestrue
-\begindemo
-^
-^oexpand
-\enddemo
-\numberlinesfalse
-Other escape combinations\footnote{Here is a full list of {\it
-defined\/} escaped characters in \Cee: \.{\\a}, \.{\\b}, \.{\\f}, \.{\\n},
-\.{\\r}, \.{\\t}, \.{\\v}, \.{\\}{$[$\it octal digit$]$}, \.{\\'},
-\.{\\"}, \.{\\?}, \.{\\\\}, \.{\\x}, \.{\\u}, \.{\\U}. Note that the
-last three combinations must be followed by a specific string of
-characters to appear in the input without generating errors.} are
-even worse: most are simply undefined. If anyone feels trapped without
-an escape, however, the same line can be typed as
-$$
-\.{TeX\_( "\\\\noexpand\\\\inmath\{\\\\yy0\{\\\\yy1\{\}\}\}" );}
-$$
-Twice the escape!
-
-If one were to look closer at the code, another oddity stands
-out: there are no \.{\$}'s anywhere in sight.
-The big money, \.{\$} is a beloved character in
-\bison. It is used in action code to reference the values of the
-appropriate terms in a production. If mathematics pays your bills, use
-\.{\\inmath} instead.
-
-@*1 The \bison\ parser(s). Let's take a short break for a broad overview of the input file.
+\ifbootstrapmode % this is a bootstrap run to extract the states
+ \message{bootstrapping \jobname.tex ...}%
+ \input limbo.sty
+ \def\optimization{5}
+ \input yy.sty
+ \modebootstrap
+\fi
+
+@**The \eatone{bison}\bison\ parser stack.
+The input language for \bison\ loosely follows the {\sc BNF} notation, with
+a few enhancements, such as the syntax for {\em actions}, to implement
+the syntax-directed translation@^syntax-directed translation@>, as
+well as various declarations for tokens, nonterminals, etc.
+
+On the one hand, the language is relatively easy to handle, is
+nearly whitespace agnostic, on the other, a primitive parser is
+required for some basic setup even at a very early stage, so the
+design must be carefully thought out. This {\em
+bootstrapping\/}@^bootstrapping@> step is discussed in more details
+later on.
+
+The path chosen here is by no means optimal. What it lacks in
+efficiency, though, it may amply gain in practicality, as we reuse the
+original grammar used by \bison\ to produce the parser(s) for both
+pretty printing and bootstrapping. Some minor subtleties arising from
+this approach are explained in later sections.
+
+As was described in the
+\ifbootstrapmode\else\locallink{parser.stacks} discussion of parser
+stacks \endlink\fi@^parser stack@> above, to pretty print a variety
+of grammar fragments, one may employ
+a {\em parser stack\/} derived from the original grammar. The most
+natural and common unit of a \bison\ grammar is a set of
+productions. It is thus natural to begin our discussion of the parsers
+in the \bison\ stack with the parser responsible for processing
+individual rules.
+
+One should note that the productions below are not concerned with the
+typesetting of the grammar. Instead this task is delegated to the
+macros in \.{yyunion.sty} and its companions. The first pass of the
+parser merely constructs an `executable abstract syntax tree' (or
+\EAST\footnote{One may argue that \EAST\ is still merely a syntactic
+construct requiring a proper macro framework for its execution and
+should be called a `weak executable syntax tree' or \WEST. This
+acronym extravagnza is heading south so we shall stop here.}) which
+can serve very diverse purposes: from collecting token declarations in
+the boostrapping pass to typesetting the grammar rules.
+
+It would be impossible to completely avoid the question of the visual
+presentation of the \bison\ input, however. It has already been
+pointed out that the syntax adopted by \bison\ is nearly insensitive
+to whitespace. This makes {\em writing\/} \bison\ grammars easier. On
+the other hand, {\em presenting\/} a grammar is best done using a
+variety of typographic devices that take advantage of the meaningful
+positioning of text on the page: skips, indents, etc. Therefore, the
+macros for \bison\ pretty printing trade a number of \bison\ syntax
+elements (such as \.{\yl}, \.{;}, action braces, etc.) for the careful
+placement of each fragment of the input on the page.
+
+Let's take a short break for a broad overview of the input file.
The basic structure is that of an ordinary \bison\ file that produces
-plain \Cee\ output. The \Cee\ actions, however, are programmed to output \TeX.
-
-@s TeX_ TeX
-@s TeXa TeX
-@s TeXb TeX
-@s TeXf TeX
-@s TeXfo TeX
-@s TeXao TeX
+plain \Cee\ output. The \Cee\ actions, however, are programmed to output \TeX.
+The \bison\ sections (separated by \.{\%\%} (shown (pretty printed)
+as \prodstyle{\%\%} below)) appear between the successive dotted lines.
@(bg.yy@>=
@G Switch to generic mode.
@@ -1457,7 +94,8 @@ plain \Cee\ output. The \Cee\ actions, however, are programmed to output \TeX.
%%
@g
-@ Bootstrap mode is next. The reason for a separate bootstrap parser is to
+@ Bootstrap\namedspot{bootstrapping}@^bootstrapping@> mode is next.
+The reason for a separate bootstrap parser is to
collect the minimal amount of information to `spool up' the `production'
parsers. To understand the mechanics and the reasons behind it, consider what happens
following a declaration such as \.{\%token TOKEN "token"}
@@ -1486,8 +124,8 @@ function of the bootstrap parser. Since the lexer is reused, some
token values need to be known in advance (and the rest either ignored
or replaced by some `made up' values). These tokens are `hard coded'
into the parser file generated by \bison\ and output using a special
-function. The switch `|@[#define@]@; BISON_BOOTSTRAP_MODE|' tells the `driver'
-program to output the hard coded token values.
+function. The switch `|@[#define@]@; BISON_BOOTSTRAP_MODE|' tells the
+`driver' program to output the hard coded token values.
@q Bizarre looking way of typing #define is due to the awkward way@>
@q \CWEB\ treats switching in and out of $-mode in inline \Cee@>
@@ -1504,10 +142,10 @@ for an appropriate subset of the \bison\ syntax is not yet available
would have to use the same scanner (unless you want to write a custom
scanner for it), which would need to know how to output tokens, for
which it would need a parser for a subset of \bison\ syntax $\ldots$
-it is a `chicken and egg'). Hence the name `bootstrap'. Once a
-functional parser for a large enough subset of the \bison\ input
-grammar is operational, {\it it\/} can be used to pair up the token
-names.
+it is a genuine `chicken and egg' problem). Hence the need for
+`bootstrap'. Once a functional parser for a large enough subset of the
+\bison\ input grammar is operational, {\it it\/} can be used to pair
+up the token names.
The second function of the bootstrap parser is to collect information
about the scanner's states. The mechanism is slightly different for
@@ -1519,14 +157,13 @@ the `driver' program in any data structure and are instead defined as
ordinary macros. The header file is the information the `driver' file
needs to output the state values.
-An additional subtlety in the case of state value output is that the
+An additional subtlety in the case of the state value output is that the
main lexer for the \bison\ grammar utilizes states extensively and thus
cannot be easily used with the bootstrap parser before the state
values are known. The solution is to substitute a very simple scanner barely
capable of lexing state declarations. Such a scanner is implemented
in \.{ssffo.w} (the somewhat cryptic name stands for `{\bf s}imple {\bf s}canner
{\bf f}or {\bf f}lex {\bf o}ptions').
-\saveparseoutputtrue
@(bb.yy@>=
@G Switch to generic mode.
%{
@@ -1548,12 +185,6 @@ in \.{ssffo.w} (the somewhat cryptic name stands for `{\bf s}imple {\bf s}canner
@ The prologue parser is responsible for parsing various grammar
declarations as well as parser options.
-\saveparseoutputfalse
-%\traceparserstatestrue
-%\tracestackstrue
-%\tracerulestrue
-%\traceactionstrue
-\saveparseoutputtrue
@(bd.yy@>=
@G Switch to generic mode.
%{@> @<Grammar parser \Cee\ preamble@> @=%}
@@ -1562,21 +193,15 @@ declarations as well as parser options.
%{@> @<Grammar parser \Cee\ postamble@> @=%}
@> @<Tokens and types ...@> @=
%%
- @> @<Fake start symbol for prologue grammar@>@;
+ @> @<Fake start symbol for prologue grammar@> @=
@> @<Parser common productions@> @=
@> @<Parser prologue productions@> @=
%%
@g
-@ Full \bison\ input parser is used when a complete \bison\ file is
+@ The full \bison\ input parser is used when a complete \bison\ file is
expected. It is also capable of parsing a `skeleton' of such a file,
similar to the one that follows this paragraph.
-\traceparserstatesfalse
-\tracestacksfalse
-\tracerulesfalse
-\traceactionsfalse
-\checktablefalse
-\saveparseoutputfalse
@(bf.yy@>=
@G Switch to generic mode.
%{@> @<Grammar parser \Cee\ preamble@> @=%}
@@ -1592,12 +217,27 @@ similar to the one that follows this paragraph.
%%
@g
-@ The first two options are essential for the parser operation. The
+@ \namedspot{bison.options}The first two options below are essential
+for the parser operation
+as each of them makes \bison\ produce additional tables (arrays) used
+in the operation (or bootstrapping) of \bison\ parsers. The
start symbol can be set implicitly by listing the appropriate
-production first.
-@q %define lr.type canonical-lr @>
-@q Make not on this and lexing too much lookahead and the \stashed trick@>
-@q Explain other options @>
+production first. Modern \bison\ also allows specifying the kind of
+parsing algorithm to be used (provided the supplied grammar is in the
+appropriate class): {\sc LALR}($n$), {\sc LR}($n$), {\sc GLR}, etc.
+The default is to use the {\sc LALR}($1$) algorithm (with the
+corresponding assumption about the grammar) which can also be set
+explicitly by putting
+\medskip
+\beginprod
+\%define lr.type canonical-lr
+\endprod
+\medskip
+\noindent
+in with the rest of the options.
+Using other types of grammars will wreak havoc
+on the parsing algorithm hardcoded into \splint\ (see \.{yyparse.sty})
+as well as on the production of \.{\\stashed} and \.{\\format} streams.
@<Grammar parser \bison\ options@>=
@G
%token-table
@@ -1605,9 +245,9 @@ production first.
%start input
@g
-@*2 Grammar rules. Most of the original comments present in
+@*1 Token declarations. Most of the original comments present in
the grammar file used by \bison\ itself have been preserved and appear in
-{\it italics\/} at the beginning of each appropriate section.
+{\it italics\/} at the beginning of the appropriate section.
To facilitate the {\it bootstrapping\/} of the parser (see above), some
declarations have been separated into their own sections. Also, a
@@ -1616,6 +256,11 @@ number of new rules have been introduced to create a hierarchy of
most of the tokens used by the grammar. Only the string versions are
kept in the |yytname| array, which, in part is the reason for a
special bootstrapping parser as explained earlier.
+\iffalse
+ \checktrailingstashtrue % see what is left at the end
+ \checktabletrue % display the table
+ \let\stashnext\stashnextwithnothing % collect the stash expanded
+\fi
@<Tokens and types for the grammar parser@>=
@G
%token GRAM_EOF 0 "end of file"
@@ -1641,6 +286,11 @@ special bootstrapping parser as explained earlier.
@ We continue with the list of tokens below, following the layout of
the original parser.
+\iffalse
+ \checktrailingstashfalse
+ \checktablefalse
+ \let\stashnext\stashnextwithnothingnx
+\fi
@<Global Declarations@>=
@G
%token
@@ -1689,15 +339,19 @@ the original parser.
%token <param> PERCENT_PARAM "%param";
@g
-@ Extra tokens for typesetting \flex\ state
+@ \namedspot{flex.options}Extra tokens for typesetting \flex\ state
declarations and options are declared in addition to the ones that a
-standard \bison\ parser recognizes.
+standard \bison\ parser recognizes. This extension of the original
+grammar has become unnecessary with the addition of the \flex\ input
+parser(s) but is left as part of the extended grammar for convenience and
+`historical' reasons.
@<Tokens and...@>=
@G
%token FLEX_OPTION FLEX_STATE_X FLEX_STATE_S
@g
-@ We are ready to describe the top levels of the parse tree. The first
+@*1 Grammar productions.
+We are ready to describe the top levels of the parse tree. The first
`sub parser' we consider is a `full' parser, that is the parser that
expects a full grammar file, complete with the prologue, declarations,
etc. This parser can be used to extract information from the grammar
@@ -1706,23 +360,23 @@ that is otherwise absent from the executable code generated by
\.{\$}\.{[}{\rm name}\.{]}.
This parser is therefore used to generate the `symbolic
switch' to provide support for symbolic term names similar to
-`genuine' \bison's \.{\$}\.{[}$\ldots$\.{]} syntax.
+the `genuine' \bison's \.{\$}\.{[}$\ldots$\.{]} syntax.
+
+The action of the parser in this case is simply to separate the
+accumulated `parse tree' from the auxiliary information carried by the
+parser on the stack.
+\saveparseoutputfalse
+\checktablefalse
+\tracenamesfalse
@<Parser full productions@>=
@G
@t}\vb{\inline}{@>
input:
prologue_declarations
- "%%" grammar epilogue.opt {@> @<Finish the input setup@> @=}
+ "%%" grammar epilogue.opt {@> TeX_( "/getsecond{/yy(3)}/to/table" ); @=}
;
@g
-@ The action of the parser in this case is simply to separate the
-accumulated `parse tree' from the auxiliary information carried by the
-parser on the stack.
-@<Finish the input setup@>=
- @[TeX_( "/getsecond{/yy(3)}/to/toksa" );@]@; /* extract grammar contents */
- @[TeX_( "/yy0{/the/toksa}/table=/yy(0)" );@]@;
-
@ Another subgrammar deals with the syntax of isolated \bison\ rules. This is
the most commonly used `subparser' since a rules cluster is the most
natural `unit' to include in a \CWEB\ file.
@@ -1772,9 +426,12 @@ is undocumented so we supply an explicit action in each case.
@<Carry on@>=
@[TeX_( "/yy0{/the/yy(1)}" );@]@;
-@ Next, a subgrammar for processing prologue declarations. Finer
+@ Next comes a subgrammar for processing prologue declarations. Finer
differentiation is possible but the `subparsers' described here work
-pretty well and impose a mild style on the grammar writer.
+pretty well and impose a mild style on the grammar writer. Note that
+these roles are not part of the official \bison\ input grammar and are
+added to make the typesetting of `file outlines' (e.g.~|@(bb.yy@>|
+above) possible.
@<Fake start symbol for prologue grammar@>=
@G
@t}\vb{\inline}{@>
@@ -1819,8 +476,8 @@ prologue_declaration:
| "%defines" {@> TeX_( "/yy0{/nx/optionflag{defines}{}/the/yy(1)}" ); @=}
| "%defines" STRING {@> @[TeX_( "/toksa{defines}" );@]@+@<Prepare one parametric option@> @=}
| "%error-verbose" {@> TeX_( "/yy0{/nx/optionflag{error verbose}{}/the/yy(1)}" ); @=}
-| "%expect" INT {@> @[TeX_( "/toksa{expect}" );@]@+@<Prepare one parametric option@> @=}
-| "%expect-rr" INT {@> @[TeX_( "/toksa{expect-rr}" );@]@+@<Prepare one parametric option@> @=}
+| "%expect" INT {@> @[TeX_( "/toksa{expect}" );@]@+@<Prepare a generic one parametric option@> @=}
+| "%expect-rr" INT {@> @[TeX_( "/toksa{expect-rr}" );@]@+@<Prepare a generic one parametric option@> @=}
| "%file-prefix" STRING {@> @[TeX_( "/toksa{file prefix}" );@]@+@<Prepare one parametric option@> @=}
| "%glr-parser" {@> TeX_( "/yy0{/nx/optionflag{glr parser}{}/the/yy(1)}" ); @=}
| "%initial-action" "{...}" {@> TeX_( "/yy0{/nx/initaction/the/yy(2)}" ); @=}
@@ -1851,11 +508,20 @@ params:
construct just parsed and attach some auxiliary info, in this case the
stream pointers.
@<Prepare one parametric option@>=
+ @[TeX_( "/yy0{/nx/oneparametricoption{/the/toksa}{/nx/stringify/the/yy(2)}/the/yy(1)}" );@]@;
+
+@ @<Prepare a generic one parametric option@>=
@[TeX_( "/yy0{/nx/oneparametricoption{/the/toksa}{/the/yy(2)}/the/yy(1)}" );@]@;
-@ Some extra declarations to typeset \flex\ options and
+@ These rules handle extra declarations to typeset \flex\ options and
declarations. These are not part of the \bison\ syntax but their
-structure is similar enough that they can be included in the grammar.
+structure is similar enough that they can be included in the
+grammar. As was pointed out \locallink{flex.options}earlier \endlink
+the addition of the \flex\ input parser to \splint\ made this
+extension of the original \bison\ grammar obsolete but it was kept as
+part of the extended grammar for convenience and `historical'
+reasons. The convenience results from simplifying the bootstrap
+procedure by using a single parser.
@<Parser prologue productions@>=
@G
prologue_declaration:
@@ -1884,8 +550,8 @@ flex_option_list:
;
flex_option:
- ID {@> TeX_( "/yy0{/nx/flexoptionpair{/the/yy(1)}{}}" ); @=}
-| ID "=" symbol {@> TeX_( "/yy0{/nx/flexoptionpair{/the/yy(1)}{/the/yy(3)}}" ); @=}
+ ID {@> TeX_( "/yy0{/nx/flexoptionpair{/nx/idit/the/yy(1)}{}}" ); @=}
+| ID "=" symbol {@> TeX_( "/yy0{/nx/flexoptionpair{/nx/idit/the/yy(1)}{/the/yy(3)}}" ); @=}
;
@g
@@ -1905,19 +571,19 @@ flex_option:
@[TeX_( "/yy0{/the/yy(1)/nx/hspace{/the/toksb}{/the/toksc}/the/yy(2)}" );@]@;
@ {\it Grammar declarations}. These declarations can appear in both
-prologue and the rules sections. Their treatment is very similar to
-prologue-only options.
+the prologue and the rules sections. Their treatment is very similar to
+the prologue-only options.
@<Parser common productions@>=
@G
grammar_declaration:
precedence_declaration {@> @<Carry on@> @=}
| symbol_declaration {@> @<Carry on@> @=}
-| "%start" symbol {@> @[TeX_( "/toksa{start}" );@]@+@<Prepare one parametric option@> @=}
+| "%start" symbol {@> @[TeX_( "/toksa{start}" );@]@+@<Prepare a generic one parametric option@> @=}
| code_props_type "{...}" generic_symlist {@> @<Assign a code fragment to symbols@> @=}
| "%default-prec" {@> TeX_( "/yy0{/nx/optionflag{default prec.}{}/the/yy(1)}" ); @=}
| "%no-default-prec" {@> TeX_( "/yy0{/nx/optionflag{no default prec.}{}/the/yy(1)}" ); @=}
| "%code" "{...}" {@> TeX_( "/yy0{/nx/codeassoc{code}{}/the/yy(2)/the/yy(1)}" ); @=}
-| "%code" ID "{...}" {@> TeX_( "/yy0{/nx/codeassoc{code}{/the/yy(2)}/the/yy(3)/the/yy(1)}" ); @=}
+| "%code" ID "{...}" {@> TeX_( "/yy0{/nx/codeassoc{code}{/nx/idit/the/yy(2)}/the/yy(3)/the/yy(1)}" ); @=}
;
code_props_type:
@@ -1945,7 +611,7 @@ code_props_type:
@t}\vb{\inline\flatten}{@>
union_name:
{@> TeX_( "/yy0{}" ); @=}
-| ID {@> @<Carry on@> @=}
+| ID {@> @<Turn an identifier into a term@> @=}
;
grammar_declaration:
@@ -1969,7 +635,7 @@ precedence_declarator:
@t}\vb{\inline}{@>
tag.opt:
{@> TeX_( "/yy0{}" ); @=}
-| TAG {@> @<Carry on@> @=}
+| TAG {@> @<Prepare a \prodstyle{TAG}@> @=}
;
@g
@@ -1977,7 +643,7 @@ tag.opt:
@[TeX_( "/yy0{/nx/codeassoc{union}{/the/yy(2)}/the/yy(3)/the/yy(1)}" );@]@;
@ @<Define symbol types@>=
- @[TeX_( "/yy0{/nx/typedecls{/the/yy(2)}{/the/yy(3)}/the/yy(1)}" );@]@;
+ @[TeX_( "/yy0{/nx/typedecls{/nx/tagit/the/yy(2)}{/the/yy(3)}/the/yy(1)}" );@]@;
@ @<Define symbol precedences@>=
@[TeX_( "/getthird{/yy(1)}/to/toksa" );@]@; /* format pointer */
@@ -1989,7 +655,16 @@ tag.opt:
@<Parser common productions@>=
@<Parser bootstrap productions@>@;
-@ These are the two most important rules for the bootstrap parser.
+@ @<Prepare a \prodstyle{TAG}@>=
+ @[TeX_( "/yy0{/nx/tagit/the/yy(1)}" );@]@;
+
+@ These are the two most important rules for the bootstrap parser. The reasons for
+the~\prodstyle{\%token} declarations to be collected during the bootstrap pass are
+outlined in the \locallink{bootstrapping}section on bootstrapping\endlink.
+The~\prodstyle{\%nterm} declarations are not strictly necessary for
+boostrapping the parsers included in \splint\ but they are added for
+the cases when the bootstrap mode is used for purposes other than
+bootstrapping \splint.
@<Parser bootstrap productions@>=
@G
@t}\vb{\flatten}{@>
@@ -2002,8 +677,13 @@ symbol_declaration:
@ {\it Just like \prodstyle{symbols.1} but accept \prodstyle{INT} for
the sake of \POSIX}. Perhaps the only point worth mentioning here is
-the inserted separator (\.{\\hspace}). Like any other separator, it takes
-two parameters, stream pointers. In this case, however, both pointers are null
+the inserted separator (\.{\\hspace\{}$p_0$\.{\}\{}$p_1$\.{\}},
+typeset as
+|TeXa("/hspace"); TeXao(@t\TeXlit"\{\hbox{$p_0$}\}\{\hbox{$p_1$}\}\hbox{$\!$}"@>);|).
+@q A string "..." is a syntactic unit in \CWEB\ so it is impossible@>
+@q to insert \TeX\ material in the middle of the string directly@>
+Like any other separator, it takes
+two parameters, the stream pointers $p_0$ and~$p_1$. In this case, however, both pointers are null
since there seems to be no other meaningful assignment. If any
formatting or stash information is needed, it can be extracted by the
symbols themselves.
@@ -2020,7 +700,9 @@ symbol.prec:
;
@g
-@ {\it One or more symbols to be \prodstyle{\%type}'d}.
+@ {\it One or more symbols to be \prodstyle{\%type}'d}. The |@<List of
+symbols@>| rules below are reused in the boostrap parser and are put
+in a separate section for this reason.
@<Parser common productions@>=
@<List of symbols@>@;
@@ -2045,7 +727,7 @@ generic_symlist_item:
;
tag:
- TAG {@> @<Carry on@> @=}
+ TAG {@> @<Prepare a \prodstyle{TAG}@> @=}
| "<*>" {@> @<Carry on@> @=}
| "<>" {@> @<Carry on@> @=}
;
@@ -2055,7 +737,7 @@ tag:
@<Parser bootstrap productions@>=
@G
symbol_def:
- TAG {@> @<Carry on@> @=}
+ TAG {@> @<Prepare a \prodstyle{TAG}@> @=}
@t}\vb{\flatten}{@>
| id {@> TeX_( "/yy0{/nx/onesymbol{/the/yy(1)}{}{}}" ); @=}
| id INT {@> TeX_( "/yy0{/nx/onesymbol{/the/yy(1)}{/the/yy(2)}{}}" ); @=}
@@ -2158,7 +840,7 @@ indentation. The `format' of the \.{\\rhs} `structure' includes the
stash pointers and a `boolean' to indicate whether the right hand side ends
with an action. Since the action can be implicit, this decision has to
be postponed until, say, a semicolon is seen.
-No formatting or stash pointers are added for such implicit action.
+No formatting or stash pointers are added for implicit actions.
@<Start the right hand side@>=
@[TeX_( "/rhsbool{/yy(1)}/to/toksa /the/toksa" );@]@;
@[TeX_( "/getthird{/yy(1)}/to/toksb" );@]@; /* the format pointer */
@@ -2188,8 +870,7 @@ is not known a different way of accessing the stack is necessary.
@[TeX_( "/rhscont{/toksa}/to{/yy(0)}" );@]@;
@[TeX_( "/yy0{/the/yy(0)/nx/midf/the/toksb}" );@]@;
-@ No pointers are provided for an {\it implicit\/} action.
-@<Add a right hand side to a production@>=
+@ @<Old `Add a right hand side to a production'@>=
@[TeX_( "/rhsbool{/yy(4)}/to/toksa /the/toksa" );@]@;
@[TeX_( "/ifrhsfull" );@]@;
@[TeX_( " /yy0{/nx/rules{/the/yy(3)/nx/rrhssep/the/yy(2)/the/yy(4)}/the/yy(2)}" );@]@;
@@ -2204,6 +885,31 @@ is not known a different way of accessing the stack is necessary.
@[TeXfo( " /nx/actbraces{}{}{0}{0}/nx/bdend}{}{/nx/rhsfulltrue}}/the/yy(2)}" );@]@;
@[TeX_( "/fi" );@]@;
+@ No pointers are provided for an {\it implicit\/} action. Processing a set of rules involves a large number of
+reexpansions. This seems to be a good place to use an array to store {\sc AST} nodes ({\let\writetexidxentry\writetextxtidxentry
+\def\texnspace{texline}\def\texispace{index}\inlineTeXx{/astarray}}). While
+providing a noticeable speed up, this technique significantly
+complicates the debugging of the grammar. In particular, inspecting a
+parsed table supplies very little information if the {\sc AST} nodes are not
+expanded. The macros in \.{yyunion.sty} provide a special debugging
+namespace where the expansion of the parser produced control sequences
+may be modified to safely expand the generated table.
+@<Add a right hand side to a production@>=
+ @[TeX_( "/rhsbool{/yy(4)}/to/toksa /the/toksa" );@]@;
+ @[TeX_( "/ifrhsfull" );@]@;
+ @[TeX_( " /yypushx{/the/yy(3)/nx/rrhssep/the/yy(2)/the/yy(4)}/on/astarray" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /rhscont{/yy(4)}/to/toksa" );@]@;
+ @[TeX_( " /edef/next{/the/toksa}" );@]@;
+ @[TeX_( " /ifx/next/empty" );@]@;
+ @[TeX_( " /toksa{/emptyterm}" );@]@;
+ @[TeX_( " /fi" );@]@;
+ @[TeXb( " /yypushx{/the/yy(3)/nx/rrhssep/the/yy(2)" );@]@;
+ @[TeXf( " /nx/rhs{/the/toksa/nx/rarhssep{0}{0}" );@]@; /* streams have already been grabbed */
+ @[TeXfo( " /nx/actbraces{}{}{0}{0}/nx/bdend}{}{/nx/rhsfulltrue}}/on/astarray" );@]@;
+ @[TeX_( "/fi" );@]@;
+ @[TeX_( "/yy0{/nx/rules{/astarraylastcs}/the/yy(2)}" );@]@;
+
@ @<Add an optional semicolon@>=
@<Carry on@>@;
@@ -2216,8 +922,9 @@ is not known a different way of accessing the stack is necessary.
of a production. Various `precedence hints' must be attached to an
appropriate portion of the rule, just before an action (which can
be inline, implicit or both in this case).
+\saveparseoutputtrue
@<Parser grammar productions@>=
-@G
+@G(b)
rhs:
{@> @<Make an empty right hand side@> @=}
| rhs symbol named_ref.opt {@> @<Add a term to the right hand side@> @=}
@@ -2235,7 +942,8 @@ named_ref.opt:
;
@g
-@ @<Make an empty right hand side@>=
+@ \saveparseoutputfalse
+@<Make an empty right hand side@>=
@[TeX_( "/yy0{/nx/rhs{}{}{/nx/rhsfullfalse}}" );@]@;
@ @<Add a term to the right hand side@>=
@@ -2329,24 +1037,24 @@ named_ref.opt:
@[TeX_( "/rhscnct{/yy(1)}/to/toksb" );@]@;
@[TeX_( "/rhsbool{/yy(1)}/to/toksc /the/toksc" );@]@;
@[TeX_( "/ifrhsfull" );@]@;
- @[TeX_( " /yy0{/nx/mergeop{/the/yy(3)}/the/yy(2)}" );@]@; /* reuse \.{\\yyval} */
+ @[TeX_( " /yy0{/nx/mergeop{/nx/tagit/the/yy(3)}/the/yy(2)}" );@]@; /* reuse \.{\\yyval} */
@[TeX_( " /supplybdirective/toksa/yyval" );@]@; /* the directive is `absorbed' by the action */
@[TeX_( " /yy0{/nx/rhs{/the/toksa}{/the/toksb}{/nx/rhsfulltrue}}" );@]@;
@[TeX_( "/else" );@]@;
@[TeXb( " /yy0{/nx/rhs{/the/toksa" );@]@;
- @[TeXao( "/nx/mergeop{/the/yy(3)}/the/yy(2)}{/the/toksb}{/nx/rhsfullfalse}}" );@]@;
+ @[TeXao( "/nx/mergeop{/nx/tagit/the/yy(3)}/the/yy(2)}{/the/toksb}{/nx/rhsfullfalse}}" );@]@;
@[TeX_( "/fi" );@]@;
@ @<Create an empty named reference@>=
@[TeX_( "/yy0{}" );@]@;
@ @<Create a named reference@>=
- @<Carry on@>@;
+ @<Turn an identifier into a term@>@;
@ Identifiers.
{\it Identifiers are returned as |uniqstr| values by the scanner.
Depending on their use, we may need to make them genuine symbols}. We,
-on the other hand simply copy the values returned by the scanner.
+on the other hand, simply copy the values returned by the scanner.
@<Parser bootstrap productions@>=
@G
id:
@@ -2388,10 +1096,10 @@ placeholders for the appropriate actions in case the parser gains some
sophistication in processing low level types (or starts expecting
different types from the scanner).
@<Turn an identifier into a term@>=
- @<Carry on@>@;
+ @[TeX_( "/yy0{/nx/idit/the/yy(1)}" );@]@;
@ @<Turn a character into a term@>=
- @<Carry on@>@;
+ @[TeX_( "/yy0{/nx/charit/the/yy(1)}" );@]@;
@ @<Turn an identifier into a symbol@>=
@<Carry on@>@;
@@ -2400,10 +1108,10 @@ different types from the scanner).
@<Carry on@>@;
@ @<Prepare the left hand side@>=
- @<Carry on@>@;
+ @<Turn an identifier into a term@>@;
@ @<Prepare a string for use@>=
- @<Carry on@>@;
+ @[TeX_( "/yy0{/nx/stringify/the/yy(1)}" );@]@;
@ {\it Variable and value.
The \prodstyle{STRING} form of variable is deprecated and is not \.{M4}-friendly.
@@ -2412,14 +1120,14 @@ For example, \.{M4} fails for \.{\%define "[" "value"}.}
@G
@t}\vb{\flatten\inline}{@>
variable:
- ID {@> @<Carry on@> @=}
-| STRING {@> @<Carry on@> @=}
+ ID {@> @<Turn an identifier into a term@> @=}
+| STRING {@> @<Prepare a string for use@> @=}
;
value:
{@> TeX_( "/yy0{}" ); @=}
-| ID {@> @<Carry on@> @=}
-| STRING {@> @<Carry on@> @=}
+| ID {@> @<Turn an identifier into a term@> @=}
+| STRING {@> @<Prepare a string for use@> @=}
| "{...}" {@> TeX_( "/yy0{/nx/bracedvalue/the/yy(1)}" ); @=}
;
@g
@@ -2443,7 +1151,7 @@ as they have to be inserted in a place that is aware of the internal definitions
definitions are used.
@<Grammar parser \Cee\ postamble@>=
-#define YYPRINT(file, type, value) yyprint (file, type, value)
+#define YYPRINT(file, type, value) @[yyprint (file, type, value)@]
static void yyprint (FILE *file, int type, YYSTYPE value){}
@ @<Bootstrap parser \Cee\ postamble@>=
@@ -2452,10 +1160,10 @@ definitions are used.
@ @<Bootstrap token output@>=
void bootstrap_tokens( char *bootstrap_token_format ) {
-
-#define _register_token_d(name) fprintf( tables_out, bootstrap_token_format, #name, name, #name );
+
+#define _register_token_d(name) @[fprintf( tables_out, bootstrap_token_format, #name, name, #name );@;
@<Bootstrap token list@>@;
-#undef _register_token_d
+#undef _register_token_d@;
}
@@ -2475,5 +1183,8 @@ token information from the grammar.
@q _register_token_d(SEMICOLON) /* can be omitted in prologue */ @>
@q _register_token_d(TAG) /* only encountered in the definition of PERCENT_PARAM */ @>
-@ Union of types.
+@ Union of types. This section of the \bison\ input lists the types
+that may appear on the value stack. Since \TeX\ does not provide any
+mechanism for type checking (nor is it clear how to translate a \Cee\
+|union| into any data structure usable in \TeX), this section is left empty.
@<Union of grammar parser types@>=
diff --git a/support/splint/cweb/bs.w b/support/splint/cweb/bs.w
index a2003d81fa..adefd23f8b 100644
--- a/support/splint/cweb/bs.w
+++ b/support/splint/cweb/bs.w
@@ -1,4 +1,4 @@
-@q Copyright 2012-2014, Alexander Shibakov@>
+@q Copyright 2012-2020, Alexander Shibakov@>
@q This file is part of SPLinT@>
@q SPLinT is free software: you can redistribute it and/or modify@>
@@ -14,7 +14,7 @@
@q You should have received a copy of the GNU General Public License@>
@q along with SPLinT. If not, see <http://www.gnu.org/licenses/>.@>
-@*1\bison\ specific routines.
+@*1\eatone{Bison}\bison\ specific routines.
The placeholder code left blank in the common routines is filed in
with the code relevant to the output of parser tables in the following sections.
@@ -173,7 +173,9 @@ change affects the generated parser.
}
-@*2Constants.
+@*2Constants. A generic list of constants to be used later in different contexts is defined below.
+As before, the appropriate macro will be defined generically to do what is required with these
+names (for example, we can turn each name into a string for reporting purposes).
@<Parser constants@>=
_register_const_d(YYEMPTY)@;
_register_const_d(YYPACT_NINF)@;
@@ -196,17 +198,11 @@ format tokens are output in.
char *token_format_suffix = NULL;
char *bootstrap_token_format = NULL;
-@ @<Parser specific option list@>=
- _register_option("token-format-char", required_argument, 0, TOKEN_FORMAT_CHAR, "")@;
- _register_option("token-format-affix", required_argument, 0, TOKEN_FORMAT_AFFIX, "")@;
- _register_option("token-format-suffix", required_argument, 0, TOKEN_FORMAT_SUFFIX, "")@;
- _register_option("bootstrap-token-format", required_argument, 0, BOOTSTRAP_TOKEN_FORMAT, "")@;
-
-@ @<Higher index parser specific options@>=
- TOKEN_FORMAT_CHAR,@[@]
- TOKEN_FORMAT_AFFIX,@[@]
- TOKEN_FORMAT_SUFFIX,@[@]
- BOOTSTRAP_TOKEN_FORMAT,@[@]
+@ @<Parser specific options without shortcuts@>=
+ register_option_("token-format-char", required_argument, 0, TOKEN_FORMAT_CHAR, "")@;
+ register_option_("token-format-affix", required_argument, 0, TOKEN_FORMAT_AFFIX, "")@;
+ register_option_("token-format-suffix", required_argument, 0, TOKEN_FORMAT_SUFFIX, "")@;
+ register_option_("bootstrap-token-format", required_argument, 0, BOOTSTRAP_TOKEN_FORMAT, "")@;
@ @<Handle parser output options@>=
case TOKEN_FORMAT_CHAR:@;
@@ -323,11 +319,8 @@ names and values in the format of your choosing.
@<Prepare token only output environment@>@;
break;
-@ @<Parser specific option list@>=
- _register_option("token-only-mode", no_argument, 0, TOKEN_ONLY_MODE, "")@;
-
-@ @<Higher index parser specific options@>=
- TOKEN_ONLY_MODE,@[@]
+@ @<Parser specific options without shortcuts@>=
+ register_option_("token-only-mode", no_argument, 0, TOKEN_ONLY_MODE, "")@;
@ @<Configure parser output modes@>=
case TOKEN_ONLY_MODE:@;
@@ -560,11 +553,11 @@ rules are not output if a crippled \bison\ is used.
@<Helper functions for parser output@>=
void print_rule( int n ) {
- int i;
-
fprintf( tables_out, "%s%s: ", (n < 10 && !optimize_actions ? " " : ""), yytname[yyr1[n]] );
#ifndef BISON_IS_CRIPPLED
+ int i;
+
i = yyprhs[n];
if ( yyrhs[i] < 0 ) {
@@ -634,14 +627,11 @@ YYPACT_NINF_desc.name = "YYPACTNINF";
@*2 Command line options.
We start with the most obvious option, the one begging for help.
-@<Higher index parser specific options@>=
- LONG_HELP,@[@]
-
-@ @<Parser specific option list@>=
- _register_option("help", no_argument, 0, LONG_HELP, "")@;
+@ @<Parser specific options without shortcuts@>=
+ register_option_("help", no_argument, 0, LONG_HELP, "")@;
@ @<Shortcuts for command line options affecting parser output@>=
- "h"
+ @[@[@], 'h'@]
@ @<Handle parser output options@>=
case 'h': /* short help */@;
@@ -655,24 +645,21 @@ We start with the most obvious option, the one begging for help.
exit(0);
break; /* should not be needed */
-@ @<Parser specific option list@>=
- _register_option("debug", optional_argument, 0, 'b', "")@;
- _register_option("mode", required_argument, 0, 'm', "")@;
- _register_option("table-separator", required_argument, 0, 'z', "")@;
+@ @<Parser specific options with shortcuts@>=
+ register_option_("debug", optional_argument, 0, 'b', "")@;
+ register_option_("mode", required_argument, 0, 'm', "")@;
+ register_option_("table-separator", required_argument, 0, 'z', "")@;
- _register_option("format", required_argument, 0, 'f', "")@; /* name? */
- _register_option("table", required_argument, 0, 't', "")@; /* specific table */
- _register_option("constant", required_argument, 0, 'c', "")@; /* specific constant */
- _register_option("name-length", required_argument, 0, 'l', "")@; /* change |MAX_NAME_LENGTH| */
- _register_option("token", required_argument, 0, 'n', "")@; /* specific token */
- _register_option("run-parse", required_argument, 0, 'p', "")@; /* run the parser */
- _register_option("parse-file", required_argument, 0, 'i', "")@; /* input for the parser */
+ register_option_("format", required_argument, 0, 'f', "")@; /* name? */
+ register_option_("table", required_argument, 0, 't', "")@; /* specific table */
+ register_option_("constant", required_argument, 0, 'c', "")@; /* specific constant */
+ register_option_("name-length", required_argument, 0, 'l', "")@; /* change |MAX_NAME_LENGTH| */
+ register_option_("token", required_argument, 0, 'n', "")@; /* specific token */
+ register_option_("run-parse", required_argument, 0, 'p', "")@; /* run the parser */
+ register_option_("parse-file", required_argument, 0, 'i', "")@; /* input for the parser */
@ The string below is a list of short options.
-@<Shortcuts for command line options affecting parser output@>=
- "z:m:f:t:"
-
@ A few options can be discussed immediately.
@<Variables and types local to the parser@>=
diff --git a/support/splint/cweb/checklists.w b/support/splint/cweb/checklists.w
new file mode 100644
index 0000000000..754855d747
--- /dev/null
+++ b/support/splint/cweb/checklists.w
@@ -0,0 +1,82 @@
+% Copyright 2012-2020, Alexander Shibakov
+% Copyright 2002-2014 Free Software Foundation, Inc.
+% This file is part of SPLinT
+%
+% SPLinT is free software: you can redistribute it and/or modify
+% it under the terms of the GNU General Public License as published by
+% the Free Software Foundation, either version 3 of the License, or
+% (at your option) any later version.
+%
+% SPLinT is distributed in the hope that it will be useful,
+% but WITHOUT ANY WARRANTY; without even the implied warranty of
+% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+% GNU General Public License for more details.
+%
+% You should have received a copy of the GNU General Public License
+% along with SPLinT. If not, see <http://www.gnu.org/licenses/>.
+
+@** Checklists. This (experimental) section serves to aid in the
+testing and extension of \splint\ by formalizing a number of procedures
+in the form of a checklist. After having witnessed first hand the effectiveness
+of checklists in aviation, the author feels that a similar approach
+will be beneficial in programming, as well. Most of these tests can and
+should be automated but the applicable situations are rather rare so
+the automation has not been implemented yet.
+
+{%
+\def\aterm#1{\item{\sqebullet\ }{\ttl #1}\ignorespaces}%
+\def\aaterm#1{\itemitem{\sqebullet\ }{\ttl #1}\ignorespaces}%
+\def\aaaterm#1{\itemitemitem{\sqebullet\ }{\ttl #1}\ignorespaces}%
+\setbox0=\hbox{\sqebullet\ \enspace}
+\parindent=0pt
+\advance\parindent by \wd0
+\bigskip
+\noindent{\ttl General checklist.}
+\smallskip
+\aterm{} Have the checklists in this section been followed?
+
+\aterm{} Have {\it all\/} the examples been built and tested?
+
+\aaterm{} \.{make}: this would build the \.{ld} parser, as well as other
+parts, like \.{ssfo.pdf}, etc.
+
+\aaterm{} \.{symbols}
+
+\aaterm{} \.{xxpression} (both \.{make} and \.{make test})
+
+\aaterm{} \.{expression} (both \.{make} and \.{make test})
+
+\aaterm{} once in a while it is useful to run a tool like \.{diffpdf} to check
+that the generated output does not change unexpectedly
+
+\aaterm{} \.{parsec} (not part of \splint)
+
+\aterm{} Have the changes been documented?
+
+\aaterm{} If any limitations have been removed, has this been reflected
+in the documentation, examples, such as \.{symbols.sty}?
+
+\aaterm{} If any new conditionals have been added, does \.{yydebug.sty} provide
+a way to check their status, if appropriate?
+
+\aaterm{} If any new script option has been added, has the script documentation been
+updated?
+
+\aterm{} If a new process has been introduced, has it been reflected in any of the checklists in
+this section?
+
+\bigskip
+\noindent{\ttl Rewriting checklist.}
+\smallskip
+\aterm{} Is the output of the new system identical?
+
+\aaterm{} once in a while it is useful to run a tool like \.{diffpdf} to check
+that the generated output does not change unexpectedly
+
+\aaterm{} has \.{diff} been used to check that \.{.gdx} and \.{.gdy} files produced
+are (nearly) identical?
+
+\aaterm{} has \.{diff} been used to check that \.{.sns} files produced by \.{symbols}
+and \.{xxpression} examples are (nearly) identical?
+
+}
diff --git a/support/splint/cweb/common.w b/support/splint/cweb/common.w
index 3ab5af93b4..0f50fdcabd 100644
--- a/support/splint/cweb/common.w
+++ b/support/splint/cweb/common.w
@@ -1,4 +1,4 @@
-@q Copyright 2012-2014, Alexander Shibakov@>
+@q Copyright 2012-2020, Alexander Shibakov@>
@q This file is part of SPLinT@>
@q SPLinT is free software: you can redistribute it and/or modify@>
@@ -14,7 +14,7 @@
@q You should have received a copy of the GNU General Public License@>
@q along with SPLinT. If not, see <http://www.gnu.org/licenses/>.@>
-@** Forcing \bison\ and \flex\ to output \TeX.
+@** Forcing \eatone{bison}\bison\ and \eatone{flex}\flex\ to output \TeX.
Instead of implementing a \bison\ (or \flex) `plugin' for outputting
\TeX\ parser, the code that follows produces a separate executable
that outputs all the required tables after the inclusion of an
@@ -25,6 +25,11 @@ assumed to be merely |printf()| statements that output the `real'
output an `action switch' appropriate for use with \TeX. In every
other respect, the included parser or scanner can use any features
allowed in `real' parsers and scanners.
+\def\action#1{\hbox{$\hbox{\\{action}}_{#1}$}}
+\def\actionn{\action{n}}
+
+@s action1 TeX
+@s actionn TeX
@*1 Common routines.
The `top' level of the scanner and parser `drivers' is very similar,
@@ -43,9 +48,6 @@ software. All the essential routines are presented in the sections
below, though.
@<\Cee\ postamble@>=
-@<Outer definitions@>;
-@<Global variables and types@>@;
-@<Auxiliary function declarations@>@;
@<Auxiliary function definitions@>@;
int main( int argc, char **argv ) {
@@ -64,9 +66,13 @@ int main( int argc, char **argv ) {
}
+ fprintf( stderr, "Outputting tables and actions\n" );
+
if ( tables_out ) {
+ fprintf( stderr, " tables ... " );
@<Perform output@>@;
+ fprintf( stderr, "actions ... " );
@<Output action switch, if any@>@;
} else {
@@ -76,6 +82,8 @@ int main( int argc, char **argv ) {
}
+ fprintf( stderr, "done, cleaning up\n" );
+
@<Clean up@>@;
return 0;
@@ -122,7 +130,7 @@ example, the |yyrthree| array, which is necessary for processing
mentioned in the previous sentence. There does not seem to be any
other way to access this information. A number of tools (GNU and
otherwise) have taken the path of narrowing the field of application
-to a few use cases invisioned by the maintainers. This includes
+to a few use cases envisioned by the maintainers. This includes
compilers, as well.
There is a strange
@@ -228,8 +236,8 @@ is to provide a general pattern.
static int optimize_tables = 0;
@ It is set using the command line option below.
-@<Raw option list@>=
- _register_option("optimize-tables", no_argument, &optimize_tables, 1, "")@;
+@<Options without arguments@>=
+ register_option_("optimize-tables", no_argument, &optimize_tables, 1, "")@;
@ The reason to implement the table output routine as a macro is to avoid
writing separate functions for tables of different types of data
@@ -408,9 +416,9 @@ the processing of the action code.
The last argument of the `flexible' macro below is supposed to be an
extended description of each option which can be later utilized by a
|usage()| function.
-@<Raw option list@>=
- _register_option("bare-actions", no_argument, &bare_actions, 1, "")@;
- _register_option("optimize-actions", no_argument, &optimize_actions, 1, "")@;
+@<Options without arguments@>=
+ register_option_("bare-actions", no_argument, &bare_actions, 1, "")@;
+ register_option_("optimize-actions", no_argument, &optimize_actions, 1, "")@;
@ The rest of the action output code mimics that for table output, starting with
the descriptor. To make the output format more flexible, this
@@ -470,11 +478,21 @@ macros which produces undesirable typesetting artefacts.}.
@d TeXf( string ) TeX_( string )
@d TeXfo( string ) TeX_( string )
@d TeXao( string ) TeX_( string )
+@d YY_FATAL_ERROR( message ) fprintf( tables_out, " /yylexcomplain{%s}/yylexerrterminate%%\n", message )
@q \CWEB\ is not aware of variadic macros, so this has to be done the old way@>
@<\Cee\ preamble@>=
#define TeX__( string, ... ) @[fprintf( tables_out, " " string "%s\n", __VA_ARGS__, "%" )@]
+@ If a full parser is not needed, the lexing mechanism is not required. To satisfy the compiler
+and the linker, the lexer and other functions still have to be declared and defined, since these functions
+are referred to in the body of the parser. The details of these declarations can be found in the driver
+code.
+@<\Cee\ preamble@>=
+ @<Outer definitions@>;
+ @<Global variables and types@>@;
+ @<Auxiliary function declarations@>@;
+
@ We begin with a few macros to facilitate the output
of tables in the format that \TeX\ can understand. As there is no
perfect way to represent an array in \TeX\ a rather weak compromise
@@ -710,7 +728,7 @@ specific cases are added to in the course of adding new features.
FOREVER {
- c = getopt_long (argc, argv, ":" @<Short option list@>, long_options, &option_index);
+ c = getopt_long (argc, argv, ( char [] ){':'@t, @>@<Short option list@>}, long_options, &option_index);
if (c == -1) break;
@@ -763,9 +781,11 @@ specific cases are added to in the course of adding new features.
}
@ @<Long options array@>=
-#define _register_option(name, arg_flag, loc, val, exp) @[{name, arg_flag, loc, val},@[@]@]
- @<Raw option list@>@;
-#undef _register_option
+#define register_option_(name, arg_flag, loc, val, exp) @[{name, arg_flag, loc, val},@[@]@]
+ @<Options without shortcuts@>@;
+ @<Options with shortcuts@>@;
+ @<Options without arguments@>@;
+#undef register_option_
@ In addition to spelling out the full command line option name (such
as \.{--help}) |getopt_long| gives the user a choice of using a
@@ -775,12 +795,28 @@ this section (and a number of others) empty to be filled in with the
driver specific code to pacify \CWEAVE.
@<Short option list@>=
+#define dd_optional_argument @[@[@], ':', ':'@]
+#define dd_required_argument @[@[@], ':'@]
+#define dd_no_argument
+#define register_option_(name, arg_flag, loc, val, ...) @[@[@], val dd_##arg_flag@]
+ @<Options with shortcuts@>@;
+#undef register_option_
+#undef dd_optional_argument
+#undef dd_required_argument
+#undef dd_no_argument
@ Some options have one-letter `shortcuts', whereas others only exist
in `fully spelled-out' form. To easily keep track of the latter, a
special enumerated list is declared. To add to this list, simply add
to the \CWEB\ section below.
@<Higher index options@>=
+#define register_option_(name, arg_flag, loc, val, ...) @[val,@[@]@]
+ @<Options without shortcuts@>@;
+#undef register_option_
+
+@ @<Options with shortcuts@>=
+
+@ @<Options without shortcuts@>=
@ @<Cases affecting the whole program@>=
diff --git a/support/splint/cweb/fk.w b/support/splint/cweb/fk.w
index 04685ff9aa..fc0c5d2e14 100644
--- a/support/splint/cweb/fk.w
+++ b/support/splint/cweb/fk.w
@@ -1,4 +1,4 @@
-@q Copyright 2012-2014, Alexander Shibakov@>
+@q Copyright 2012-2020, Alexander Shibakov@>
@q This file is part of SPLinT@>
@q SPLinT is free software: you can redistribute it and/or modify@>
@@ -14,7 +14,7 @@
@q You should have received a copy of the GNU General Public License@>
@q along with SPLinT. If not, see <http://www.gnu.org/licenses/>.@>
-@*1 \flex\ specific routines. The output of the scanner automaton
+@*1\eatone{Flex}\flex\ specific routines. The output of the scanner automaton
follows the steps similar to the ones taken during the parser output.
The major difference is in the output of actions and constants.
@*2 Tables.
@@ -90,7 +90,7 @@ way.
@ @<Output scanner actions@>=
if ( output_desc.output_actions ) {
-
+
int i, j;
yyscan_t fake_scanner;
@@ -106,15 +106,24 @@ way.
yy_ec[0] = 0;
yy_base[1] = max_yybase_entry;
+
+ yy_base[2] = 0;
+ yy_chk[0] = 2;
+
yy_chk[max_yybase_entry] = 1;
yy_nxt[max_yybase_entry] = 1;
+ yy_nxt[0] = 1;
+
+ fprintf( stderr, "max entry: %d\n", max_yybase_entry );
+
}
+
for ( i = 1; i <= max_yyaccept_entry; i++ ) {
fprintf( tables_out, action_desc.act_setup, i );
-
+
if ( i == YY_END_OF_BUFFER ) {
fprintf( tables_out, " %% YY_END_OF_BUFFER\n%s\n", " \\yylexeofaction" );
@@ -127,15 +136,17 @@ way.
(( struct yyguts_t *)fake_scanner)->yy_hold_char = 0;
yy_accept[1] = i;
+ if ( i%10 == 0 ) {
+ fprintf( stderr, "." );
+ }
yylex( NULL, fake_scanner );
-
}
}
fprintf( tables_out, action_desc.act_suffix, i );
}
-
+
fprintf( tables_out, " %% end of file states:\n%s\n",
" %#define YY_STATE_EOF(state) (YY_END_OF_BUFFER + state + 1)"
);
@@ -376,8 +387,7 @@ changes.
" \\csname doflexaction\\number #1\\parsernamespace\\endcsname\n"@/
" \\yylextail\n"@;
"}\\stashswitch{yydoactionswitch}%\n";
- action_desc.act_setup = "\n\\expandafter\\def\\csname doflexaction%d\\parsernamespace\\endcsname{%%\n"
- " \\YYRULESETUP";
+ action_desc.act_setup = "\n\\expandafter\\def\\csname doflexaction%d\\parsernamespace\\endcsname{%%";
action_desc.act_suffix = "}%% end of rule %d\n";
action_desc.action1 = NULL;
action_desc.actionn = NULL;
@@ -435,14 +445,11 @@ are handled separately, because they contain underscores.
@*2 Command line options.
We start with the most obvious option, the one begging for help.
-@<Higher index scanner specific options@>=
- LONG_HELP,@[@]
-
-@ @<Scanner specific option list@>=
- _register_option("help", no_argument, 0, LONG_HELP, "")@;
+@ @<Scanner specific options without shortcuts@>=
+ register_option_("help", no_argument, 0, LONG_HELP, "")@;
@ @<Shortcuts for command line options affecting scanner output@>=
- "h"
+ @[@[@], 'h'@]
@ @<Handle scanner output options@>=
case 'h': /* short help */@;
@@ -456,22 +463,18 @@ We start with the most obvious option, the one begging for help.
exit(0);
break; /* should not be needed */
-@ @<Scanner specific option list@>=
- _register_option("debug", optional_argument, 0, 'b', "")@;
- _register_option("mode", required_argument, 0, 'm', "")@;
- _register_option("table-separator", required_argument, 0, 'z', "")@;
-
- _register_option("format", required_argument, 0, 'f', "")@; /* name? */
- _register_option("table", required_argument, 0, 't', "")@; /* specific table */
- _register_option("constant", required_argument, 0, 'c', "")@; /* specific constant */
- _register_option("name-length", required_argument, 0, 'l', "")@; /* change |MAX_NAME_LENGTH| */
- _register_option("token", required_argument, 0, 'n', "")@; /* specific token */
- _register_option("run-scan", required_argument, 0, 'p', "")@; /* run the scanner */
- _register_option("scan-file", required_argument, 0, 'i', "")@; /* input for the scanner */
-
-@ The string below is a list of short options.
-@<Shortcuts for command line options affecting scanner output@>=
- "b::z:m:f:t:"
+@ @<Scanner specific options with shortcuts@>=
+ register_option_("debug", optional_argument, 0, 'b', "")@;
+ register_option_("mode", required_argument, 0, 'm', "")@;
+ register_option_("table-separator", required_argument, 0, 'z', "")@;
+
+ register_option_("format", required_argument, 0, 'f', "")@; /* name? */
+ register_option_("table", required_argument, 0, 't', "")@; /* specific table */
+ register_option_("constant", required_argument, 0, 'c', "")@; /* specific constant */
+ register_option_("name-length", required_argument, 0, 'l', "")@; /* change |MAX_NAME_LENGTH| */
+ register_option_("token", required_argument, 0, 'n', "")@; /* specific token */
+ register_option_("run-scan", required_argument, 0, 'p', "")@; /* run the scanner */
+ register_option_("scan-file", required_argument, 0, 'i', "")@; /* input for the scanner */
@ A few options can be immediately discussed.
@<Variables and types local to the scanner driver@>=
diff --git a/support/splint/cweb/fo.w b/support/splint/cweb/fo.w
new file mode 100644
index 0000000000..81694024c3
--- /dev/null
+++ b/support/splint/cweb/fo.w
@@ -0,0 +1,702 @@
+@q Copyright (c) 1990 The Regents of the University of California. @>
+@q All rights reserved. @>
+
+@q This code is derived from software contributed to Berkeley by @>
+@q Vern Paxson. @>
+
+@q The United States Government has rights in this work pursuant @>
+@q to contract no. DE-AC03-76SF00098 between the United States @>
+@q Department of Energy and the University of California. @>
+
+@q This file is part of SPLinT. @>
+
+@q Redistribution and use in source and binary forms, with or without @>
+@q modification, are permitted provided that the following conditions @>
+@q are met: @>
+
+@q 1. Redistributions of source code must retain the above copyright @>
+@q notice, this list of conditions and the following disclaimer. @>
+@q 2. Redistributions in binary form must reproduce the above copyright @>
+@q notice, this list of conditions and the following disclaimer in the @>
+@q documentation and/or other materials provided with the distribution. @>
+
+@q Neither the name of the University nor the names of its contributors @>
+@q may be used to endorse or promote products derived from this software @>
+@q without specific prior written permission. @>
+
+@q THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR @>
+@q IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED @>
+@q WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR @>
+@q PURPOSE. @>
+
+@**The \ifbootstrapmode flex \else\flex\ \fi parser stack.
+\ifbootstrapmode % this is a bootstrap run to generate the tables
+ \input limbo.sty
+ \def\optimization{5}
+ \input yy.sty
+ \modebootstrap
+\else % otherwise set up the pretty printing of tokens
+ \let\hostparsernamespace\flexnamespace
+\fi
+The scanner generator, \flex, uses \bison\ to produce a parser for its
+input language. Its lexer is output by \flex\ itself so both are
+reused to generate the parser and the scanner for pretty printing
+\flex\ input.
+
+This task is made somewhat complicated by the dependence of the \flex\
+input scanner on the correctly placed whitespace\footnote{For example,
+each regular expression definition in section~1 must start at the
+beginning of the line.}, as well as the reliance of the said scanner
+on rather involved state switching. Therefore, making subparsers for
+different fragments of \flex\ input involves not only choosing an
+appropriate subset of grammar rules to correctly process the
+grammatic constructs but also setting up the correct lexer states.
+
+The first subparser is designed to process a complete \flex\
+file. This parser is not currently part of any parser stack and is
+only used for testing. This is the only parser that does not rely on
+any custom adjustments to the lexer state to operate correctly.
+@(fip.yy@>=
+@G
+%{@> @<Preamble for the \flex\ parser@> @=%}
+ @> @<Options for \flex\ parser@> @=
+%union {@> @=}
+%{@> @<Postamble for \flex\ parser@> @=%}
+ @> @<Token definitions for \flex\ input parser@>@=
+%%
+ @> @<Productions for \flex\ parser@> @=
+%%
+@g
+
+@ The selection of options for \bison\ parsers suitable for \splint\
+have been discussed
+\ifbootstrapmode\else\locallink{bison.options}earlier \endlink\fi so we
+list them here without further comments.
+@<Options for \flex\ parser@>=
+@G
+%token-table
+%debug
+%start goal
+@g
+
+@ A parser for section~1 (definitions and declarations). This parser requires a custom
+lexer, as discussed above, to properly set up the state. Short of
+this, the lexer may produce the wrong kind of tokens or even generate
+an error.
+@(ddp.yy@>=
+@G
+%{@> @<Preamble for the \flex\ parser@> @=%}
+ @> @<Options for \flex\ parser@> @=
+%union {@> @=}
+%{@> @<Postamble for \flex\ parser@> @=%}
+ @> @<Token definitions for \flex\ input parser@>@=
+%%
+ @> @<Exclusive productions for \flex\ section~1 parser@> @=
+ @> @<Productions for \flex\ section~1 parser@> @=
+%%
+
+@ A parser for section~2 (rules and actions). This subparser must also
+use a custom set up for its lexer as discussed above.
+@(rap.yy@>=
+@G
+%{@> @<Preamble for the \flex\ parser@> @=%}
+ @> @<Options for \flex\ parser@> @=
+%union {@> @=}
+%{@> @<Postamble for \flex\ parser@> @=%}
+ @> @<Token definitions for \flex\ input parser@>@=
+%%
+ @> @<Special \flex\ section~2 parser productions@> @=
+ @> @<Productions for \flex\ section~2 parser@> @=
+%%
+@g
+
+@ A parser for just the regular expression syntax. A custom
+lexer initialization must precede the use of this parser, as well.
+@(rep.yy@>=
+@G
+%{@> @<Preamble for the \flex\ parser@> @=%}
+ @> @<Options for \flex\ parser@> @=
+%union {@> @=}
+%{@> @<Postamble for \flex\ parser@> @=%}
+ @> @<Token definitions for \flex\ input parser@>@=
+%%
+ @> @<Special productions for regular expressions@> @=
+ @> @<Rules for \flex\ regular expressions@> @=
+%%
+
+@*1 Token and state declarations for the \eatone{flex}\flex\ input scanner.
+Needless to say, the original grammar used by \flex\ was not designed
+with pretty printing in mind (and why would it be?). Instead, efficiency
+was the goal which resulted in a number of lexical constructs being
+processed `on the fly', as the lexer encounters them. Such syntax
+fragments never reach the parser, and would not have a chance to be
+displayed by our routines, unless some grammar extensions and
+alterations were introduced.
+
+To make the pretty printing possible, a number of new tokens have been
+introduced below that are later used in a few altered or entirely new
+grammar productions.
+@<Token definitions for \flex\ input parser@>=
+@G
+%token CHAR NUMBER SECTEND SCDECL XSCDECL NAME PREVCCL EOF_OP
+%token OPTION_OP OPT_OUTFILE OPT_PREFIX OPT_YYCLASS OPT_HEADER OPT_EXTRA_TYPE
+%token OPT_TABLES
+
+%token CCE_ALNUM CCE_ALPHA CCE_BLANK CCE_CNTRL CCE_DIGIT CCE_GRAPH
+%token CCE_LOWER CCE_PRINT CCE_PUNCT CCE_SPACE CCE_UPPER CCE_XDIGIT
+
+%token CCE_NEG_ALNUM CCE_NEG_ALPHA CCE_NEG_BLANK CCE_NEG_CNTRL CCE_NEG_DIGIT CCE_NEG_GRAPH
+%token CCE_NEG_LOWER CCE_NEG_PRINT CCE_NEG_PUNCT CCE_NEG_SPACE CCE_NEG_UPPER CCE_NEG_XDIGIT
+
+%left CCL_OP_DIFF CCL_OP_UNION
+
+@ We introduce an additional option type to capture all the non-parametric options used
+by the \flex\ lexer. The original lexer processes these options at the
+point of recognition, while the typesetting parser needs to be aware of them.
+@<Token definitions for \flex\ input parser@>=
+@G
+%token TOP_OP POINTER_OP ARRAY_OP DEF_OP RE_DEF OPT_OTHER OPT_DEPRECATED
+
+@ {\em \POSIX\ and \.{AT\&T} \lex\ place the
+precedence of the repeat operator, \.{\{\}}, below that of concatenation.
+Thus, \.{ab\{3\}} is\/ \.{ababab}. Most other \POSIX\ utilities use an {\rm Extended
+Regular Expression (ERE)} precedence that has the repeat operator
+higher than concatenation. This causes \.{ab\{3\}} to yield\/ \.{abbb}.
+
+In order to support the \POSIX\ and \.{AT\&T} precedence and the \flex\
+precedence we define two token sets for the begin and end tokens of
+the repeat operator, \prodstyle{BEGIN_REPEAT_POSIX} and\/ \prodstyle{END_REPEAT_POSIX}. The lexical scanner chooses
+which tokens to return based on whether {\let\it\itbold\prodstyle{posix\_compat} or \prodstyle{lex\_compat}
+are specified. Specifying either \prodstyle{posix\_compat} or \prodstyle{lex\_compat}} will
+cause \flex\ to parse scanner files as per the \.{AT\&T} and \POSIX-mandated behavior.}
+@<Token definitions for \flex\ input parser@>=
+@G
+%token BEGIN_REPEAT_POSIX END_REPEAT_POSIX BEGIN_REPEAT_FLEX END_REPEAT_FLEX
+
+@*1 The grammar for \eatone{flex}\flex\ input.
+The original grammar has been carefully split into sections to
+facilitate the assembly of various subparsers in the \flex's
+stack. Neither the \flex\ parser nor its scanner are part of the
+bootstrap procedure which simplifies both the input file organization,
+as well as the macro design. Some amount of preprocessing is still
+necessary, however, to extract the state names from the lexer file
+(see \ifbootstrapmode\else\locallink{state.grabbing}above \endlink\fi for the
+explanation). We can nevertheless get away with an empty \Cee\ preamble.
+@<Preamble for the \flex\ parser@>=
+
+@ @<Productions for \flex\ parser@>=
+@G
+@t}\vb{\inline\flatten}{@>
+goal:
+ initlex sect1 sect1end
+ sect2 initforrule {@> @<Assemble a \flex\ input file@> @=}
+ ;
+
+sect1end:
+ SECTEND {@> @<Copy the value@> @=}
+ ;
+
+initlex:
+ {@> @=}
+ ;
+@g
+
+@ @<Assemble a \flex\ input file@>=
+ @[TeX_( "/yy0{/the/yy(2)/the/yy(4)}" );@]@;
+
+@ @<Productions for \flex\ parser@>=
+@<Productions for \flex\ section~1 parser@>@;
+@<Productions for \flex\ section~2 parser@>@;
+
+@ @<Exclusive productions for \flex\ section~1 parser@>=
+@G
+@t}\vb{\inline\flatten}{@>
+goal:
+ sect1 {@> @<Assemble a \flex\ section~1 file@> @=}
+ ;
+
+@ @<Assemble a \flex\ section~1 file@>=
+ @[TeX_( "/table/expandafter{/the/yy(1)}" );@]@;
+
+@ @<Productions for \flex\ section~1 parser@>=
+@G
+sect1:
+ sect1 startconddecl namelist1 {@> @<Add start condition declarations@> @=}
+ | sect1 options {@> @<Add options to section~1@> @=}
+ | {@> @<Create an empty section~1@> @=}
+ | error {@> @<Report an error in section~1 and quit@> @=}
+ ;
+
+startconddecl:
+ SCDECL {@> @<Prepare a state declaration@> @=}
+ | XSCDECL {@> @<Prepare an exclusive state declaration@> @=}
+ ;
+
+namelist1:
+ namelist1 NAME {@> @<Add a name to a list@> @=}
+ | NAME {@> @<Start a \prodstylens{namelist1}{\flexnamespace} with a name@> @=}
+ | error {@> @<Report an error in \prodstylens{namelist1}{\flexnamespace} and quit@> @=}
+ ;
+@g
+
+@ @<Add start condition declarations@>=
+ @[TeX_( "/yy0{/the/yy(1)/nx/flscondecl/the/yy(2){/the/yy(3)}}" );@]@;
+
+@ @<Add options to section~1@>=
+ @[TeX_( "/yy0{/the/yy(1)/the/yy(2)}" );@]@;
+
+@ @<Create an empty section~1@>=
+ @[TeX_( "/yy0{}" );@]@;
+
+@ @<Report an error in section~1 and quit@>=
+ @[TeX_( "/yyerror" );@]@;
+
+@ @<Prepare a state declaration@>=
+ @[TeX_( "/yy0{{s}/the/yy(1)}" );@]@;
+
+@ @<Prepare an exclusive state declaration@>=
+ @[TeX_( "/yy0{{x}/the/yy(1)}" );@]@;
+
+@ @<Add a name to a list@>=
+ @[TeX_( "/yy0{/the/yy(1)/nx/flnamesep{}{}/nx/flname/the/yy(2)}" );@]@;
+
+@ @<Start a \prodstylens{namelist1}{\flexnamespace} with a name@>=
+ @[TeX_( "/yy0{/nx/flname/the/yy(1)}" );@]@;
+
+@ @<Report an error in \prodstylens{namelist1}{\flexnamespace} and quit@>=
+ @[TeX_( "/yyerror" );@]@;
+
+@ @<Productions for \flex\ section~1 parser@>=
+@G
+options:
+ OPTION_OP optionlist {@> @<Start an options list@> @=}
+ | POINTER_OP {@> @<Add a pointer option@> @=}
+ | ARRAY_OP {@> @<Add an array option@> @=}
+ | TOP_OP '\n' {@> @<Add a \prodstylens{\%top}{\flexnamespace} directive@> @=}
+ | DEF_OP RE_DEF {@> @<Add a regular expression definition@> @=}
+ | OPT_DEPRECATED {@> @<Output a deprecated option@> @=}
+ ;
+@t}\vb{\inline\flatten}{@>
+optionlist:
+ optionlist option {@> @<Add an option to a list@> @=}
+ | {@> @<Make an empty option list@> @=}
+ ;
+@t}\vb{\resetf}{@>
+option:
+ OPT_OUTFILE '=' NAME {@> @<Record the name of the output file@> @=}
+ | OPT_EXTRA_TYPE '=' NAME {@> @<Declare an extra type@> @=}
+ | OPT_PREFIX '=' NAME {@> @<Declare a prefix@> @=}
+ | OPT_YYCLASS '=' NAME {@> @<Declare a class@> @=}
+ | OPT_HEADER '=' NAME {@> @<Declare the name of a header@> @=}
+ | OPT_TABLES '=' NAME {@> @<Declare the name for the tables@> @=}
+ | OPT_OTHER {@> @<Output a non-parametric option@> @=}
+ ;
+@g
+
+@ @<Start an options list@>=
+ @[TeX_( "/yy0{/nx/floptions{/the/yy(2)}}" );@]@;
+
+@ @<Add a pointer option@>=
+ @[TeX_( "/yy0{/nx/flptropt/the/yy(1)}" );@]@;
+
+@ @<Add an array option@>=
+ @[TeX_( "/yy0{/nx/flarrayopt/the/yy(1)}" );@]@;
+
+@ @<Add a \prodstylens{\%top}{\flexnamespace} directive@>=
+ @[TeX_( "/yy0{/nx/fltopopt/the/yy(1)/the/yy(2)}" );@]@;
+
+@ @<Add a regular expression definition@>=
+ @[TeX_( "/yy0{/nx/flredef/the/yy(1)/the/yy(2)}" );@]@;
+
+@ @<Add an option to a list@>=
+ @[TeX_( "/yy0{/the/yy(1)/the/yy(2)}" );@]@;
+
+@ @<Make an empty option list@>=
+ @[TeX_( "/yy0{}" );@]@;
+
+@ @<Record the name of the output file@>=
+ @[TeX_( "/yy0{/nx/flopt{file}/the/yy(3)}" );@]@;
+
+@ @<Declare an extra type@>=
+ @[TeX_( "/yy0{/nx/flopt{xtype}/the/yy(3)}" );@]@;
+
+@ @<Declare a prefix@>=
+ @[TeX_( "/yy0{/nx/flopt{prefix}/the/yy(3)}" );@]@;
+
+@ @<Declare a class@>=
+ @[TeX_( "/yy0{/nx/flopt{yyclass}/the/yy(3)}" );@]@;
+
+@ @<Declare the name of a header@>=
+ @[TeX_( "/yy0{/nx/flopt{header}/the/yy(3)}" );@]@;
+
+@ @<Declare the name for the tables@>=
+ @[TeX_( "/yy0{/nx/flopt{tables}/the/yy(3)}" );@]@;
+
+@ @<Output a non-parametric option@>=
+ @[TeX_( "/yy0{/nx/flopt{other}/the/yy(1)}" );@]@;
+
+@ @<Output a deprecated option@>=
+ @[TeX_( "/yy0{/nx/flopt{deprecated}/the/yy(1)}" );@]@;
+
+@ @<Special \flex\ section~2 parser productions@>=
+@G
+goal:
+ sect2 {@> @<Output section~2@> @=}
+ ;
+@g
+
+@ @<Output section~2@>=
+ @[TeX_( "/table/yy(1)" );@]@;
+
+@ This portion of the grammar was changed to make it possible to read the
+action code.
+@<Productions for \flex\ section~2 parser@>=
+@G
+sect2:
+ sect2 scon initforrule flexrule '\n' '\n' {@> @<Add a rule to section~2@> @=}
+ | sect2 scon '{' sect2 '}' {@> @<Add a group of rules to section~2@> @=}
+ | {@> @<Start an empty section~2@> @=}
+ | sect2 '\n' {@> @<Add a bare action@> @=}
+ ;
+@t}\vb{\inline\flatten}{@>
+initforrule:
+ {@> @[TeX_( "/flin@@ruletrue/yylexnext" );@] @=}
+ ;
+@g
+
+@ @<Add a rule to section~2@>=
+ @[TeX_( "/ifflcontinued@@action" );@]@;
+ @[TeX_( " /toksb{/flactionc}" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /toksb{/flaction}" );@]@;
+ @[TeX_( "/fi" );@]@;
+ @[TeX_( "/toksa/expandafter{/astformat@@flaction}" );@]@; /* capture the formatting action */
+ @[TeX_( "/yypushx{/the/yy(1)/the/toksb{/the/yy(2)}{/the/yy(4)}/the/yy(5)/the/yy(6){/the/toksa}}/on/astarray" );@]@;
+ @[TeX_( "/yy0{/astarraylastcs}" );@]@;
+ @[TeX_( "/let/astformat@@flaction/empty" );@]@; /* reset the format */
+
+@ @<Add a group of rules to section~2@>=
+ @[TeX_( "/yy0{/the/yy(1)/nx/flactiongroup{/the/yy(2)}/the/yy(3){/the/yy(4)}/the/yy(5)}" );@]@;
+
+@ @<Start an empty section~2@>=
+ @[TeX_( "/yy0{}" );@]@;
+
+@ @<Add a bare action@>=
+ @[TeX_( "/yy0{/the/yy(1)/nx/flbareaction/the/yy(2)}" );@]@;
+
+@ @<Productions for \flex\ section~2 parser@>=
+@G
+@t}\vb{\inline\flatten}{@>
+scon_stk_ptr:
+ {@> @=}
+ ;
+@t}\vb{\resetf}{@>
+scon:
+ '<' scon_stk_ptr namelist2 '>' {@> @<Create a list of start conditions@> @=}
+ | '<' '*' '>' {@> @<Create a universal start condition@> @=}
+ | {@> @<Create an empty start condition@> @=}
+ ;
+
+namelist2:
+ namelist2 ',' sconname {@> @<Add a start condition to a list@> @=}
+ | sconname {@> @<Start a list with a start condition name@> @=}
+ | error {@> @<Report an error compiling a start condition list@> @=}
+ ;
+@t}\vb{\inline\flatten}{@>
+sconname:
+ NAME {@> @<Make a \prodstylens{NAME}{\flexnamespace} into a start condition@> @=}
+ ;
+
+@ @<Create a list of start conditions@>=
+ @[TeX_( "/yy0{/nx/flsconlist{/the/yy(1)}{/the/yy(3)}{/the/yy(4)}}" );@]@;
+
+@ @<Create a universal start condition@>=
+ @[TeX_( "/yy0{/nx/flsconuniv/the/yy(3)}" );@]@;
+
+@ @<Create an empty start condition@>=
+ @[TeX_( "/yy0{}" );@]@;
+
+@ @<Add a start condition to a list@>=
+ @[TeX_( "/yy0{/the/yy(1)/nx/flnamesep/the/yy(2)/the/yy(3)}" );@]@;
+
+@ @<Start a list with a start condition name@>=
+ @<Copy the value@>@;
+
+@ @<Report an error compiling a start condition list@>=
+ @[TeX_( "/yyerror" );@]@;
+
+@ @<Make a \prodstylens{NAME}{\flexnamespace} into a start condition@>=
+ @[TeX_( "/yy0{/nx/flname/the/yy(1)}" );@]@;
+
+@ @<Productions for \flex\ section~2 parser@>=
+ @<Rules for \flex\ regular expressions@>@;
+
+@ @<Special productions for regular expressions@>=
+@G
+goal:
+ flexrule {@> @<Output a regular expression@> @=}
+ ;
+@g
+
+@ The parsed regular expression is output in the \.{\\table}
+register. It is important to ensure that whenever this parser is used
+inside another parser that uses \.{\\table} for output, the changes to
+this register stay local. The \.{\\frexproc} macro in \.{yyunion.sty}
+ensures that all the changes are local to the parsing macro.
+@<Output a regular expression@>=
+ @[TeX_( "/table/yy(1)" );@]@;
+
+@ @<Rules for \flex\ regular expressions@>=
+@G
+flexrule:
+ '^' rule {@> @<Match a rule at the beginning of the line@> @=}
+ | rule {@> @<Match an ordinary rule@> @=}
+ | EOF_OP {@> @<Match an end of file@> @=}
+ | error {@> @<Report an error and quit@> @=}
+ ;
+
+@ @<Match a rule at the beginning of the line@>=
+ @[TeX_( "/toksa/expandafter{/astformat@@flrule}" );@]@;
+ @[TeX_( "/let/astformat@@flrule/empty" );@]@;
+ @[TeX_( "/yy0{/nx/flbolrule{/the/yy(2)}{/the/toksa}}" );@]@;
+
+@ @<Match an ordinary rule@>=
+ @[TeX_( "/toksa/expandafter{/astformat@@flrule}" );@]@;
+ @[TeX_( "/let/astformat@@flrule/empty" );@]@;
+ @[TeX_( "/yy0{/nx/flrule{/the/yy(1)}{/the/toksa}}" );@]@;
+
+@ @<Match an end of file@>=
+ @[TeX_( "/yy0{/nx/fleof/the/yy(1)}" );@]@;
+
+@ @<Report an error and quit@>=
+ @[TeX_( "/yyerror" );@]@;
+
+@ @<Rules for \flex\ regular expressions@>=
+@G
+rule:
+ re2 re {@> @<Match a regular expression with a trailing context@> @=}
+ | re2 re '$' {@> @<Disallow a repeated trailing context@> @=}
+ | re '$' {@> @<Match a regular expression at the end of the line@> @=}
+ | re {@> @<Match an ordinary regular expression@> @=}
+ ;
+
+re:
+ re '|' series {@> @<Match a sequence of alternatives@> @=}
+ | series {@> @<Match a sequence of singletons@> @=}
+ ;
+@t}\vb{\inline\flatten}{@>
+re2:
+ re '/' {@> @<Prepare to match a trailing context@> @=}
+ ;
+@g
+
+@ @<Match a regular expression with a trailing context@>=
+ @[TeX_( "/getsecond{/yy(1)}/to/toksa/getthird{/yy(1)}/to/toksb" );@]@;
+ @[TeX_( "/yy0{/nx/flretrail{/the/toksa}{/the/toksb}{/the/yy(2)}}" );@]@;
+
+@ @<Disallow a repeated trailing context@>=
+ @[TeX_( "/yyerror" );@]@;
+
+@ @<Match a regular expression at the end of the line@>=
+ @[TeX_( "/yy0{/nx/flreateol{/the/yy(1)}/the/yy(2)}" );@]@;
+
+@ @<Match an ordinary regular expression@>=
+ @<Copy the value@>@;
+
+@ @<Match a sequence of alternatives@>=
+ @[TeX_( "/yy0{/the/yy(1)/nx/flor/the/yy(2)/the/yy(3)}" );@]@;
+
+@ @<Match a sequence of singletons@>=
+ @<Copy the value@>@;
+
+@ @<Prepare to match a trailing context@>=
+ @[TeX_( "/yy0{/nx/fltrail{/the/yy(1)}{/the/yy(2)}}" );@]@;
+
+@ @<Rules for \flex\ regular expressions@>=
+@G
+series:
+ series singleton {@> @<Extend a series by a singleton@> @=}
+ | singleton {@> @<Match a singleton@> @=}
+ | series BEGIN_REPEAT_POSIX
+ NUMBER ',' NUMBER END_REPEAT_POSIX {@> @<Match a series of specific length@> @=}
+ | series BEGIN_REPEAT_POSIX
+ NUMBER ',' END_REPEAT_POSIX {@> @<Match a series of minimal length@> @=}
+ | series BEGIN_REPEAT_POSIX
+ NUMBER END_REPEAT_POSIX {@> @<Match a series of exact length@> @=}
+ ;
+@g
+
+@ @<Extend a series by a singleton@>=
+ @[TeX_( "/yy0{/the/yy(1)/the/yy(2)}" );@]@;
+
+@ @<Match a singleton@>=
+ @<Copy the value@>@;
+
+@ @<Match a series of specific length@>=
+ @<Create a series of specific length@>@;
+
+@ @<Match a series of minimal length@>=
+ @<Create a series of minimal length@>@;
+
+@ @<Match a series of exact length@>=
+ @<Create a series of exact length@>@;
+
+@ @<Rules for \flex\ regular expressions@>=
+@G
+singleton:
+ singleton '*' {@> @<Create a lazy series match@> @=}
+ | singleton '+' {@> @<Create a nonempty series match@> @=}
+ | singleton '?' {@> @<Create a possible single match@> @=}
+ | singleton BEGIN_REPEAT_FLEX
+ NUMBER ',' NUMBER END_REPEAT_FLEX {@> @<Create a series of specific length@> @=}
+ | singleton BEGIN_REPEAT_FLEX
+ NUMBER ',' END_REPEAT_FLEX {@> @<Create a series of minimal length@> @=}
+ | singleton BEGIN_REPEAT_FLEX
+ NUMBER END_REPEAT_FLEX {@> @<Create a series of exact length@> @=}
+ | '.' {@> @<Match (almost) any character@> @=}
+ | fullccl {@> @<Match a character class@> @=}
+ | PREVCCL {@> @<Match a \prodstylens{PREVCCL}{\flexnamespace}@> @=}
+ | '"' string '"' {@> @<Match a string@> @=}
+ | '(' re ')' {@> @<Match an atom@> @=}
+ | CHAR {@> @<Match a specific character@> @=}
+ ;
+@g
+
+@ @<Create a lazy series match@>=
+ @[TeX_( "/yy0{/nx/flrepeat{/the/yy(1)}}" );@]@;
+
+@ @<Create a nonempty series match@>=
+ @[TeX_( "/yy0{/nx/flrepeatstrict{/the/yy(1)}}" );@]@;
+
+@ @<Create a possible single match@>=
+ @[TeX_( "/yy0{/nx/flrepeatonce{/the/yy(1)}}" );@]@;
+
+@ @<Create a series of specific length@>=
+ @[TeX_( "/yy0{/nx/flrepeatnm{/the/yy(1)}{/the/yy(3)}{/the/yy(5)}}" );@]@;
+
+@ @<Create a series of minimal length@>=
+ @[TeX_( "/yy0{/nx/flrepeatgen{/the/yy(1)}{/the/yy(3)}}" );@]@;
+
+@ @<Create a series of exact length@>=
+ @[TeX_( "/yy0{/nx/flrepeatn{/the/yy(1)}{/the/yy(3)}}" );@]@;
+
+@ @<Match (almost) any character@>=
+ @[TeX_( "/yy0{/nx/fldot/the/yy(1)}" );@]@;
+
+@ @<Match a character class@>=
+ @<Copy the value@>@;
+
+@ @<Match a \prodstylens{PREVCCL}{\flexnamespace}@>=
+ @<Copy the value@>@;
+
+@ @<Match a string@>=
+ @[TeX_( "/yy0{/nx/flstring{/the/yy(1)}{/the/yy(2)}{/the/yy(3)}}" );@]@;
+
+@ @<Match an atom@>=
+ @[TeX_( "/toksa/expandafter{/astformat@@flparens}" );@]@;
+ @[TeX_( "/let/astformat@@flparens/empty" );@]@;
+ @[TeX_( "/yy0{/nx/flparens{/the/yy(1)}{/the/yy(2)}{/the/yy(3)}{/the/toksa}}" );@]@;
+
+@ @<Match a specific character@>=
+ @[TeX_( "/yy0{/nx/flchar/the/yy(1)}" );@]@;
+
+@ @<Rules for \flex\ regular expressions@>=
+@G
+fullccl:
+ fullccl CCL_OP_DIFF braceccl {@> @<Subtract a character class@> @=}
+ | fullccl CCL_OP_UNION braceccl {@> @<Create a union of character classes@> @=}
+ | braceccl {@> @<Turn a basic character class into a character class@> @=}
+ ;
+
+braceccl:
+ '[' ccl ']' {@> @<Create a character class@> @=}
+ | '[' '^' ccl ']' {@> @<Create a complementary character class@> @=}
+ ;
+
+ccl:
+ ccl CHAR '-' CHAR {@> @<Add a range to a character class@> @=}
+ | ccl CHAR {@> @<Add a character to a character class@> @=}
+ | ccl ccl_expr {@> @<Add an expression to a character class@> @=}
+ | {@> @<Create an empty character class@> @=}
+ ;
+@g
+
+@ @<Subtract a character class@>=
+ @[TeX_( "/yy0{/nx/flccldiff{/the/yy(1)}{/the/yy(3)}}" );@]@;
+
+@ @<Create a union of character classes@>=
+ @[TeX_( "/yy0{/nx/flcclunion{/the/yy(1)}{/the/yy(3)}}" );@]@;
+
+@ @<Turn a basic character class into a character class@>=
+ @<Copy the value@>@;
+
+@ @<Create a character class@>=
+ @[TeX_( "/yy0{/nx/flbraceccl{/the/yy(1)}{/the/yy(2)}{/the/yy(3)}}" );@]@;
+
+@ @<Create a complementary character class@>=
+ @[TeX_( "/yy0{/nx/flbracecclneg{/the/yy(1)}{/the/yy(3)}{/the/yy(4)}}" );@]@;
+
+@ @<Add a range to a character class@>=
+ @[TeX_( "/yy0{/the/yy(1)/nx/flcclrnge{/nx/flchar/the/yy(2)}{/nx/flchar/the/yy(4)}}" );@]@;
+
+@ @<Add a character to a character class@>=
+ @[TeX_( "/yy0{/the/yy(1)/nx/flchar/the/yy(2)}" );@]@;
+
+@ @<Add an expression to a character class@>=
+ @[TeX_( "/yy0{/the/yy(1)/nx/flcclexpr/the/yy(2)}" );@]@;
+
+@ @<Create an empty character class@>=
+ @[TeX_( "/yy0{}" );@]@;
+
+@ @<Rules for \flex\ regular expressions@>=
+@G
+ccl_expr:
+@t}\vb{\flatten}{@>
+ CCE_ALNUM {@> @<Copy the value@> @=}
+ | CCE_ALPHA {@> @<Copy the value@> @=}
+ | CCE_BLANK {@> @<Copy the value@> @=}
+ | CCE_CNTRL {@> @<Copy the value@> @=}
+ | CCE_DIGIT {@> @<Copy the value@> @=}
+ | CCE_GRAPH {@> @<Copy the value@> @=}
+ @t}\vb{\fold\flatten}{@>
+ | CCE_LOWER {@> @<Copy the value@> @=}
+ | CCE_PRINT {@> @<Copy the value@> @=}
+ | CCE_PUNCT {@> @<Copy the value@> @=}
+ | CCE_SPACE {@> @<Copy the value@> @=}
+ | CCE_XDIGIT {@> @<Copy the value@> @=}
+ | CCE_UPPER {@> @<Copy the value@> @=}
+@t}\vb{\fold\flatten}{@>
+ | CCE_NEG_ALNUM {@> @<Copy the value@> @=}
+ | CCE_NEG_ALPHA {@> @<Copy the value@> @=}
+ | CCE_NEG_BLANK {@> @<Copy the value@> @=}
+ | CCE_NEG_CNTRL {@> @<Copy the value@> @=}
+ | CCE_NEG_DIGIT {@> @<Copy the value@> @=}
+ | CCE_NEG_GRAPH {@> @<Copy the value@> @=}
+ @t}\vb{\fold\flatten}{@>
+ | CCE_NEG_PRINT {@> @<Copy the value@> @=}
+ | CCE_NEG_PUNCT {@> @<Copy the value@> @=}
+ | CCE_NEG_SPACE {@> @<Copy the value@> @=}
+ | CCE_NEG_XDIGIT {@> @<Copy the value@> @=}
+ | CCE_NEG_LOWER {@> @<Copy the value@> @=}
+ | CCE_NEG_UPPER {@> @<Copy the value@> @=}
+ ;
+@t}\vb{\inline}{@>
+string:
+ string CHAR {@> @<Extend a \flex\ string by a character@> @=}
+ | {@> @<Make an empty regular expression string@> @=}
+ ;
+@g
+
+@ @<Copy the value@>=
+ @[TeX_( "/yy0{/the/yy(1)}" );@]@;
+
+@ @<Extend a \flex\ string by a character@>=
+ @[TeX_( "/yy0{/the/yy(1)/nx/flchar/the/yy(2)}" );@]@;
+
+@ @<Make an empty regular expression string@>=
+ @[TeX_( "/yy0{}" );@]@;
+
+@ This is needed to get the |yytoknum| array. A trivial declaration suffices.
+@<Postamble for \flex\ parser@>=
+#define YYPRINT(file, type, value) @[yyprint (file, type, value)@]
+ static void yyprint (FILE *file, int type, YYSTYPE value){}
diff --git a/support/splint/cweb/lo.w b/support/splint/cweb/lo.w
index b28711423c..68ef1b6595 100644
--- a/support/splint/cweb/lo.w
+++ b/support/splint/cweb/lo.w
@@ -1,4 +1,4 @@
-@q Copyright 2012-2014 Alexander Shibakov@>
+@q Copyright 2012-2020 Alexander Shibakov@>
@q Copyright 2002-2014 Free Software Foundation, Inc.@>
@q This file is part of SPLinT@>
@@ -15,20 +15,21 @@
@q You should have received a copy of the GNU General Public License@>
@q along with SPLinT. If not, see <http://www.gnu.org/licenses/>.@>
-@*1 The scanner for grammar syntax.
-\ifx\parsernamespace\UNDEFINED
+@**The scanner for \ifx\bison\UNDEFINED\.{bison}\else\bison\fi\ syntax.
+\ifx\bison\UNDEFINED
\input limbo.sty
\input grabstates.sty
\immediate\openout\stlist=lo_states.h
\fi
The fact that \bison\ has a relatively straightforward grammar is
-due to the sophistication of its scanner. The primary reason for this
+partly due to the sophistication of its scanner. The primary reason for this
increased complexity is \bison's awareness
of syntax variations in its input files. In addition to the grammar
syntax, the parser has to be able to deal with extended \Cee\ syntax
inside \bison's actions.
-Since the names of the scanner {\it states\/} reside in the common
+Since the names\namedspot{state.grabbing} of the scanner
+{\em states@^scanner states@>\/} reside in the common
namespace with other variables, in order to make the \TeX\ version of
the scanner aware of the numerical values of the states, a special
procedure is required. It is executed as part of \flex's user
@@ -52,10 +53,11 @@ void define_all_states( void ) {
@o
@g
-@ It is convenient to abbreviate some commonly used subexpressions.
+@*1 Definitions and state declarations.
+It is convenient to abbreviate some commonly used subexpressions.
@<Grammar lexer definitions@>=
@<Grammar lexer states@>@;
-@G
+@G(fs1)
letter [.abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_]
notletter [^.abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_]{-}[%\{]
id {letter}({letter}|[-0-9])*
@@ -65,14 +67,14 @@ int [0-9]+
@ {\it Zero or more instances of backslash-newline. Following \gcc, allow
white space between the backslash and the newline}.
@<Grammar lexer definitions@>=
-@G
+@G(fs1)
splice (\\[ \f\t\v]*\n)*
@g
@ {\it An equal sign, with optional leading whitespaces. This is used in some
deprecated constructs}.
@<Grammar lexer definitions@>=
-@G
+@G(fs1)
eqopt ([[:space:]]*=)?
@g
@@ -81,7 +83,7 @@ routine mentioned above. The state information is collected by a
special small scanner that is coupled with the bootstrap parser. This
way, all the necessary token information comes `hardwired' in the
bootstrap parser, and the small scanner itself does not use any state
-manipulation and thus can get away without any state setup. It can,
+manipulation and thus can get away with using no state setup. It can,
however, scan just enough of the \flex\ syntax to extract the state
information from it (only the state {\it names\/} are needed) and
output it in the form of a header file for the `real' lexer output
@@ -98,6 +100,19 @@ output it in the form of a header file for the `real' lexer output
@g
@ {\it Strings and characters in directives/rules}.
+%\yyflexdebugtrue
+%\traceparserstatestrue
+%\tracestackstrue
+%\tracerulestrue
+%\traceactionstrue
+%\tracebadcharstrue
+%\prodstyle{\%\%}%
+\traceparserstatesfalse
+\tracestacksfalse
+\tracerulesfalse
+\traceactionsfalse
+\tracebadcharsfalse
+\yyflexdebugfalse
@<Grammar lexer states@>=
@G
%x SC_ESCAPED_STRING SC_ESCAPED_CHARACTER
@@ -139,7 +154,7 @@ Four types of user code:
%x SC_PROLOGUE SC_BRACED_CODE SC_EPILOGUE SC_PREDICATE
@g
-@ {\it \Cee\ and \Cee++ comments in code}.
+@ {\it \Cee\ and \Ceepp\ comments in code}.
@<Grammar lexer states@>=
@G
%x SC_COMMENT SC_LINE_COMMENT
@@ -175,8 +190,8 @@ adopted in this package to work.
%option outfile="lo.c"
@g
-@*2 Tokenizing with regular expressions.
-Here is a full collection of regular expressions employed by the scanner.
+@*1 Tokenizing with regular expressions.
+Here is a full list of regular expressions recognized by the \bison\ scanner.
@<Grammar token regular expressions@>=
@<Scan grammar white space@>@;
@<Scan \flex\ directives and options@>@;
@@ -184,7 +199,7 @@ Here is a full collection of regular expressions employed by the scanner.
@<Do not support zero characters@>@;
@<Scan after an identifier, check whether a colon is next@>@;
@<Scan bracketed identifiers@>@;
- @<Scan a Yacc comment@>@;
+ @<Scan a \yacc\ comment@>@;
@<Scan a \Cee\ comment@>@;
@<Scan a line comment@>@;
@<Scan a \bison\ string@>@;
@@ -199,15 +214,17 @@ Here is a full collection of regular expressions employed by the scanner.
@<Add the scanned symbol to the current string@>@;
@ @<Scan grammar white space@>=
-@G
+@G(fs2)
<INITIAL,SC_AFTER_IDENTIFIER,SC_BRACKETED_ID,SC_RETURN_BRACKETED_ID>
{
- /* {\it Comments and white space.} */
- "," {@> @[TeX_( "/yycomplain{stray `,' treated as white space}/yylexnext" );@]@=}
- [ \f\n\t\v] |
+@t}\vb{\insertraw{\inscomment{\it comments and white space}}}{@>
+ "," {@> @[TeX_( "/yywarn{stray `,' treated as white space}" );@]@=}
+ [ \f\n\t\v] |
"//".* {@> @[TeX_( "/yylexnext" );@]@=}
@= "/*" {@> @[TeX_( "/contextstate/YYSTART /yyBEGIN{SC_YACC_COMMENT}/yylexnext" );@]@=}@>@/
- /* {\it |@[#line@]| directives are not documented, and may be withdrawn or modified in future versions of \bison.} */
+
+@t}\vb{\insertraw{\inscomment{\it \.{\#line} directives are not documented, and may be withdrawn or modified in future versions of \bison}}}{@>
+
^"#line "{int}(" \"".*"\"")?"\n" {@> @[TeX_( "/yylexnext" );@]@=}
}
@g
@@ -219,7 +236,7 @@ to \.{../build-aux/cross-options.pl}}. For most options the scanner
returns a pair of pointers as the value.
@<Scan \bison\ directives@>=
-@G
+@G(fs2)
<INITIAL>
{
"%binary" {@> @[TeX_( "/yylexreturnptr{PERCENT_NONASSOC}" );@]@=}
@@ -267,8 +284,7 @@ returns a pair of pointers as the value.
"%union" {@> @[TeX_( "/yylexreturnptr{PERCENT_UNION}" );@]@=}
"%verbose" {@> @[TeX_( "/yylexreturnptr{PERCENT_VERBOSE}" );@]@=}
"%yacc" {@> @[TeX_( "/yylexreturnptr{PERCENT_YACC}" );@]@=}
-
- /* {\it deprecated} */
+@t}\vb{\insertraw{\inscomment{\it deprecated}}}{@>
"%default"[-_]"prec" {@> @[TeX_( "/yypdeprecated{\\%default-prec}" );@]@=}
"%error"[-_]"verbose" {@> @[TeX_( "/yypdeprecated{\\%define parse.error verbose}" );@]@=}
"%expect"[-_]"rr" {@> @[TeX_( "/yypdeprecated{\\%expect-rr}" );@]@=}
@@ -281,50 +297,44 @@ returns a pair of pointers as the value.
"%pure"[-_]"parser" {@> @[TeX_( "/yypdeprecated{\\%pure-parser}" );@]@=}
"%token"[-_]"table" {@> @[TeX_( "/yypdeprecated{\\%token-table}" );@]@=}
- /* {\it Semantic predicate.} */
+@t}\vb{\insertraw{\inscomment{\it semantic predicate}}}{@>
+
"%?"[ \f\n\t\v]*"{" {@> @[TeX_( "/yyBEGIN{SC_PREDICATE}/yylexnext" );@]@=}
- "%"{id}|"%"{notletter}([[:graph:]])+ {@> @[@<Possbly complain about a bad directive@>@]@=}
+ "%"{id}|"%"{notletter}([[:graph:]])+ {@> @[@<Possibly complain about a bad directive@>@]@=}
"=" {@> @[TeX_( "/yylexreturnptr{EQUAL}" );@]@=}
"|" {@> @[TeX_( "/yylexreturnptr{PIPE}" );@]@=}
";" {@> @[TeX_( "/yylexreturnptr{SEMICOLON}" );@]@=}
{id} {@> @[@<Prepare an identifier@>@]@=}
- {int} {@> @[TeX_( "/edef/next{/yylval{/nx/anint{/the/yytext}" );@]@;
- @> @[TeX_( "{/the/yyfmark}{/the/yysmark}}}/next" );@]@;
+ {int} {@> @[TeX_( "/edef/next{/yylval{/nx/anint{/the/yytext}" );@]@=
+ @> @[TeX_( " {/the/yyfmark}{/the/yysmark}}}/next" );@]@=
@> @[TeX_( "/yylexreturn{INT}" );@]@=}
- 0[xX][0-9abcdefABCDEF]+ {@> @[TeX_( "/edef/next{/yylval{/nx/hexint{/the/yytext}" );@]@;
- @> @[TeX_( "{/the/yyfmark}{/the/yysmark}}}/next" );@]@;
+ 0[xX][0-9abcdefABCDEF]+ {@> @[TeX_( "/edef/next{/yylval{/nx/hexint{/the/yytext}" );@]@=
+ @> @[TeX_( " {/the/yyfmark}{/the/yysmark}}}/next" );@]@=
@> @[TeX_( "/yylexreturn{INT}" );@]@=}
-
- /* {\it Identifiers may not start with a digit. Yet, don't silently accept \.{1FOO} as \.{1 FOO}.} */
- {int}{id} {@> @[TeX_( "/yycomplain{invalid identifier: /the/yytext}" );@]
- @> @[TeX_( "/yyerrterminate" );@]@=}
-
- /* {\it Characters.} */
+@t}\vb{\insertraw{\inscomment{\it identifiers may not start with a digit; yet, don't silently accept \.{1foo} as \.{1 foo}}}}{@>
+ {int}{id} {@> @[TeX_( "/yyfatal{invalid identifier: /the/yytext}" );@]@=}
+@t}\vb{\insertraw{\inscomment{\it characters}}}{@>
"'" {@> @[TeX_( "/yyBEGIN{SC_ESCAPED_CHARACTER}/yylexnext" );@]@=}
-
- /* {\it Strings.} */
+@t}\vb{\insertraw{\inscomment{\it strings}}}{@>
"\"" {@> @[TeX_( "/yyBEGIN{SC_ESCAPED_STRING}/yylexnext" );@]@=}
-
- /* {\it Prologue.} */
+@t}\vb{\insertraw{\inscomment{\it prologue}}}{@>
"%{" {@> @[@<Start assembling prologue code@>@]@=}
-
- /* {\it Code in between braces.} Originally preceded by \.{\\STRINGGROW} but it is omitted here. */
+@t}\vb{\insertraw{\inscomment{{\it code in between braces}; originally preceded by \.{\\STRINGGROW} but it is omitted here}}}{@>
"{" {@> @[TeX_( "/lonesting/z@@/yyBEGIN{SC_BRACED_CODE}/yylexnext" );@]@=}
-
- /* {\it A type.} */
+@t}\vb{\insertraw{\inscomment{\it a type}}}{@>
"<*>" {@> @[TeX_( "/yylexreturnptr{TAG_ANY}" );@]@=}
"<>" {@> @[TeX_( "/yylexreturnptr{TAG_NONE}" );@]@=}
"<" {@> @[TeX_( "/lonesting=/z@@/yyBEGIN{SC_TAG}/yylexnext" );@]@=}
"%%" {@> @[@<Switch sections@>@]@=}
- "[" {@> @[TeX_( "/let/bracketedidstr=/empty" );@]@;
+ "[" {@> @[TeX_( "/let/bracketedidstr=/empty" );@]
@> @[TeX_( "/bracketedidcontextstate/YYSTART" );@]
@> @[TeX_( "/yyBEGIN{SC_BRACKETED_ID}/yylexnext" );@]@=}
- <<EOF>> {@> @[TeX_( "/yyterminate% EOF in INITIAL" );@]@=}
+ <<EOF>> {@> @[TeX_( "/yyterminate" );@]/* \flexrenstyle{EOF} in \flexsnstyle{INITIAL} */@=}
[^\[%A-Za-z0-9_<>{}\"\'*;|=/, \f\n\t\v]+|. {@> @[@<Process a bad character@>@]@=}
}
@@ -333,7 +343,7 @@ returns a pair of pointers as the value.
@ Some additional constructs needed to typeset simple \flex\
declarations. This is not part of the original \bison\ scanner.
@<Scan \flex\ directives and options@>=
-@G
+@G(fs2)
<INITIAL>
{
"%option" {@> @[TeX_( "/yylexreturnptr{FLEX_OPTION}" );@]@=}
@@ -348,9 +358,8 @@ of the character matching by the rest of the lexer.
@[TeX_( "/edef/next{/nx/csname lexspecial[/the/yytextpure]/nx/endcsname}" );@]@;
@[TeX_( "/expandafter/expandafter/expandafter/ifx/next/relax" );@]@;
@[TeX_( " /iftracebadchars" );@]@;
- @[TeX_( " /yycomplain{invalid character(s): /the/yytext}" );@]@;
+ @[TeX_( " /yyfatal{invalid character(s): /the/yytext}" );@]@;
@[TeX_( " /fi" );@]@;
- @[TeX_( " /yylexreturn{$undefined}" );@]@;
@[TeX_( "/else" );@]@;
@[TeX_( " /expandafter/lexspecialchar/expandafter{/next}{/the/yyfmark}{/the/yysmark}/yylexnext" );@]@;
@[TeX_( "/fi" );@]@;
@@ -379,14 +388,15 @@ of the character matching by the rest of the lexer.
@[TeX_( "/edef/next{/yylval{{api.pure}{pure-parser}{/the/yyfmark}{/the/yysmark}}}/next" );@]@;
@[TeX_( "/yylexreturn{PERCENT_FLAG}" );@]@;
-@ @<Possbly complain about a bad directive@>=
+@ @<Possibly complain about a bad directive@>=
@[TeX_( "/iftracebadchars" );@]@;
- @[TeX_( " /yycomplain{invalid directive: /the/yytext}" );@]@;
+ @[TeX_( " /yywarn{invalid directive: /the/yytext}" );@]@;
@[TeX_( "/fi" );@]@;
- @[TeX_( "/yylexnext" );@]@;
-@ @<Prepare an identifier@>=
- @[TeX_( "/edef/next{/yylval{/nx/idit{/the/yytextpure}{/the/yytext}" );@]@;
+@ At this point we save the spelling and the location of the identifier. The token is returned
+later, after the context is known.
+@<Prepare an identifier@>=
+ @[TeX_( "/edef/next{/yylval{{/the/yytextpure}{/the/yytext}" );@]@;
@[TeX_( " {/the/yyfmark}{/the/yysmark}}}/next" );@]@;
@[TeX_( "/let/bracketedidstr=/empty" );@]@;
@[TeX_( "/yyBEGIN{SC_AFTER_IDENTIFIER}/yylexnext" );@]@;
@@ -402,18 +412,18 @@ of the character matching by the rest of the lexer.
@[TeX_( "/edef/next{/postoks{{/the/yyfmark}{/the/yysmark}}}/next" );@]@;
@[TeX_( "/yyBEGIN{SC_PROLOGUE}/yylexnext" );@]@;
-@ {\it Supporting \.{\\0} complexifies our implementation for no expected added value}.
+@ {\it Supporting \flexrestyle{\\0} complexifies our implementation for no expected added value}.
@<Do not support zero characters@>=
-@G
+@G(fs2)
<SC_ESCAPED_CHARACTER,SC_ESCAPED_STRING,SC_TAG>
{
- \0 {@> @[TeX_( "/yycomplain{invalid null character}/yylexnext" );@]@=}
+ \0 {@> @[TeX_( "/yywarn{invalid null character}" );@]@=}
}
@g
@ @<Scan after an identifier, check whether a colon is next@>=
-@G
+@G(fs2)
<SC_AFTER_IDENTIFIER>
{
"[" {@> @[@<Process the bracketed part of an identifier@>@]@=}
@@ -461,7 +471,7 @@ of the character matching by the rest of the lexer.
@[TeX_( "/yylexreturn{ID}" );@]@;
@ @<Scan bracketed identifiers@>=
-@G
+@G(fs2)
<SC_BRACKETED_ID>
{
<<EOF>> {@> @[@<Complain about unexpected end of file inside brackets@>@]@=}
@@ -473,19 +483,19 @@ of the character matching by the rest of the lexer.
@ @<Process bracketed identifier@>=
@[TeX_( "/ifx/bracketedidstr/empty" );@]@;
- @[TeX_( " /edef/bracketedidstr{/nx/idit{/the/yytextpure}" );@]@;
- @[TeX_( " {/the/yytext}{/the/yyfmark}{/the/yysmark}}" );@]@;
+ @[TeX_( " /edef/bracketedidstr{{/the/yytextpure}{/the/yytext}" );@]@;
+ @[TeX_( " {/the/yyfmark}{/the/yysmark}}" );@]@;
@[TeX_( " /let/next=/yylexnext" );@]@;
@[TeX_( "/else" );@]@;
- @[TeX_( " /def/next{/yycomplain{unexpected " );@]@;
- @[TeX_( " identifier in bracketed name: /the/yytext}/yylexnext}" );@]@;
+ @[TeX_( " /def/next{/yywarn{unexpected identifier " );@]@;
+ @[TeX_( " in bracketed name: /the/yytext}}" );@]@;
@[TeX_( "/fi" );@]@;
@[TeX_( "/next" );@]@;
@ @<Finish processing bracketed identifier@>=
@[TeX_( "/yyBEGINr/bracketedidcontextstate" );@]@;
@[TeX_( "/ifx/bracketedidstr/empty" );@]@;
- @[TeX_( " /def/next{/yycomplain{an identifier expected}/yylexnext}" );@]@;
+ @[TeX_( " /def/next{/yywarn{an identifier expected}}" );@]@;
@[TeX_( "/else" );@]@;
@[TeX_( " /ifnum/bracketedidcontextstate=/yylexstate{INITIAL}/relax" );@]@;
@[TeX_( " /expandafter/yylval/expandafter{/bracketedidstr}" );@]@;
@@ -498,14 +508,14 @@ of the character matching by the rest of the lexer.
@[TeX_( "/next" );@]@;
@ @<Complain about improper identifier characters@>=
- @[TeX_( "/yycomplain{invalid character(s) in bracketed name: /the/yytext}/yyerrterminate" );@]@;
+ @[TeX_( "/yyfatal{invalid character(s) in bracketed name: /the/yytext}" );@]@;
@ @<Complain about unexpected end of file inside brackets@>=
@[TeX_( "/yyBEGINr/bracketedidcontextstate" );@]@;
- @[TeX_( "/yycomplain{unexpected end of file inside brackets}/yyerrterminate" );@]@;
+ @[TeX_( "/yyfatal{unexpected end of file inside brackets}" );@]@;
@ @<Scan bracketed identifiers@>=
-@G
+@G(fs2)
<SC_RETURN_BRACKETED_ID>
{
. {@> @[@<Return a bracketed identifier@>@]@=}
@@ -519,32 +529,30 @@ of the character matching by the rest of the lexer.
@[TeX_( "/yyBEGIN{INITIAL}" );@]@;
@[TeX_( "/yylexreturn{BRACKETED_ID}" );@]@;
-@ {\it Scanning a Yacc comment. The initial \.{/*} is already eaten}.
-@<Scan a Yacc comment@>=
-@G
+@ {\it Scanning a \yacc\ comment. The initial \.{/*} is already eaten}.
+@<Scan a \yacc\ comment@>=
+@G(fs2)
<SC_YACC_COMMENT>
{
- <<EOF>> {@> @[TeX_( "/yycomplain{unexpected end of file in " );@]
- @> @[TeX_( " a comment}/yyerrterminate" );@]@=}
- "*/" {@> @[TeX_( "/yyBEGINr{/contextstate}/yylexnext" );@]@=}
+ <<EOF>> {@> @[TeX_( "/yyfatal{unexpected end of file in a comment}" );@]@=}
+ "*/" {@> @[TeX_( "/yyBEGINr/contextstate /yylexnext" );@]@=}
.|\n {@> @[TeX_( "/yylexnext" );@]@=}
}
@g
@ {\it Scanning a \Cee\ comment. The initial \.{/*} is already eaten}.
@<Scan a \Cee\ comment@>=
-@G
+@G(fs2)
<SC_COMMENT>
{
- <<EOF>> {@> @[TeX_( "/yycomplain{unexpected end of file in " );@]
- @> @[TeX_( " a comment}/yyerrterminate" );@]@=}
- "*"{splice}"/" {@> @[TeX_( "/STRINGGROW/yyBEGINr/contextstate/yylexnext" );@]@=}
+ <<EOF>> {@> @[TeX_( "/yyfatal{unexpected end of file in a comment}" );@]@=}
+ "*"{splice}"/" {@> @[TeX_( "/STRINGGROW/yyBEGINr/contextstate /yylexnext" );@]@=}
}
@g
@ {\it Scanning a line comment. The initial \.{//} is already eaten}.
@<Scan a line comment@>=
-@G
+@G(fs2)
<SC_LINE_COMMENT>
{
<<EOF>> {@> @[TeX_( "/yyBEGINr/contextstate /ROLLBACKCURRENTTOKEN" );@]
@@ -557,41 +565,37 @@ of the character matching by the rest of the lexer.
@ {\it Scanning a \bison\ string, including its escapes.
The initial quote is already eaten}.
@<Scan a \bison\ string@>=
-@G
+@G(fs2)
<SC_ESCAPED_STRING>
{
- <<EOF>> {@> @[TeX_( "/yycomplain{unexpected end of file in " );@]
- @> @[TeX_( " a string}/yyerrterminate" );@]@=}
+ <<EOF>> {@> @[TeX_( "/yyfatal{unexpected end of file in a string}" );@]@=}
"\"" {@> @[@<Finish a \bison\ string@>@]@=}
- "\n" {@> @[TeX_( "/yycomplain{unexpected end of line in " );@]
- @> @[TeX_( " a string}/yyerrterminate" );@]@=}
+ "\n" {@> @[TeX_( "/yyfatal{unexpected end of line in a string}" );@]@=}
}
@g
@ @<Finish a \bison\ string@>=
@[TeX_( "/STRINGFINISH" );@]@;
- @[TeX_( "/edef/next{/yylval{/nx/stringify{/the/laststring}" );@]@;
- @[TeX_( "{/the/laststringraw}{/the/yyfmark}{/the/yysmark}}}/next" );@]@;
+ @[TeX_( "/edef/next{/yylval{{/the/laststring}{/the/laststringraw}" );@]@;
+ @[TeX_( " {/the/yyfmark}{/the/yysmark}}}/next" );@]@;
@[TeX_( "/yyBEGIN{INITIAL}" );@]@;
@[TeX_( "/yylexreturn{STRING}" );@]@;
@ {\it Scanning a \bison\ character literal, decoding its escapes.
The initial quote is already eaten}.
@<Scan a character literal@>=
-@G
+@G(fs2)
<SC_ESCAPED_CHARACTER>
{
- <<EOF>> {@> @[TeX_( "/yycomplain{unexpected end of file in " );@]
- @> @[TeX_( " a literal}/yyerrterminate" );@]@=}
+ <<EOF>> {@> @[TeX_( "/yyfatal{unexpected end of file in a literal}" );@]@=}
"'" {@> @[@<Return an escaped character@>@]@=}
- "\n" {@> @[TeX_( "/yycomplain{unexpected end of line in " );@]
- @> @[TeX_( " a literal}/yyerrterminate" );@]@=}
+ "\n" {@> @[TeX_( "/yyfatal{unexpected end of line in a literal}" );@]@=}
}
@g
@ @<Return an escaped character@>=
@[TeX_( "/STRINGFINISH" );@]@;
- @[TeX_( "/edef/next{/yylval{/nx/charit{/the/laststring}{/the/laststringraw}" );@]@;
+ @[TeX_( "/edef/next{/yylval{{/the/laststring}{/the/laststringraw}" );@]@;
@[TeX_( " {/the/yyfmark}{/the/yysmark}}}/next" );@]@;
@[TeX_( "/STRINGFREE" );@]@;
@[TeX_( "/yyBEGIN{INITIAL}" );@]@;
@@ -599,14 +603,13 @@ The initial quote is already eaten}.
@ {\it Scanning a tag. The initial angle bracket is already eaten}.
@<Scan a tag@>=
-@G
+@G(fs2)
<SC_TAG>
{
">" {@> @[@<Finish a tag@>@]@=}
([^<>]|->)+ {@> @[TeX_( "/STRINGGROW/yylexnext" );@]@=}
"<" {@> @[@<Raise nesting level@>@]@=}
- <<EOF>> {@> @[TeX_( "/yycomplain{unexpected end of file in " );@]
- @> @[TeX_( " a literal}/yyerrterminate" );@]@=}
+ <<EOF>> {@> @[TeX_( "/yyfatal{unexpected end of file in a literal}" );@]@=}
}
@g
@@ -614,7 +617,7 @@ The initial quote is already eaten}.
@[TeX_( "/advance/lonesting/m@@ne" );@]@;
@[TeX_( "/ifnum/lonesting</z@@" );@]@;
@[TeX_( " /STRINGFINISH" );@]@;
- @[TeX_( " /edef/next{/yylval{/nx/tagit{/the/laststring}{/the/laststringraw}" );@]@;
+ @[TeX_( " /edef/next{/yylval{{/the/laststring}{/the/laststringraw}" );@]@;
@[TeX_( " {/the/yyfmark}{/the/yysmark}}}/next" );@]@;
@[TeX_( " /STRINGFREE" );@]@;
@[TeX_( " /yyBEGIN{INITIAL}" );@]@;
@@ -632,7 +635,7 @@ so it makes sense to raise the nesting level one by one.
@[TeX_( "/yylexnext" );@]@;
@ @<Decode escaped characters@>=
-@G
+@G(fs2)
<SC_ESCAPED_STRING,SC_ESCAPED_CHARACTER>
{
\\[0-7]{1,3} {@> @[TeX_( "/STRINGGROW/yylexnext" );@]@=}
@@ -645,17 +648,16 @@ so it makes sense to raise the nesting level one by one.
\\t {@> @[TeX_( "/STRINGGROW/yylexnext" );@]@=}
\\v {@> @[TeX_( "/STRINGGROW/yylexnext" );@]@=}
- /* {\it \.{\\\\[\\"\\'?\\\\]} would be shorter, but it confuses |xgettext|.} */
+ /* {\it \flexrestyle{\\\\[\\"\\'?\\\\]} is shorter but confuses |xgettext|} */
\\("\""|"'"|"?"|"\\") {@> @[TeX_( "/STRINGGROW/yylexnext" );@]@=}
\\(u|U[0-9abcdefABCDEF]{4})[0-9abcdefABCDEF]{4} {@> @[TeX_( "/STRINGGROW/yylexnext" );@]@=}
- \\(.|\n) {@> @[TeX_( "/yycomplain{invalid character after " );@]
- @> @[TeX_( " /\\-escape: /the/yytext}/yylexnext" );@]@=}
+ \\(.|\n) {@> @[TeX_( "/yyfatal{invalid character after /\\: /the/yytext}" );@]@=}
}
@g
@ @<Scan user-code characters and strings@>=
-@G
+@G(fs2)
<SC_CHARACTER,SC_STRING>
{
{splice}|\\{splice}[^\n\[\]] {@> @[TeX_( "/STRINGGROW/yylexnext" );@]@=}
@@ -663,42 +665,34 @@ so it makes sense to raise the nesting level one by one.
<SC_CHARACTER>
{
- "'" {@> @[TeX_( "/STRINGGROW /yyBEGINr{/contextstate}/yylexnext" );@]@=}
- \n {@> @[TeX_( "/yycomplain{unexpected end of line instead of " );@]
- @> @[TeX_( " a character}/yyerrterminate" );@]@=}
- <<EOF>> {@> @[TeX_( "/yycomplain{unexpected end of file instead of " );@]
- @> @[TeX_( " a character}/yyerrterminate" );@]@=}
+ "'" {@> @[TeX_( "/STRINGGROW /yyBEGINr/contextstate /yylexnext" );@]@=}
+ \n {@> @[TeX_( "/yyfatal{unexpected end of line instead of a character}" );@]@=}
+ <<EOF>> {@> @[TeX_( "/yyfatal{unexpected end of file instead of a character}" );@]@=}
}
<SC_STRING>
{
- "\"" {@> @[TeX_( "/STRINGGROW /yyBEGINr{/contextstate}/yylexnext" );@]@=}
- \n {@> @[TeX_( "/yycomplain{unexpected end of line instead of " );@]
- @> @[TeX_( " a character}/yyerrterminate" );@]@=}
- <<EOF>> {@> @[TeX_( "/yycomplain{unexpected end of file instead of " );@]
- @> @[TeX_( " a character}/yyerrterminate" );@]@=}
+ "\"" {@> @[TeX_( "/STRINGGROW /yyBEGINr/contextstate /yylexnext" );@]@=}
+ \n {@> @[TeX_( "/yyfatal{unexpected end of line instead of a character}" );@]@=}
+ <<EOF>> {@> @[TeX_( "/yyfatal{unexpected end of file instead of a character}" );@]@=}
}
@g
@ @<Strings, comments etc.\ found in user code@>=
-@G
+@G(fs2)
<SC_BRACED_CODE,SC_PROLOGUE,SC_EPILOGUE,SC_PREDICATE>
{
- "'" {@> @[TeX_( "/STRINGGROW /contextstate/YYSTART" );@]
- @> @[TeX_( " /yyBEGIN{SC_CHARACTER}/yylexnext" );@]@=}
- "\"" {@> @[TeX_( "/STRINGGROW /contextstate/YYSTART" );@]
- @> @[TeX_( " /yyBEGIN{SC_STRING}/yylexnext" );@]@=}
- "/"{splice}"*" {@> @[TeX_( "/STRINGGROW /contextstate/YYSTART" );@]
- @> @[TeX_( " /yyBEGIN{SC_COMMENT}/yylexnext" );@]@=}
- "/"{splice}"/" {@> @[TeX_( "/STRINGGROW /contextstate/YYSTART" );@]
- @> @[TeX_( " /yyBEGIN{SC_LINE_COMMENT}/yylexnext" );@]@=}
+ "'" {@> @[TeX_( "/STRINGGROW /contextstate/YYSTART /yyBEGIN{SC_CHARACTER}/yylexnext" );@]@=}
+ "\"" {@> @[TeX_( "/STRINGGROW /contextstate/YYSTART /yyBEGIN{SC_STRING}/yylexnext" );@]@=}
+ "/"{splice}"*" {@> @[TeX_( "/STRINGGROW /contextstate/YYSTART /yyBEGIN{SC_COMMENT}/yylexnext" );@]@=}
+ "/"{splice}"/" {@> @[TeX_( "/STRINGGROW /contextstate/YYSTART /yyBEGIN{SC_LINE_COMMENT}/yylexnext" );@]@=}
}
@g
@ {\it Scanning some code in braces (actions, predicates). The
initial \.{\{} is already eaten}.
@<Scan code in braces@>=
-@G
+@G(fs2)
<SC_BRACED_CODE,SC_PREDICATE>
{
"{"|"<"{splice}"%" {@> @[TeX_( "/STRINGGROW /advance/lonesting/@@ne /yylexnext" );@]@=}
@@ -706,8 +700,7 @@ initial \.{\{} is already eaten}.
/* {\it Tokenize \.{<<\%} correctly (as \.{<<} \.{\%}) rather than incorrectly (as \.{<} \.{<\%}).} */
"<"{splice}"<" {@> @[TeX_( "/STRINGGROW /yylexnext" );@]@=}
- <<EOF>> {@> @[TeX_( "/yycomplain{unexpected end of line " );@]
- @> @[TeX_( " inside braced code}/yyerrterminate" );@]@=}
+ <<EOF>> {@> @[TeX_( "/yyfatal{unexpected end of line inside braced code}" );@]@=}
}
<SC_BRACED_CODE>
@@ -752,12 +745,11 @@ braced code.
@ {\it Scanning some prologue: from \.{\%\{} (already scanned) to \.{\%\}}}.
@<Scan prologue@>=
-@G
+@G(fs2)
<SC_PROLOGUE>
{
"%}" {@> @[@<Finish braced code@>@]@=}
- <<EOF>> {@> @[TeX_( "/yycomplain{unexpected end of file " );@]
- @> @[TeX_( " inside prologue}/yyerrterminate" );@]@=}
+ <<EOF>> {@> @[TeX_( "/yyfatal{unexpected end of file inside prologue}" );@]@=}
}
@g
@@ -770,7 +762,7 @@ braced code.
@ {\it Scanning the epilogue (everything after the second \prodstyle{\%\%}, which
has already been eaten)}.
@<Scan the epilogue@>=
-@G
+@G(fs2)
<SC_EPILOGUE>
{
<<EOF>> {@> @[@<Handle end of file in the epilogue@>@]@=}
@@ -789,7 +781,7 @@ has already been eaten)}.
\immediate\closeout\stlist
\fi
@<Add the scanned symbol to the current string@>=
-@G
+@G(fs2)
<SC_COMMENT,SC_LINE_COMMENT,SC_BRACED_CODE,SC_PREDICATE,SC_PROLOGUE,SC_EPILOGUE,
SC_STRING,SC_CHARACTER,SC_ESCAPED_STRING,SC_ESCAPED_CHARACTER>. |
<SC_COMMENT,SC_LINE_COMMENT,SC_BRACED_CODE,SC_PREDICATE,
diff --git a/support/splint/cweb/mkeparser.w b/support/splint/cweb/mkeparser.w
index 937a9e5498..f60ccf5d64 100644
--- a/support/splint/cweb/mkeparser.w
+++ b/support/splint/cweb/mkeparser.w
@@ -1,4 +1,4 @@
-% Copyright 2012-2014, Alexander Shibakov
+% Copyright 2012-2020, Alexander Shibakov
% This file is part of SPLinT
%
% SPLinT is free software: you can redistribute it and/or modify
@@ -48,11 +48,11 @@ interpret the acronym as something easier to remember.
@ @<Short option list@>=
@<Shortcuts for command line options affecting parser output@>@;
-@ @<Raw option list@>=
- @<Parser specific option list@>@;
+@ @<Options with shortcuts@>=
+ @<Parser specific options with shortcuts@>@;
-@ @<Higher index options@>=
- @<Higher index parser specific options@>@;
+@ @<Options without shortcuts@>=
+ @<Parser specific options without shortcuts@>@;
@ @<Cases affecting the whole program@>=
@<Handle parser output options@>@;
@@ -89,21 +89,25 @@ interpret the acronym as something easier to remember.
@*1 Parser dependent settings.
This is it for the core table output functions.
-To make all this into a working code in this
-case, lexing and error function declarations are supplied.
+To make all of this into working code in this
+case, lexing and error functions are supplied.
+
+If an existing parser is reused as |PARSER_FILE| these functions may
+have been redefined by the programmer, in which case a mechanism to
+supply the appropriate definitions is provided.
@<Auxiliary function declarations@>=
#ifndef HAS_SCANNER
int yylex(void);
- int yyerror(void);
+ int yyerror(char *);
#endif
@ @<Auxiliary function definitions@>=
#ifndef HAS_SCANNER
int yylex(void){}
- int yyerror(void){}
+ int yyerror(char * text){}
#endif
-@ \let\B\oldB % \Cee\ mode mixes all up
+@ %\let\B\oldB % \Cee\ mode mixes all up
@c
@<\Cee\ preamble@>@;
diff --git a/support/splint/cweb/mkscanner.w b/support/splint/cweb/mkscanner.w
index 22c39e9342..e847428199 100644
--- a/support/splint/cweb/mkscanner.w
+++ b/support/splint/cweb/mkscanner.w
@@ -1,4 +1,4 @@
-% Copyright 2012-2014, Alexander Shibakov
+% Copyright 2012-2020, Alexander Shibakov
% This file is part of SPLinT
%
% SPLinT is free software: you can redistribute it and/or modify
@@ -51,11 +51,11 @@ interpret the acronym as something easier to remember.
@ @<Cases affecting the whole program@>=
@<Handle scanner output options@>@;
-@ @<Raw option list@>=
- @<Scanner specific option list@>@;
+@ @<Options with shortcuts@>=
+ @<Scanner specific options with shortcuts@>@;
-@ @<Higher index options@>=
- @<Higher index scanner specific options@>@;
+@ @<Options without shortcuts@>=
+ @<Scanner specific options without shortcuts@>@;
@ @<Short option list@>=
@<Shortcuts for command line options affecting scanner output@>@;
@@ -87,6 +87,7 @@ lexer written for a different purpose, the situation may be different.
@<\Cee\ preamble@>@;
typedef int YYSTYPE;
#define YY_BREAK return 0;
+#define YY_USER_ACTION fprintf( tables_out, "%s\n", " \\YYRULESETUP" );
#include LEXER_FILE
diff --git a/support/splint/cweb/np.w b/support/splint/cweb/np.w
index aa20e551c7..58379649a5 100644
--- a/support/splint/cweb/np.w
+++ b/support/splint/cweb/np.w
@@ -1,4 +1,4 @@
-@q Copyright 2012-2014, Alexander Shibakov@>
+@q Copyright 2012-2020, Alexander Shibakov@>
@q This file is part of SPLinT@>
@q SPLinT is free software: you can redistribute it and/or modify@>
@@ -14,8 +14,8 @@
@q You should have received a copy of the GNU General Public License@>
@q along with SPLinT. If not, see <http://www.gnu.org/licenses/>.@>
-@*1 The name parser. What follows is an example parser for the name
-processing. This approach (i.e. using a `full blown' parser/scanner
+@** The name parser. What follows is an example parser for the term
+name processing. This approach (i.e. using a `full blown' parser/scanner
combination) is probably not the best way to implement such machinery
but its main purpose is to demonstrate a way to create a separate
parser for local purposes.
@@ -51,17 +51,18 @@ parser for local purposes.
@G
%token PERCENT_IDENTIFIER
%token IDENTIFIER
-%token OPTIONAL
-%token NO_ATTR
+%token OPTIONAL NO_ATTR EXTENDED LT RT
%token INTEGER
-%token EXTENDED
-%token WILDCARD
+%token WILDCARD C_ESCCHAR
+%token META_IDENTIFIER
@g
@ @<Parser productions@>=
@G
full_name:
identifier_string suffixes.opt {@> @<Compose the full name@> @=}
+| META_IDENTIFIER {@> @<Turn a \prodstylens{META\_IDENTIFIER}{\smallnamespace} into a full name@> @=}
+| quoted_name suffixes.opt {@> @<Compose the full name@> @=}
;
identifier_string:
@@ -69,17 +70,24 @@ identifier_string:
| IDENTIFIER {@> @<Start with an identifier@> @=}
| '<' IDENTIFIER '>' {@> @<Start with a tag@> @=}
| '\'' WILDCARD '\'' {@> @<Start with a quoted string@> @=}
+| '\'' C_ESCCHAR '\'' {@> @<Start with an escaped character@> @=}
| '\'' '>' '\'' {@> @<Start with a \prodstyle{'>'} string@> @=}
| '\'' '<' '\'' {@> @<Start with a \prodstyle{'<'} string@> @=}
| '\'' '.' '\'' {@> @<Start with a \prodstyle{'.'} string@> @=}
| '\'' '_' '\'' {@> @<Start with an \prodstyle{'\_'} string@> @=}
| '\'' '-' '\'' {@> @<Start with a \prodstyle{'-'} string@> @=}
+| '\'' '$' '\'' {@> @<Start with a \prodstyle{'\$'} string@> @=}
+| '$' {@> @<Prepare a \bison\ stack name@> @=}
| qualifier {@> @<Turn a qualifier into an identifier@> @=}
| identifier_string IDENTIFIER {@> @<Attach an identifier@> @=}
| identifier_string qualifier {@> @<Attach qualifier to a name@> @=}
| identifier_string INTEGER {@> @<Attach an integer@> @=}
;
+quoted_name:
+ '\"' PERCENT_IDENTIFIER '\"' {@> @<Process quoted option@> @=}
+| '\"' IDENTIFIER '\"' {@> @<Process quoted name@> @=}
+;
suffixes.opt:
{@> TeX_( "/yy0{}" ); @=}
| '.' {@> TeX_( "/yy0{/nx/dotsp/nx/sfxnone}" ); @=}
@@ -102,16 +110,24 @@ qualified_suffixes:
| qualifier {@> @<Start suffixes with a qualifier@> @=}
;
+@t}\vb{\inline\flatten}{@>
qualifier:
OPTIONAL {@> TeX_( "/yy0{/the/yy(1)}" ); @=}
| NO_ATTR {@> TeX_( "/yy0{/the/yy(1)}" ); @=}
| EXTENDED {@> TeX_( "/yy0{/the/yy(1)}" ); @=}
+| LT {@> TeX_( "/yy0{/the/yy(1)}" ); @=}
+| RT {@> TeX_( "/yy0{/the/yy(1)}" ); @=}
;
@g
@ @<Compose the full name@>=
@[TeX_( "/yy0{/the/yy(1)/the/yy(2)}/namechars/yyval" );@]@;
+@ @<Turn a \prodstylens{META\_IDENTIFIER}{\smallnamespace} into a full name@>=
+ @[TeX_( "/getfirst{/yy(1)}/to/toksa" );@]@;
+ @[TeX_( "/getsecond{/yy(1)}/to/toksb" );@]@;
+ @[TeX_( "/yy0{/nx/idstr{/the/toksa}{/the/toksb}}/namechars/yyval" );@]@;
+
@ @<Attach option name@>=
@[TeX_( "/getfirst{/yy(1)}/to/toksa" );@]@;
@[TeX_( "/getsecond{/yy(1)}/to/toksb" );@]@;
@@ -130,22 +146,33 @@ qualifier:
@ @<Start with a quoted string@>=
@[TeX_( "/getfirst{/yy(2)}/to/toksa" );@]@;
@[TeX_( "/getsecond{/yy(2)}/to/toksb" );@]@;
- @[TeX_( "/yy0{/nx/chstr{/the/toksa}{/the/toksb}}" );@]@;
+ @[TeX_( "/sansfirst/toksb" );@]@;
+ @[TeX_( "/yy0{/nx/chstr{/the/toksb}{/the/toksb}/nx/visflag{/nx/termvstring}{}}" );@]@;
+
+@ @<Start with an escaped character@>=
+ @[TeX_( "/getsecond{/yy(2)}/to/toksb" );@]@;
+ @[TeX_( "/yy0{/nx/chstr{/the/toksb}{/the/toksb}/nx/visflag{/nx/termvstring}{}}" );@]@;
@ @<Start with a \prodstyle{'<'} string@>=
- @[TeX_( "/yy0{/nx/chstr{<}{<}}" );@]@;
+ @[TeX_( "/yy0{/nx/chstr{<}{<}/nx/visflag{/nx/termvstring}{}}" );@]@;
@ @<Start with a \prodstyle{'>'} string@>=
- @[TeX_( "/yy0{/nx/chstr{/greaterthan}{/greaterthan}}" );@]@;
+ @[TeX_( "/yy0{/nx/chstr{/greaterthan}{/greaterthan}/nx/visflag{/nx/termvstring}{}}" );@]@;
@ @<Start with an \prodstyle{'\_'} string@>=
- @[TeX_( "/yy0{/nx/chstr{/uscoreletter}{/uscoreletter}}" );@]@;
+ @[TeX_( "/yy0{/nx/chstr{/uscoreletter}{/uscoreletter}/nx/visflag{/nx/termvstring}{}}" );@]@;
@ @<Start with a \prodstyle{'-'} string@>=
- @[TeX_( "/yy0{/nx/chstr{-}{-}}" );@]@;
+ @[TeX_( "/yy0{/nx/chstr{-}{-}/nx/visflag{/nx/termvstring}{}}" );@]@;
+
+@ @<Start with a \prodstyle{'\$'} string@>=
+ @[TeX_( "/yy0{/nx/chstr{/safemath}{/safemath}/nx/visflag{/nx/termvstring}{}}" );@]@;
@ @<Start with a \prodstyle{'.'} string@>=
- @[TeX_( "/yy0{/nx/chstr{.}{.}}" );@]@;
+ @[TeX_( "/yy0{/nx/chstr{.}{.}/nx/visflag{/nx/termvstring}{}}" );@]@;
+
+@ @<Prepare a \bison\ stack name@>=
+ @[TeX_( "/yy0{/nx/bidstr{/nx/$}{/safemath}}" );@]@;
@ @<Turn a qualifier into an identifier@>=
@<Start with an identifier@>@;
@@ -164,9 +191,29 @@ qualifier:
@ @<Attach qualifier to a name@>=
@<Attach an identifier@>
-@ @<Attach an integer@>=
- @<Attach an identifier@>@;
+@ An integer at the end of an identifier (such as |id1|) is
+interpreted as a suffix (similar to the way \MF\ treats identifiers,
+and \mft\ typesets them\footnote{This allows, for example, names like
+|$[term0]| while leaving |$[char2int]| in its `natural' form.}) to
+mitigate a well-intentioned but surprisingly inconvenient feature of
+\CTANGLE, namely outputting something like \.{id.1} as \.{id\ .1} in an
+attempt to make sure that integers do not interfere with structure
+dereferences. For this to produce meaningful results, a stricter
+interpretation of \prodstyle{IDENTIFIER} syntax is required,
+represented by the \.{id\_strict} syntax below.
+@<Attach an integer@>=
+ @[TeX_( "/yy0{/the/yy(1)/nx/dotsp/nx/sfxi/the/yy(2)}" );@]@;
+@ @<Process quoted name@>=
+ @[TeX_( "/getfirst{/yy(2)}/to/toksa" );@]@;
+ @[TeX_( "/getsecond{/yy(2)}/to/toksb" );@]@;
+ @[TeX_( "/yy0{/nx/idstr{/the/toksa}{/the/toksb}/nx/visflag{/nx/termvstring}{}}" );@]@;
+
+@ @<Process quoted option@>=
+ @[TeX_( "/getfirst{/yy(2)}/to/toksa" );@]@;
+ @[TeX_( "/getsecond{/yy(2)}/to/toksb" );@]@;
+ @[TeX_( "/yy0{/nx/optstr{/the/toksa}{/the/toksb}/nx/visflag{/nx/termvstring}{}}" );@]@;
+
@ @<Attach suffixes@>=
@[TeX_( "/yy0{/nx/dotsp/the/yy(2)}" );@]@;
@@ -211,8 +258,14 @@ definitions are used.
@<Union of parser types@>=
-@*1 The name scanner.
-%\checktabletrue
+@** The name scanner.
+The scanner for lexing term names is admittedly {\em ad hoc\/} and
+rather redundant. A minor reason for this is to provide some
+flexibility for name typesetting. Another reason is to let the
+existing code serve as a template for similar procedures in other
+projects. At the same time, it must be pointed out that this scanner
+is executed multiple times for every \bison\ section, so its
+efficiency directly affects the speed at which the parser operates.
@(small_lexer.ll@>=
@G
@> @<Lexer definitions@> @=
@@ -230,10 +283,13 @@ void define_all_states( void ) {
@ @<Lexer definitions@>=
@<Lexer states@>@;
-@G
+@G(fs1)
letter [_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ]
-wc ([^\\\'\"]{-}[_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0-9]|\\.)
+c-escchar \\[fnrtv]
+wc ([^\\\'\"$.<>]{-}[_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0-9]|\\.)
id {letter}({letter}|[-0-9])*
+id_strict {letter}(({letter}|[-0-9])*{letter})?
+meta_id "*"{id_strict}"*"?
int [0-9]+
@g
@@ -268,27 +324,8 @@ int [0-9]+
@<Scan identifiers@>@;
@ White space skipping.
-\traceparserstatestrue
-\tracestackstrue
-\tracerulestrue
-\traceactionstrue
-\tracelookaheadtrue
-\traceparseresultstrue
-\tracebadcharstrue
-\yyflexdebugtrue
-%
-\traceparserstatesfalse
-\tracestacksfalse
-\tracerulesfalse
-\traceactionsfalse
-\tracelookaheadfalse
-\traceparseresultsfalse
-\tracebadcharsfalse
-\yyflexdebugfalse
-%
-\yyskipparsetrue
@<Scan white space@>=
-@G
+@G(fs2)
[ \f\n\t\v] {@> @[TeX_( "/yylexnext" );@]@=}
@g
@@ -297,9 +334,8 @@ its present state, it certainly is. However, if later on the
typesetting style for some of the keywords would need to be adjusted,
such changes would be easy to implement, since the template is already
here.
-\yyskipparsefalse % this is not necessary
@<Scan identifiers@>=
-@G
+@G(fs2)
"%binary" {@> @[TeX_( "/yylexreturnval{PERCENT_IDENTIFIER}" );@]@=}
"%code" {@> @[TeX_( "/yylexreturnval{PERCENT_IDENTIFIER}" );@]@=}
"%debug" {@> @[TeX_( "/yylexreturnval{PERCENT_IDENTIFIER}" );@]@=}
@@ -355,26 +391,31 @@ here.
"%pure"[-_]"parser" {@> @[TeX_( "/yylexreturnval{PERCENT_IDENTIFIER}" );@]@=}
"%token"[-_]"table" {@> @[TeX_( "/yylexreturnval{PERCENT_IDENTIFIER}" );@]@=}
"%"({letter}|[0-9]|[-_]|"%"|[<>])+ {@> @[TeX_( "/yylexreturnval{PERCENT_IDENTIFIER}" );@]@=}
-
+@t}\vb{\insertraw{\inscomment{\it suffixes}}}{@>
"opt" {@> @[TeX_( "/yylexreturnval{OPTIONAL}" );@]@=}
"na" {@> @[TeX_( "/yylexreturnval{NO_ATTR}" );@]@=}
"ext" {@> @[TeX_( "/yylexreturnval{EXTENDED}" );@]@=}
-
-[<>._\'] {@> @[TeX_( "/yylexreturnchar" );@]@=}
+"l" {@> @[TeX_( "/yylexreturnval{LT}" );@]@=}
+"r" {@> @[TeX_( "/yylexreturnval{RT}" );@]@=}
+@t}\vb{\insertraw{\inscomment{\it delimeters}}}{@>
+[<>$._\'\"] {@> @[TeX_( "/yylexreturnchar" );@]@=}
+{c-escchar} {@> @[TeX_( "/yylexreturnval{C_ESCCHAR}" );@]@=}
{wc} {@> @[TeX_( "/yylexreturnval{WILDCARD}" );@]@=}
-
-{id} {@> @[@<Prepare to process an identifier@>@]@=}
+@t}\vb{\insertraw{\inscomment{\it identifiers and other names}}}{@>
+{id_strict} {@> @[@<Prepare to process an identifier@>@]@=}
+{meta_id} {@> @[@<Prepare to process a meta-identifier@>@]@=}
{int} {@> @[TeX_( "/yylexreturnval{INTEGER}" );@]@=}
-
-"\"" {@> @[TeX_( "/yylexnext" );@]@=}
+@t}\vb{\insertraw{\inscomment{\it everything else}}}{@>
. {@> @[@<React to a bad character@>@]@=}
@g
@ @<Prepare to process an identifier@>=
@[TeX_( "/yylexreturnval{IDENTIFIER}" );@]@;
+@ @<Prepare to process a meta-identifier@>=
+ @[TeX_( "/yylexreturnval{META_IDENTIFIER}" );@]@;
+
@ @<React to a bad character@>=
@[TeX_( "/iftracebadchars" );@]@;
- @[TeX_( " /yycomplain{invalid character(s): /the/yytext}" );@]@;
+ @[TeX_( " /yyfatal{invalid character(s): /the/yytext}" );@]@;
@[TeX_( "/fi" );@]@;
- @[TeX_( "/yylexreturn{$undefined}" );@]@;
diff --git a/support/splint/cweb/philosophy.w b/support/splint/cweb/philosophy.w
index 4d30f2d765..7b173f5d2f 100644
--- a/support/splint/cweb/philosophy.w
+++ b/support/splint/cweb/philosophy.w
@@ -1,3 +1,19 @@
+@q Copyright 2012-2020, Alexander Shibakov@>
+@q This file is part of SPLinT@>
+
+@q SPLinT is free software: you can redistribute it and/or modify@>
+@q it under the terms of the GNU General Public License as published by@>
+@q the Free Software Foundation, either version 3 of the License, or@>
+@q (at your option) any later version.@>
+
+@q SPLinT is distributed in the hope that it will be useful,@>
+@q but WITHOUT ANY WARRANTY; without even the implied warranty of@>
+@q MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the@>
+@q GNU General Public License for more details.@>
+
+@q You should have received a copy of the GNU General Public License@>
+@q along with SPLinT. If not, see <http://www.gnu.org/licenses/>.@>
+
@**Philosophy.
This section should, perhaps, be more appropriately called {\it rant\/} but
{\it philosophy\/} sounds more academic. The design of any software involves
@@ -5,58 +21,61 @@ numerous choices, and \splint\ is no exception. Some of these choices
are explained in the appropriate places in the package files. This
section collects a few `big picture' viewpoints that did not fit elsewhere.
-@*1 On typographic style.
+@*1 On typographic convention.
It must seem quite perplexing to some readers that a
-document with a focus on {\it pretty-printing\/} displays such a
-wanton disregard for good typographic taste. Haphazard choice of
-styles to present programming constructs, random overabundance of
-fonts on almost every single page are just a few among the many typographic sins
-and design guffaws so amply manifested on these pages. The author has
-to take full responsibility for the lack of taste in this
-opus and has only one argument in his defense: this is not
+manual focussing on {\it pretty-printing\/} shows such a
+wanton disregard for good typographic style. Haphazard choice of
+layouts to present programming constructs, random overabundance of
+fonts on almost every page are just a few of the many typographic sins
+and design guffaws so amply manifested in this opus. The author must
+take full responsibility for the lack of taste in this
+document and has only one argument in his defense: this is not
merely a book for a good night read but a piece of technical
documentation.
-In many ways, the goal of this document is somewhat contrary to that
+In many ways, the goal of this document is somewhat different from that
of a well-written manual: to display the main features
prominently and in logical order. After all, this is a package that is
-intended to help {\it write\/} such manuals so it inevitably must
-display some use cases that demonstrate a variety of typographic styles
-possible to achieve with \splint. Needless to say, {\it variety\/} and
-{\it consistency\/} seldom go hand in hand and it is consistency that
-makes for a pretty page. One of the objectives has been to demonstrate a
+intended to help {\it write\/} such manuals so it must inevitably
+present some use cases that exhibit a variety of typographic styles
+achievable with \splint. Needless to say, {\it variety\/} and
+{\it consistency\/} seldom go hand in hand and it is the consistency that
+makes for a pretty page. One of the objectives has been to reveal a
number of quite technical programming constructs so one should keep in
mind that it is assumed that the reader will want to look up the input
files to see how some (however ugly and esoteric) typographic effects
-had been achieved.
+have been achieved.
-On the other hand, to use a clich\'e, beauty is in the eyes of the
+On the other hand, to quote a clich\'e, beauty is in the eyes of the
beholder so what makes a book readable (or even beautiful) may well
-depend on the background of the reader. As an example, letterspacing
+depend on the reader's background. As an example, letterspacing
as a typographic device is almost universally reviled in Western
typography (aside from a few niche uses such as setting titles). In
Russian, however (at least until recently), letterspacing has been
routinely used for emphasis (or, as a Russian would put it,
e$\,$m$\,$p$\,$h$\,$a$\,$s$\,$i$\,$s) in lieu of, say, {\it italics}. Before
I hear any objections from typography purists, let me just say that
-this technique fits perfectly with the way emphasis works in the Russian speech: a
-speaker slowly enunciates the sounds of each word (incidentally,
-emphasizing {\it emphasis\/} is a perfect example of why this method
-would fail in most English texts). Letterspaced
-sentences are easy to find on a page and set a special reading rhythm,
-which is an added bonus in many cases, although it does violate the
-`universally gray pages are a must' dogma.
+this technique fits in perfectly with the way emphasis works in the
+Russian speech: the speaker slowly enunciates the sounds of each word
+(incidentally, emphasizing {\it emphasis\/} this way is a perfect example of the
+inevitable failure of any attempted letterspaced highlighting in most
+English texts). Letterspaced sentences are easy to find on a page, and
+they set a special reading rhythm, which is an added bonus in many
+cases, although their presense openly violates
+the `universally gray pages are a must' dogma.
@*1 Why GPL.
-The choice of license for this project goes beyond merely showing the
-source. \TeX, by its very nature is an open source language, so it
-is not a matter of hiding anything from the user or a potential
-developer. The \Cee\ code is a different matter but the source is not
+Selecting the license for this project involves more than the
+availability of the source code. \TeX, by its very nature is an
+interpreted\footnote{There are some exceptions to this, in the form of
+preloaded {\em formats}.} language, so it
+is not a matter of hiding anything from the reader or a potential
+programmer. The \Cee\ code is a different matter but the source is not
that complicated. Reducing the licensing issue to the ability of
someone else to see the source code is a great
-oversimplification. Without getting into too many details of so-called
+oversimplification. Short of getting into too many details of the so-called
`open source licenses' (other than GPL) and arguing with their advocates, let me simply
-express my lack of understanding at the arguments that purport that
+express my lack of understanding of the arguments purporting that
BSD-style licenses introduce more freedom by allowing a software
vendor to incorporate the BSD-licensed software into their
products. What benefit does one derive from such `extension' of software
@@ -69,22 +88,23 @@ misplaced such hopes are.
I am not going to argue for the benefits of free software at length, either
(such benefits seem self-evident to me, although the readers should
-feel free to disagree). Let me just point out that software companies
+feel free to disagree). Let me just point out that the software companies
enjoy quite a few freedoms that we, as software consumers elect to
afford them. Among such freedoms are the ability to renege on any
-promises made to potential users and withdraw any guarantees that such
-users might enjoy. Free software, of course, does not provide any
-guarantees, either but `you get what you paid for'. As a result of
-such `release of any responsibility', the claims of increased
+promises made to us and withdraw any guarantees that we might enjoy.
+As a result of such `release of any responsibility', the claims of increased
reliability or better support for the commercial software sound a
-bit hollow. Another well spread tactic is user brainwashing and
+bit hollow. Free software, of course, does not provide any
+guarantees, either but `you get what you paid for'.
+
+Another well spread industry tactic is user brainwashing and
changing the culture (usually for the worse) in order to promote new
`user-friendly' features of commercial software. Instead of taking
advantage of computers as cognitive machines we have come to view
them as advanced media players that we interact with through
artificial, unnatural interfaces. Meaningless terminology (`UX' for
`user experience'? What in the world is `user experience'?)
-proliferates, and programmers are happy to deceive themselves with
+proliferates, and programmers are all too happy to deceive themselves with
their newly discovered business prowess.
One would hope that the somewhat higher standards of the `real'
@@ -105,13 +125,14 @@ software is quite possible, though, just look at programmable
thermostats, simple cellphones and other `invisible' gadgets we
enjoy. The `software ideology' with its `IP' lingo is spreading like a
virus even through the world of real things. We now expect products to
-break and are too quick to forgive sloppy engineering that goes into
-everyday things. We are also getting used to the idea that it is the
-manufacturers that get to dictate the terms of use for `their' products
-and that we are merely borrowing `their' stuff.
+break and are too quick to forgive sloppy (or worse, malicious)
+engineering that goes into everyday things. We are also getting
+used to the idea that it is the manufacturers that get to dictate
+the terms of use for `their' products and that we are merely
+borrowing `their' stuff.
-The GPL was conceived as an antidote to this scourge. This document is a
-remarkable piece of `legal engineering': a self-propagating license
+The GPL was conceived as an antidote to this scourge. This license is a
+remarkable piece of `legal engineering': a self-propagating contract
with a clearly outlined set of goals. While by itself it does not
guarantee reliability or quality, it does inhibit the spread of the `IP'
(which is sometimes sarcastically, though quite perceptively,
@@ -121,29 +142,32 @@ software.
The industry has adapted, of course. So called (non GPL) `open source
licenses', that are supposed to be an improvement on GPL,
are a sort of `immune reaction' to the free software
-movement. Convince and confuse enough apathetic users and the
+movement. Describing GPL as `viral', creating dismissive acronims such as FLOSS to
+refer to the free software, and spreading outright misinformation about GPL
+are just a few of the tactics employed by the software companies.
+Convince and confuse enough apathetic users and the
protections granted by GPL are no longer visible.
-@*1 Why not \Cee$++$ or OOP in general.
+@*1 Why not C{\tt ++} or OOP in general.
The choice of the language was mainly driven by \ae sthetic motives:
-\Cee$++$ has a bloated and confusing standard, partially supported by
+\Ceepp\ has a bloated and confusing standard, partially supported by
various compilers. It seems that there is no agreement on what
-\Cee$++$ really is or how to use some of its constructs. This is all
+\Ceepp\ really is or how to use some of its constructs. This is all
in contrast to \Cee\ with its well defined and concise body of
specifications and rather well established stylistics. The existence
-of `obfuscated \Cee' is not good evidence of deficiency and \Cee$++$
+of `obfuscated \Cee' is not good evidence of deficiency and \Ceepp\
is definitely not immune to this malady.
Object oriented design has certainly taken on an aura of a religious
dictate, universally adhered to and forcefully promoted by its
followers. Unfortunately, the definition of what constitutes an
-`object-oriented' approach is rather vague. A few abstract concepts are
+`object-oriented' approach is rather vague. A few informal concepts are
commonly tossed about to give the illusion of a well developed
abstraction (such as `polymorphism', `encapsulation', and so on) but
-definitions vary in both length and contents, depending on the source.
+definitions vary in both length and content, depending on the source.
-On a syntactic level, some features of object-oriented languages are
-undoubtedly very practical (such as a |this| pointer in \Cee$++$),
+On the syntactic level, some features of object-oriented languages are
+undoubtedly very practical (such as a |this| pointer in \Ceepp),
however, many of those features can be effectively emulated with some
clever uses of an appropriate preprocessor (there are a few
exceptions, of course, |this| being one of them). The rest of the
@@ -188,17 +212,18 @@ software with inadequate tools merely `to encourage development'.
The feeling of a \.{WEB} source being {\it over-documented\/} is most
certainly subjective, and, I am sure, not shared by all `current
programmers'. The advantage of using \.{WEB}-like tools, however, is
-that it gives the programmer the ability to place the vital
+that it gives the programmer the ability to place vital
information where it does not distract the reader (`developer',
`maintainer', call it whatever you like) from the logical flow of the
code.
-Some of the complaints in \cite[Ho] are definitely justified,
+Some of the complaints in \cite[Ho] are definitely justified (see
+below for a few similar criticisms of \CWEB),
although it seems that a better approach would be to write an improved
tool similar to \.{WEB}, rather than give up all the flexibility such
a tool provides.
-@*1 Why \CWEB.
+@*1 Why \eatone{CWEB}\CWEB.
\CWEB\ is not as polished as \TeX\ but it works and has a
number of impressive features. It is, regrettably, a `niche' tool and
a few existing extensions of \CWEB\ and software based on similar ideas
@@ -207,16 +232,179 @@ largely neglected even though it seems to have a more logical
foundation than OOP. Under these circumstances, \CWEB\ seemed to be
the best available option.
-@*1 Why not GitHub, Bitbucket, etc.
-Git is an incredible tool and is used extensively in the development
+@*2 Some \eatone{CWEB}\CWEB\ idiosynchrasies.
+\CWEB\ was among the first tools for literate programming intended
+for public use\footnote{The original \WEB\ was designed to support
+DEK's \TeX\ and \MF\ projects and was inteded for \Pascal\ family
+languages.}. By almost every measure it is a very successful design:
+the program mostly does what is intended, was used in a number of
+projects, and made a significant contribution to the practice of {\it
+literate programming}@^literate programming@>. It also gave rise to a
+multitude of similar software packages (see, for example,
+\noweb@^noweb@>\ by N.~Ramsey, \cite[Ra]), which proves the vitality
+of the approach taken by the authors of \CWEB.
+
+While the value of \CWEB\ is not in dispute, it would be healthy to
+outline a few deficiencies\footnote{Quirks would be a better term.}
+that became apparent after intensive (ab)use of this software. Before
+we proceed to list our criticisms, however, the author must make a
+disclaimer that not only most of the complaints below stem from trying
+to use \CWEB\ outside of its intended field of application but such
+use has also been hampered by the author's likely lack of familiarity
+with some ot \CWEB's features.
+
+The first (non)complaint that must be mentioned here is \CWEB's narrow
+focus on \Cee-styled languages. The `grammar' used to process the
+input is hard coded in \CWEAVE, so any changes to it inevitably
+involve rewriting portions of the code and rebuilding \CWEAVE. As
+\Cee11 came to prominence, a few of its constructs have been left
+behind by \CWEAVE. Among the most obvious of these are variadic macros
+and compound literals. The former is only a problem in \CWEB's \.{@@d}
+style definitions (which are of questionable utility to begin with)
+while the lack of support for the latter may be somewhat amended by
+the use of \.{@@[}$\ldots$\.{@@]} and \.{@@;} constructs to
+manipulate \CWEAVE's perception of a given {\em chunk\/} as either an
+{\em exp\/} or a {\em stmt}. This last mechanism of syntactic markup
+is spartan but remarkably effective, although the code thus annotated
+tends to be hard to read in the editor (while resulting in just as
+beautifully typeset pages, nonetheless).
+
+Granted, \CWEB's stated goal was to bring the technique of literate
+programming to \Cee, \Ceepp, and related languages so the criticism
+above must be viewed in this context. Since \CWEAVE\ outputs \TeX, one
+avenue for customizing its use to one's needs is modifying the macros
+in \.{cwebmac.tex}. \splint\ took this route by rewriting a number of
+macros, ranging from simple operator displays (replacing, say, `$=$' with
+`|=|') to extensively customizing the indexing mechanism.
+
+Unfortunately, this strategy could only take one thus far. The \TeX\
+output produced by \CWEAVE\ does not always avail itself to this
+approach readily. To begin with, while combining its `chunks' into
+larger ones, \CWEAVE\ dives in and out of the math mode unpredictably,
+so any macros trying to read their `environment' must be ready to operate both
+inside and outside of the math mode and leave the proper mode behind when
+they are done. The situation is not helped by the fact that both the
+beginning and the end of the math mode in \TeX\ are marked by the same
+character (\.{\$}, and it costs you, indeed) so `expandable' macros
+are difficult to design.
+
+Adding to these difficulties is \CWEAVE's facility to insert raw \TeX\
+material in the middle of its input (the \.{@@t}$\ldots$\.{@@>}
+construct). While rather flexible, by default it puts all such user
+supplied \TeX\ fragments inside an \.{\\hbox} which brings with it all
+the advantages, and, unfortunately, disadvantages of grouping,
+inability to introduce line breaks within the fragment, etc. There is,
+of course, an easy fix to most of these woes, outlined in \CWEB's
+manual: one can simply type \.{@@t\}}$\,$\TeX\ stuff$\,$\.{\{@@>} which
+inserts \.{\\hbox\{\}}$\,$\TeX\ stuff$\,$\.{\{\}} into \CWEAVE's output. The
+cost of this hack (aside from looking and feeling rather ugly on the
+editor screen, not to mention disrupting the editor's brace
+accounting) is a superfluous \.{\\hbox\{\}} left behind {\em before\/}
+the `\TeX\ stuff'. The programmer's provided \TeX\ code is unable to
+remove this box (at the macro level, i.e.~in \TeX's `mouth' using
+D.~Knuth's terminology, one may still succeed with the \.{\\lastbox}
+approach unless the \.{\\hbox} was inserted in the main vertical mode)
+and it may result in an unwanted blank line, slow down
+the typesetting, etc. Most of these side-effects are easily treatable
+but it would still be nice if a true `\.{asm} style' insertion of raw
+\TeX\ were possible\footnote{It must be said that in the majority of
+cases such side-effects are indeed desirable, and save the programmer some
+typing but it seems that the \.{@@t} facility was not well thought
+out in its entirety.}.
+
+In general, the lack of structure in \CWEAVE's generated \TeX\ seems
+to hinder even seemingly legitimate uses of \.{cwebmac.tex}
+macros. Even such a natural desire as to use a different type size for
+the \Cee\ portions of the \CWEB\ input is unexpectedly tricky to
+implement. Modifying the \.{\\B} macro results in rather wasteful
+multiple reading of the tokens in the \Cee\ portion, not to mention
+the absense of any guarantee that \.{\\B} can find the end of its
+argument (the macros used by \splint\ look for the \.{\\par} inserted
+by \CWEAVE\ whenever \.{\\B} is output but an unsuspecting programmer
+may disrupt this mechanism by inserting h\.{\{}is, her\.{\}} own
+\.{\\par} using the \.{@@t} facility with the aim to put a picture in
+the middle of the code, for example.
+
+The authors of \CWEB\ understood the importance of the
+cross-referencing facilities provided by their program. There are
+several control sequences dedicated to indexing alone (which itself
+has been the subject of criticism aimed at \CWEB). The indexing
+mechanism addresses a number of important needs, although it does not
+seem to be as flexible as required in some instances. For example, most
+book indices are split into sections according to the first letter of
+the indexed word to make it easier to find the desired term in the
+index (or to establish that it is not indexed). Doing so in \CWEB\
+requires some macro acrobatics, to say the least.
+
+Also absent is a facility to explicitly inhibit the indexing of a
+specific word (in \CWEAVE's own source, the references for |pp| fill
+up several lines in the index) or limit it to definitions only (as
+\CWEAVE\ automatically does for single letter identifiers). This too, can be
+fixed by writing new indexing macros.
+
+Finally, the index is created at the point of \CWEAVE\ invocation,
+before any pagination information becomes available. It is therefore
+difficult to implement any page oriented referencing scheme. Instead,
+the index and all the other cross referencing facilities are tied to
+section numbers. In the vast majority of cases, this is a superior
+scheme: sections tend to be short and the index creation is
+fast. Sometimes, however, it is useful to provide the page information
+to the index macros. Unfortunately, after the index creation is
+completed, any connection between the words in the original document
+and those in the index is lost.
+
+The indexing macros in \splint\ that deal with \bison\ and \flex\ code
+have the advantage of being able to use the page numbers so a better
+indexing scheme is possible. The section numbering approach taken by
+\splint\ approximately follows that of \noweb: the section reference
+consists of two parts, where the first is the page number the section
+starts on, and the the second is the index of the section within the
+page. Within the page, sections are indexed by (sequences of) letters
+of the aphabet (\.a$\ldots$\.z and, in the rarest of cases,
+\.{aa}$\ldots$\.{zz} and so on). Numbering the sections themselves is
+not terribly complicated. Where it gets interesting, is during the production
+of the index entries based on this system. When the sections are short, just
+referencing the section where the term appears works well. Sometimes,
+however, a section is split between two or more pages, in which case
+the indexing macros provide a compromise: whenever the term appears on
+a page different from the one on which the corresponding section
+starts, the index entry for that term uses the page number instead of
+the section reference. The difference between the two is easy to see,
+since the page number does not have any alphabetic characters in it.
+
+This is not {\em exactly\/} how the references work in \noweb, since
+\noweb\ ignores the \TeX\ portion of the section and only references
+the code {\em chunks\/} but it is similar in spirit. Other
+conveniences, also borrowed from \noweb, are the references in the
+margins that allow the reader to jump from one chink to the next
+whenever the code chunk is composed of several sections. All of these
+changes are implemented with macros only, so, for example, the finer
+section number${}/{}$page number scheme is not available for the index
+entries produced by \CWEAVE\ itself. In the case of \CWEB\ generated
+entries only the section numbers are used (which in most cases do provide
+the correct page number as part of the reference, however).
+
+To conclude this Festivus@^Festivus@>\footnote{Yes, I am old enough to know what
+this means.} style airing of grievances, let me state once again that
+\CWEB\ is a remarkable tool, and incredibly useful as it is, although
+it does test one's ability to write sophisticated \TeX\ if subtle
+effects are desired. Finally, when all else fails, one is free to
+modify \CWEB\ itself or even write one's own literate programming tool.
+
+@*1 Why not GitHub$^{\hbox{\sevenpoint\copyright}}$, Bitbucket$^{\hbox{\sevenpoint\copyright}}$, etc.
+Git is fantastic software that is used extensively in the development
of \splint. The distribution archive is a Git repository. The use of
-centralized services such as GitHub, however, seems redundant. The
+centralized services such as GitHub$^{\hbox{\sixpoint\copyright}}$\footnote{A recent aquisition of
+GitHub$^{\hbox{\sixpoint\copyright}}$
+by a company that not so long ago used expletives to refer to the free software
+movement only strengthens my suspicions, although everyone is welcome to draw
+their own conclusions.}, however, seems redundant. The
standard cycle, `clone-modify-create pull request' works the same even
when `clone' is replaced by `download'. Thus, no functionality is
lost. This might change if the popularity of the package unexpectedly
increases.
-On the other hand, GitHub and its cousins are commercial entities,
+On the other hand, GitHub$^{\hbox{\sixpoint\copyright}}$ and its cousins are commercial entities,
whose availability in the future is not guaranteed (nothing is
certain, of course, no matter what distribution method is
chosen). Keeping \splint\ as an archive of a Git repository seems like
diff --git a/support/splint/cweb/references.w b/support/splint/cweb/references.w
index 76dc718d3b..83397c93bb 100644
--- a/support/splint/cweb/references.w
+++ b/support/splint/cweb/references.w
@@ -1,3 +1,19 @@
+@q Copyright 2012-2020, Alexander Shibakov@>
+@q This file is part of SPLinT@>
+
+@q SPLinT is free software: you can redistribute it and/or modify@>
+@q it under the terms of the GNU General Public License as published by@>
+@q the Free Software Foundation, either version 3 of the License, or@>
+@q (at your option) any later version.@>
+
+@q SPLinT is distributed in the hope that it will be useful,@>
+@q but WITHOUT ANY WARRANTY; without even the implied warranty of@>
+@q MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the@>
+@q GNU General Public License for more details.@>
+
+@q You should have received a copy of the GNU General Public License@>
+@q along with SPLinT. If not, see <http://www.gnu.org/licenses/>.@>
+
@** Bibliography. This list of references is not meant to be
exhaustive or complete. These are merely the papers and the books
mentioned in the body of the program above. Naturally, this project
@@ -6,7 +22,6 @@ to list them all due to time and (human) memory limitations.
{%
\def\BASIX{{B\kern-.7ptA\kern-.7ptS\kern-.3pt\lower1.3pt\hbox{I}\kern-.3pt X}}
-\def\MF{{\tt METAFONT}}
\def\bterm#1{\item{[#1]\namedspot{#1bibref}\quad}\ignorespaces}%
\setbox0=\hbox{[ISO/C11]\quad}
\parindent=0pt
@@ -16,6 +31,9 @@ to list them all due to time and (human) memory limitations.
\centerline{\dinkus}%
\smallskip
+\bterm{ACM}Ronald M.~Baecker, Aaron~Marcus, {\it Human Factors and Typography for More Readable Programs},
+Reading, Massachusetts: Addison-Wesley, 1990, xx+344~pp.
+
\bterm{Ah}Alfred V.~Aho et al., {\it Compilers: Principles,
Techniques, and Tools}, Pearson Education, 2006.
@@ -23,10 +41,16 @@ Techniques, and Tools}, Pearson Education, 2006.
Yacc-compatible Parser Generator}, The Free Software Foundation, 2013.
\url{http://www.gnu.org/software/bison/}
+\bterm{CWEB}Donald E. Knuth and Silvio Levy {\it The \CWEB\ System of Structured Documentation},
+Reading, Massachusetts: Addison-Wesley, 1993, iv+227~pp.
+
\bterm{DEK1}Donald E.~Knuth, {\it The \TeX book}, Addison-Wesley Reading, Massachusetts, 1984.
\bterm{DEK2}Donald E.~Knuth {\it The future of \TeX\ and \MF}, TUGboat {\bf 11} (4), p.~489, 1990.
+\bterm{DHB}R.~Kent Dybvig, Robert Hieb, and Carl Bruggeman, {\em Syntactic Abstraction in Scheme},
+Lisp Symb.\ Comput.\ 5, {\bf 4} (Dec.~1992), pp.~295--326.
+
\bterm{Do}Jean-luc Doumont, {\it Pascal pretty-printing: an example of ``preprocessing with \TeX''},
TUGboat {\bf 15} (3), 1994---Proceedings of the 1994 TUG Annual Meeting
@@ -58,11 +82,16 @@ pp.~136--140, 2009---Euro\TeX\ 2009 Proceedings.
\bterm{Jo}Derek M.~Jones, {\it The New C Standard: An Economic and
Cultural Commentary}, available at \url{http://www.knosof.co.uk/cbook/cbook.html}.
+\bterm{KR}B.~Kernighan, D.~Ritchie, {\it The \Cee\ programming language}, Englewood Cliffs, NJ: Prentice Hall, 1978.
+
\bterm{La}{\it The \.{l3regex} package: regular expressions in \TeX}, The \LaTeX3\ Project.
\bterm{Pa}Vern Paxson et al., {\it Lexical Analysis With Flex, for
Flex~2.5.37}, July~2012. \url{http://flex.sourceforge.net/manual/}.
+\bterm{Ra}Norman Ramsey, {\it Literate programming simplified}, IEEE Software, {\bf 11} (5),
+pp.~97--105, 1994.
+
\bterm{Sh}Alexander Shibakov, {\it Parsers in \TeX\ and using \CWEB\ for general pretty-printing},
TUGboat {\bf 35} (1), 2014, available as part of the documentation supplied with \splint.
diff --git a/support/splint/cweb/so.w b/support/splint/cweb/so.w
new file mode 100644
index 0000000000..d7a7696b8c
--- /dev/null
+++ b/support/splint/cweb/so.w
@@ -0,0 +1,835 @@
+@q Copyright (c) 1990 The Regents of the University of California. @>
+@q All rights reserved. @>
+
+@q This code is derived from software contributed to Berkeley by @>
+@q Vern Paxson. @>
+
+@q The United States Government has rights in this work pursuant @>
+@q to contract no. DE-AC03-76SF00098 between the United States @>
+@q Department of Energy and the University of California. @>
+
+@q This file is part of SPLinT. @>
+
+@q Redistribution and use in source and binary forms, with or without @>
+@q modification, are permitted provided that the following conditions @>
+@q are met: @>
+
+@q 1. Redistributions of source code must retain the above copyright @>
+@q notice, this list of conditions and the following disclaimer. @>
+@q 2. Redistributions in binary form must reproduce the above copyright @>
+@q notice, this list of conditions and the following disclaimer in the @>
+@q documentation and/or other materials provided with the distribution. @>
+
+@q Neither the name of the University nor the names of its contributors @>
+@q may be used to endorse or promote products derived from this software @>
+@q without specific prior written permission. @>
+
+@q THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR @>
+@q IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED @>
+@q WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR @>
+@q PURPOSE. @>
+
+@**The lexer for \ifx\flex\UNDEFINED\.{flex}\else\flex\ \fi syntax.
+\ifx\flex\UNDEFINED
+ \input limbo.sty
+ \input grabstates.sty
+ \immediate\openout\stlist=fil_states.h
+\fi
+The original lexer for \flex\ grammar relies on a few rules that use `trailing context'.
+The lexing mechanism implemented by \splint\ cannot process such rules properly in general.
+The rules used by \flex\ match fixed-length trailing context only, which makes it possible
+to replace them with ordinary patterns and use |yyless()| in the actions.
+@(fil.ll@>=
+@G
+%{@> @<Preamble for \flex\ lexer@> @=%}
+ @> @<Options for \flex\ input lexer@> @=
+ @> @<Additional options for \flex\ input lexer@> @=
+ @> @<State definitions for \flex\ input lexer@> @=
+ @> @<Definitions for \flex\ input lexer@> @=
+%%
+ @> @<Postamble for \flex\ input lexer@> @=
+ @> @<Patterns for \flex\ lexer@> @=
+%%
+ @> @<Auxilary code for \flex\ lexer@> @=
+@g
+
+@ @<Preamble for \flex\ lexer@>=
+
+@ There are a few options that are necessary to ensure that the lexer
+functions properly. Some of them (like \.{caseless}) directly
+affect the behavior of the scanner, others (e.g.~\.{noyy\_top\_state})
+prevent generation of unnecessary code.
+@<Options for \flex\ input lexer@>=
+@G
+%option caseless nodefault stack noyy_top_state
+%option nostdinit
+@g
+
+@ @<Additional options for \flex\ input lexer@>=
+@G
+%option bison-bridge
+%option noyywrap nounput noinput reentrant
+%option debug
+%option stack
+%option outfile="fil.c"
+@g
+
+@*1 Regular expression and state definitions.
+The lexer uses a large number of states to control its operation. Both
+section~1 and section~2 rules rely on the scanner being in the
+appropriate state. Otherwise (see \.{symbols.sty} example) the lexer
+may parse the same fragment in a wrong context.
+@<State definitions for \flex\ input lexer@>=
+@G
+%x SECT2 SECT2PROLOG SECT3 CODEBLOCK PICKUPDEF SC CARETISBOL NUM QUOTE
+%x FIRSTCCL CCL ACTION RECOVER COMMENT ACTION_STRING PERCENT_BRACE_ACTION
+%x OPTION LINEDIR CODEBLOCK_MATCH_BRACE
+%x GROUP_WITH_PARAMS
+%x GROUP_MINUS_PARAMS
+%x EXTENDED_COMMENT
+%x COMMENT_DISCARD
+
+@ Somewhat counterintuitively, \flex\ definitions do not {\it always\/} have to be
+fully formed regular expressions. For example, after
+$$
+\hbox to 3in{\flexrenstyle{BOGUS}\hfil\.{\^[a-}}
+$$
+one can form the following action:
+$$
+\hbox to 3in{\flexrenstyle{BOGUS}\.{t]}\hfil\.{;}}
+$$
+although without the `\.{\^}' in the definition of
+`\flexrenstyle{BOGUS}' \flex\ would have put a `\.{)}' inside the
+character class. We will assume such (rather counterproductive) tricks
+are not used. If the definition is not a well-formed regular
+expression the pretty printing will be suspended.
+@<Definitions for \flex\ input lexer@>=
+@G(fs1)
+WS [[:blank:]]+
+OPTWS [[:blank:]]*
+NOT_WS [^[:blank:]\r\n]
+
+NL \r?\n
+
+NAME ([[:alpha:]_][[:alnum:]_-]*)
+NOT_NAME [^[:alpha:]_*\n]+
+
+SCNAME {NAME}
+
+ESCSEQ (\\([^\n]|[0-7]{1,3}|x[[:xdigit:]]{1,2}))
+
+FIRST_CCL_CHAR ([^\\\n]|{ESCSEQ})
+CCL_CHAR ([^\\\n\]]|{ESCSEQ})
+CCL_EXPR ("[:"^?[[:alpha:]]+":]")
+
+LEXOPT [porkacne]
+
+M4QSTART "[["
+M4QEND "]]"
+
+@ @<Postamble for \flex\ input lexer@>=
+
+@*1 Regular expressions for \flex\ input scanner.
+The code below treats \prodstyle{\%pointer} and \prodstyle{\%array} the same way it treats
+\prodstyle{\%option} while typesetting.
+@<Patterns for \flex\ lexer@>=
+@G(fs2)
+<INITIAL>{
+ ^{WS} {@> @[TeX_( "/flindented@@codetrue/yyBEGIN{CODEBLOCK}/yylexnext" );@]@=}
+ ^"/*" {@> @[TeX_( "/yypushstate{COMMENT}/yylexnext" );@]@=}
+ ^#{OPTWS}line{WS} {@> @[TeX_( "/yypushstate{LINEDIR}/yylexnext" );@]@=}
+ ^"%s"{NAME}? {@> @[TeX_( "/yylexreturnptr{SCDECL}" );@]@=}
+ ^"%x"{NAME}? {@> @[TeX_( "/yylexreturnptr{XSCDECL}" );@]@=}
+ ^"%{".*{NL} {@> @<Start a \Cee\ code section@> @=}
+
+ ^"%top"[[:blank:]]*"{"[[:blank:]]*{NL} {@> @<Begin the \prodstyle{\%top} directive@> @=}
+ ^"%top".* {@> @[TeX_( "/yyfatal{malformed '/harmlesscomment top' directive}" );@] @=}
+
+ {WS} {@> @[;@]/* discard */ @=}
+
+ ^"%%".* {@> @<Start section 2@> @=}
+
+ ^"%pointer".*{NL} {@> @[TeX_( "/flinc@@linenum/yylexreturn{POINTER_OP}" );@]@=}
+ ^"%array".*{NL} {@> @[TeX_( "/flinc@@linenum/yylexreturn{ARRAY_OP}" );@]@=}
+
+ ^"%option" {@> @[TeX_( "/yyBEGIN{OPTION}/yylexreturn{OPTION_OP}" );@]@=}
+
+ ^"%"{LEXOPT}{OPTWS}[[:digit:]]*{OPTWS}{NL} {@> @[TeX_( "/flinc@@linenum/yyflexoptreturn{OPT_DEPRECATED}" );@]@=}
+ ^"%"{LEXOPT}{WS}.*{NL} {@> @[TeX_( "/flinc@@linenum/yyflexoptreturn{OPT_DEPRECATED}" );@]@=}
+
+ ^"%"[^porksexcan{}].* {@> @[TeX_( "/yyfatal{unrecognized '/harmlesscomment' directive: /the/yytext}" );@] @=}
+
+ ^{NAME} {@> @<Copy the name and start a definition@> @=}
+ {SCNAME} @> @[TeX_( "/RETURNNAME" );@] @=
+ ^{OPTWS}{NL} {@> @[TeX_( "/flinc@@linenum/yylexnext" );@]/* allows blank lines in section 1 */@=}
+ {OPTWS}{NL} {@> @[TeX_( "/flinc@@linenum/yylexnext" );@]/* maybe end of comment line */@=}
+}
+
+@ @<Start a \Cee\ code section@>=
+ @[TeX_( "/flinc@@linenum" );@]@;
+ @[TeX_( "/flindented@@codefalse/yyBEGIN{CODEBLOCK}" );@]@;
+ @[TeX_( "/yylexnext" );@]@;
+
+@ Ignore setting |brace_start_line| as it is only used internally to report errors.
+@<Begin the \prodstyle{\%top} directive@>=
+ @[TeX_( "/flinc@@linenum" );@]@;
+ @[TeX_( "/def/flbrace@@depth{1}" );@]@;
+ @[TeX_( "/yypushstate{CODEBLOCK_MATCH_BRACE}/yylexnext" );@]@;
+
+@ @<Start section 2@>=
+ @[TeX_( "/def/flsectnum{2}/def/flbracelevel{0}" );@]@;
+ @[TeX_( "/yyBEGIN{SECT2PROLOG}/yylexreturnptr{SECTEND}" );@]@;
+
+@ @<Copy the name and start a definition@>=
+ @[TeX_( "/fldidadeffalse/yyBEGIN{PICKUPDEF}" );@]@;
+ @[TeX_( "/yylexreturnsym{DEF_OP}" );@]@;
+
+@ @<Patterns for \flex\ lexer@>=
+@G(fs2)
+<COMMENT>{
+ "*/" {@> @[TeX_( "/yypopstate/yylexnext" );@]@=}
+ "*" {@> @[TeX_( "/yylexnext" );@]@=}
+ {M4QSTART} {@> @[TeX_( "/yylexnext" );@]@=}
+ {M4QEND} {@> @[TeX_( "/yylexnext" );@]@=}
+ [^*\n] {@> @[TeX_( "/yylexnext" );@]@=}
+ {NL} {@> @[TeX_( "/flinc@@linenum/yylexnext" );@]@=}
+}
+
+/* This is the same as \flexsnstyle{COMMENT}, but is discarded rather than output. */
+<COMMENT_DISCARD>{
+ "*/" {@> @[TeX_( "/yypopstate/yylexnext" );@]@=}
+ "*" {@> @[TeX_( "/yylexnext" );@]@=}
+ [^*\n] {@> @[TeX_( "/yylexnext" );@]@=}
+ {NL} {@> @[TeX_( "/flinc@@linenum/yylexnext" );@]@=}
+}
+
+<EXTENDED_COMMENT>{
+ ")" {@> @[TeX_( "/yypopstate/yylexnext" );@]@=}
+ [^\n\)]+ {@> @[TeX_( "/yylexnext" );@]@=}
+ {NL} {@> @[TeX_( "/flinc@@linenum/yylexnext" );@]@=}
+}
+
+<LINEDIR>{
+ \n {@> @[TeX_( "/yypopstate/yylexnext" );@]@=}
+ [[:digit:]]+ {@> @[TeX_( "/fllinenum=/number/yytext/yylexnext" );@]@=}
+ \"[^"\n]*\" {@> @[TeX_( "/yylexnext" );@] /* ignore the file name in the line directives */ @=}
+ . {@> @[TeX_( "/yylexnext" );@] /* ignore spurious characters */ @=}
+}
+
+<CODEBLOCK>{
+ ^"%}".*{NL} {@> @[TeX_( "/flinc@@linenum/yyBEGIN{INITIAL}/yylexnext" );@]@=}
+ {M4QSTART} {@> @[TeX_( "/yylexnext" );@]@=}
+ {M4QEND} {@> @[TeX_( "/yylexnext" );@]@=}
+ . {@> @[TeX_( "/yylexnext" );@]@=}
+ {NL} {@> @[TeX_( "/flinc@@linenum/ifflindented@@code/yyBEGIN{INITIAL}/fi/yylexnext" );@]@=}
+}
+
+<CODEBLOCK_MATCH_BRACE>{
+ "}" {@> @<Pop state if code braces match@> @=}
+ "{" {@> @[TeX_( "/flinc/flbrace@@depth/yylexnext" );@] @=}
+ {NL} {@> @[TeX_( "/flinc@@linenum/yylexnext" );@]@=}
+ {M4QSTART} {@> @[TeX_( "/yylexnext" );@]@=}
+ {M4QEND} {@> @[TeX_( "/yylexnext" );@]@=}
+ [^{}\r\n] {@> @[TeX_( "/yylexnext" );@]@=}
+ <<EOF>> {@> @[TeX_( "/yyfatal{Unmatched '/lbchar'}" );@] @=}
+}
+
+@ @<Pop state if code braces match@>=
+ @[TeX_( "/fldec/flbrace@@depth" );@]@;
+ @[TeX_( "/ifnum/flbrace@@depth=/z@@/relax" );@]@;
+ @[TeX_( " /yypopstate/yylexreturnxchar/n" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /yylexnext" );@]@;
+ @[TeX_( "/fi" );@]@;
+
+@ @<Patterns for \flex\ lexer@>=
+@G(fs2)
+<PICKUPDEF>{
+ {WS} {@> @[TeX_( "/yylexnext" );@]@=}
+ {NOT_WS}[^\r\n]* {@> @<Skip trailing whitespace, save the definition@> @=}
+ {NL} {@> @<Complain if not inside a definition, continue otherwise@> @=}
+}
+
+@ @<Skip trailing whitespace, save the definition@>=
+ @[TeX_( "/edef/flnmdef{{/the/yytext}{/the/yytextpure}{/the/yyfmark}{/the/yysmark}}" );@]@;
+ @[TeX_( "/fldidadeftrue/yylexnext" );@]@;
+
+@ @<Complain if not inside a definition, continue otherwise@>=
+ @[TeX_( "/iffldidadef" );@]@;
+ @[TeX_( " /yylval/expandafter{/flnmdef}" );@]@;
+ @[TeX_( " /def/next{/flinc@@linenum/yyBEGIN{INITIAL}/yylexreturn{RE_DEF}}" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /def/next{/yyfatal{incomplete name definition}}" );@]@;
+ @[TeX_( "/fi/next" );@]@;
+
+@ @<Patterns for \flex\ lexer@>=
+@G(fs2)
+<OPTION>{
+ {NL} {@> @[TeX_( "/flinc@@linenum/yyBEGIN{INITIAL}/yylexnext" );@] @=}
+ {WS} {@> @[TeX_( "/floption@@sensetrue/yylexnext" );@] @=}
+
+ "=" {@> @[TeX_( "/yylexreturnchar" );@]@=}
+
+ no {@> @<Toggle |option_sense|@> @=};
+
+ 7bit {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ 8bit {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+
+ align {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ always-interactive {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+
+ array {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ ansi-definitions {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ ansi-prototypes {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ backup {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ batch {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ bison-bridge {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ bison-locations {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+
+ "c++" {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ caseful|case-sensitive {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ caseless|case-insensitive {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ debug {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ default {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ ecs {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ fast {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+
+ full {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+
+ input {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ interactive {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ lex-compat {@> @<Set |lex_compat|@> @=}
+ posix-compat {@> @<Set |posix_compat|@> @=}
+ main {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+
+ meta-ecs {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ never-interactive {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+
+ perf-report {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ pointer {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ read {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ reentrant {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ reject {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ stack {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ stdinit {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ stdout {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ unistd {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ unput {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ verbose {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ warn {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yylineno {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yymore {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yywrap {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+
+ yy_push_state {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yy_pop_state {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yy_top_state {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+
+ yy_scan_buffer {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yy_scan_bytes {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yy_scan_string {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+
+ yyalloc {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yyrealloc {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yyfree {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+
+ yyget_debug {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yyset_debug {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yyget_extra {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yyset_extra {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yyget_leng {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yyget_text {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yyget_lineno {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yyset_lineno {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yyget_in {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yyset_in {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yyget_out {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yyset_out {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yyget_lval {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yyset_lval {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yyget_lloc {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+ yyset_lloc {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+
+ extra-type {@> @[TeX_( "/yylexreturn{OPT_EXTRA_TYPE}" );@]@=}
+ outfile {@> @[TeX_( "/yylexreturn{OPT_OUTFILE}" );@]@=}
+ prefix {@> @[TeX_( "/yylexreturn{OPT_PREFIX}" );@]@=}
+ yyclass {@> @[TeX_( "/yylexreturn{OPT_YYCLASS}" );@]@=}
+ header(-file)? {@> @[TeX_( "/yylexreturn{OPT_HEADER}" );@]@=}
+ tables-file {@> @[TeX_( "/yylexreturn{OPT_TABLES}" );@]@=}
+ tables-verify {@> @[TeX_( "/yyflexoptreturn{OPT_OTHER}" );@]@=}
+
+ \"[^"\n]*\" {@> @[TeX_( "/edef/flnmstr{{/the/yytext}{/the/yytextpure}}/yylexreturnsym{NAME}" );@]@=}
+
+ (([a-mo-z]|n[a-np-z])[[:alpha:]\-+]*)|. {@> @[TeX_( "/yyfatal{unrecognized /%option: /the/yytext}" );@]@=}
+}
+
+@ @<Toggle |option_sense|@>=
+ @[TeX_( "/iffloption@@sense" );@]@;
+ @[TeX_( " /floption@@sensefalse" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /floption@@sensetrue" );@]@;
+ @[TeX_( "/fi/yylexnext" );@]@;
+
+@ @<Set |lex_compat|@>=
+ @[TeX_( "/iffloption@@sense" );@]@;
+ @[TeX_( " /fllex@@compattrue" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /fllex@@compatfalse" );@]@;
+ @[TeX_( "/fi/yyflexoptreturn{OPT_OTHER}" );@]@;
+
+@ @<Set |posix_compat|@>=
+ @[TeX_( "/iffloption@@sense" );@]@;
+ @[TeX_( " /flposix@@compattrue" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /flposix@@compatfalse" );@]@;
+ @[TeX_( "/fi/yyflexoptreturn{OPT_OTHER}" );@]@;
+
+@ The \flexsnstyle{RECOVER} state is never used for typesetting and is only added for completeness.
+@<Patterns for \flex\ lexer@>=
+@G(fs2)
+<RECOVER>.*{NL} {@> @[TeX_( "/flinc@@linenum/yyBEGIN{INITIAL}/yylexnext" );@] @=}
+
+@ Like \bison, \flex\ allows insertion of \Cee\ code in the middle of the input file.
+\saveparseoutputtrue
+@<Patterns for \flex\ lexer@>=
+@G(fs2)
+<SECT2PROLOG>{
+ ^"%{".* {@> @<Consume the brace and increment the brace level@> @=}
+ ^"%}".* {@> @<Consume the brace and decrement the brace level@> @=}
+
+ ^{WS}.* {@> @[TeX_( "/yylexnext" );@]@=}
+
+ ^{NOT_WS}.* {@> @<Begin section 2, prepare to reread, or ignore braced code@> @=}
+ . {@> @[TeX_( "/yylexnext" );@] @=}
+ {NL} {@> @[TeX_( "/flinc@@linenum/yylexnext" );@] @=}
+
+ <<EOF>> {@> @[TeX_( "/def/flsectnum{0}/yyterminate" );@] @=}
+}
+
+@ All the code inside is ignored.
+\saveparseoutputfalse
+@<Consume the brace and increment the brace level@>=
+ @[TeX_( "/flinc/flbracelevel/yyless{2}/yylexnext" );@]@;
+
+@ @<Consume the brace and decrement the brace level@>=
+ @[TeX_( "/fldec/flbracelevel/yyless{2}/yylexnext" );@]@;
+
+@ @<Begin section 2, prepare to reread, or ignore braced code@>=
+ @[TeX_( "/ifnum/flbracelevel>/z@@" );@]@;
+ @[TeX_( " /let/next/yylexnext" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /def/next{/yysetbol{/@@ne}/yyBEGIN{SECT2}/yyless{0}/yylexnext}" );@]@;
+ @[TeX_( "/fi/next" );@]@;
+
+@ A pattern below (for the character class processing) had to be broken into two lines.
+A symbol ($\odot$@^$\odot$ separator, \flex@>) was inserted to indicate that a break had occured. The macros for \flex\
+typesetting use a different mechanism from that of \bison\ macros and allow typographic
+corrections to be applied to sections of the \flex\ code represented by various nonterminals.
+These corrections can also be delayed. For the details, an interested reader may consult
+\.{yyunion.sty}.
+@<Patterns for \flex\ lexer@>=
+@G(fs2)
+<SECT2>{
+ ^{OPTWS}{NL} {@> @[TeX_( "/flinc@@linenum/yylexnext" );@] /* allow blank lines in section 2 */ @=}
+ ^{OPTWS}"%{" {@> @<Start braced code in section 2@> @=}
+ ^{OPTWS}"<" {@> @[TeX_( "/ifflsf@@skip@@ws/else/yyBEGIN{SC}/fi/yylexreturnraw<" );@] @=}
+ ^{OPTWS}"^" {@> @[TeX_( "/yylexreturnraw^" );@] @=}
+ \" {@> @[TeX_( "/yyBEGIN{QUOTE}/yylexreturnxchar/flquotechar" );@] @=}
+ "{"[[:digit:]] {@> @<Process a repeat pattern@> @=}
+ "$"([[:blank:]]|{NL}) {@> @[TeX_( "/yyless{1}/yylexreturnraw/$" );@] @=}
+
+ {WS}"%{" {@> @<Process braced code in the middle of section 2@> @=}
+ {WS}"|".*{NL} {@> @<Process a deferred action@> @=}
+ ^{WS}"/*" {@> @<Process a comment inside a pattern@> @=}
+ ^{WS} @> ; /* allow indented rules */@=
+ {WS} {@> @<Decide whether to start an action or skip whitespace inside a rule@> @=}
+
+ {OPTWS}{NL} {@> @<Finish the line and/or action@> @=}
+
+ ^{OPTWS}"<<EOF>>" |
+ "<<EOF>>" {@> @[TeX_( "/yylexreturnptr{EOF_OP}" );@] @=}
+
+ ^"%%".* {@> @<Start section 3@> @=}
+@t}\vb{\insertraw{\insrulealign{\rulealigntemplate}{\cr\egroup\egroup}}}{@>
+ "["@>@t}\vb{\insertraw{\insparensalign{&}{}}}{@>@=({FIRST_CCL_CHAR}|{CCL_EXPR})@>@t}\vb{\insertraw{\insparensalign{\rlap{$\odot$}\cr&}{}}}{@>@=({CCL_CHAR}|{CCL_EXPR})* {@> @<Start processing a character class@> @=}
+
+ "{-}" {@> @[TeX_( "/yylexreturn{CCL_OP_DIFF}" );@] @=}
+ "{+}" {@> @[TeX_( "/yylexreturn{CCL_OP_UNION}" );@] @=}
+
+ "{"{NAME}"}"[[:space:]]? {@> @<Process a named expression after checking for whitespace at the end@> @=}
+
+ "/*" {@> @<Decide if this is a comment@> @=}
+ "(?#" {@> @<Determine if this is extended syntax or return a parenthesis@> @=}
+ "(?" {@> @<Determine if this is a parametric group or return a parenthesis@> @=}
+ "(" {@> @[TeX_( "/flsf@@push/yylexreturnraw/(" );@] @=}
+ ")" {@> @[TeX_( "/flsf@@pop/yylexreturnraw/)" );@] @=}
+
+ [/|*+?.(){}] {@> @[TeX_( "/yylexreturnchar" );@] @=}
+ . {@> @[TeX_( "/RETURNCHAR" );@] @=}
+}
+
+@ @<Start braced code in section 2@>=
+ @[TeX_( "/def/flbracelevel{1}" );@]@;
+ @[TeX_( "/indented@@codefalse/doing@@codeblocktrue" );@]@;
+ @[TeX_( "/yyBEGIN{PERCENT_BRACE_ACTION}" );@]@;
+ @[TeX_( "/yylexnext" );@]@;
+
+@ @<Process a repeat pattern@>=
+ @[TeX_( "/yyless{1}/yyBEGIN{NUM}" );@]@;
+ @[TeX_( "/iffllex@@compat" );@]@;
+ @[TeX_( " /def/next{/yylexreturn{BEGIN_REPEAT_POSIX}}" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /ifflposix@@compat" );@]@;
+ @[TeX_( " /def/next{/yylexreturn{BEGIN_REPEAT_POSIX}}" );@]@;
+ @[TeX_( " /else" );@]@;
+ @[TeX_( " /def/next{/yylexreturn{BEGIN_REPEAT_FLEX}}" );@]@;
+ @[TeX_( " /fi" );@]@;
+ @[TeX_( "/fi/next" );@]@;
+
+@ @<Process braced code in the middle of section 2@>=
+ @[TeX_( "/def/flbracelevel{1}" );@]@;
+ @[TeX_( "/yyBEGIN{PERCENT_BRACE_ACTION}" );@]@;
+ @[TeX_( "/ifflin@@rule" );@]@;
+ @[TeX_( " /fldoing@@rule@@actiontrue" );@]@;
+ @[TeX_( " /flin@@rulefalse" );@]@;
+ @[TeX_( " /def/next{/yylexreturnxchar/n}" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /let/next/yylexnext" );@]@;
+ @[TeX_( "/fi/next" );@]@;
+
+@ This action has been changed to accomodate the new grammar. The separator (\.{\yl})
+is treated as an ordinary (empty) action.
+@<Process a deferred action@>=
+ @[TeX_( "/ifflsf@@skip@@ws" );@]@;/* whitespace ignored, still inside a pattern */
+ @[TeX_( " /yylessafter{|}" );@]@;
+ @[TeX_( " /let/next/yylexnext" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /flinc@@linenum" );@]@;
+ @[TeX_( " /fldoing@@rule@@actiontrue" );@]@;
+ @[TeX_( " /flin@@rulefalse" );@]@;
+ @[TeX_( " /flcontinued@@actiontrue" );@]@;
+ @[TeX_( " /unput{/n}" );@]@;
+ @[TeX_( " /yyBEGIN{ACTION}" );@]@;
+ @[TeX_( " /edef/next{/nx/yylexreturnxchar/n}" );@]@;
+ @[TeX_( "/fi/next" );@]@;
+
+@ @<Process a comment inside a pattern@>=
+ @[TeX_( "/ifflsf@@skip@@ws" );@]@;
+ @[TeX_( " /yypushstate{COMMENT_DISCARD}" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /unput{//*}" );@]@;
+ @[TeX_( " /def/flbracelevel{0}" );@]@;
+ @[TeX_( " /flcontinued@@actionfalse" );@]@;
+ @[TeX_( " /yyBEGIN{ACTION}" );@]@;
+ @[TeX_( "/fi/yylexnext" );@]@;
+
+@ @<Decide whether to start an action or skip whitespace inside a rule@>=
+ @[TeX_( "/ifflsf@@skip@@ws" );@]@;
+ @[TeX_( " /let/next/yylexnext" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /def/flbracelevel{0}" );@]@;
+ @[TeX_( " /flcontinued@@actionfalse" );@]@;
+ @[TeX_( " /yyBEGIN{ACTION}" );@]@;
+ @[TeX_( " /ifflin@@rule" );@]@;
+ @[TeX_( " /fldoing@@rule@@actiontrue" );@]@;
+ @[TeX_( " /flin@@rulefalse" );@]@;
+ @[TeX_( " /def/next{/yylexreturnxchar/n}" );@]@;
+ @[TeX_( " /else" );@]@;
+ @[TeX_( " /let/next/yylexnext" );@]@;
+ @[TeX_( " /fi" );@]@;
+ @[TeX_( "/fi/next" );@]@;
+
+@ @<Finish the line and/or action@>=
+ @[TeX_( "/ifflsf@@skip@@ws" );@]@;
+ @[TeX_( " /flinc@@linenum" );@]@;
+ @[TeX_( " /let/next/yylexnext" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /def/flbracelevel{0}" );@]@;
+ @[TeX_( " /flcontinued@@actionfalse" );@]@;
+ @[TeX_( " /yyBEGIN{ACTION}" );@]@;
+ @[TeX_( " /unput{/n}" );@]@;
+ @[TeX_( " /ifflin@@rule" );@]@;
+ @[TeX_( " /fldoing@@rule@@actiontrue" );@]@;
+ @[TeX_( " /flin@@rulefalse" );@]@;
+ @[TeX_( " /def/next{/yylexreturnxchar/n}" );@]@;
+ @[TeX_( " /else" );@]@;
+ @[TeX_( " /let/next/yylexnext" );@]@;
+ @[TeX_( " /fi" );@]@;
+ @[TeX_( "/fi/next" );@]@;
+
+@ @<Start section 3@>=
+ @[TeX_( "/def/flsectnum{3}" );@]@;
+ @[TeX_( "/yyBEGIN{SECT3}" );@]@;
+ @[TeX_( "/yyterminate" );@]@;
+
+@ @<Start processing a character class@>=
+ @[TeX_( "/edef/flnmstr{/the/yytext}" );@]@;
+ @[TeX_( "/yyless{1}" );@]@;
+ @[TeX_( "/yyBEGIN{FIRSTCCL}" );@]@;
+ @[TeX_( "/yylexreturnraw[" );@]@;
+
+@ Return a special \prodstyle{CHAR} and return the whitespace back into the input.
+The braces and the possible trailing whitespace will be dealt with by the typesetting code.
+@<Process a named expression after checking for whitespace at the end@>=
+ @[TeX_( "/edef/flend@@ch{/the/yytextlastchar}" );@]@;
+ @[TeX_( "/ifnum/flend@@ch=`/}/relax" );@]@;
+ @[TeX_( " /flend@@is@@wsfalse" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /flend@@is@@wstrue" );@]@;
+ @[TeX_( "/fi" );@]@;
+ @[TeX_( "/toksa/expandafter{/astformat@@flnametok}" );@]@;
+ @[TeX_( "/let/astformat@@flnametok/empty" );@]@;
+ @[TeX_( "/edef/next{/yylval{{/nx/flnametok{/the/yytext}{/the/toksa}}{}{/the/yyfmark}{/the/yysmark}}}/next" );@]@;
+ @[TeX_( "/ifflend@@is@@ws" );@]@;
+ @[TeX_( " /unput{ }" );@]@;
+ @[TeX_( "/fi" );@]@;
+ @[TeX_( "/yylexreturn{CHAR}" );@]@;
+
+@ @<Decide if this is a comment@>=
+ @[TeX_( "/ifflsf@@skip@@ws" );@]@;
+ @[TeX_( " /yypushstate{COMMENT_DISCARD}" );@]@;
+ @[TeX_( " /yylexnext" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /yyless{1}" );@]@;
+ @[TeX_( " /yylexreturnraw//" );@]@;
+ @[TeX_( "/fi" );@]@;
+
+@ @<Determine if this is extended syntax or return a parenthesis@>=
+ @[TeX_( "/iffllex@@compat" );@]@;
+ @[TeX_( " /def/next{/yyless{1}/flsf@@push/yylexreturnraw(}" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /ifflposix@@compat" );@]@;
+ @[TeX_( " /def/next{/yyless{1}/flsf@@push/yylexreturnraw(}" );@]@;
+ @[TeX_( " /else" );@]@;
+ @[TeX_( " /def/next{/yypushstate{EXTENDED_COMMENT}}" );@]@;
+ @[TeX_( " /fi" );@]@;
+ @[TeX_( "/fi/next" );@]@;
+
+@ @<Determine if this is a parametric group or return a parenthesis@>=
+ @[TeX_( "/flsf@@push" );@]@;
+ @[TeX_( "/iffllex@@compat" );@]@;
+ @[TeX_( " /def/next{/yyless{1}}" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /ifflposix@@compat" );@]@;
+ @[TeX_( " /def/next{/yyless{1}}" );@]@;
+ @[TeX_( " /else" );@]@;
+ @[TeX_( " /def/next{/yyBEGIN{GROUP_WITH_PARAMS}}" );@]@;
+ @[TeX_( " /fi" );@]@;
+ @[TeX_( "/fi/next" );@]@;
+ @[TeX_( "/yylexreturnraw(" );@]@;
+
+@ @<Patterns for \flex\ lexer@>=
+@G(fs2)
+<SC>{
+ {OPTWS}{NL}{OPTWS} {@> @[TeX_( "/flinc@@linenum" );@] /* allow blank lines and continuations */@+@=}@>
+ [,*] {@> @[TeX_( "/yylexreturnchar" );@] @=}@>
+ ">" {@> @[TeX_( "/yyBEGIN{SECT2}/yylexreturnchar" );@] @=}
+ ">"^ {@> @[TeX_( "/yyBEGIN{CARETISBOL}/yyless{1}/yylexreturnraw>" );@] @=}
+ {SCNAME} {@> @[TeX_( "/RETURNNAME" );@] @=}
+ . {@> @[TeX_( "/yyfatal{bad <start condition>: /the/yytext}" );@] @=}
+}
+
+<CARETISBOL>"^" {@> @[TeX_( "/yyBEGIN{SECT2}/yylexreturnchar" );@] @=}
+
+<QUOTE>{
+ [^"\n] {@> @[TeX_( "/RETURNCHAR" );@] @=}
+ \" {@> @[TeX_( "/yyBEGIN{SECT2}/yylexreturnxchar/flquotechar" );@] @=}
+
+ {NL} {@> @[TeX_( "/yyfatal{missing quote}" );@] @=}
+}
+
+<GROUP_WITH_PARAMS>{
+ ":" {@> @[TeX_( "/yyBEGIN{SECT2}/yylexnext" );@] @=}
+ "-" {@> @[TeX_( "/yyBEGIN{GROUP_MINUS_PARAMS}/yylexnext" );@] @=}
+ i {@> @[TeX_( "/flsf@@case@@instrue/yylexnext" );@] @=}
+ s {@> @[TeX_( "/flsf@@dot@@alltrue/yylexnext" );@] @=}
+ x {@> @[TeX_( "/flsf@@skip@@wstrue/yylexnext" );@] @=}
+}
+
+<GROUP_MINUS_PARAMS>{
+ ":" {@> @[TeX_( "/yyBEGIN{SECT2}/yylexnext" );@] @=}
+ i {@> @[TeX_( "/flsf@@case@@insfalse/yylexnext" );@] @=}
+ s {@> @[TeX_( "/flsf@@dot@@allfalse/yylexnext" );@] @=}
+ x {@> @[TeX_( "/flsf@@skip@@wsfalse/yylexnext" );@] @=}
+}
+
+<FIRSTCCL>{
+ "^"[^-\]\n] {@> @[TeX_( "/yyBEGIN{CCL}/yyless{1}/yylexreturnraw^" );@] @=}
+ "^"("-"|"]") {@> @[TeX_( "/yyless{1}/yylexreturnraw^" );@] @=}
+ . {@> @[TeX_( "/yyBEGIN{CCL}/RETURNCHAR" );@] @=}
+}
+
+<CCL>{
+ -[^\]\n] {@> @[TeX_( "/yyless{1}/yylexreturnraw-" );@] @=}
+ [^\]\n] {@> @[TeX_( "/RETURNCHAR" );@] @=}
+ "]" {@> @[TeX_( "/yyBEGIN{SECT2}/yylexreturnchar" );@] @=}
+ .|{NL} {@> @[TeX_( "/yyfatal{bad character class}" );@] @=}
+}
+
+<FIRSTCCL,CCL>{
+ "[:alnum:]" {@> @[TeX_( "/xcclreturn{CCE_ALNUM}" );@] @=}
+ "[:alpha:]" {@> @[TeX_( "/xcclreturn{CCE_ALPHA}" );@] @=}
+ "[:blank:]" {@> @[TeX_( "/xcclreturn{CCE_BLANK}" );@] @=}
+ "[:cntrl:]" {@> @[TeX_( "/xcclreturn{CCE_CNTRL}" );@] @=}
+ "[:digit:]" {@> @[TeX_( "/xcclreturn{CCE_DIGIT}" );@] @=}
+ "[:graph:]" {@> @[TeX_( "/xcclreturn{CCE_GRAPH}" );@] @=}
+ "[:lower:]" {@> @[TeX_( "/xcclreturn{CCE_LOWER}" );@] @=}
+ "[:print:]" {@> @[TeX_( "/xcclreturn{CCE_PRINT}" );@] @=}
+ "[:punct:]" {@> @[TeX_( "/xcclreturn{CCE_PUNCT}" );@] @=}
+ "[:space:]" {@> @[TeX_( "/xcclreturn{CCE_SPACE}" );@] @=}
+ "[:upper:]" {@> @[TeX_( "/xcclreturn{CCE_UPPER}" );@] @=}
+ "[:xdigit:]" {@> @[TeX_( "/xcclreturn{CCE_XDIGIT}" );@] @=}
+
+ "[:^alnum:]" {@> @[TeX_( "/xcclreturn{CCE_NEG_ALNUM}" );@] @=}
+ "[:^alpha:]" {@> @[TeX_( "/xcclreturn{CCE_NEG_ALPHA}" );@] @=}
+ "[:^blank:]" {@> @[TeX_( "/xcclreturn{CCE_NEG_BLANK}" );@] @=}
+ "[:^cntrl:]" {@> @[TeX_( "/xcclreturn{CCE_NEG_CNTRL}" );@] @=}
+ "[:^digit:]" {@> @[TeX_( "/xcclreturn{CCE_NEG_DIGIT}" );@] @=}
+ "[:^graph:]" {@> @[TeX_( "/xcclreturn{CCE_NEG_GRAPH}" );@] @=}
+ "[:^lower:]" {@> @[TeX_( "/xcclreturn{CCE_NEG_LOWER}" );@] @=}
+ "[:^print:]" {@> @[TeX_( "/xcclreturn{CCE_NEG_PRINT}" );@] @=}
+ "[:^punct:]" {@> @[TeX_( "/xcclreturn{CCE_NEG_PUNCT}" );@] @=}
+ "[:^space:]" {@> @[TeX_( "/xcclreturn{CCE_NEG_SPACE}" );@] @=}
+ "[:^upper:]" {@> @[TeX_( "/xcclreturn{CCE_NEG_UPPER}" );@] @=}
+ "[:^xdigit:]" {@> @[TeX_( "/xcclreturn{CCE_NEG_XDIGIT}" );@] @=}
+ {CCL_EXPR} {@> @[TeX_( "/yyfatal{bad character class expression: /the/yytext}" );@] @=}
+}
+
+<NUM>{
+ [[:digit:]]+ {@> @[TeX_( "/yylexreturnval{NUMBER}" );@] @=}
+
+ "," {@> @[TeX_( "/yylexreturnchar" );@] @=}
+ "}" {@> @<Finish the repeat pattern@> @=}
+ . {@> @[TeX_( "/yyfatal{bad character inside {}'s}" );@] @=}
+
+ {NL} {@> @[TeX_( "/yyfatal{missing /nx/}}" );@] @=}
+}
+
+@ @<Finish the repeat pattern@>=
+ @[TeX_( "/yyBEGIN{SECT2}" );@]@;
+ @[TeX_( "/iffllex@@compat" );@]@;
+ @[TeX_( " /def/next{/yylexreturn{END_REPEAT_POSIX}}" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /ifflposix@@compat" );@]@;
+ @[TeX_( " /def/next{/yylexreturn{END_REPEAT_POSIX}}" );@]@;
+ @[TeX_( " /else" );@]@;
+ @[TeX_( " /def/next{/yylexreturn{END_REPEAT_FLEX}}" );@]@;
+ @[TeX_( " /fi" );@]@;
+ @[TeX_( "/fi/next" );@]@;
+
+
+@ @<Patterns for \flex\ lexer@>=
+@G(fs2)
+<PERCENT_BRACE_ACTION>{
+ {OPTWS}"%}".* {@> @[TeX_( "/def/flbracelevel{0}/yylexnext" );@] @=}
+
+ <ACTION>"/*" {@> @[TeX_( "/yypushstate{COMMENT}/yylexnext" );@] @=}
+
+ <CODEBLOCK,ACTION>{
+ "reject" {@> @[TeX_( "/yylexnext" );@]@=}
+ "yymore" {@> @[TeX_( "/yylexnext" );@]@=}
+ }
+
+ {M4QSTART} {@> @[TeX_( "/yylexnext" );@]@=}
+ {M4QEND} {@> @[TeX_( "/yylexnext" );@]@=}
+ . {@> @[TeX_( "/yylexnext" );@]@=}
+ {NL} {@> @<Process a newline inside a braced group@> @=}
+}
+
+@ This actions has been modified to output \prodstyle{'\\n'}.
+@<Process a newline inside a braced group@>=
+ @[TeX_( "/flinc@@linenum" );@]@;
+ @[TeX_( "/ifnum/flbracelevel=/z@@" );@]@;
+ @[TeX_( " /iffldoing@@rule@@action" );@]@;
+ @[TeX_( " /yylexreturnxchar/n" );@]@;
+ @[TeX_( " /else" );@]@;
+ @[TeX_( " /yylexnext" );@]@;
+ @[TeX_( " /fi" );@]@;
+ @[TeX_( " /fldoing@@rule@@actionfalse" );@]@;
+ @[TeX_( " /fldoing@@codeblockfalse" );@]@;
+ @[TeX_( " /yyBEGIN{SECT2}" );@]@;
+ @[TeX_( "/else" );@]@;
+ @[TeX_( " /iffldoing@@codeblock" );@]@;
+ @[TeX_( " /ifflindented@@code" );@]@;
+ @[TeX_( " /fldoing@@rule@@actionfalse" );@]@;
+ @[TeX_( " /fldoing@@codeblockfalse" );@]@;
+ @[TeX_( " /yyBEGIN{SECT2}" );@]@;
+ @[TeX_( " /fi" );@]@;
+ @[TeX_( " /fi" );@]@;
+ @[TeX_( " /yylexnext" );@]@;
+ @[TeX_( "/fi" );@]@;
+
+@ @<Patterns for \flex\ lexer@>=
+@G(fs2)
+/* |reject| and |yymore()| are checked for above, in \flexsnstyle{PERCENT\_BRACE\_ACTION} */
+<ACTION>{
+ "{" {@> @[TeX_( "/flinc/flbracelevel/yylexnext" );@] @=}
+ "}" {@> @[TeX_( "/fldec/flbracelevel/yylexnext" );@] @=}
+ {M4QSTART} {@> @[TeX_( "/yylexnext" );@]@=}
+ {M4QEND} {@> @[TeX_( "/yylexnext" );@]@=}
+ [^[:alpha:]_{}"'/\n\[\]]+ {@> @[TeX_( "/yylexnext" );@]@=}
+ [\[\]] {@> @[TeX_( "/yylexnext" );@]@=}
+ {NAME} {@> @[TeX_( "/yylexnext" );@]@=}
+ "'"([^'\\\n]|\\.)*"'" {@> @[TeX_( "/yylexnext" );@]@=}
+ \" {@> @[TeX_( "/yyBEGIN{ACTION_STRING}/yylexnext" );@]@=}
+ {NL} {@> @<Process a newline inside an action@> @=}
+ . {@> @[TeX_( "/yylexnext" );@]@=}
+}
+
+@ This actions has been modified to output \prodstyle{'\\n'}.
+@<Process a newline inside an action@>=
+ @[TeX_( "/flinc@@linenum" );@]@;
+ @[TeX_( "/ifnum/flbracelevel=/z@@" );@]@;
+ @[TeX_( " /iffldoing@@rule@@action" );@]@;
+ @[TeX_( " /yylexreturnxchar/n" );@]@;
+ @[TeX_( " /else" );@]@;
+ @[TeX_( " /yylexnext" );@]@;
+ @[TeX_( " /fi" );@]@;
+ @[TeX_( " /fldoing@@rule@@actionfalse" );@]@;
+ @[TeX_( " /yyBEGIN{SECT2}" );@]@;
+ @[TeX_( "/fi" );@]@;
+
+@ @<Patterns for \flex\ lexer@>=
+@G(fs2)
+<ACTION_STRING>{
+ [^"\\\n]+ {@> @[TeX_( "/yylexnext" );@] @=}
+ \\. {@> @[TeX_( "/yylexnext" );@] @=}
+ {NL} {@> @[TeX_( "/flinc@@linenum/yyBEGIN{ACTION}/yylexnext" );@] @=}
+ \" {@> @[TeX_( "/yyBEGIN{ACTION}/yylexnext" );@] @=}
+ . {@> @[TeX_( "/yylexnext" );@] @=}
+}
+
+<COMMENT,COMMENT_DISCARD,ACTION,ACTION_STRING><<EOF>> {@> @[TeX_( "/yyfatal{EOF encountered inside an action}" );@] @=}
+
+<EXTENDED_COMMENT,GROUP_WITH_PARAMS,GROUP_MINUS_PARAMS><<EOF>> {@> @[TeX_( "/yyfatal{EOF encountered inside pattern}" );@] @=}
+
+<SECT2,QUOTE,FIRSTCCL,CCL>{ESCSEQ} {@> @<Process an escaped sequence@> @=}
+
+@ @<Process an escaped sequence@>=
+ @[TeX_( "/ifnum/YYSTART=/number/csname flexstate/parsernamespace FIRSTCCL/endcsname/relax" );@]@;
+ @[TeX_( " /yyBEGIN{CCL}" );@]@;
+ @[TeX_( "/fi" );@]@;
+ @[TeX_( "/RETURNCHAR" );@]@;
+
+@ @<Patterns for \flex\ lexer@>=
+@G(fs2)
+<SECT3>{
+ {M4QSTART} {@> @[TeX_( "/yylexnext" );@] @=}
+ {M4QEND} {@> @[TeX_( "/yylexnext" );@] @=}
+ [^\[\]\n]*(\n?) {@> @[TeX_( "/yylexnext" );@] @=}
+ (.|\n) {@> @[TeX_( "/yylexnext" );@] @=}
+ <<EOF>> {@> @[TeX_( "/def/flsectnum{0}/yyterminate" );@] @=}
+}
+
+<*>.|\n {@> @[TeX_( "/yyfatal{bad character: /the/yytext}" );@] @=}
+
+@ @<Auxilary code for \flex\ lexer@>=
+void define_all_states( void ) {
+ @<Collect state definitions for the \flex\ lexer@>@;
+}
+
+@ @<Collect state definitions for the \flex\ lexer@>=
+#define _register_name( name ) @[Define_State( #name, name )@]
+#include "fil_states.h"
+#undef _register_name
+
diff --git a/support/splint/cweb/splint.w b/support/splint/cweb/splint.w
index 05fe5c42fc..e50e090c32 100644
--- a/support/splint/cweb/splint.w
+++ b/support/splint/cweb/splint.w
@@ -1,4 +1,4 @@
-% Copyright 2012-2015, Alexander Shibakov
+% Copyright 2012-2020, Alexander Shibakov
% This file is part of SPLinT
%
% SPLinT is free software: you can redistribute it and/or modify
@@ -13,25 +13,1806 @@
%
% You should have received a copy of the GNU General Public License
% along with SPLinT. If not, see <http://www.gnu.org/licenses/>.
-\newwrite\gindex
+%
+\newwrite\gindex % index entries generated by the various parsers, \prodstyle{...} commands, etc.
+%
+\input limbo.sty
+\input frontmatter.sty
+\def\optimization{5}
+\input yy.sty
+\modenormal
+\input noweb.sty
+ \xreflocaltrue
+ \readlxrefs % read the reference file if exists before any sections appear
+ \newwrite\xrefstream % references for noweb like style of sectioning.
+ \immediate\openout\xrefstream=\jobname.xxr
+% multi-column output
+\input dcols.sty
+\topskip=9pt % this is a purely aesthetic choice, also negating the \raggedbottom
+ % option in cwebmac.tex
+% set the typesetting of various token groups
+\let\currentparsernamespace\parsernamespace
+\let\currenttokeneq\tokeneq
+ \let\parsernamespace\mainnamespace
+ \let\hostparsernamespace\mainnamespace % for \nameproc in tokeneqpretty
+ \let\tokeneq\tokeneqpretty
+ \let\optstrextra\optstrextraesc
+ %\traceprettytokenstrue
+ \input bo.tok % re-use token equivalence table to set the typesetting of tokens
+ \input btokenset.sty % adjust the typesetting of some tokens
+ \let\parsernamespace\flexnamespace
+ \let\hostparsernamespace\flexnamespace
+ \input fo.tok
+ \input ftokenset.sty % ... for the flex input lexer
+ \let\parsernamespace\flexpseudorenamespace
+ \let\hostparsernamespace\flexpseudorenamespace
+ \input fretokenset.sty % regular expression names
+ % index entries
+ \let\parsernamespace\indexpseudonamespace
+ \input yypretty.sty
+ \prettywordpair{TOKEN}{{\tt TOKEN} {\rm(example)}}%
+ \prettywordpair{token}{{\tt "token"} {\rm(example)}}%
+\let\tokeneq\currenttokeneq
+\let\parsernamespace\currentparsernamespace
+\let\hostparsernamespace\mainnamespace % the namespace where tokens are looked up
+ % by \nameproc and friends for typesetting purposes
+%
+\immediate\openout\exampletable=\jobname.exl % file for parser output examples
+
+\def\nontitle#1{{\ttl #1}}
+\def\cite[#1]{%
+ \def\next{#1}\setbox0=\hbox{l}%
+ [\ifx\next\empty$\,$\hbox{\vrule width\wd0 height\ht0 depth\dp0}$\,$\else \locallink{#1bibref}#1\endlink\fi]%
+}
+
+\let\N\textN
+\let\N\chapterN
+\let\M\textM
+
+\defreserved{Y}{\.{Y}}
+\showlastactiontrue
+
+@**Introduction.
+\setupfootnotes
+\splint\footnote{I was tempted to call the package {\tt ParLALRgram}
+which stands for Parsing {\sc LALR} Grammars or {\tt PinT} for
+`Parsing in \TeX' but both sounded too generic.} (Simple Parsing and
+Lexing in \TeX, or, following the great GNU
+tradition of creating recursive names, \splint\ Parses Languages
+in \TeX) is a system (or
+rather a m\'elange of systems) designed to
+facilitate the development of parsing macros in \TeX\ and (to a lesser
+degree) to assist one in documenting parsers written in other languages. As
+an application, parsers for \bison\ and \flex\ input file syntax have been
+developed, along with a macro collection that makes it possible to
+design and pretty print\footnote{The term {\it pretty printing\/} is used here in
+its technical sense as one might find that there is nothing pretty about
+the output of the parsing routines presented in this document.}
+\bison\ grammars and \flex\ automata using \CWEB. The \.{examples}
+directory contains a few other parsers designed to pretty print
+various languages (among them is \ld, the language of the \GNU\
+linker).
+
+@s TeX_ TeX
+@s TeXa TeX
+@s TeXb TeX
+@s TeXf TeX
+@s TeXfo TeX
+@s TeXao TeX
+
+@*1 \eatone{CWEB}\CWEB\ and literate programming.
+Writing software in \CWEB\ involves two programs. The first of these is
+\CTANGLE\ that outputs the actual code, intended to be in
+\Cee. In reality, \CTANGLE\ cares very little about the language it
+produces. Among the exceptions are \Cee\ comments and |@[#line@]| directives that might
+confuse lesser software but \bison\ is all too happy to swallow them
+(there are also some \Cee\ specific constructs that \CTANGLE\ tries to
+recognize). \CTANGLE's main function is to rearrange the text of the
+program as written by the programmer (in a way that, hopefully,
+emphasizes the internal logic of the code) into an appropriate
+sequence (e.g.~all variable declaration must textually precede their
+use). All that is required to adopt \CTANGLE\ to produce \bison\
+output is some very rudimentary post- and pre-processing.
+
+Our main concern is thus \CWEAVE\ that not only pretty prints the
+program but also creates an index, cross-references all the
+sections, etc. Getting \CWEAVE\ to pretty print a language other than
+\Cee\ requires some additional attention. A true digital warrior would
+probably try to decipher \CWEAVE's output `in the raw' but, alas, my
+WebFu is not that strong. The loophole comes in the form of a rarely
+(for a good reason) used \CWEB\ command: the verbatim (\.{@@=...@@>})
+output. The material to be output by this construct undergoes minimal
+processing and is put inside \.{\\vb\{}$\ldots$\.{\}}. All that is
+needed now is a way to process this virtually straight text inside \TeX.
+
+This manual, as well as nearly every other document that accompanies
+\splint\ is itself a source for a computer program (or, as is the case
+with this document, several programs) that is extracted using
+\CTANGLE. We refer an interested reader to \cite[CWEB] for a detailed
+description of the syntax and use patterns of \CWEB. The following is
+merely a brief overview of the approach.
+
+Every \CWEB\ document is split into {\em sections}, each divided into
+three parts (any one of which can be empty): the \TeX\ part, the middle part, and
+the \Cee\ part (which should more appropriately be called the {\em code
+part\/}). The code part of each\footnote{With the exception of the nameless \.{@@c}
+sections.} section carries a name for cross referencing
+purposes. The sections themselves are automatically numbered by \CWEAVE\ and
+their code parts may be referenced from other sections, as well
+as included in other sections' code parts using \CWEB's cross referencing
+syntax (such as |@<A production@>|). Using the same name for the \Cee\
+portion in several sections has the effect of merging the
+corresponding code fragments. When the section with such a name is
+used (included) later, all of the concatenated fragments are included
+as well, even the ones that appear after the point in the \CWEB\
+document where such inclusion takes place.
+
+The original \CWEB\ macros (from \.{cwebmac.tex}) used the numbers
+generated by \CWEAVE\ to refer to specific sections. This was true
+for the table of contents, as well as the index entries. The macros
+used by \splint\ adopt a different convention, proposed by N.~Ramsey
+for his literate programming software, \noweb. In the new system
+(which will be referred to as the \noweb\ style of cross referencing),
+each section is labelled by the page number where it starts and an
+alphabetic character that indicates the order of appearance of the
+section on the page. Also following \noweb, the new macros display
+links beween the fragments of the same section in the margins. This
+allows for quicker navigation between sections of the code and lets
+the reader to get a quick overview of what gets `collected' in a given
+section.
+
+The top level (\.{@@**}) sections, introducing
+major portions of the code have also been given more prominent
+appearance and carry a chapter number in addition to the the \noweb\
+style section number (the latter is used for cross references, as the
+chapter number gives no indication as to where the said chapter is
+located).
+
+\CWEB\ also generates an {\em index\/} of all the identifiers (with
+some exceptions, such as single letter names) appearing in the
+\Cee\ portion of each section, {\em except\/} those that appear inside
+the {\em verbatim@^verbatim block@>\/} portions of the code
+(i.e.~between \.{@@=} and \.{@@>}). Since \splint\ uses the verbatim blocks
+extensively, additional indexing facilities have been implemented to
+provide indexing for the non-\Cee\ languages handled by various
+\splint\ parsers.
+
+@*1 Pretty (and not so pretty) printing.
+Pretty-printing can be narrowly defined as a way to organize the
+presentation of the program's text. The range of visual devices used
+for this purpose is usually limited to indentation and discrete line
+skips, to mimic the capabilities of an old computer terminal. Some
+authors (see~\cite[ACM]) have replaced the term pretty printing with
+{\em program visualization\/} to refer to a much broader range of
+graphic tools for translating the code (and its meaning) into a richer
+medium. This manual uses the terms {\em pretty printing\/} and {\em
+program visualization\/} interchangeably.
+
+Pretty printing in the broader sense above has been the subject of
+research for some time. The monograph~\cite[ACM] develops a methodical
+(if not formalized) approach to the design of visualization frameworks
+for programming languages (although the main focus is on procedural
+\Cee-like languages).
+
+A number of papers about pretty printing have appeared since,
+extending the research to new languages, and suggesting new
+visualizatin rules.
+Unfortunately, most of this research is driven by rules of
+thumb and anecdotes (the approach fully embraced by this manual),
+although there have been a few rigorous studies investigating
+isolated visualization techniques (see, for example, the discussion
+of variable declaration placement in~\cite[Jo]).
+
+Perhaps the only firm conclusion one can draw from this discussion is
+that {\em writing\/} the code and {\em reading\/} it are very different
+activities so facilitating the former may in turn make the latter more
+difficult and vice versa. Some well known languages try to arrive at a
+compromise where the syntax forces a certain style of
+presentation on the programmer. An example of a successful language in
+this group is Python with its meaningful white space. The author does
+not share the enthusiasm some programmers express for this approach.
+
+On the other hand, a language like \Cee\ does not enforce any
+presentation format\footnote{The `feature' so masterfully exploited by
+the International Obfuscated \Cee\ Code Contest ({\sc IOCCC})
+participants.}. The authors of
+\Cee\ even remarked that semicolons and braces were merely a nod to
+the compiler (or, one might add, static analysis software,
+see~\cite[KR]). It may thus seem reasonable that such redundant
+syntax elements may be replaced by different typographic devices (such
+as judicially chosen skips and indentation, or the choice of fonts)
+when (pretty) printing the code.
+
+Even the critics of pretty printing
+usually concede that well indented code is easier to read. The practice
+of using different typefaces to distinguish between various
+syntactic elements (such as reserved words and general identifiers) is
+a subject of some controversy, although not as pronounced as some of
+the more drastic approaches (such as completely replacing the brace
+pairs with indentation as practiced by \splint\ for \bison\ input or
+by the authors of~\cite[ACM] for the control statements in \Cee).
+
+The goal of \splint\ was not to force any parcticular `pretty printing
+philosophy' on the programmer (although, if one uses the macros `as
+is', some form of quiet approval is assumed $\ldots$) but rather to
+provide one with the tools necessary to implement one's own vision of
+making the code readable.
+
+One tacit assumption made by the author is that an integral part of
+any pretty printing strategy is extracting (some) meaning from the raw
+text. This is done by {\em parsing\/} the program, the subject we
+discuss next. It should be said that it is the parser design in \TeX\
+that \splint\ aims to facilitate, with pretty printing being merely an
+important application.
+
+@*1 Parsing and parsers.
+At an abstract level, a {\em parser@^parser@>\/} is just a routine
+that transforms text. Naturally, not every possible tranformation is
+beneficial, so, informally, the value of a parser lies in its ability
+to expose some {\em meaning\/} in the text. If valid texts are reduced
+to a small finite set (while each text can be arbitrarily long) one
+can concievably write a primitive string matching algorithm that
+recognizes whether any given input is an element of such set, and if
+it is, which one. Such `parsers' would be rather limited and are only
+mentioned to illustrate the point that, in general, the texts being
+parsed are not required to follow any particular specifiction.
+
+In practice, however, real world parsers rely on the
+presence of some structure in the input to do their work. The latter
+can be introduced by supplying a formal (computable) description of
+every valid input. The `ridgidity' of this specification directly
+affects the sophistication of the parsing algorithm required to
+process a valid input (or reject an invalid one).
+
+Parsing algorithms normally follow a model where the text is processed
+a few symbols at a time and the information about the symbols
+already seen is carried in some easily accessible form. `A few symbols at a time'
+often translates to `at most one symbol', while `easily accessible'
+reduces to using a stack-like data structure for bookkeeping.
+
+A popular way of specifying {\em structure\/} is by using a {\em
+formal grammar@^grammar@>}\footnote{While popular, formal grammars are
+not the only way of describing a language. For example, `powers of $2$
+presented in radix $3$' is a specification that cannot be defined by a
+context-free grammar, although it is possible to write a (very complex)
+grammar for it.} that essentially expresses how some (preferably
+meaningful) parts of the text relate to other parts. Keeping with the
+principle of making the information about the seen portions of the
+input easily accessible, practical grammars are normally required to
+express the meaning of a fragment in a manner that does not depend
+on the input that surrounds the fragment (i.e.~to be {\em
+context-free@^context-free@>}). Real-world languages rarely satisfy
+this requirement\footnote{Processing |typedef|'s in \Cee\ is a well
+known case of such a language defect.} thus presenting a challenge to
+parser generating software that assumes the language is context-free.
+
+Even the task of parsing all context-free languages is too ambitious
+in most practical scenarios, so further limitations on the grammar are
+normally imposed. One may require that the next action of the parsing
+algorithm must depend exclusively on the next symbol seen and one of
+the finitely many {\em states\/} the parser may be in. The action here
+simply refers to the choice of the next state, as well as the possible
+decision to consume more input or output a portion of the {\em
+abstract syntax tree@^abstract syntax tree@>\/} which is discussed
+below.
+
+The same language may have more than one grammar and the choice of the
+latter normally has a profound effect on the selection of
+the parsing algorithm. Without getting too deep into the parsing
+theory, consider the following simple sketch.
+\medskip
+\beginprod
+\format{\inline\flatten}
+pexp:
+ '(' pexp ')' \
+ ` astring \
+;
+%
+astring:
+ \
+ ` '*' astring \
+;
+\endprod
+\medskip
+\noindent Informally, the language consists of `strings of $n$ \.{*}'s
+nested $m$ parentheses deep'. After parsing such a string, one might
+be interested in the values of $m$ and $n$.
+
+The three
+states the parser may be in are `start', `parsing \prodstyle{pexp}' and
+`parsing \prodstyle{astring}'. A quick glance at the grammar above
+shows that switching between the states is straightforward (we omit
+the discussion of the `start' state for brevity):
+if the next symbol is \.{(}, parse the next~\prodstyle{pexp},
+otherwise, if the next symbol is \.{*}, parse~\prodstyle{astring}.
+Finally, if the next symbol is \.{)} and we
+are parsing~\prodstyle{pexp}, finish parsing it and look for the next
+input, otherwise, we are parsing~\prodstyle{astring}, finish parsing
+it, make it a~\prodstyle{pexp}, finish parsing a~\prodstyle{pexp}
+started by a parenthesis, and look for more input. This unnecessarily
+long (as well as incomplete and imprecise) description serves
+to present a simple fact that the
+parsing states are most naturally represented by individual {\em
+functions\/} resulting in what is known as a {\em recursive descent
+parser@^recursive descent parser@>\/} in which the call stack is the
+`data structure' responsible for keeping track of the parser's
+state. One disadvantage of the algorithm above is that the maximal
+depth of the call stack reaches $m+n$ which may present a problem for
+longer strings.
+
+Computing $m$ and $n$ above now reduces to incrementing an appropriate
+variable upon exiting the corresponding function. More important,
+however, is the observation that this parsing algorithm can be
+extracted from the grammar in a very straightforward fashion. To
+better illustrate the r\^ole of the grammar in the choice of the
+parsing algorithm, consider the following syntax for the same
+language:
+\medskip
+\beginprod
+\format{\inline\flatten}
+pexp:
+ '(' pexp ')' \
+ ` astring \
+;
+%
+astring:
+ \
+ ` astring '*' \
+;
+\endprod
+\medskip
+\noindent While the language is unchanged, so the algorithm
+above still works, the lookahead tokens are not {\em immediately\/}
+apparent upon looking at the productions. Some preprocessing must take
+place before one can decide on the choice of parser states and the
+appropriate lookahead tokens. Such algorithms indeed exist and result
+in what is known as an {\sc LR} parser for the fragment above
+(actually, a simpler {\sc LALR} parser may be built for this
+grammar\footnote{Both of these algorithms will use the parser stack
+more efficiently, effectively resolving the `call stack depth' issue
+mentioned earlier.}). One can see that some grammar types may make
+the selection of the parsing algorithm more involved. Since \splint\ relies
+on \bison\ for the generation of the parsing algorithm, one must
+ensure that the grammar is {\sc LALR}$(1)$\footnote{The newest versions of
+\bison\ are capable of processing a {\em much\/} wider set of
+grammars, although \splint\ can only handle the \bison\ output for
+{\sc LALR}$(1)$ parsers.}.
+
+@*1 Using the \eatone{bison}\bison\ parser.
+The process of using \splint\ for writing parsing macros in \TeX\ is
+treated in considerable detail later in this document. A shorter
+(albeit somewhat outdated but still applicable) version of this
+process is outlined in \cite[Sh], included as part of \splint's documentation.
+We begin, instead, by explaining how one such parser can be used to pretty print a
+\bison\ grammar. Following the convention mentioned above and putting
+all non-\Cee\ code inside \CWEAVE's verbatim blocks, consider the
+following (meaningless) code fragment\footnote{The software included in the package
+contains a number of preprocessing scripts that reduce the necessity of using
+the verbatim blocks for every line of the \bison\ code so the snippet above can
+instead be presented without the distraction of \.{@@=...@@>}, looking more
+like the `native' \bison\ input}. The fragment contains a mixture
+of \Cee\ and \bison\ code, the former appears outside of the verbatim blocks.
+\begindemo
+^@@= non_terminal: @@>
+^@@= term.1 term.2 {@@> a = b; @@=}@@>
+^@@= **H term.3 other_term {@@> $$ = $1; @@=}@@>
+^@@= **H still more terms {@@> f($1); @@=}@@>
+^@@= ; @@>
+\enddemo
+The fragment above will appear as (the output of \CTANGLE\ can be
+examined in \.{sill.y})
+@<A silly example@>=
+@G
+non_terminal:
+ term.1 term.2 {@> a = b; @=}
+| term.3 other_term {@> $$ = $1; @=}
+| still more terms {@> f($1); @=}
+;
+@g
+
+@ $\ldots$ if the syntax is correct.
+In case it is a bit off (note the missing colon after \.{whoops}), the parser will give up and
+you will see a different result. The code in the fragment below is easily
+recognizable, and some parts of it (all of \Cee\ code, in fact) are
+still pretty printed by \CWEAVE. Only the verbatim portion is left
+unprocessed.
+@<A silly example@>=
+@G
+whoops
+ term.1 term.2 {@>@+ a = b; @+@=}
+| term.3 other_term {@>@+ $$ = $1; @+@=}
+| still more terms {@>@+ f($1); @+@=}
+;
+@g
+
+@ The \TeX\ header that makes such output possible is quite plain. In the case
+of this document it begins as
+\begindemo
+^\input limbo.sty
+^\input frontmatter.sty
+^\def\optimization{5}
+^\input yy.sty
+\nooutput
+\enddemo
+The first two lines are presented here merely for completeness: there is
+no parsing-relevant code in them. The third line
+(\.{\\def\\optimization\{5\}}) may be ignored for now (we discuss some
+ways the parser code may be sped up
+\locallink{optimization}later\endlink. The line that
+follows loads the macros that implement the parsing and scanning
+machinery.
+
+This is enough to set up all the basic
+mechanisms used by the parsing and lexing macros. The rest of the header
+provides a few definitions to fine tune the typesetting of
+grammar productions. It starts with
+\begindemo
+^\let\currentparsernamespace\parsernamespace
+^ \let\parsernamespace\mainnamespace
+^ \let\currenttokeneq\tokeneq
+^ \def\tokeneq#1#2{\prettytoken{#1}}
+^ \input bo.tok % re-use token equivalence table to set the typesetting of tokens
+^ \let\tokeneq\currenttokeneq
+^ \input btokenset.sty
+\nooutput
+\enddemo
+We will have a chance to discuss all the \.{\\}$\ldots$\.{namespace}
+macros later, at this point it will suffice to say that the lines
+above are responsible for controlling the typesetting of term names. The
+file \.{bo.tok} consists of a number of lines like the ones below:
+\begindemo
+^\tokeneq {STRING}{{34}{115}{116}{114}{105}{110}{103}{34}}
+^\tokeneq {PERCENT_TOKEN}{{34}{37}{116}{111}{107}{101}{110}{34}}
+\nooutput
+\enddemo
+The cryptic looking sequences of integers above are strings of {\sc ASCII}
+codes of the letters that form the name that \bison\ uses when it needs to
+refer to the corresponding token (thus, the second one is
+\toksa{}\numberstochars{34}{37}{116}{111}{107}{101}{110}{34}\end
+\.{\the\toksa} which might help explain why such an indirect scheme
+has been chosen). The macro \.{\\tokeneq} is defined in
+\.{yymisc.sty}, which in turn is input by \.{yy.sty} but what about
+the token names themselves? In this case they were extracted
+automatically from the \CWEB\ source file by the
+\locallink{bootstrapping}{\em bootstrapping parser\/} \endlink during the
+\CWEAVE\ processing stage. All of these definitions can be
+overwritten to get the desired output (say, one might want to typeset
+\.{ID} in a roman font, as `identifier'; all that needs to be done to
+make this possible is a macro that says \.{\\prettywordpair\{ID\}\{\{\\rm
+identifier\}\}} in an appropriate namespace (usually
+\.{\\hostparternamespace})). The file \.{btokenset.sty} input above
+contains a number of such definitions.
+
+@ To round off this short overview, I must mention a caveat associated
+with using the macros in this collection: while one of the greatest
+advantages of using \CWEB\ is its ability to rearrange the code in a
+very flexible way, the parser will either give up or produce
+unintended output if this feature is abused while describing the
+grammar. For example, in the code below
+@<A silly example@>=
+@G
+next_term:
+ stuff @> @<Rest of line@> @={@> a = f( x ); @=}
+@g
+@<A production@>@;
+
+@ the line titled |@<A production@>| is intended to be a rule defined
+later. Notice that while it seems that the parser was able to recognize
+the first code fragment as a valid \bison\ input, it misplaced the
+|@<Rest of line@>|, having erroneously assumed it to be a part of
+the action code for this grammar (later on we will go into the details of
+why it is necessary to collect all the non-verbatim output of \CWEAVE,
+even that which contains no interesting \Cee\ code; hint: it has
+something to do with money (\.{\$}), also known as math and the way
+\CWEAVE\ processes the `gaps' between verbatim sections). The production
+line that follows did not fare as well: the parser gave up. There
+is simply no point in including such a small language fragment as a
+valid input for the grammar the parser uses to process the verbatim
+output.
+@<A production@>=
+@G
+ more stuff in this line {@> @[b = g(y);@]@=}
+@g
+
+@ Finally, if you forget that only the verbatim part of the output is
+looked at by the parser you might get something unrecognizable, such
+as
+@<Rest of line@>=
+ but not all of it
+
+@ To correct this, one can provide a more complete grammar fragment to
+allow the parser to complete its task successfully. In some cases,
+this imposes too strict a constraint on the programmer. Instead, the
+parser that pretty prints \bison\ grammars allows one to add {\it
+hidden context\/} to the code fragments above. The context is added
+inside \.{\\vb} sections using \CWEB's \.{@@t}$\ldots$\.{@@>} facility. The \CTANGLE\
+output is not affected by this while the code above can now be typeset as:
+@<A silly example@>=
+@G
+next_term:
+ stuff @> @t}\vb{\formatlocal{\let\peekstash\stashtoterm}}{@> @<Rest of line@> @t}\vb{FAKE}{@> @={@> a = f( x ); @=}
+@g
+@<A production@>@;
+
+@ $\ldots$ even a single line can now be displayed properly.
+@<A production@>=
+@G
+@t}\vb{\formatlocal{\skipheader} FAKE:}{@>
+ more stuff in this line {@> b = g( y ); @=}
+@g
+
+@ With enough hidden context, even a small rule fragment can be
+typeset as intended. The `action star' was inserted to reveal some of
+the context.
+@<Rest of line@>=
+@G
+@t}\vb{\formatlocal{\skipheader} FAKE:}{@>
+ but not all of it
+@t}\vb{\{\stashed{$\star$}\}}{@>
+@g
+@ What makes all of this even more confusing is that \CTANGLE\ will
+have no trouble outputting this as a(n almost, due to the
+intentionally bad \.{whoops} production above) valid \bison\ file
+(as can be checked by looking into \.{sill.y}). The author
+happens to think that one should not fragment the software into pieces
+that are too small: \bison\ is not \Cee\ so it makes sense to write
+\bison\ code differently. However, if the logic behind your code
+organization demands such fine fragmentation, hidden context provides
+you with a tool to show it off. A look inside the source of this
+document shows that adding hidden context can be a bit ugly so it is
+not recommended for routine use. The short example above is output in
+the file below.
+@(sill.y@>=
+ @<A silly example@>@;
+
+@*1 On debugging. This concludes a short introduction to the \bison\
+grammar pretty printing using this macro collection. It would be
+incomplete, however, without a short reference to debugging\footnote{Here
+we are talking about debugging the output produced by \CWEAVE\ when
+the included \bison\ parser is used, {\it not\/} debugging parsers
+written with the help of this software: the latter topic is covered in more
+detail later on}. There is a
+fair amount of debugging information that the macros can output,
+unfortunately, very little of it is tailored to the {\em use\/} of the
+macros in the \bison\ parser. Most of it is designed to help build a
+{\em new\/} parser. If you find that the \bison\ parser gives up too often
+or even crashes (the latter is most certainly a bug in the \splint\
+version of the \bison\ parser itself), the first approach is to make
+sure that your code {\em compiles}, i.e.\ forget about the printed
+output and try to see if the `real' \bison\ accepts the code (just the
+syntax, no need to worry about conflicts and such).
+
+If this does not shed any light on why the macros seem to fail, turn
+on the debugging output by saying \.{\\trace$\ldots$true} to activate the
+appropriate trace macros. This may produce {\it a lot\/} of output, even for
+small fragments, so turn it on for only a section at a time. If you
+need still {\it more\/} details of the inner workings of the parser
+and the lexer, various other debugging conditionals are available. For
+example, \.{\\yyflexdebugtrue} turns on the debugging output for the
+scanner. There are a number of such conditionals that are discussed in
+the commentary for the appropriate \TeX\ macros. Most of these
+conditionals are documented in \.{yydebug.sty}, which provides a
+number of handy shortcuts for a few commonly encountered
+situations, as well.
+
+Remember, what you are seeing at this point is the parsing process of
+the \bison\ input file, not the one for {\it your\/} grammar (which
+might not even be complete at this point). However, if all of the
+above fails, you are on your own: drop me a line if you figure out how
+to fix any bugs you find.
+
+@** Terminology. \namedspot{terminology}This short chapter is an informal
+listing of a few loose definitions of
+the concepts used repeatedly in this documentation. Most of this terminology is
+rather standard. Formal precision is not the goal here, instead, intuitive
+explanations are substituted whenever possible.
+{%
+\def\aterm#1{\item{\sqebullet}{\ttl #1}: \ignorespaces}%
+\setbox0=\hbox{\sqebullet\enspace}
+\parindent=0pt
+\advance\parindent by \wd0
+\smallskip
+\aterm{bison {\rm(as well as} flex{\rm)} parser{\rm(}s{\rm)}}
+while, strictly speaking, not a formally defined
+term, this combination will always stand for one of the parsers generated
+by this package designed to parse a subset of the `official' grammar for
+\bison\ or \flex\ input files. All of these parsers are described later in
+this documentation. The term {\it main parser\/} will be
+used as a substitute in example documentation for the same purpose.
+
+\aterm{driver} a generic but poorly defined concept. In this
+documentation it is used predominantly to mean both the \Cee\ code and
+the resulting executable that outputs the \TeX\ macros that contain the
+parser tables, token values, etc., for the parsers built by the user. It
+is understood that the \Cee\ code of the `driver' is unchanged and the
+information about the parser itself is obtained by {\it including\/} the \Cee\
+file produced by \bison\ in the `driver' (see the examples supplied
+with the package).
+
+\aterm{lexer} a synonym for {\it scanner}, a subroutine that performs the {\it
+lexical analysis\/} phase of the parsing process, i.e.\ groups various
+characters from the input stream into parser {\it tokens}.
+
+\aterm{namespace} this is an overused bit of terminology meaning a
+set of names grouped together according to some relatively
+well defined principle. In a language without a well developed type
+system (such as \TeX) it is usually accompanied by a specially designed
+naming scheme. {\it Parser namespaces\/} are commonly used in this
+documentation to mean a collection of all the data structures describing a
+parser and its state, including tables, stacks, etc., named by using the
+`root' name (say \.{\\yytable}) and adding the name of the parser (for
+example, \.{[main]}). To support this naming scheme, a number of
+macros work in unison to create and rename the `data macros'
+accordingly\footnote{To be precise, the {\em namespaces\/} in this
+manual, would more appropriately be referred to as {\em named
+scopes}. The {\em tag namespace\/} in \Cee\ is an example of a
+(built-in) language namespace where the {\em grammatical r\^ole\/} of the
+identifier determines its association with the appropriate set.}.
+
+\aterm{parser stack}
+a collection of parsers, usually derived from a common set of
+productions, and sharing a common lexer. As the name suggests, the
+parsers in the collection are tried in order until the input is parsed
+successfully or every parser has been tried. This terminology may be the
+source of some confusion, since each parsing algorithm used by \bison\
+maintains several stacks. We will always refer to them by naming a specific
+task the stack is used for (such as the {\em value stack\/} or the
+{\em state stack}, etc.).
+
+\aterm{pretty printing {\rm or} program visualization}
+The terms above are used interchangeably in this manual to mean
+typesetting the program code in a way that emphasizes its meaning as
+seen by the author of the program\footnote{Or the person
+typesetting the code.}. It is usually assumed that such
+meaning is extracted by the software (a specially designed {\em
+parser\/}) and translated into a suitable visual representation.
+
+\aterm{symbolic switch} a macro (or an associative array of macros)
+that let the \TeX\ parser generated by the package associate {\it
+symbolic term names\/} (called {\it named references\/} in the official
+\bison\ documentation) with the terms. Unlike the `real' parser, the
+parser created with this suite requires some extra setup as explained
+in the included examples (one can also consult the source for this
+documentation which creates but does not use a symbolic switch).
+
+\aterm{symbolic term name} (also refered to as a {\it named reference\/}
+in the \bison\ manual): a (relatively new) way to refer to stack
+values in \bison. In addition to using the `positional' names such as
+\.{\$}$n$ to refer to term values, one can utilize the new syntax:
+\.{\$}\.{[}\\{name}\.{]} (or even \.{\$}\\{name} when the \\{name}
+has a tame enough syntax). The `\\{name}' can be assigned by the
+user or can be the name of the nonterminal or token used in the
+productions.
+
+\aterm{term} in a narrow sense, an `element' of a grammar. Instead of
+a long winded definition, an example, such as \prodstyle{ID} should
+suffice. Terms are further classified into {\it terminals\/} (tokens)
+and {\it nonterminals\/} (which can be intuitively thought of as
+composite terms).
+
+\aterm{token} in short, an element of a set. Usually encoded as an
+integer by most parsers, a {\em token\/} is an indivisible {\em term\/}
+produced for the parser by the scanner. \TeX's scanner uses a more
+sophisticated token classification, for example, $($character code,
+character category$)$ pairs, etc.
+
+}
+@** Languages, scanners, parsers, and \TeX. % Or $\ldots$
+\vtop{\halign to\hsize{\kern-1.5pt\it#\hfil\tabskip0pt plus1fil\cr
+Tokens and tables keep macros in check.\cr
+Make 'em with \bison, use \.{WEAVE} as a tool.\cr
+Add \TeX\ and \CTANGLE, and \Cee\ to the pool.\cr
+Reduce 'em with actions, look forward, not back.\cr
+Macros, productions, recursion and stack!\cr
+\noalign{\vskip2pt}
+\omit\hfil\eightpoint Computer generated (most likely)\cr}}
+\bigskip
+\def\recount#1{${}^{(#1)}$}%
+\noindent In order to understand the parsing routines in this collection,
+it would help to gain some familiarity with the internals of the
+parsers produced by \bison\ for its intended target: \Cee. A person
+looking inside a parser delivered by \bison\ would
+quickly discover that the parsing procedure itself (|yyparse|)
+occupies a rather small portion of the file. If (s)he were to further
+reduce the size of the file by removing all the preprocessor
+directives intended to anticipate every conceivable combination of the
+operating system, compiler, and \Cee\ dialect, and various reporting
+and error logging functions it would become very clear that the most
+valuable product of \bison's labor is a collection of integer {\it
+tables\/} that control the actions of the parser routine. Moreover,
+the routine itself is an extremely concise and well-structured loop
+composed of |goto|'s and a number of numerical conditionals. If one
+could think of a way of accessing arrays and processing conditionals
+in the language of one's choice, once the tables produced by \bison\
+have been converted into a form suitable for the consumption by the
+appropriate language engine, the parser implementation becomes
+straightforward. Or nearly so.
+
+The {\it scanning\/} (or {\it lexing\/}) step of this process---a way
+to convert a stream of symbols into a stream of integers, deserves
+some attention, as well. There are a number of excellent programs
+written to automate this step in much the same fashion as \bison\
+automates the generation of parsers. One such tool, \flex, though
+(in the opinion of this author) slightly lacking in the simplicity and
+elegance as compared to \bison, was used to implement the lexer for
+this software suite. Lexing in \TeX\ will be discussed in considerable
+detail later in this manual.
+
+The language of interest in our case is, of course, \TeX, so our
+future discussion will revolve around the five elements mentioned
+above: \recount{1}data structures (mainly arrays and stacks),
+\recount{2}converting
+\bison's output into a form suitable for \TeX's consumption,
+\recount{3}processing raw streams of \TeX's tokens and converting them into
+streams of parser tokens, \recount{4}the implementation of \bison's
+|yyparse| in \TeX, and, finally, \recount{5}producing \TeX\ output via {\it
+syntax-directed translation} (which requires an appropriate
+abstraction to represent \bison's actions inside \TeX). We shall
+begin by discussing the parsing process itself.
+
+@*1 Arrays, stacks and the parser.
+Let us briefly examine the programming environment offered by \TeX.
+Designed for typesetting, \TeX's remarkable language
+provides a layer of macro processing atop of a set of commands that
+produce the output fulfilling its primary mission: delivering page
+layouts. In The \TeX book, the macro {\it expansion\/} is likened to
+mastication, whereas \TeX's main product, the typographic output is the
+result of its `digestion' process. Not everything that goes through
+\TeX's digestive tract ends up leaving a trace on the final page: a
+file full of \.{\\relax}'s will produce no output, even though
+\.{\\relax} is not a macro, and thus would have to be processed by
+\TeX\ at the lowest level.
+
+It is time to describe the details of defining suitable data structures
+in \TeX. At first glance, \TeX\ provides rather standard means of
+organizing and using the memory. At the core of its generic
+programming environment is an array of \.{\\count}$\,n$ {\it
+registers\/}, which may be viewed as general purpose integer variables
+that are randomly accessible by their indices. The integer arithmetic
+machinery offered by \TeX\ is spartan but is very adequate for the sort of
+operations a parser would perform: mostly additions and
+comparisons.
+
+Is the \.{\\count} array a good way to store tables in \TeX? Probably
+not. The first factor is the {\it size\/} of this array: only 256
+\.{\\count} registers exist in a standard \TeX\ (the actual number of
+such registers on a typical machine running \TeX\ is significantly
+higher but this author is a great believer in standards, and to his
+knowledge, none of the standardization efforts in the \TeX\ world has
+resulted in anything even close to the definitive masterpiece that is
+The \TeX book). The issue of size can be mitigated to some extent by
+using a number of other similar arrays used by \TeX\ (\.{\\catcode},
+\.{\\uccode}, \.{\\dimen}, \.{\\sfcode} and others can be used for
+this purpose as long as one takes care to restore the `sane' values
+before the control is handed off to \TeX's typesetting mechanisms). If a
+table has to span several such arrays, however, the complexity of
+accessing code would have to increase significantly, and the issue of
+size would still haunt the programmer.
+
+The second factor is the utilization of several registers by \TeX\ for special
+purposes (in addition, some of these registers can only store a
+limited range of values). Thus, the first 10 \.{\\count} registers are
+used by the plain \TeX\ for (well, {\it intended\/} for, anyway) the
+purposes of page accounting: their values would have to be carefully
+saved and restored before and after each parsing call,
+respectively. Other registers (\.{\\catcode} in particular) have even
+more disrupting effects on \TeX's internal mechanisms. While all of
+this can be managed (after all, using \TeX\ as an arithmetic engine
+such as a parser suspends the need for any typographic or other
+specialized functions controlled by these arrays), the added
+complexity of using several memory banks simultaneously and the speed penalty
+caused by the need to save and restore register values make this
+approach much less attractive.
+
+What other means of storing arrays are provided by \TeX? Essentially,
+only three options remain: \.{\\token} registers, macros holding whole
+arrays, and associative arrays accessed through
+\.{\\csname}$\,\ldots\,$\.{\\endcsname}. In the first two cases if care
+is taken to store such arrays in an
+appropriate form one can use \TeX's \.{\\ifcase} primitive to access
+individual elements. The trade-off is the speed of such
+access: it is {\it linear\/} in the size of the array for most
+operations, and worse than that for others, such as removing the last
+item of an array. Using clever ways
+of organizing such arrays, one can improve the linear access time to
+$O(\log n)$ by simply modifying the access macros but at the moment, a
+straightforward \.{\\ifcase} is used after expanding a list macro or
+the contents of a \.{\\token}$\,n$ register in an {\it un\/}optimized
+parser. An {\it optimized\/} parser uses associative arrays.
+
+The array discussion above is just as applicable to {\it stacks\/}
+(indeed, an array is the most common form of stack
+implementation). Since stacks pop up and disappear frequently (what
+else are stacks to do?), list macros are usually used to store
+them. The optimized parser uses a separate \.{\\count} register to
+keep track of the top of the stack in the corresponding associative
+array.
+
+Let us now switch our attention
+to the code that implements the parser and scanner {\it functions\/}.
+If one has spent some time writing \TeX\ macros of any sophistication
+(or any macros, for that matter) (s)he must be familiar with the general
+feeling of frustration and the desire to `just call a function here and move
+on'. Macros\footnote{Formally defined as `$\ldots$ special
+compile-time functions that consume and produce {\em syntax objects}'
+in~\cite[DHB].} produce {\it tokens\/}, however, and tokens must either
+expand to nothing or stay and be contributed to your input, or worse,
+be out of place and produce an error. One way to sustain a stream
+of execution with macros is {\it tail recursion\/} (i.e.~always expanding the
+{\it last token left standing}).
+
+As we have already discussed, \bison's
+|yyparse()| is a well laid out loop organized as a sequence of
+|goto|'s (no reason to become religious about structured programming
+here). This fact, and the following well known trick, make \Cee\ to \TeX\
+translation nearly straightforward. The macro \TeX niques employed by the
+sample code below are further discussed elsewhere in this manual.
+
+% The macro mess below looks painful but this is the only place such layout is used
+% The approach can be easily generalized and put in limbo.sty but it seems
+% a bit redundant at this point.
+
+\newcount\piccount
+\newdimen\lasthsize
+\setbox5=\vtop{
+\demomargin=0pt
+\let\demoastyle\empty
+\begindemo
+^label A: ...
+\nooutput
+^ if**L**Krm(condition)**N
+^ goto C;
+\nooutput
+^label B: ...
+\nooutput
+^ goto A;
+\nooutput
+^label C: ...
+\nooutput
+\enddemo
+}
+\dp5=\z@@
+
+\setbox3=\vtop{
+\demomargin=0pt
+\let\demoastyle\empty
+\begindemo
+^\if**L**Krm(condition)**N
+^ \let\next=\labelC
+^\else
+^ \let\next=\labelAtail
+\enddemo
+}
+\dp3=\z@@
+
+\newdimen\lastdepth
+
+\def\startfitpar{%
+ \bgroup
+ \lasthsize=\hsize
+ \advance\lasthsize-1.5in
+ \vsize=\baselineskip
+ \topskip=\z@@
+ \setbox0\box2 % empty it
+ % this sounds good at first but there is no good way to pull the insertions out after the
+ % box manipulations that follow;
+ % insertions will thus be contributed to whatever page was being worked on when the
+ % picture insertions {\it started}; hence, if these happen to start at the very top of the page,
+ % any insertion that follows will be contributed to the previous page; we correct this for footnotes
+ % below
+ % \holdinginserts=1
+ \output{%
+ \global\setbox2=\vbox{
+ \ifvoid2
+ \else
+ \prevdepth=\dp2
+ \unvbox2
+ \fi
+ \lastdepth=\dp255
+ \unvbox255
+ % this would be tempting, however, the \eject that follows should disappear
+ % in addition, one really should not be playing with page breaking in the middle of
+ % such tricky insertions
+ % \penalty\outputpenalty
+ % \kern-\lastdepth % to make sure \baselineskip is accounted for
+ }%
+ }\eject
+ \output{%
+ \setbox0=\vbox{%
+ \unvbox255%
+ }% \lastbox would almost work ... if not for insertions
+ \global\advance\piccount1
+ \global\setbox2=\vbox{%
+ \prevdepth=\dp2 \unvbox2
+ \hbox to\hsize{%
+ \ifnum\piccount<15
+ \hbox to1.5in{%
+ \ifnum\piccount=1
+ \ \box5
+ \fi
+ \hfill}%
+ \fi
+ \box0 \hfill
+ \ifnum\piccount=1
+ \box3 \ %
+ \fi
+ \ifvoid\footins % reinsert footnotes
+ \else
+ \insert\footins{\unvbox\footins}%
+ \fi
+ }%
+ }%
+ }%
+ \parshape=15
+ 0pt 2.7in
+ 0pt 2.7in
+ 0pt 2.7in
+ 0pt 2.7in
+ 0pt 2.7in
+ 0pt 2.7in
+ 0pt 2.7in
+ 0pt \lasthsize
+ 0pt \lasthsize
+ 0pt \lasthsize
+ 0pt \lasthsize
+ 0pt \lasthsize
+ 0pt \lasthsize
+ 0pt \lasthsize
+ 0pt \hsize
+}
+
+\def\endfitpar{%
+ \par
+ \eject
+ \egroup
+ % see the comment above
+ % \holdinginserts=0
+ \prevdepth=\dp2
+ \unvbox2
+}
+
+\startfitpar
+\noindent Given the code on the left (where |goto|'s
+are the only means of branching but can appear inside conditionals),
+one way to translate it into \TeX\ is to define a set of macros (call
+them \.{\\labelA}, \.{\\labelAtail} and so forth for clarity) that end in
+\.{\\next} (a common name for this purpose). Now, \.{\\labelA} will
+implement the code that comes between \.{label A:} and \.{goto C;},
+whereas \.{\\labelAtail} is responsible for the code after \.{goto C;}
+and before \.{label B:}
+(provided no other |goto|'s intervene which can always be
+arranged). The conditional which precedes \.{goto C;} can now be written in
+\TeX\ as presented on the right, where (condition) is an appropriate
+translation of the corresponding condition
+in the code being translated (usually, one of `$=$' or `$\not=$'). Further
+details can be extracted from the \TeX\ code that implements these
+functions where the corresponding \Cee\ code is presented alongside
+the macros that mimic its functionality%
+\footnote{Running the risk of overloading the reader with details, the author
+would like to note that the actual implementation follows a {\it slightly\/} different
+route in order to avoid any \.{\\let} assignments or changing the
+meaning of \.{\\next}}.
+This concludes the overview of the general approach,
+It is time to consider the way characters get consumed
+on the lower levels of the macro hierarchy and the interaction between the different
+layers of the package.
+\endfitpar
+
+@*1 \TeX\ into tokens.
+Thus far we have covered the ideas
+behind items \recount{1} and \recount{4} on our list. It is time to
+discuss the lowest level of processing performed by these macros:
+converting \TeX's tokens into the tokens consumed by the parser,
+i.e.\ part \recount{3} of the plan. Perhaps, it would be most appropriate
+to begin by reviewing the concept of a {\it token}.
+
+As commonly defined, a token is simply an element of a set (see the section
+on \locallink{terminology}terminology\endlink\ earlier in this manual).
+Depending on
+how much structure the said set possesses, a token can be represented by
+an integer or a more complicated data structure. In the discussion
+below, we will be dealing with two kinds of tokens: the tokens
+consumed by the parsers and the \TeX\ tokens seen by the input
+routines. The latter play the r\^ole of {\it characters\/} that combine
+to become the former. Since \bison's internal representation for its tokens
+is non-negative integers, this is what the scanner must produce.
+
+\TeX's tokens are a good deal more sophisticated: they can be
+either pairs $(c_{\rm ch}, c_{\rm cat})$, where $c_{\rm ch}$ is the
+character code and $c_{\rm cat}$ is \TeX's category code ($1$ and $2$ for
+group characters, $5$ for end of line, etc.), or {\it control
+sequences\/}, such as \.{\\relax}. Some of these tokens (control
+sequences and {\it active}, i.e.~category~13 characters) can have
+complicated internal structure (expansion). The situation is further
+complicated by \TeX's \.{\\let} facility, which can create
+`character-like' control sequences, and the lack of conditionals
+to distinguish them from the `real' characters. Finally, not all pairs
+can appear as part of the input (say, there is no $(n, 0)$ token for
+any $n$, in the terminology above).
+
+The scanner expects to see {\it characters} in its input, which are
+represented by their {\sc ASCII} codes, i.e.~integers between $0$ and
+$255$ (actually, a more general notion of the Unicode character is
+supported but we will not discuss it further). Before character codes
+appear as the input to the scanner, however, and make its integer
+table-driven mechanism `tick', a lot of work must be done to collect
+and process the stream of \TeX\ tokens produced after \CWEAVE\ is done
+with your input. This work becomes even more complicated when the
+typesetting routines that interpret the parser's output must sneak
+outside of the parsed stream of text (which is structured by the
+parser) and insert the original \TeX\ code produced by \CWEAVE\ into
+the page.
+
+\splint\ comes with a customizeable input routine of
+moderate complexity (\.{\\yyinput}) that classifies all \TeX\ tokens
+into seven categories: `normal' spaces (i.e.~category~10 tokens,
+skipped by \TeX's parameter scanning mechanism),
+`explicit' spaces (includes the control sequences \.{\\let} to \.{\ },
+as well as \.{\\\ }), groups ({\it avoid} using \.{\\bgroup} and \.{\\egroup} in
+your input but `real', \.{\{}$\ldots$\.{\}} groups are fine), active
+characters, normal characters (of all character categories that can
+appear in \TeX\ input, including \.{\$}, \.{\^}, \.{\#}, \.{a}--\.{Z},
+etc.), single letter control sequences, and multi-letter control
+sequences. Each of these categories can be processed separately to
+`fine-tune' the input routine to the problem at hand. The input
+routine is not very fast, instead, flexibility was the main
+goal. Therefore, if speed is desirable, a customized input routine
+is a great place to start. As an example, a minimalistic
+\.{\\yyinputtrivial} macro is included.
+
+When \.{\\yyinput} `returns' by calling \.{\\yyreturn} (which is a
+macro you design), your lexing routines have access to three
+registers: \.{\\yycp@@}, that holds the character value of the
+character just consumed by \.{\\yyinput}, \.{\\yybyte}, that most of
+the time holds the token just removed from the input,
+and \namedspot{yybytepure-discussion}\.{\\yybytepure}, that (again, with very few
+exceptions) holds a `normalized' version of the read character (i.e.~a
+character of the same character code as \.{\\yycp@@}, and category~12
+(to be even more precise (and to use nested parentheses), `normalized'
+characters have the same category code as that of `\.{.}' at the point
+where \.{yyinput.sty} is read)).
+
+Most of the time it is the character code one needs (say, in the case
+of \.{\\\{}, \.{\\\}}, \.{\\\&} and so on) but under some circumstances the
+distinction is important (outside of \.{\\vb\{}$\ldots$\.{\}}, the sequence
+\.{\\1} has nothing to do with the digit `\.{1}'). This mechanism
+makes it easy to examine the consumed token. It also forms
+the foundation of the `hidden context' passing mechanism described later.
+
+The remainder of this section discusses the internals of \.{\\yyinput}
+and some of the design trade-offs one has to make while working on
+processing general \TeX\ token streams. It is typeset in `small print'
+and can be skipped if desired.
+\smallskip
+\begingroup
+\abovedisplayskip=5pt%
+\abovedisplayshortskip=2pt%
+\belowdisplayskip=5pt%
+\belowdisplayshortskip=2pt%
+\fnotesstart=1
+\fnotesspan=2
+\noofcolumns=2
+\icgap=1em%
+\eightpoint
+\linecount=73
+\setmcparams
+\def\.#1{{\chardef\\=`\\\chardef\&=`\&\tt #1}}%
+\dsskip=0pt%
+\begindoublecols
+To examine every token in its path (including spaces that are easy to
+skip), the input routine uses one of the two well-known {\sc \TeX}nologies:
+\.{\\futurelet\\next\\examinenext} or its equivalent
+\.{\\afterassignment\\examinenext\\let\\next=}\hbox{\tt\char"20}.
+Recursively inserting one of these sequences, \.{\\yyinput} can go
+through any list of tokens, as long as it knows where to stop
+(i.e.~return an end of file character). The
+signal to stop is provided by the \.{\\yyeof}
+sequence, which should not appear in any `ordinary' text
+presented for parsing, other than for the purpose of providing such a
+stop signal. Even the dependence on \.{\\yyeof} can be eliminated if
+one is willing to invest the time in writing macros that juggle \TeX's
+\.{\\token} registers and only limit oneself to input from such
+registers (which is, aside from an obvious efficiency hit, a strain on
+\TeX's memory, as you have to store multiple (3 in the general case)
+copies of your input to be able to back up when the lexer makes a
+wrong choice). Another approach to avoid the use of stop tokens is
+to store the whole input as a {\it parameter\/} for the appropriate macro.
+This scheme is remarkably powerful and can produce {\it expandable\/} versions
+of very complicated routines, although the amount of effort required to
+write such macros grows at a frightening rate. As the text inside
+\.{\\vb\{}$\ldots$\.{\}} is nearly always well structured, the care that
+\.{\\yyinput} takes in processing such character lists is an
+overkill. In a more `hostile' environment (such as the one encountered
+by the now obsolete \.{\\Tex} macros), however, this extra attention to detail pays
+off in the form of a more robust input mechanism.
+
+One subtlety deserves a special mention here, as it can be important
+to the designer of `higher-level' scanning macros. Two types of tokens
+are extremely difficult to deal with whenever \TeX's own lexing
+mechanisms are used: (implicit) spaces and even more so, braces. We
+will only discuss braces here, however, almost everything that follows
+applies equally well to spaces (category 10 tokens to be precise), with
+a few simplifications (or complications, in a couple of places). To
+understand the difficulty, let's consider one of the approaches above:
+$$
+\.{\\futurelet\\next\\examinenext}.
+$$
+The macro \.{\\examinenext}
+usually looks at \.{\\next} and inserts another macro (usually also called
+\.{\\next}) at the very end of its expansion list. This macro usually
+takes one parameter, to consume the next token. This mechanism works
+flawlessly, until the lexer encounters a \.{\{}br\.{,}sp\.{\}}ace. The \.{\\next}
+sequence, seen by \.{\\examinenext} contains a lot of information
+about the brace ahead: it knows its category code (left brace, so $1$), its
+character code (in case there was, say a \.{\\catcode`\\[=1{\tt\char`\ }}
+earlier) but not whether it is a `real' brace (i.e.\ a character
+\.{\{}$_1$) or an implicit one (a \.{\\bgroup}). There is no way to find
+that out until the control sequence `launched' by \.{\\examinenext}
+sees the token as a parameter.
+
+If the next token is a `real' brace, however,
+\.{\\examinenext}'s successor will never see the token itself: the
+braces are stripped by \TeX's scanning mechanism. Even if it finds a
+\.{\\bgroup} as the parameter, there is no guarantee that the actual
+input was not \.{\{\\bgroup\}}. One way to handle this is by applying
+\.{\\string} before consuming the next token. If prior to
+expanding \.{\\string} care has been taken to set the \.{\\escapechar}
+appropriately (remember, we know the character code of the next
+token in advance), as soon as one sees a character with
+\.{\\escapechar}'s character code,
+(s)he knows that an implicit brace has just been seen. One added
+complication to all this is that a very determined programmer can
+insert an {\it active\/} character (using, say, the \.{\\uccode}
+mechanism) that has the {\it same\/} character code as the {\it
+brace\/} token that it has been \.{\\let} to! Even setting this
+disturbing possibility aside, the \.{\\string} mechanism
+(or, its cousin, \.{\\meaning}) is
+far from perfect: both produce a sequence of category 12 and 10 tokens
+that are mixed into the original input. If
+it is indeed a brace character that we just saw, we can consume the next
+token and move on but what if this was a control sequence? After all,
+just as easily as \.{\\string} makes a sequence into characters,
+\.{\\csname}$\,\ldots\,$\.{\\endcsname} pair will make any sequence of
+characters into a control sequence so determining the end the character
+sequence produced by \.{\\string} may prove impossible. Huh~$\ldots$
+
+What we need is a backup mechanism: keeping a copy of the
+token sequence ahead, one can use \.{\\string} to see whether
+the next token is a real
+brace first, and if it is, consume it and move on (the active character
+case can be handled as the implicit case below, with one extra backup
+to count how many tokens have been consumed). At this point the brace has to be {\it
+reinserted\/} in case, at some point, a future `back up'
+requires that the rest of the tokens are removed from the output (to
+avoid `\.{Too many \}'s}' complaints from \TeX). This can be done by using
+the \.{\\iftrue\{\\else\}\\fi} trick (and a generous sprinkling of \.{\\expandafter}s).
+Of course, some bookkeeping is needed to keep track of how deep inside the
+braced groups we are.
+For an implicit brace, more work is needed: read all the
+characters that \.{\\string} produced (and maybe more), then remember
+the number of characters consumed. Remove the rest of the input using
+the method described above and restart the scanning from the same point
+knowing that the next token can be scanned as a parameter.
+
+Another strategy is to design a general enough macro that counts
+tokens in a token register and simply recount the tokens after every
+brace was consumed.
+
+Either way, it takes a lot of work. If anyone would
+like to pursue the counting strategy, simple counting macros
+are provided in \.{/examples/count/count.sty}.
+The macros in this example
+supply a very general counting mechanism that does not depend on
+\.{\\yyeof} (or {\it any\/} other token) being `special' and can count the
+tokens in any token register, as long as none of those tokens is an
+\.{\\outer} control sequence. In other words, if the macro is used
+immediately after the assignment to the token register, it should
+always produce a correct count.
+
+Needless to say, if such a general mechanism is desired, one has to
+look elsewhere. The added complications of treating spaces (\TeX\
+tends to ignore them most of the time) make this a torturous exercise
+in \TeX's macro wizardry.
+
+The included \.{\\yyinput} has two ways of
+dealing with braces: strip them or view the whole group as a
+token. Pick one or write a different \.{\\yyinput}. Spaces, implicit
+or explicit, are reported as a specially selected character code and
+consumed with a likeness of
+\.{\\afterassignment\\moveon\\let\\next={\tt\char`\ }}. This behavior
+can be adjusted if needed.
+
+Now that a steady stream of character codes is arriving at \.{\\yylex}
+after \.{\\yyreturn} the job of converting it into numerical tokens
+is performed by the {\it scanner} (or {\it lexer\/}, or {\it tokenizer\/},
+or even {\it tokener}), discussed in the next section.
+\enddoublecols
+\endgroup
+
+@*1 Lexing in \TeX. In a typical system that uses a parser to process
+text, the parsing pass is usually split into several stages: the raw
+input, the lexical analysis (or simply {\it lexing}), and the parsing
+proper. The {\it lexing\/} (also called {\it scanning}, we use these
+terms interchangeably) clumps various sequences of characters into
+{\it tokens\/} to facilitate the parsing stage. The reasons for this
+particular hierarchy are largely pragmatic and are partially historic
+(there is no reason that {\it parsing\/} cannot be done in multiple
+phases, as well, although it usually isn't).
+
+If one recalls a few basic facts from the formal language theory, it
+becomes obvious that a lexer, that parses {\it regular\/} languages,
+can (theoretically) be replaced by an {\sc LALR} parser, that parses {\it
+context-free\/} ones (or some subset thereof, which is
+still a super set of all regular languages). A common justification given for
+creating specialized lexers is efficiency and speed. The
+reality is somewhat more subtle. While we do care about the efficiency of
+parsing in \TeX, having a specialized scanner is important for
+a number of different reasons.
+
+The real advantage of having a dedicated scanner is the ease with which it
+can match incomplete inputs and back up. A parser can, of course,
+{\it recognize\/} any valid input that is also acceptable to a lexer, as well
+as {\it reject\/} any input that does not form a valid token. Between
+those two extremes, however, lies a whole realm of options that a
+traditional parser will have great difficulty exploring. Thus, to
+mention just one example, it
+is relatively easy to set up a {\sc DFA}\footnote{Which stands for
+Deterministic Finite Automaton, a common (and mathematically unique)
+way of implementing a scanner for regular languages. Incidentally {\sc
+LALR} mentioned above is short for Look Ahead Left to Right.}
+so that the {\it longest\/}
+matching input is accepted. The only straightforward way to do this
+with a traditional parser is to parse longer and longer inputs again
+and again. While this process can be optimized to a certain degree,
+the fact that a parser has a {\it stack\/} to maintain limits its
+ability to back up.
+
+As an aside, the mechanism by which \CWEB\ assembles its `scraps'
+into chunks of recognized code is essentially iterative lexing,
+very similar to what a human does to make sense of complicated
+texts. Instead of trying to match the longest running piece of text,
+\CWEB\ simply looks for patterns to combine inputs into larger
+chunks, which can later be further combined. Note that this is not
+quite the same as the approach taken by, say {\sc GLR} parsers, where
+the parser must match the {\it whole\/} input or declare a
+failure. Where a \CWEB-type parser may settle for the first available
+match (or the longest available) a {\sc GLR} parser must try {\it
+all\/} possible matches or use an algorithm to reject the majority of
+the ones that are bound to fail in the end.
+
+This `\CWEB\ way' is also different from a traditional `strict' {\sc
+LR} parser/scanner approach and certainly deserves serious
+consideration when the text to be parsed possesses some rigid
+structure but the parser is only allowed to process it one small
+fragment at a time.
+
+Returning to the present macro suite, the lexer produced by \flex\
+uses integer tables similar to those employed by \bison\ so the
+usual {\sc\TeX}niques used in implementing \.{\\yyparse} are fully
+applicable to \.{\\yylex}.
+
+An additional advantage provided by having a \flex\ scanner implemented
+as part of the suite is the availability of the original \bison\ scanner written
+in \Cee\ for the use by the macro package.
+
+This said, the code generated by \flex\ contains a few idiosyncrasies
+not present in the \bison\ output. These `quirks' mostly involve
+handling of end of input and error conditions. A quick glance at the
+\.{\\yylex} implementation will reveal a rather extensive collection of
+macros designed to deal with end of input actions.
+
+Another difficulty one has to face in translating \flex\ output into
+\TeX\ is a somewhat unstructured namespace delivered in the final
+output (this is partially due to the \POSIX\ standard that \flex\
+strives to follow). One consequence of this `messy' approach is that the
+writer of a \flex\ scanner targeted to \TeX\ has to declare \flex\
+`states' (more properly called {\it subautomata}) twice: first for the
+benefit of \flex\ itself, and then again, in the {\it \Cee\ preamble\/}
+portion of the code to output the states to be used by the action code
+in the lexer. \.{Define\_State($\ldots$)} macro is provided for this
+purpose. This macro can be used explicitly by the programmer or be
+inserted by a specially designed parser.
+Using \CWEB\ helps to keep these declarations together.
+
+The `hand-off' from the scanner to the parser is implemented
+through a pair of registers: \.{\\yylval}, a token register
+containing the value of the returned token and \.{\\yychar}, a
+\.{\\count} register that contains the numerical value of the
+token to be returned.
+
+Upon matching a token, the scanner passes one crucial piece of
+information to the programmer: the character sequence representing the token
+just matched (\.{\\yytext}). This is not the whole story
+though as there are three more token sequences that are made available
+to the parser writer whenever a token is matched.
+
+The first of these is simply a `normalized' version of
+\.{\\yytext} (called \.{\\yytextpure}). In most cases it
+is a sequence of \TeX\ tokens with the same character codes as the one
+in \.{\\yytext} but with their category codes set to 12
+(see the discussion of \.{\\yybytepure}
+\locallink{yybytepure-discussion}above\endlink). In
+cases when the tokens in \.{\\yytext} are {\it not}
+$(c_{\rm ch}, c_{\rm cat})$ pairs, a few simple
+conventions are followed, some of which will be explained below. This
+sequence is provided merely for convenience and its typical use is to
+generate a key for an associative array.
+
+The other two sequences are special `stream pointers' that provide
+access to the extended scanner mechanism in order to implement the passing
+of the `formatting hints' to the parser, as well as incorporate
+\CWEAVE\ formatted code into the input, without introducing any changes to
+the original grammar. As the mechanism itself and the motivation
+behind it are somewhat subtle, let us spend a few moments discussing
+the range of formatting options desirable in a generic pretty-printer.
+
+Unlike strict parsers employed by most compilers, a parser designed
+for pretty printing cannot afford being too picky about the structure
+of its input (\cite[Go] calls such parsers `loose'). To provide
+a simple illustration, an isolated identifier, such as `\.{lg\_integer}'
+can be a type name, a variable name, or a structure tag (in a language like
+\Cee\ for example). If one expects the pretty printer to typeset this
+identifier in a correct style, some context must be supplied, as
+well. There are several strategies a pretty printer can employ to get
+a hold of the necessary context. Perhaps the simplest way to handle
+this, and to reduce the complexity of the pretty printing algorithm is
+to insist on the programmer providing enough context for the parser to do
+its job. For short examples like the one above, this may be an acceptable
+strategy. Unfortunately, it is easy to come up with longer snippets of
+grammatically deficient text that a pretty printer should be expected
+to handle. Some pretty printers, such as the one employed by \CWEB\
+and its ilk (the original \.{WEB}, \.{FWEB}), use a very flexible
+bottom-up technique that tries to make sense of as large a portion of
+the text as it can before outputting the result (see also \cite[Wo],
+which implements a similar algorithm in \LaTeX).
+
+The expectation is that this algorithm will handle the majority (about
+90\%? it would be interesting to carry out a study in the spirit of
+the ones discussed in \cite[Jo] to find out) of the
+cases with the remaining few left for the author to correct. The
+question is, how can such a correction be applied?
+
+\CWEB\ itself provides two rather different mechanisms for handling
+these exceptions. The first uses direct typesetting commands (for
+example, \.{@@/} and \.{@@\#} for canceling and
+introducing a line break, resp.) to change the typographic output.
+
+The second (preferred) way is to supply {\it hidden context\/} to the
+pretty-printer. Two commands, \.{@@;} and
+\.{@@[}$\ldots$\.{@@]} are used for this purpose. The
+former introduces a `virtual semicolon' that acts in every way like a
+real one except it is not typeset (it is not output in the source file
+generated by \CTANGLE\ either but this has nothing to do with pretty
+printing, so I will not mention \CTANGLE\ anymore). For
+instance, from the parser's point of view, if the preceding text was
+parsed as a `scrap' of type {\it exp}, the addition of \.{@@;}
+will make it into a `scrap' of type {\it stmt\/} in \CWEB's
+parlance. The second construct (\.{@@[}$\ldots$\.{@@]}),
+is used to create an {\it exp\/} scrap out of whatever happens to be
+inside the brackets.
+
+This is a powerful tool at the author's disposal. Stylistically,
+such context hints are the right way to handle exceptions,
+since using them forces the writer to emphasize the {\it logical\/}
+structure of the formal text. If the pretty printing style is changed
+later on, the texts with such hidden contexts should be able to
+survive intact in the final document (as an example, using a break
+after every statement in \Cee\ may no longer be considered
+appropriate, so any forced break introduced to support this convention
+would now have to be removed, whereas \.{@@;}'s would simply
+quietly disappear into the background).
+
+The same hidden context idea has another important advantage: with
+careful grammar fragmenting (facilitated by \CWEB's or any other
+literate programming tool's `hypertext' structure) and a more diverse
+hidden context (or even arbitrary hidden text) mechanism, it is
+possible to use a strict parser to parse incomplete language
+fragments. For example, the productions that are needed to parse
+\Cee's expressions form a complete subset of the grammar. If the
+grammar's `start' symbol is changed to \prodstyle{expression} (instead of
+the \prodstyle{translation-unit} as it is in the full \Cee\ grammar), a
+variety of incomplete \Cee\ fragments can now be parsed and
+pretty-printed. Whenever such granularity is still too `coarse',
+carefully supplied hidden context will give the pretty printer enough
+information to adequately process each fragment. A number of such {\it
+sub}-parsers\namedspot{parser.stacks} can be tried on each fragment (this may sound
+computationally expensive, however, in practice, a carefully chosen
+hierarchy of parsers will finish the job rather quickly) until a
+correct parser produced the desired output (this approach is similar
+to, although not quite the same as the one employed by the {\it General LR
+parsers}).
+
+This somewhat lengthy discussion brings us to the question directly
+related to the tools described in this manual: how does one provide
+typographical hints or hidden context to the parser?
+
+One obvious solution is to build such hints directly into the
+grammar. The parser designer can, for instance, add new tokens
+(say, \.{BREAK\_LINE}) to the grammar and extend the
+production set to incorporate the new additions. The risk of
+introducing new conflicts into the grammar is low (although not
+entirely non-existent, due to the lookahead limitations of {\sc LR}($1$)
+grammars) and the changes required are easy, although very tedious, to
+incorporate.
+
+In addition to being labor intensive, this solution has two other
+significant shortcomings: it alters the original grammar and hides its
+logical structure; it also `bakes in' the pretty-printing conventions
+into the language structure (making the `hidden' context much less
+`stealthy'). It does avoid the `synchronicity problem' mentioned
+below.
+
+A marginally better technique is to introduce a new regular expression
+recognizable by the scanner which will then do all the necessary
+bookkeeping upon matching the sequence. All the difficulties with
+altering the grammar mentioned above apply in this case, as well, only
+at the `lexical analysis level'. At a minimum, the set of tokens
+matched by the scanner would have to be altered.
+
+A much more satisfying approach involves inserting the hints at the input stage and
+passing this information to the scanner and the parser as part of the token
+`values'. The hints themselves can masquerade as characters ignored by the scanner
+(white space\footnote{Or even the `intercharacter space', to make the
+hints truly invisible to the scanner.}, for example) and preprocessed by a specially designed
+input routine. The scanner then simply passes on the values to the
+parser. This makes hints, in effect, invisible.
+
+The difficulty now lies in synchronizing the token production with the
+parser. This subtle complication is very familiar to anyone who has
+designed \TeX's output routines: the parser and the lexer are not
+synchronous, in the sense that the scanner might be reading several
+(in the case of the general {\sc LR}$(n)$ parsers) tokens\footnote{Even if
+one were to somehow mitigate the effects of the lookahead {\it in the
+parser\/}, the scanner would still have to read the characters of the
+current token up to (and, in some cases, beyond) the (token's)
+boundary which, in most cases, is
+the whitespace, possibly hiding the next hint.} ahead of the
+parser before deciding on how to proceed (the same way \TeX\ can
+consume a whole paragraph's worth of text before exercising its page
+builder).
+
+If we simple-mindedly let the scanner return every hint it has encountered
+so far, we may end up feeding the parser the hints meant for the token
+that appears {\it after\/} the fragment the parser is currently working
+on. In other words, when the scanner `backs up' it must correctly back
+up the hints as well.
+
+This is exactly what the scanner produced by the tools in this package
+does: along with the main stream of tokens meant for the parser, it
+produces two\footnote{There would be no difficulty in splitting either
+of these streams into multiple `substreams' by modifying the stream
+extraction macros accordingly.} hidden streams (called the \.{\\yyformat} stream and
+the \.{\\yystash} stream) and provides the parser with two
+strings (currently only strings of digits are used although arbitrary
+sequences of \TeX\ tokens can be used as pointers) with the promise
+that {\it all the `hints' between the beginning of the corresponding
+stream and the point labeled by the current stream pointer appeared
+among the characters up to and, possibly, including the ones matched
+as the current token}. The macros to extract the relevant parts of the
+streams (\.{\\yyreadfifo} and its cousins) are provided for the
+convenience of the parser designer.
+
+The \.{\\yystash} stream collects all the typesetting commands inserted by
+\CWEB\ to be possibly used in displaying the action code in \bison\
+productions, for example. Because of this, it may appear in somewhat
+unexpected places, introducing spaces where the programmer did not
+neccessarily intend (such as at the beginning of the line, etc.). To
+mitigate this problem, the \.{\\yystash} stream macros are implemented
+to be entirely invisible to the lexer. Making them produce spaces is
+also possible, and some examples are provided in \.{symbols.sty}.
+The interested reader can consult the input routine macros in
+\.{yyinput.sty} for the
+details of the internal representation of the streams.
+
+In the interest of full disclosure, let me point out that this simple
+technique introduces a significant strain on \TeX's
+computational resources: the lowest level macros, the ones that handle
+character input and are thus executed (sometimes multiple times), for
+{\it every\/} character in the input stream are rather complicated and
+therefore, slow. Whenever the use of such streams is not desired a simpler
+input routine can be written to speed up the process (see
+\.{\\yyinputtrivial} for a working example of such macro).
+
+Finally, while probably not directly related to the present
+discussion, this approach has one more interesting feature: after the
+parser is finished, the parser output and the streams exist
+`statically', fully available for any last minute preprocessing or for
+debugging purposes, if necessary\footnote{One may think of the parser output
+as an {\it executable abstract syntax tree (AST)}.}. Under most circumstances, the parser
+output is `executed' and the macros in the output are the ones reading
+the various streams using the pointers supplied at the parsing stage
+(at least, this is the case for all the parsers supplied with the
+package).
+
+@*1 Inside semantic actions: switch statements and `functions' in \TeX.
+So far we have looked at the lexer for your input, and a grammar ready to be put into
+action (we will talk about actions a few moments later). It is time to discuss
+how the tables produced by \bison\ get converted into \TeX\ {\it macros\/}
+that drive the parser in {\it \TeX}.
+
+The tables that drive the \bison\ input parsers
+are collected in \.{\{b,d,f,g,n\}yytab.tex} and \.{small\_tab.tex}. Each
+one of these files contains the tables that implement a specific parser
+used during different stages of processing.
+Their exact function is well explained
+in the source file produced by \bison\ ({\it how} this is done is
+detailed elsewhere, see \cite[Ah] for a good reference). It would
+suffice to mention here that there are three types of tables in this
+file: \recount{1}numerical tables such as \.{\\yytable} and
+\.{\\yycheck} (both are either \TeX's token registers in an
+unoptimized parser or associate arrays in an optimized version of such
+as discussed below),
+\recount{2}a string array \.{\\yytname}, and \recount{3}an action
+switch. The action switch is what gets called when the parser does a
+{\it reduction}. It is easy to notice that the numerical tables come
+`premade' whereas the string array consisting of token names
+is difficult to recognize. This is intentional: this form of initialization
+is designed to allow the widest range of
+characters to appear inside names. The macros that do this reside in
+\.{yymisc.sty}. The generated table files also contain
+constant and token declarations used by the parser.
+
+The description of the process used to output \bison\ tables in an
+appropriate form continues in the section about
+\locallink{bsfile}outputting \TeX\ tables\endlink, we pick it up here
+with the description of the syntax-directed translation and the
+actions. The line
+$$
+\.{\\switchon\\next\\in\\currentswitch}
+$$
+is responsible for calling an appropriate action in the current
+switch, as is easy to infer. A {\it switch\/} is also a macro that
+consists of strings of \TeX\ tokens intermixed with \TeX\ macros
+inside braces. Each group of macros
+gets executed whenever the character or the group of characters in
+\.{\\next} matches a substring preceding the braced group. If there
+are two different substrings
+that match, only the earliest group of macros gets expanded.
+Before a state is
+used, a special control sequence,
+\.{\\setspecialcharsfrom\\switchname} can be used to put the \TeX\
+tokens in a form suitable for the consumption by \.{\\switchon}'s. The
+most important step it performs is it {\it turns every token in the
+list into a character with the same character code and category
+12\/}. Thus \.{\\\{} becomes \.{\{}$_{12}$. There are other ways of
+inserting tokens into a state: enclosing a token or a string of tokens in
+\.{\\raw...\\raw} adds it to the state macro unchanged. If you have
+a sequence of category 12 characters you want to add to the state, put
+it after \.{\\classexpand} (such sequences are usually prepared by the
+\.{\\setspecialchars} macro that uses the token tables generated by
+\bison\ from your grammar).
+
+You can give a case a readable label (say, \.{brackets}) and enclose
+this label in \.{\\raw}$\ldots$\.{\\raw}. A word of caution: an `\.{a}'
+inside of \.{\\raw}$\ldots$\.{\\raw} (which is most likely an
+\.{a}$_{11}$ unless you played with the category codes before loading the
+\.{\\switchon} macros) and the one outside it are two different
+characters, as one is no longer a letter (category 11) in the eyes of
+\TeX\ whereas the other one still is. For this reason one should not
+use characters other than letters in h\.{\{}is\.{,}er\.{\}} state
+{\em names}: the way a state picks an action does not distinguish between,
+say, a `\.{(}' in `\.{(letter)}' and a stand alone `\.{(}' and may
+pick an action that you did not intend\footnote{One way to mitigate
+this is by putting such named states at the end of the switch, {\em
+after\/} the actions labelled by the standalone characters.}.
+This applies even if `\.{(}'
+is not among the characters explicitly inserted in the state macro: if
+an action for a given character is not found in the state macro, the
+\.{\\switchon} macro will insert a current \.{\\default} action
+instead, which most often you would want to be \.{\\yylex} or
+\.{\\yyinput} (i.e.\ skip this token). If a single `\.{(}' or `\.{)}' matches
+the braced group that follows `\.{(letter)}' chaos may ensue (most
+likely \TeX\ will keep reading past the \.{\\end} or \.{\\yyeof} that
+should have terminated the input). Make the names of character
+categories as unique as possible: the \.{\\switchon} is simply a
+string matching mechanism, with the added differentiation between
+characters of different categories.
+
+Finally, the construct \.{\\statecomment}{\it
+anything\/}\.{\\statecomment} allows you to insert comments in the
+state sequence (note that the state {\it name\/} is put at the
+beginning of the state macro (by \.{\\setspecialcharsfrom})
+in the form of a special control sequence
+that expands to nothing: this elaborate scheme is needed because
+another control sequence can be \.{\\let} to the state macro which
+makes the debugging information difficult to decipher). The debugging
+mode for the lexer implemented with these macros is activated by
+\.{\\tracedfatrue}.
+
+The functionality of the \.{\\switchon} (as well as the \.{\\switchonwithtype}, which
+is capable of some rudimentary type checking) macros (for `historical'
+reasons, one can also use \.{\\action} as a synonym for the latter) has been
+implemented in a number of other macro packages (see \cite[Fi] that
+discusses the well-known and widely used \.{\\CASE} and \.{\\FIND}
+macros). The macros in this collection have the additional property
+that the only assignments that persist after the \.{\\switchon}
+completes are the ones performed by the user code inside the selected
+case.
+
+This last property of the switch macros is implemented using another
+mechanism that is part of this macro suite: the `subroutine-like'
+macros, \.{\\begingroup}$\ldots$\.{\\tokreturn}. For examples, an
+interested reader can take a look at the macros included with the
+package. A typical use is
+\.{\\begingroup}$\ldots$\.{\\tokreturn\{\}\{\\toks0 \}\{\}} which will
+preserve all the changes to \.{\\toks0} and have no other side effects
+(if, for example, in typical \TeX\ vernacular, \.{\\next} is used
+to implement tail recursion inside the group, after the
+\.{\\tokreturn}, \.{\\next} will still have the same value it
+had before the group was entered). This functionality comes at the
+expense of some computational efficiency.
+
+This covers most of the routine computations inside semantic actions,
+all that is left is a way to `tap' into the stack automaton
+built by \bison\ using an interface similar to the special
+\.{\$$n$} variables utilized by the `genuine' \bison\ parsers
+(i.e.\ written in \Cee\ or any other target language supported by
+\bison).
+
+This r\^ole is played by the several varieties of \.{\\yy$\,p$} command
+sequences (for the sake of completeness, $p$ stands for one of \.{($n$)},
+\.{[{\rm name}]}, \.{]{\rm name}[} or $n$, here $n$ is a
+string of digits, and a `name' is any name acceptable as a symbolic
+name for a term in \bison). Instead
+of going into the minutia of various flavors of \.{\\yy}-macros, let me
+just mention that one can get by with only two `idioms' and still
+be able to write parsers of arbitrary sophistication:
+\.{\\yy($n$)} can be treated as a token register containing the
+value of the $n$-th term of the rule's right hand side, $n>0$. The left
+hand side of a production is accessed through \.{\\yyval}. A
+convenient shortcut is \.{\\yy0\{{\rm \TeX\space material}\}} which
+will expand (as in \.{\\edef}) the `\TeX\ material' inside the braces. Thus, a simple way
+to concatenate the values of the first two production terms is
+\.{\\yy0\{\\the\\yy(1)\\the\\yy(2)\}}. The included \bison\
+parser can also be used to provide support for `symbolic names',
+analogous to \bison's \.{{\$}[{\rm name}]} but a
+bit more effort is required on the user's part to initialize such support.
+Using symbolic names can make the parser more readable and maintainable,
+however.
+
+There is also a \.{\\bb$\,n$} macro, that has no analogue in the
+`real' \bison\ parsers, and provides access to the term
+values in the `natural order' (e.g.~\.{\\bb1} is the last term read). Its
+intended use is with the `inline' rules (see the main parser for
+such examples). As of version \.{3.0} \bison\ no longer outputs
+|yyrhs| and |yyprhs|, which makes it impossible to produce the
+|yyrthree| array necessary for processing such rules in the `left to right'
+order. One might also note that the new notation is better suited for
+the inline rules since the value that is pushed on the stack is that
+of \.{\\bb0}, i.e.~the term implicitly inserted by \bison. Be aware
+that there are no \.{\\bb[$\cdot$]} or \.{\\bb($\cdot$)} versions of
+these macros, for obvious reasons. A less obvious feature of this
+macro is its `nonexpandable' nature. This means they cannot be used
+inside \.{\\edef}. Thus, the most common use pattern is
+\.{\\bb$\,n$\{\\toks$\,m$\}} with a subsequent expansion of
+\.{\\toks$\,m$}. Making these macros expandable is certainly possible
+but does not seem crucial for the intended limited use pattern.
+
+Naturally, a parser writer may need a number of other data
+abstractions to complete the task. Since these are highly dependent on
+the nature of the processing the parser is supposed to provide, we
+refer the interested reader to the parsers included in the package as
+a source of examples of such specialized data structures.
+
+One last remark about the parser operation is worth making here:
+the parser automaton itself does not make any \.{\\global}
+assignments. This (along with some careful semantic action writing)
+can be used to `localize' the effects of the parser operation and,
+most importantly, to create `reentrant' parsers that can, e.g.\ call
+{\it themselves\/} recursively.
+
+@*1 `Optimization'.
+\namedspot{optimization}By default, the generated parser and scanner keep all of their tables
+in separate token registers. Each stack is kept in a single macro (this
+description is further complicated by the support for parser {\it
+namespaces\/} that exists even for unoptimized parsers but this
+subtlety will not be mentioned again---see the macros in the package
+for further details). Thus, every time a table
+is accessed, it has to be expanded making the table access latency
+linear in {\it the size of the table}. The same holds for stacks and
+the action `switches', of
+course. While keeping the parser tables (which are immutable) in token
+registers does not have any better rationale than saving the control
+sequence memory (the most abundant memory in \TeX), this way of
+storing {\it stacks} does have an advantage when multiple parsers get
+to play simultaneously. All one has to do to switch from one parser to
+another is to save the state by renaming the stack control sequences.
+
+When the parser and scanner are `optimized', all these control
+sequenced are `spread over' appropriate associative arrays. One caveat
+to be aware of: the action switches for both the parser and the scanner
+have to be output differently (a command line option is used to
+control this) for optimized and unoptimized parsers. While it is
+certainly possible to optimize only some of the parsers (if your
+document uses multiple) or even only some {\it parts\/} of a given
+parser (or scanner), the details of how to do this are rather
+technical and are left for the reader to discover by reading the
+examples supplied with the package. At least at the beginning it is
+easier to simply set the highest optimization level and use it
+consistently throughout the document.
+
+@*1 {\it \TeX\/} with a different {\sl slant} or do you C an escape?.
+Some \TeX\ productions below probably look like alien script.
+The authors of \cite[Er] cite a number of reasons to view pretty printing of
+\TeX\ in general as a nearly impossible task. The macros included with
+the package follow a very straightforward strategy and do not try to
+be very comprehensive. Instead, the burden of presenting \TeX\ code in
+a readable form is placed on the programmer. Appropriate hints can be
+supplied by means of indenting the code, using assignments ($=$) where
+appropriate, etc. If you would rather look at straight \TeX\
+instead, the line \.{\\def\\texnspace\{other\}} at the beginning of
+this section can be uncommented and
+{\let\writetexidxentry\writetextxtidxentry
+|TeX_( "/noexpand/inmath{/yy0{/yy1{}}}" );|} becomes {%
+\def\texnspace{other}%
+\def\texispace{other}% for the index
+\let\writetexidxentry\writetextxtidxentry % for the index appearance
+|TeX_( "/noexpand/inmath{/yy0{/yy1{}}}" );|}.
+There is, however, more to this story. A look at the actual file will
+reveal that the line above was typed as
+$$
+\.{TeX\_( "/noexpand/inmath\{/yy0\{/yy1\{\}\}\}" );}
+$$
+The `escape character' is leaning the other way!
+The lore of \TeX\ is uncompromising: `\.{\\}' is {\it the\/} escape
+character. What is the reason to avoid it in this case?
+
+The mystery is not very deep: `\.{/}' was chosen as an escape character
+by the parser macros (a quick glance at \.{?yytab.tex} will reveal as
+much). There is, of course, nothing sacred (other than tradition,
+which this author is trying his hardest to follow) about what character code
+the escape character has. The reason to look for an alternative is straightforward: `\.{\\}' is
+a special character in \Cee, as well (also an `escape', in fact). The line
+\.{TeX\_( "..." );} is a {\it macro-call\/} but $\ldots$ in \Cee. This
+function simply prints out (almost `as-is') the line in
+parenthesis. An attempt at \.{TeX\_( "\\noexpand" );} would result in
+\numberlinestrue
+\begindemo
+^
+^oexpand
+\enddemo
+\numberlinesfalse
+Other escape combinations\footnote{Here is a full list of {\it
+defined\/} escaped characters in \Cee: \.{\\a}, \.{\\b}, \.{\\f}, \.{\\n},
+\.{\\r}, \.{\\t}, \.{\\v}, \.{\\}{$[$\it octal digit\/$]$}, \.{\\'},
+\.{\\"}, \.{\\?}, \.{\\\\}, \.{\\x}, \.{\\u}, \.{\\U}. Note that the
+last three combinations must be followed by a specific string of
+characters to appear in the input without generating errors.} are
+even worse: most are simply undefined. If anyone feels trapped without
+an escape, however, the same line can be typed as
+$$
+\.{TeX\_( "\\\\noexpand\\\\inmath\{\\\\yy0\{\\\\yy1\{\}\}\}" );}
+$$
+Twice the escape!
+
+If one were to look even closer at the code, another oddity stands
+out: there are no \.{\$}'s anywhere in sight.
+The big money, \.{\$} is a beloved character in
+\bison. It is used in action code to reference the values of the
+appropriate terms in a production. If mathematics pays your bills, use
+\.{\\inmath} instead.
@i bo.x
@i lo.x
+@i fo.x
+@i so.x
@i np.x
@i common.w
@i bs.w
@i fk.w
@i philosophy.w
+@i checklists.w
@i references.w
-\let\N\oldN
\let\hostparsernamespace\mainnamespace % to typeset examples in the text
% properly
@**Index. This section is, perhaps, the most valuable product of
\CWEB's labors. It lists references to definitions (set in {\it
italic}) as well as uses for each \Cee\ identifier used in the
-source. Special facilities have been added to extend indexing to
-\bison\ grammar terms and \TeX\ control sequences encountered in
+source. Special facilities have been added to extend the indexing to
+\bison\ grammar terms, \flex\ regular expression names and state names, as well as
+\flex\ options,
+and \TeX\ control sequences encountered in
\bison\ actions. Definitions of tokens (via \prodstyle{\%token},
\prodstyle{\%nterm} and \prodstyle{\%type} directives) are
%$\underline{\hbox{underlined}}$
@@ -64,7 +1845,7 @@ appeared on the left hand side of a production. A production:
}%
\beginmprod
left_hand_side:
- term.1 term.2 term.3 \{\stashed{|TeX_("/dosomething/yy(1)");|}\}
+ term.1 term.2 term.3 \{\stashed{|TeX_("/do/something/yy(1)");|}\}
\endmprod
inside the \TeX\ part of a \CWEB\ section will generate several
index entries, as well, including the entries for any
@@ -82,21 +1863,51 @@ program). The same applies to the way the index is constructed (it
would be easy to only use the `string' name of the token if
available, thus avoiding referencing the same token twice).
-\TeX\ control sequences are listed following the index of all \bison\
-entries. The two indices are separated by a {\it dinkus}
+\TeX\ control sequences are listed following the index of all \bison\ and \flex\
+entries. The different sections of the index are separated by a {\it dinkus\/}
(\dinkus). Since it is nearly impossible to determine at what point a
\TeX\ macro is defined (and most of them are defined outside of the
\CWEB\ sources), only their uses are listed (to be more precise, {\it
every\/} appearance of a macro is assumed to be its use). In a few cases, a
-`graphic' representation for a control sequence is also listed (for
-example, {\termindexfalse\def\texnspace{texline}\inlineTeXx{/getfirst}} represents
-{\termindexfalse\def\texnspace{other}\inlineTeXx{/getfirst}}). The index entries are ordered alphabetically. The
+`graphic' representation for a control sequence appears in the index (for
+example, {\let\writetexidxentry\writetextxtidxentry
+\def\texnspace{texline}\def\texispace{index}\inlineTeXx{/getfirst}} represents
+{\let\writetexidxentry\writetextxtidxentry
+\def\texnspace{other}\def\texispace{other}\inlineTeXx{/getfirst}$\!$}).
+The index entries are ordered alphabetically. The
latter may not be entirely obvious in the cases when the `graphical
representation' of the corresponding token manifests a significant
-departure from its string version (such as |TeX_("/yy(1)");|
-instead of {\def\texnspace{other}|TeX_("/yy(1)");|}).
+departure from its string version (such as
+{\let\writetexidxentry\writetextxtidxentry|TeX_("/yy(1)");|}
+instead of {\def\texnspace{other}\def\texispace{other}%
+\let\writetexidxentry\writetextxtidxentry
+|TeX_("/yy(1)");|$\!$}). Incidentally, for the examples on this page
+(as well an example in the section about \TeX\ pretty-printing) both
+the `graphic' as well as `text' versions of the control sequence are
+indexed. It is instructive to verify that their location in the index
+corresponds to the `spelling' of their visual representation (thus,
+{\let\writetexidxentry\writetextxtidxentry
+\def\texnspace{texline}\def\texispace{index}\inlineTeXx{/getfirst}}
+appears under `p'). One should also be aware that the indexing of some terms has
+been suppressed, since they appear too often.
+\unsetfootnotes % this way the footnote stream is not affected by the extra index pages
+% TODO: explain the visibility system. Note the anomalous order of \prodstyle{term.1}
+% vs.~\prodstyle{term0} due to the dot in \.{term.1}, which is otherwise invisible. Underscore the
+% importance of following a consistent naming scheme, including the `stringized' versions
+% of token names.
+@q Include the list of index section markers; this is a hack to get around @>
+@q the lack of control over the generation of \CWEB's index; the correct order @>
+@q of index entries depends on the placement of this inclusion @>
+@i alphas.hx
+
\closeout\gindex
+\termindexfalse % do not attach indexing entries to the terms in the index, or the section list
+\def\next{\expandafter\eatone\string}
+\edef\unindexable{{\next\the}{\next\nx}{\next\yy}{\next\yylexnext}{\next\else}{\next\fi}{\next\yyBEGIN}{\next\next}}
+\input gindex.sty
+%\indexverbosetrue
\let\inx\inxmod
\let\fin\finmod
-\displaytokenrawtrue
+\lxrefseparator % start generating section lists
+%\displaytokenrawtrue % so that the `nonstringified' version of the token is displayed as well
\def\topofcontents{\null\vskip-3\baselineskip\centerline{C{\sc ONTENTS} (\sc\uppercase\expandafter{\title})}\medskip}
diff --git a/support/splint/cweb/ssffo.w b/support/splint/cweb/ssffo.w
index 56e710b8c6..315bffc798 100644
--- a/support/splint/cweb/ssffo.w
+++ b/support/splint/cweb/ssffo.w
@@ -1,4 +1,4 @@
-@q Copyright 2012-2015, Alexander Shibakov@>
+@q Copyright 2012-2020, Alexander Shibakov@>
@q This file is part of SPLinT@>
@q SPLinT is free software: you can redistribute it and/or modify@>
@@ -16,18 +16,21 @@
\input limbo.sty
\def\optimization{5}
\input yy.sty
-
+\modenormal
\let\oldN\N
\let\N\textN
\let\M\textM
-\def\hostparsernamespace{[unreacheable]}
+% uncomment the next line to leave the typesetting of tokens in its raw state.
+%\def\hostparsernamespace{[unreacheable]}
+\let\hostparsernamespace\mainnamespace
+\input btokenset.sty
@** A simple scanner for \flex\ options.
This is a `bare-bones' scanner for a subset of the `extended' \bison\
-grammar that parses, well, some of the `extensions', namely, the
+grammar that parses some of the `extensions', namely, the
\flex\ state declarations. It does not use the state mechanism
itself, and is supposed to be used with the bootstrapping parser, even
-though it is not strictly necessary. It parses state declarations as
+though this is not strictly necessary. It parses state declarations as
long as they are separated into their own \CWEB\ sections and extracts
the {\it names\/} of the states. The \flex\ scanner output `driver'
does the rest after including the produced header file.
@@ -57,7 +60,7 @@ something that should not have been. Making the syntax and the grammar
more restrictive helps to acheive this, as well as makes the overall
design simpler.
@<Lexer definitions@>=
-@G
+@G(fs1)
letter [_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ]
id {letter}({letter}|[-0-9])*
@g
@@ -89,13 +92,15 @@ of tokens recognized by this routine is not very wide.
@ White space skipping.
@<Scan white space@>=
-@G
+@G(fs2)
[ \f\n\t\v] {@> @[TeX_( "/yylexnext" );@]@=}
@g
-@ The rest of it are either identifiers or \.{\%}-options.
+@ The rest of it are either identifiers or \.{\%}-options. The typesetting of
+the appropriate \bison\ tokens below was arranged by inputting \.{btokenset.sty} and
+relying on the pretty-printing macros for {\it \TeX} to do their job.
@<Scan identifiers@>=
-@G
+@G(fs2)
{id} {@> @<Return an identifier@> @=}
"%x" {@> @[TeX_( "/yylexreturnptr{FLEX_STATE_X}" );@] @=}
"%s" {@> @[TeX_( "/yylexreturnptr{FLEX_STATE_S}" );@] @=}
@@ -110,7 +115,7 @@ of tokens recognized by this routine is not very wide.
@ The lexer returns standard \.{\\yyunion} types.
@<Return an identifier@>=
- @[TeX_( "/edef/next{/yylval{/nx/idit{/the/yytextpure}{/the/yytext}" );@]@;
+ @[TeX_( "/edef/next{/yylval{{/the/yytextpure}{/the/yytext}" );@]@;
@[TeX_( " {/the/yyfmark}{/the/yysmark}}}/next" );@]@;
@[TeX_( "/yylexreturn{ID}" );@]@;