1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
|
1). The BNF macros cannot deal with environments that are started by one of
the optional parameters and ended by another. For example the following
example (due to Florence Maraninchi of LGI-IMAG Campus, BP 53X, 38041
Grenoble cedex, FRANCE) does not work.
This is a structural problem, that I do not have time to consider at the
moment. If anyone else solves it, will they please let me know?
________________________________________________________________________________
\newenvironment{tabu}{\begin{tabular}{ll}[t]}{\end{tabular}}
\begin{grammar}
[(colon){\begin{tabu} : & }]
[(period){\end{tabu}}]
[(semicolon){\\ $\mid$ & }]
[(comma){ }]
[(quote){\begin{bf}}{\end{bf}}]
toto : expression.
expression: constante; idf;expression operateur expression.
operateur: "+" ; "-" ; "*" ; "/".
constante: "0" ; "1" ; "2" ; "3" ; "4".
\end{grammar}
________________________________________________________________________________
2). The above example also made me aware of another problem that has
not yet been reported. If you try and include a command with an optional
parameter in one of the optional parameters of the grammar environment,
LaTeX will get horribly confused. For example, a grammar environment
such as
--------------------------------------------------------------------------------
\begin{grammar}
[(colon){\rule[.5\lineskip]{10pt}{\lineskip}}]
wrong : won't work.
\end{grammar}
won't work. This is due to TeX' macro expansion mechanism, and an
elegant solution would require a fairly major overhaul, which I don't
have time for at the moment.
A hack is to change the syntax of the optional commands of the grammar
environment so that the optional commands are delimited by some other
symbol than "[" and "]". If, for example, we were to choose "!" as our
(left _and_ right) delimiter, then lines 63, 65, 66 and 69 of the
original BNF macros would have to be changed. They are currently
...............................................................................
\def\@dogrammarchars{
\@ifnextchar [{\@getchardef}{\@defaultchardefs}}
\def\@getchardef[(#1)#2]{
\@dogrammarchar{#1}[#2]
\@dogrammarchars}
\def\@dogrammarchar#1[#2]{
\csname if@#1\endcsname\else
\csname @def#1\endcsname{#2}\csname @#1true\endcsname\fi}
...............................................................................
and would have to become
................................................................................
\def\@dogrammarchars{
\@ifnextchar !{\@getchardef}{\@defaultchardefs}}
% ^
\def\@getchardef!(#1)#2!{
% ^ ^
\@dogrammarchar{#1}!#2!
% ^ ^
\@dogrammarchars}
\def\@dogrammarchar#1!#2!{
% ^ ^
\csname if@#1\endcsname\else
\csname @def#1\endcsname{#2}\csname @#1true\endcsname\fi}
................................................................................
(sorry to belabour the obvious, but to be on the safe side, the "^" are
only to indicate where the changes have taken place)
The optional parameters may not now contain any "!" symbols, or else
we're back where we started from.
3). Thanks to David Wright (wright@tasis.eecs.utas.edu.au) and Arto
Viitanen (av@uta.fi) for the next one.
I included a couple of spaces in the BNF macros, where I shouldn't have,
which leads to spurious spaces being produced in the output. (Dave
Wright's example was "->" appearing as "- >", and Arto Viitanen's was
"<terminal>" appearing as "<terminal >". The solution is to remove the
extra spaces, on lines 22 and 24. These were
................................................................................
\catcode`\<\active
\def<{{\@deactifygrammarchars \@first#1}}
% ^
\catcode`\>\active
\def>{{\@deactifygrammarchars \@second#1}}}
% ^
\endgroup
................................................................................
The "^" symbols indicate the spaces that should be removed.
4) The following is due to Craig Brown (cmb@research.canon.oz.au) at
Canon Information Systems Research Australia. This bug was the result
of my ignorance of the subtleties of TeX's input mechanism.
Just another comment regarding your Context Free Grammar.
This works:
\newenvironment{tligrammar}%
{\begin{grammar}%
[(nonterminal){\begin{bf}}{\end{bf}}]%
[(colon){ ::=}]%
[(comma){~}]%
[(semicolon){ $|$}]}%
{\end{grammar}}
\begin{tligrammar}
<A>: <B>, <C>, <D>.
\end{tligrammar}
and this does not:
\begin{grammar}
[(nonterminal){\begin{bf}}{\end{bf}}]
[(colon){ ::=}]
[(comma){~}]
[(semicolon){ $|$}]
<A>: <B>, <C>, <D>.
\end{grammar}
Conclusion: Latex is black magic!
Regards, Craig Brown.
Craig Brown | cmb@research.canon.oz.au
Canon Information Systems Research Australia | Phone +61-2-805-2900
PO Box 313 NORTH RYDE NSW 2113 | Fax +61-2-805-2929
5) The following major bug (what an embarassment) was found by Mark van
den Brand at the University of Nijmegen. I can't understand that nobody,
including myself, found it earlier.
If the left hand side is repeated in alternative production rules
seperated by semicolons, the result is not what one would want.
For example;
\begin{grammar}
rule:
first alternative;
rule:
second alternative.
\end{grammar}
is printed more or less as
rule:
first alternative;
rule:
second alternative.
Although this sort of construction may not be used very often when
writing context free grammars, it is more common in attribute grammars
(different alternatives have different attributes) and unavoidable in
affix grammars (some affixes are an inherent part of the left hand
side). I'm afraid an ugly hack might be necessary to repair this.
6) From Andreas Maassen (maassen@zeus.informatik.rwth-aachen.de)
The default value for nonterminal didn't work. The problem was that an
initial "<" was read before the default values were initialised, so that
it was read as a character, and not as a command. This has now been
repaired.
I had also forgotten to put "$"'s round the default values, so rather
than producing "<" and ">", the default was an upside down "!" and an
upside down "?". This has also been repaired.
|
