[Commit] mint-2004b nickle.tex,1.3,1.4

[Bart Massey]

Committed by: bart

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

Modified Files:
	nickle.tex 
Log Message:
Edited nickle section.



Index: nickle.tex
===================================================================
RCS file: /local/src/CVS/mint-2004b/nickle.tex,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- nickle.tex	1 Dec 2004 08:59:17 -0000	1.3
+++ nickle.tex	1 Dec 2004 21:55:55 -0000	1.4
@@ -7,134 +7,112 @@
 generally useful as computer performance has increased over the last two
 decades.
 
-\subsection{Polite Types}
-
-The Nickle type system provides both ``polite'' static typechecking along
-with full dynamic typechecking.  The rule for the compile-time checker is to
-never reject a correct program.  For example, the division operator `/',
-when given integer operands, returns integer results only when the divisor
-is evenly divisible by the dividend, otherwise it returns a ratioanl
-result.  The function:
-\begin{verbatim}
-	int f (int a, int b) { return a / b; }
-\end{verbatim}
-is acceptable to the static typechecking system because it may produce an
-integer result.  Dynamic typechecking is inserted into the generated code to
-check to make sure the result is of the right type at run-time.
+\subsection{Language Features}
 
-\subsection{Structured Values}
+The Nickle type system provides both ``polite'' static
+typechecking along with full dynamic typechecking.  The rule
+for the compile-time checker is to never reject a correct
+program.  Dynamic typechecking is inserted into the
+generated code to check to make sure the result is also of
+the right type at run-time.
 
-Nickle includes an array of composite data types, from arrays and hash
-tables to records and tagged unions.  These behave much like their C
-bretheren, with the exception of arrays which are first-class objects in
-Nickle, unlike C.  Assignment and function parameter passing is done by
-value.
+Nickle includes an array of composite data types, from
+arrays and hash tables to records and tagged unions.  These
+behave much like their C bretheren.  Notable exceptions
+include arrays, which are first-class objects in Nickle.
+Assignment and function parameter passing is done by value:
+reference-typed parameters may be used for efficiency or
+clarity.
 
 Any non-recursive value within Nickle can be represented within the
 compilation environment as a constant or initializer.  This means that large
 data structures can be generated entirely in-place and used in a dynamic
 context, without resorting to intermediate variables.
-\begin{verbatim}
-	h = (int [string]) { "hello" => 1, "world" => 2 }
-\end{verbatim}
-produces a hash table with the two given elements.  A new hash table is
-constructed each time the constant expression is evaluated.
-
-\subsection{Other Language Features}
 
 Nickle provides for namespaces which are similar to Java modules.  This
 provides a reasonably usable module mechanism with minimal overhead.
 Standard libraries present their functionality entirely within a namespace
 permitting brief names without cluttering the space for application names.
 
-The numeric system in Nickle provides three representations:
-
-\begin{enumerate}
-\item Arbitrary precision integers
-\item Arbitrary precision rationals
-\item Arbitrary mantissa-length floats with arbitrary precision exponents
-\end{enumerate}
-
-The semantics of all operators is well defined by the language specification
-in all cases and is constant across all Nickle implementations.  Rationals
-are normally presented with `{' and `}' surrounding the repeating part of
-the decimal expansion.  Floating point numbers default to 256 bits of
-mantissa, providing sufficient accuracy for iterative development
-of numeric algorithms.
-
 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
 mechanism to programmers transitioning from purely imperative languages.
 
+Nickle has a host of other features outside the scope of
+this paper.
+The numeric system in Nickle provides three representations:
+arbitrary precision integers,
+arbitrary precision rationals
+and arbitrary mantissa-length floats with arbitrary precision exponents.
+The semantics of all operators is well defined by the language specification
+in all cases and is constant across all Nickle implementations. 
 A thread API is included to permit the development of parallel algorithms.
-This includes threads, mutexes, semaphores and a fixed priority scheduler.
-
-\subsection{Well Defined Behaviour}
-
-Every operator in Nickle has a well defined behaviour; there are no
-``implemenetation defined'' sections in the specification.  Expressions in
-Nickle are always evaluated left-to-right.  Integers and rational values are
-arbitrary precision, avoiding machine word size dependencies.  Floating
-point numbers have user-defined mantissa size and arbitrary precision
-exponents, permitting precise numeric computations.  These guarantees provide
-a consistent and straightforward interpretation for Nickle programs in all
-implementations.
+This includes threads, mutexes, semaphores and a fixed
+priority scheduler.
+The interested reader should investigate the Nickle web site
+at \href{http://nickle.org}{http://nickle.org} for more information.
 
 \subsection{The Nickle Grammar}
 
-With a sometimes painful adoption of C syntax, Nickle has stretched the
-capabilities of existing parser generators significantly.  There remain in
-the current LALR grammar four reduce/reduce conflicts and one shift/reduce
-conflict.  The reduce/reduce conflicts are ``resolved'' by ensuring that the
-more common expressions are accepted while the unusual ones rejected.
-Obviously it would be nice if this artificial syntax restriction were
-removed.
+With a sometimes painful adoption of C syntax, Nickle has
+stretched the capabilities of existing parser generators
+significantly.  The current LALR grammar contains four
+reduce/reduce conflicts, as well as one shift/reduce
+conflict not resolved by operator precedence rules.  The
+parser has been manually inspect to ensure that these conflicts
+are ``resolved'' in a reasonable way at parse time.
+Obviously it would be nice to be able to force particular
+conflict resolutions ala operator precedence.
 
-The YACC-based tools provide only for synthesized attributes and Nickle
-uses inherited attributes at some points in the parse.  To work around this,
-a kludge was inserted into the actions to store inherited attributes inside
-the existing value stack using ``$0'' and ``$-2'' as positional values.
+YACC provides only for synthesized attributes.  Nickle uses
+inherited attributes at some points in the parse.  To work
+around this, the usual set of kludges store inherited
+attributes inside the existing value stack using ``\$0'' and
+``\$-2'' as positional values.
 
-Printing a function value produces a text representation of the function, so
-the compiler must retain the entire parse tree.  With YACC tools, a
-hand-constructed tree is used.  Each time the language syntax changes, this
-code must be modified to match.
+Printing a function value produces a text representation of
+the function, so the compiler must retain the entire parse
+tree.  YACC actions are used to hand-construct the parse
+tree.  Each time the language syntax changes, this code must
+be modified to match.
 
 \subsection{Using Nickle for Parser Generation}
 
-The choice of implementation language for any project is generally quite
-important.  Selecting the right language reduces the semantic gap between
-problem and program representation.  Contrarywise, the wrong language can
-cause the programmer to spend large amounts of time in low level bookkeeping
-algorithms and other semantic impedence matching code.
-
-As parser generation involves complex data structures and manipulations on
-large sets of objects, a language which provides reasonable typechecking
-along with automatic storage management seems like a good fit.  As with Lola
-and Flo above, the ability to interact with the parser immediately reduces
-the time needed to verify changes in the grammar.
-
-All of these make Nickle a good choice for a parser generator implementation.
-
-\subsection{Using Nickle for Parsing}
+Selecting the right language for implementation of a project
+reduces the semantic gap between problem and program
+representation.  Choosing the wrong language can cause the
+programmer to spend large amounts of time in low level
+bookkeeping algorithms and other semantic impedance-matching
+code.
 
-Given a Nickle-based parser generator, one possible result would be to force
-developers to also use Nickle for the resulting parser.  Such a B\&D approach
-would not serve the developers well:
+Parser generation involves complex data structures and
+manipulations on large sets of objects. A language which
+provides reasonable typechecking 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
+parser reduces the time needed to verify changes
+in the grammar.
 
-\begin{enumerate}
-\item Nickle is not a widely used language.  As such, few developers would
-be able to develop parsers.
-\item Nickle is not a high performance language.  With strictly defined
-semantics and arbitrary precision numerics, the typical Nickle program runs
-tens of times slower than equivalent C or Java code.  A parser in Nickle
-would probably not perform acceptably in most environments.
-\item Parsers are often embedded in other applications.  Attempting to
-access a Nickle function from an existing application places significant
-demands on the application developer.
-\end{enumerate}
+For all of these reasons, Nickle seems to be
+a good choice for a parser generator implementation.
+Other modern languages also seem suitable, but the authors
+have less experience with their features and pitfalls.
 
-Hence, while a good language for producing a parser generator, it would
-behoove the designers to consider permitting other languages for the
-final parser implementation.
+Given a Nickle-based parser generator, one possible result
+is to force developers to also use Nickle for the
+resulting parser.  This approach does not serve language
+developers well.  Nickle is not a widely used language.  As
+such, few developers would be able to develop parsers.
+Nickle is not a high performance language.  With strictly
+defined semantics and arbitrary precision numerics, the
+typical Nickle program runs tens of times slower than
+equivalent C or Java code.  A parser in Nickle might not
+perform acceptably in some environments.  Parsers are often
+embedded in other applications.  Attempting to access a
+Nickle function from an existing application places
+significant demands on the application developer.
+The Nickle parser generator has thus been factored from the
+parsing runtime as discussed in section~\ref{sec-mint},
+overcoming these difficulties.