[Commit] mint-2004b intro.tex, 1.6, 1.7 lola.tex, 1.4, 1.5 nickle.tex, 1.7, 1.8 tool.tex, 1.11, 1.12 translators.tex, 1.6, 1.7

Bart Massey commit at keithp.com
Wed Dec 1 22:04:47 PST 2004


Committed by: bart

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

Modified Files:
	intro.tex lola.tex nickle.tex tool.tex translators.tex 
Log Message:
Spellchecked.



Index: intro.tex
===================================================================
RCS file: /local/src/CVS/mint-2004b/intro.tex,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- intro.tex	2 Dec 2004 02:45:29 -0000	1.6
+++ intro.tex	2 Dec 2004 06:04:44 -0000	1.7
@@ -41,7 +41,7 @@
 language platforms.
 
 The Nickle programming language extends C-like syntax and
-semantics to accomodate modern programming techniques and
+semantics to accommodate modern programming techniques and
 styles.  As such, its syntax presents some unique challenges
 for standard automatic parser generation.  The Nickle
 front-end is currently implemented in C, using FLEX~\cite{flex} and

Index: lola.tex
===================================================================
RCS file: /local/src/CVS/mint-2004b/lola.tex,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- lola.tex	1 Dec 2004 21:41:00 -0000	1.4
+++ lola.tex	2 Dec 2004 06:04:44 -0000	1.5
@@ -23,7 +23,7 @@
 \scriptsize
 \begin{verbatim}
 ;
-; this grammar recognises integer
+; this grammar recognizes integer
 ; expressions involving +,-,*,/
 ; and unary -
 ;
@@ -78,7 +78,7 @@
 parser in Pascal.  
 Formal testing of this implementation demonstrated that it would correctly
 parse the standard ASCII control sequences.  The lack of parsing correctness
-in many existing adhoc ANSI X3.64 implementations reinforces the use of
+in many existing ad hoc ANSI X3.64 implementations reinforces the use of
 higher level parsing tools in such designs.  As the parser itself was
 written in Pascal, performance
 of the resulting system was more than adequate.
@@ -118,7 +118,7 @@
 concurrent development.  Building hand-crafted lexers turned
 out to be a significant development effort.  Using an
 existing simplistic tokenizing lexer allowed grammar changes
-to be tested in advance of lexer reimplementation, but this
+to be tested in advance of lexer re-implementation, but this
 mechanism had obvious drawbacks.  The need for an automated
 lexer generator was clear.
 

Index: nickle.tex
===================================================================
RCS file: /local/src/CVS/mint-2004b/nickle.tex,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- nickle.tex	2 Dec 2004 05:19:48 -0000	1.7
+++ nickle.tex	2 Dec 2004 06:04:44 -0000	1.8
@@ -2,7 +2,7 @@
 
 The Nickle Programming Language was developed as a C-like
 procedural imperative language with strong types and several useful notions
-adopted from the functional programming community.  Originally targetted
+adopted from the functional programming community.  Originally targeted
 twenty years ago as an algorithmic prototyping language, it has become more
 generally useful as computer performance has increased over the last two
 decades.
@@ -10,15 +10,15 @@
 \subsection{Language Features}
 
 The Nickle type system provides both ``polite'' static
-typechecking along with full dynamic typechecking.  The rule
+type checking along with full dynamic type checking.  The rule
 for the compile-time checker is to never reject a correct
-program.  Dynamic typechecking is inserted into the
+program.  Dynamic type checking is inserted into the
 generated code to check to make sure the result is also of
 the right type at run-time.
 
 Nickle includes a wide range of composite data types, from
 arrays and hash tables to records and tagged unions.  These
-behave much like their C bretheren.  Nickle assignment and
+behave much like their C brethren.  Nickle assignment and
 function parameter passing is done by value: reference-typed
 parameters may be used for efficiency or clarity.
 
@@ -34,7 +34,7 @@
 
 From the functional programming community, Nickle inherits first-class
 functions, closures and continuations.  Nickle exposes continuations
-throught the C-like setjmp/longjmp API which has proven a comprehensible
+through the C-like setjmp/longjmp API which has proven a comprehensible
 mechanism to programmers transitioning from purely imperative languages.
 
 Nickle has a host of other features outside the scope of
@@ -86,7 +86,7 @@
 
 Parser generation involves complex data structures and
 manipulations on large sets of objects. A language which
-provides reasonable typechecking along with automatic
+provides reasonable type checking along with automatic
 storage management thus seems like a good fit.  As
 illustrated by the discussion of Lola and Flo in
 section~\ref{sec-lola}, the ability to interact with the

Index: tool.tex
===================================================================
RCS file: /local/src/CVS/mint-2004b/tool.tex,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -d -r1.11 -r1.12
--- tool.tex	2 Dec 2004 02:51:38 -0000	1.11
+++ tool.tex	2 Dec 2004 06:04:44 -0000	1.12
@@ -12,7 +12,7 @@
 
 Mint is a canonical parser generator with a unique architecture which
 lends itself to a variety of interesting applications, as well as
-streamlining tasks that are related to syntatic analysis.
+streamlining tasks that are related to syntactic analysis.
 
 \subsection{Design}
 
@@ -25,14 +25,14 @@
 construct or utilize canonical LR(1) parsers in most cases.
 Processor speeds and memory capacities have
 grown dramatically in the twenty years since.
-It seems unecessary to implement a
+It seems unnecessary to implement a
 more complex algorithm just to achieve a reduction in table
 size and parser generation time.  In addition, as noted
 previously, the additional discrimination power of LR(1)
 parsing is expected to permit simplification of some parts
 of the Nickle grammar.
 
-Second, rather than targetting a specific output language
+Second, rather than targeting a specific output language
 such as C, MINT generates language independent lexing and
 parsing tables.  These tables can then be loaded by
 lexer/parser libraries (the MINT runtime) implemented in the
@@ -44,7 +44,7 @@
 table generation from processing, enabling simultaneous
 accomplishment of these goals.
 
-Third, MINT does not allow one to execute arbitary actions during the
+Third, MINT does not allow one to execute arbitrary actions during the
 parsing of input. Instead, MINT constructs an abstract syntax
 tree, consisting in essence of a specified subset of the full
 parse tree. The one action grammar rules may take is to
@@ -87,7 +87,7 @@
 easy to specify in the MINT descriptions what sort of tree
 will be output.  A serious disadvantage is the lack of
 sufficient abstraction, which leads to tight coupling
-between the grammar and the backend code which walks the
+between the grammar and the back-end code which walks the
 resulting trees.  Changes to the tree specification to help
 deal with this problem are currently under active consideration.
 
@@ -100,7 +100,7 @@
 easily added if needed.
 
 The lexer is a standard DFA-based algorithm with three enhancements:
-lexer states (aka ``exclusive start conditions''), lookahead patterns, and
+lexer states (i.e. ``exclusive start conditions''), lookahead patterns, and
 arbitrary size character sets. Because no code generation is performed
 at at lexer generation time, the lexer cannot perform arbitrary
 actions upon a rule match. The only allowed actions are to return a
@@ -177,7 +177,7 @@
 small Nickle subset proved to be more difficult, however. The
 implementation of the parser generator was fairly na\"ive -- as 
 this particular version was intended to be a proof of concept more
-than an efficient implementation of the canoncial LR(1) parsing
+than an efficient implementation of the canonical LR(1) parsing
 algorithm.  However, the generated parser and lexer were more than
 fast enough for general use.
 

Index: translators.tex
===================================================================
RCS file: /local/src/CVS/mint-2004b/translators.tex,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- translators.tex	2 Dec 2004 06:00:33 -0000	1.6
+++ translators.tex	2 Dec 2004 06:04:44 -0000	1.7
@@ -22,7 +22,7 @@
 
 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
+precedence and associativities 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




More information about the Commit mailing list