[Commit] mint-2004b conclusions.tex, 1.4, 1.5 mint.tex, 1.5, 1.6 translators.tex, 1.2, 1.3

[Bart Massey]

Committed by: bart

Update of /local/src/CVS/mint-2004b
In directory home.keithp.com:/tmp/cvs-serv27758

Modified Files:
	conclusions.tex mint.tex translators.tex 
Log Message:
fixed some stuff



Index: conclusions.tex
===================================================================
RCS file: /local/src/CVS/mint-2004b/conclusions.tex,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- conclusions.tex	1 Dec 2004 21:18:35 -0000	1.4
+++ conclusions.tex	1 Dec 2004 23:20:49 -0000	1.5
@@ -1,5 +1,10 @@
 \section{Conclusions and Future Work}\label{sec-conclusions}
 
+A number of important pieces of work on MINT remain.  The
+operator precedence system needs to be extended to handle
+more complex resolutions.  This will, for example, allow
+cleaning up the rest of the warnings in the Nickle grammar.
+
 As experimental as it is, the current implementation of MINT
 is versatile.
 The ease with which it has been able to bootstrap itself suggests that

Index: mint.tex
===================================================================
RCS file: /local/src/CVS/mint-2004b/mint.tex,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- mint.tex	1 Dec 2004 23:00:41 -0000	1.5
+++ mint.tex	1 Dec 2004 23:20:49 -0000	1.6
@@ -9,6 +9,8 @@
 
 \newcommand{\mysep}{\par\noindent\rule{0.75in}{0.5pt}\\}
 
+\newcommand{\id}[1]{{\tt #1}}
+
 \def\lastname{Kuo, LaMar, Massey, Packard}
 
 \begin{document}

Index: translators.tex
===================================================================
RCS file: /local/src/CVS/mint-2004b/translators.tex,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- translators.tex	1 Dec 2004 23:00:41 -0000	1.2
+++ translators.tex	1 Dec 2004 23:20:49 -0000	1.3
@@ -1,36 +1,50 @@
 \section{Translators in MINT}\label{sec-exp}
 
-A simple examples should be adequate to demonstrate the essentials
-of the MINT parser generator language.  More example grammars, including
-the grammar for the parser generator itself appear in the appendix.
+Some experience has already been gained in building MINT
+translators.  It is worth considering some example
+translators, and evaluating the current status of the MINT
+tool using these translators.
 
-Each grammar file is divided into three sections -- tokens,
-precedence, and rules.  The tokens section specifies an identifier for
-each token, along with a regular expression specifying the pattern
-of input associated with that token.  In short, the token section
-compactly represents a lexer. 
+\subsection{MINT Descriptions}
 
-The precedence section allows ambiguous grammars to be specified and
-disambiguated by the user by specifying the precedence and assocativity
-of tokens in the grammar, similar to the YACC ``\%left'' ``\%right''
-and ``\%nonassoc'' directives.
+A simple example should be adequate to demonstrate the essentials
+of the MINT parser generator language.  Example grammars, including
+the grammar for the parser generator itself, appear in an
+appendix.  A sensible place to begin the discussion is with
+the first example, the expression grammar on page \pageref{gram-expr}.
 
-The rules section represents the productions of the context free grammar.
-The syntax of these rules may seem a little confusing at first.   A rule
+Each grammar file is divided into three sections:
+\id{tokens}, \id{precedence} and \id{rules}.  The
+\id{tokens} section specifies an identifier for each token,
+along with a regular expression specifying the pattern of
+input associated with that token.  This is, of course,
+standard fare for lexer specification.
+
+The \id{precedence} section allows ambiguous grammars to be
+specified and disambiguated by the user by specifying the
+precedence and assocativities in the grammar. This is
+currently standard operator-precedence parsing, comparable
+to YACC's \id{\%left}, \id{\%right} and \id{\%nonassoc}
+directives.  One short term plan for MINT is to change and
+extend this section to allow more complex resolutions.
+
+The \id{rules} section represents the productions of the context free grammar.
+A rule
 consists of a nonterminal which is tagged with some kind of descriptor, and
 zero or more symbols which represent a possible sentence the nonterminal
-can derive.  Each symbol may be ``tagged'' meaning such that its value 
+can derive.  Each symbol may be {\em tagged}: its value 
 will appear in the syntax tree resulting from a successful parse tagged by a identifier.
 Untagged values are not included in the syntax tree.  This
-labelling allows the user to write syntax tree walkers which are
-readable and since the tags are not positional, allows more flexibility
-in modifying the grammar.  The omission of the untagged values reduces
-redundant syntactic clutter.
-
-A few examples may clarify things:
+labelling allows the user to write simpler syntax tree
+walkers. Since the tags are not positional, untagged values
+allow
+more flexibility
+in modifying the grammar, while reducing
+syntactic clutter.
 
-In this example, there is one nonterminal (E) with four productions.
-Addition and multiplication are binary operators in which the left
-operand is tagged ``op1'' and the right is tagged ``op2''.  Both the
-additon symbol and the multiplication symbol are untagged -- so they
+In the expression grammar example, there is one nonterminal (E) with four productions.
+Addition and multiplication are binary operators: the left
+operand is tagged \id{op1} and the right is tagged \id{op2}.  Both the
+addition symbol and the multiplication symbol are untagged: they
 will not be included in the resulting syntax tree.
+