afl-material: comparison handouts/ho06.tex

equal deleted inserted replaced

-:0451b8b67f62
+:c6a1e19e9801
 $\Rightarrow$
 $\underbrace{\text{set of (parsed input, unparsed input)}}_{\text{output}}$
 \end{center}
 \noindent
-Given the extended effort we have spent implementing a lexer
+Given the extended effort we have spent implementing a lexer in order
-in order to generate list of tokens, it might be surprising that in
+to generate list of tokens, it might be surprising that in what
-what follows we shall often use strings as input. This is for making
+follows we shall often use strings as input, rather than list of
-the explanation more lucid. It does not make our previous work on
+tokens. This is for making the explanation more lucid. It does not
-lexers obsolete (remember they transform a string into a list of
+make our previous work on lexers obsolete (remember they transform a
-tokens). Lexers will still be needed for building a somewhat realistic
+string into a list of tokens). Lexers will still be needed for
-compiler.
+building a somewhat realistic compiler.
-But as said, parser combinators are relatively agnostic about what
+As mentioned above, parser combinators are relatively agnostic about what
 kind of input they process. In my Scala code I use the following
 polymorphic types for parser combinators:
 \begin{center}
 input:\;\; \texttt{I}  \qquad output:\;\; \texttt{T}
 \end{center}
 \noindent That is they take as input something of type \texttt{I} and
-return a set of pairs of type \texttt{Set[(T, I)]}. Since the input needs
+return a set of pairs of type \texttt{Set[(T, I)]}. Since the input
-to be of ``sequence-kind'', I actually have to often write \texttt{I
+needs to be of ``sequence-kind'', I actually have to often write
-<\% Seq[\_]} for the input type. This ensures the input is a
+\texttt{I <\% Seq[\_]} for the input type. This ensures the input is a
 subtype of Scala sequences. The first component of the generated pairs
 corresponds to what the parser combinator was able to process from the
-input and the second is the unprocessed part of the input (therefore
+input and the second is the unprocessed part, or leftover, of the
-the type of this unprocessed part is the same as the input). As we
+input (therefore the type of this unprocessed part is the same as the
-shall see shortly, a parser combinator might return more than one such
+input). A parser combinator might return more than one such pair; the
-pair; the idea is that there are potentially several ways of how to
+idea is that there are potentially several ways of how to parse the
-parse the input.  As a concrete example, consider the string
+input.  As a concrete example, consider the string
 \begin{center}
 \tt\Grid{iffoo\VS testbar}
 \end{center}
 $\left\{ \left(\texttt{\Grid{if}}\;,\; \texttt{\Grid{foo\VS testbar}}\right),
 \left(\texttt{\Grid{iffoo}}\;,\; \texttt{\Grid{\VS testbar}}\right) \right\}$
 \end{center}
 \noindent where the first pair means the parser could recognise
-\texttt{if} from the input and leaves the rest as `unprocessed' as the
+\texttt{if} from the input and leaves the \texttt{foo\VS testbar} as
-second component of the pair; in the other case it could recognise
+`unprocessed' part; in the other case it could recognise
 \texttt{iffoo} and leaves \texttt{\VS testbar} as unprocessed. If the
 parser cannot recognise anything from the input at all, then parser
 combinators just return the empty set $\{\}$. This will indicate
 something ``went wrong''\ldots or more precisely, nothing could be
 parsed.
 Also important to note is that the type \texttt{T} for the processed
-part is different from the input type. In the example above is just
+part is different from the input type \texttt{I} in the parse. In the
-happens to be the same. The reason for the difference is that in
+example above is just happens to be the same. The reason for the
-general we are interested in transforming our input into something
+potential difference is that in general we are interested in
-``different''\ldots for example into a tree; or if we implement the
+transforming our input into something ``different''\ldots for example
-grammar for arithmetic expressions, we might be interested in the
+into a tree; or if we implement the grammar for arithmetic
-actual integer number the arithmetic expression, say \texttt{1 + 2 *
+expressions, we might be interested in the actual integer number the
-3}, stands for. In this way we can use parser combinators to
+arithmetic expression, say \texttt{1 + 2 * 3}, stands for. In this way
-implement relatively easily a calculator, for instance.
+we can use parser combinators to implement relatively easily a
+calculator, for instance.
 The main idea of parser combinators is that we can easily build parser
 combinators out of smaller components following very closely the
 structure of a grammar. In order to implement this in an
 object-oriented programming language, like Scala, we need to specify
 and returns a set of type \mbox{\texttt{Set[(T, I)]}}.
 \begin{center}
 \begin{lstlisting}[language=Scala]
 abstract class Parser[I, T] {
-def parse(ts: I): Set[(T, I)]
+def parse(in: I) : Set[(T, I)]
-def parse_all(ts: I): Set[T] =
+def parse_all(in: I) : Set[T] =
-for ((head, tail) <- parse(ts); if (tail.isEmpty))
+for ((head, tail) <- parse(in); if (tail.isEmpty))
 yield head
 }
 \end{lstlisting}
 \end{center}
 $s$ is the unprocessed part of the input string.
 \item Otherwise return the empty set $\{\}$.
 \end{itemize}
 \noindent
-The input type of this simple parser combinator for characters is
+The input type of this simple parser combinator is \texttt{String} and
-\texttt{String} and the output type is \texttt{Char}. This means
+the output type is \texttt{Char}. This means \texttt{parse} returns
-\texttt{parse} returns  \mbox{\texttt{Set[(Char, String)]}}.
+\mbox{\texttt{Set[(Char, String)]}}.  The code in Scala is as follows:
-The code in Scala is as follows:
 \begin{center}
 \begin{lstlisting}[language=Scala,basicstyle=\small\ttfamily, numbers=none]
 case class CharParser(c: Char) extends Parser[String, Char] {
 def parse(in: String) =
 empty set (in Scala \texttt{Set()}). Since this parser recognises
 characters and just returns characters as the processed part, the
 output type of the parser is \texttt{Char}.
 If we want to parse a list of tokens and interested in recognising a
-number token, we could write something like this
+number token, for example, we could write something like this
 \begin{center}
 \begin{lstlisting}[language=Scala,basicstyle=\small\ttfamily,numbers=none]
 case object NumParser extends Parser[List[Token], Int] {
 def parse(ts: List[Token]) = ts match {
 In this parser the input is of type \texttt{List[Token]}. The function
 parse looks at the input \texttt{ts} and checks whether the first
 token is a \texttt{Num\_token} (let us assume our lexer generated
 these tokens for numbers). But this parser does not just return this
 token (and the rest of the list), like the \texttt{CharParser} above,
-rather it extracts the string \texttt{s} from the token and converts it
+rather it extracts also the string \texttt{s} from the token and
-into an integer. The hope is that the lexer did its work well and this
+converts it into an integer. The hope is that the lexer did its work
-conversion always succeeds. The consequence of this is that the output
+well and this conversion always succeeds. The consequence of this is
-type for this parser is \texttt{Int}, not \texttt{Token}. Such a
+that the output type for this parser is \texttt{Int}, not
-conversion would be needed if we want to implement a simple calculator
+\texttt{Token}. Such a conversion would be needed if we want to
-program.
+implement a simple calculator program, because string-numbers need to
+be transformed into \texttt{Int}-numbers in order to do the
+calculations.
 These simple parsers that just look at the input and do a simple
 transformation are often called \emph{atomic} parser combinators.
 More interesting are the parser combinators that build larger parsers
 \end{center}
 \noindent The types of this parser combinator are again generic (we
 have \texttt{I} for the input type, and \texttt{T} for the output
 type). The alternative parser builds a new parser out of two existing
-parsers \texttt{p} and \texttt{q} given as arguments.  Both parsers
+parsers \texttt{p} and \texttt{q} which are given as arguments.  Both
-need to be able to process input of type \texttt{I} and return in
+parsers need to be able to process input of type \texttt{I} and return
-\texttt{parse} the same output type \texttt{Set[(T,
+in \texttt{parse} the same output type \texttt{Set[(T,
 I)]}.\footnote{There is an interesting detail of Scala, namely the
 \texttt{=>} in front of the types of \texttt{p} and \texttt{q}. They
 will prevent the evaluation of the arguments before they are
 used. This is often called \emph{lazy evaluation} of the
-arguments. We will explain this later.}  The alternative parser
+arguments. We will explain this later.}  The alternative parser runs
-should run the input with the first parser \texttt{p} (producing a set
+the input with the first parser \texttt{p} (producing a set of pairs)
-of pairs) and then run the same input with \texttt{q} (producing
+and then runs the same input with \texttt{q} (producing another set of
-another set of pairs).  The result should be then just the union of
+pairs).  The result should be then just the union of both sets, which
-both sets, which is the operation \texttt{++} in Scala.
+is the operation \texttt{++} in Scala.
 The alternative parser combinator allows us to construct a parser that
 parses either a character \texttt{a} or \texttt{b} using the
 \texttt{CharParser} shown above. For this we can write
 \end{center}
 \noindent Later on we will use Scala mechanism for introducing some
 more readable shorthand notation for this, like \texttt{"a" |
 "b"}. Let us look in detail at what this parser combinator produces
-with some sample strings
+with some sample strings.
 \begin{center}
 \begin{tabular}{rcl}
 input strings & & output\medskip\\
 \texttt{\Grid{acde}} & $\rightarrow$ & $\left\{(\texttt{\Grid{a}}, \texttt{\Grid{cde}})\right\}$\\
 parse anything with \pcode{ccde}, therefore the empty
 set is returned.
 A bit more interesting is the \emph{sequence parser combinator}. Given
 two parsers, say again, $p$ and $q$, we want to apply first the input
 to $p$ producing a set of pairs; then apply $q$ to all the unparsed
 parts in the pairs; and then combine the results. Mathematically we would
-write something like this for the expected set of pairs:
+write something like this for the result set of pairs:
 \begin{center}
 \begin{tabular}{lcl}
 $\{((\textit{output}_1, \textit{output}_2), u_2)$ & $\,|\,$ &
 $(\textit{output}_1, u_1) \in p(\text{input})
 \;\wedge\;$\\
 && $(\textit{output}_2, u_2) \in q(u_1)\}$
 \end{tabular}
 \end{center}
-\noindent Notice that the $p$ wil first be run on the input, producing
-pairs of the form $(\textit{output}_1, u_1)$ where the $u_1$ stands
-for the unprocessed, or leftover, parts. We want that $q$ runs on all
-these unprocessed parts $u_1$. This again will produce some
-processed part , $p$ and
-$q$, we apply both parsers to the input (remember parsers are
-functions) and combine the output (remember they are sets of pairs)
-\begin{center}
-$p(\text{input}) \cup q(\text{input})$
-\end{center}
-\noindent In Scala we would implement alternative parser
-combinator as follows
-\begin{center}
-\begin{lstlisting}[language=Scala, numbers=none]
-class AltParser[I, T]
-(p: => Parser[I, T],
-q: => Parser[I, T]) extends Parser[I, T] {
-def parse(in: I) = p.parse(in) ++ q.parse(in)
-}
-\end{lstlisting}
-\end{center}
-\noindent The types of this parser combinator are again generic (we
-just have \texttt{I} for the input type, and \texttt{T} for the output
-type). The alternative parser builds a new parser out of two existing
-parsers \texttt{p} and \texttt{q}.  Both need to be able to process
-input of type \texttt{I} and return the same output type
-\texttt{Set[(T, I)]}.\footnote{There is an interesting detail of
-Scala, namely the \texttt{=>} in front of the types of \texttt{p}
-and \texttt{q}. They will prevent the evaluation of the arguments
-before they are used. This is often called \emph{lazy evaluation} of
-the arguments. We will explain this later.}  Therefore the output
-type of this parser is \texttt{T}. The alternative parser should run
-the input with the first parser \texttt{p} (producing a set of pairs)
-and then run the same input with \texttt{q} (producing another set of
-pairs).  The result should be then just the union of both sets, which
-is the operation \texttt{++} in Scala.
-The alternative parser combinator already allows us to
-construct a parser that parses either a character \texttt{a}
-or \texttt{b}, as
-\begin{center}
-\begin{lstlisting}[language=Scala, numbers=none]
-new AltParser(CharParser('a'), CharParser('b'))
-\end{lstlisting}
-\end{center}
-\noindent Later on we will use again Scala mechanism for introducing some
-more readable shorthand notation for this, like \texttt{"a" | "b"}. Let us look in detail at what this parser combinator produces with some sample strings
-\begin{center}
-\begin{tabular}{rcl}
-input strings & & output\medskip\\
-\texttt{\Grid{acde}} & $\rightarrow$ & $\left\{(\texttt{\Grid{a}}, \texttt{\Grid{cde}})\right\}$\\
-\texttt{\Grid{bcde}} & $\rightarrow$ & $\left\{(\texttt{\Grid{b}}, \texttt{\Grid{cde}})\right\}$\\
-\texttt{\Grid{ccde}} & $\rightarrow$ & $\{\}$
-\end{tabular}
-\end{center}
-\noindent We receive in the first two cases a successful
-output (that is a non-empty set). In each case, either
-\pcode{a} or \pcode{b} is in the processed part, and
-\pcode{cde} in the unprocessed part. Clearly this parser cannot
-parse anything in the string \pcode{ccde}, therefore the empty
-set.
-A bit more interesting is the \emph{sequence parser combinator}. Given
-two parsers, say again, $p$ and $q$, we want to apply first the input
-to $p$ producing a set of pairs; then apply $q$ to all the unparsed
-parts in the pairs; and then combine the results like
-\begin{center}
-\begin{tabular}{lcl}
-$\{((\textit{output}_1, \textit{output}_2), u_2)$ & $\;|\;$ &
-$(\textit{output}_1, u_1) \in p(\text{input})
-\;\wedge\;$\\
-&& $(\textit{output}_2, u_2) \in q(u_1)\}$
-\end{tabular}
-\end{center}
 \noindent Notice that the $p$ will first be run on the input,
-producing pairs of the form $\textit{output}_1$ and unprocessed part
+producing pairs of the form $(\textit{output}_1, u_1)$ where the $u_1$
-$u_1$. This unprocessed part is fed into the second parser $q$. The
+stands for the unprocessed, or leftover, parts pf $p$. We want that
-overall result of the sequence parser combinator is pairs of the form
+$q$ runs on all these unprocessed parts $u_1$. Therefore these
+unprocessed parts are fed into the second parser $q$. The overall
+result of the sequence parser combinator is pairs of the form
 $((\textit{output}_1, \textit{output}_2), u_2)$. This means the
-unprocessed part of both parsers is the unprocessed part the second
+unprocessed part of the sequqnce p[arser combinator is the unprocessed
-parser $q$ leaves as leftover. The processed parts of both
+part the second parser $q$ leaves as leftover. The processed parts of
-parsers is a pair consisting of the outputs of $p$ and $q$, namely
+of the component parsers is a pair consisting of the outputs of $p$
-$(\textit{output}_1, \textit{output}_2)$. This behaviour can be
+and $q$, namely $(\textit{output}_1, \textit{output}_2)$. This
-implemented in Scala as follows:
+behaviour can be implemented in Scala as follows:
 \begin{center}
 \begin{lstlisting}[language=Scala,numbers=none]
 class SeqParser[I, T, S]
 (p: => Parser[I, T],
 component is the unprocessed part left over after running the second
 parser \texttt{q}. Therefore the input type of the sequence parser
 combinator is as usual \texttt{I}, but the output type is
 \begin{center}
-\texttt{Set[((T, S), I)]}
+\texttt{(T, S)}
 \end{center}
 \noindent
-If any of the runs of \textit{p} and \textit{q} fail, that is produce
+This means \texttt{parse} in the sequence parser combinator returns
-the empty set, then \texttt{parse} will also produce the empty set.
+sets of type \texttt{Set[((T, S), I)]}.  Notice that we have
-Notice that we have now two output types for the sequence parser
+essentially two output types for the sequence parser combinator
-combinator, because in general \textit{p} and \textit{q} might produce
+(packaged in a pair), because in general \textit{p} and \textit{q}
-different things (for example first we recognise a number and then a
+might produce different things (for example first we recognise a
-string corresponding to an operator).
+number and then a string corresponding to an operator).  If any of the
+runs of \textit{p} and \textit{q} fail, that is produce the empty set,
+then \texttt{parse} will also produce the empty set.
 With the shorthand notation we shall introduce later for the sequence
 parser combinator, we can write for example \pcode{"a" ~ "b"}, which
 is the parser combinator that first recognises the character
 \texttt{a} from a string and then \texttt{b}. Let us look again at
 \end{tabular}
 \end{center}
 \noindent The second and third example fail, because something is
-``missing'' in the sequence we are looking for. Also notice how the
+``missing'' in the sequence we are looking for. The first succeeds but
-results nest with sequences: the parsed part is a nested pair of the
+notice how the results nest with sequences: the parsed part is a
-form \pcode{((a, b), c)}. If we nest the sequence parser differently,
+nested pair of the form \pcode{((a, b), c)}. If we nest the sequence
-for example \pcode{"a" ~ ("b" ~ "c")}, then also our output pairs nest
+parser differently, for example \pcode{"a" ~ ("b" ~ "c")}, then also
-differently
+our output pairs nest differently
 \begin{center}
 \begin{tabular}{rcl}
 input strings & & output\medskip\\
 \texttt{\Grid{abcde}} & $\rightarrow$ & $\left\{((\texttt{\Grid{a}},(\texttt{\Grid{b}}, \texttt{\Grid{c}})), \texttt{\Grid{de}})\right\}$\\
 \]
 \noindent where the unprocessed (empty) parts have been stripped away
 from the pairs; everything where the second part was not empty has
 been thrown away as well, because they represent
-ultimately-unsuccessful-parses.
+ultimately-unsuccessful-parses. The main point is that the sequence
+parser combinator returns pairs that can nest according to the
+nesting of the component parsers.
-Note carefully that constructing a parser such \pcode{"a" | ("a" ~
-"b")} will result in a typing error. The intention is that we want
-to parse an \texttt{a}, or an \texttt{a} followed by a
+Consider also carefully that constructing a parser such \pcode{"a" |
-\texttt{b}. However, the first parser has as output type a single
+("a" ~ "b")} will result in a typing error. The intention with this
-character (recall the type of \texttt{CharParser}), but the second
+parser is that we want to parse an \texttt{a}, or an \texttt{a}
-parser produces a pair of characters as output. The alternative parser
+followed by a \texttt{b}. However, the first parser has as output type
-is required to have both component parsers to have the same type---we
+a single character (recall the type of \texttt{CharParser}), but the
-need to be able to build the union of two sets, which means in Scala
+second parser produces a pair of characters as output. The alternative
-they need to be of the same type.  Therefore the typing error.
+parser is required to have both component parsers to have the same
-We will see later how we can build
+type---we need to be able to build the union of two sets, which means
+in Scala they need to be of the same type.  Since ther are not, there
+is a typing error in this example.  We will see later how we can build
 this parser without the typing error.
 The next parser combinator, called \emph{semantic action}, does not
 actually combine smaller parsers, but applies a function to the result
 of a parser.  It is implemented in Scala as follows
 }
 \end{lstlisting}
 \end{center}
-\noindent This parser combinator takes a parser \texttt{p}
+\noindent This parser combinator takes a parser \texttt{p} (with input
-with output type \texttt{T} as one argument as well as a
+type \texttt{I} and output type \texttt{T}) as one argument but also a
-function \texttt{f} with type \texttt{T => S}. The parser
+function \texttt{f} (with type \texttt{T => S}). The parser \texttt{p}
-\texttt{p} produces sets of type \texttt{(T, I)}. The
+produces sets of type \texttt{Set[(T, I)]}. The semantic action
-semantic action combinator then applies the function
+combinator then applies the function \texttt{f} to all the `processed'
-\texttt{f} to all the parser outputs. Since this function is of
+parser outputs. Since this function is of type \texttt{T => S}, we
-type \texttt{T => S}, we obtain a parser with output type
+obtain a parser with output type \texttt{S}. Again Scala lets us
-\texttt{S}. Again Scala lets us introduce some shorthand
+introduce some shorthand notation for this parser
-notation for this parser combinator. Therefore we will write
+combinator. Therefore we will write \texttt{p ==> f} for it.
-\texttt{p ==> f} for it.
 What are semantic actions good for? Well, they allow you to transform
-the parsed input into a datastructure you can use for further
+the parsed input into datastructures you can use for further
 processing. A simple example would be to transform parsed characters
 into ASCII numbers. Suppose we define a function \texttt{f} (from
 characters to ints) and use a \texttt{CharParser} for parsing
 the character \texttt{c}.
 \end{lstlisting}
 \end{center}
 \noindent
 produces \texttt{Set((123,abc))}. The problem is that \texttt{123} is
-still a string (the double-quotes are not printed by Scala). We need
+still a string (the required double-quotes are not printed by
-to convert it into the corresponding \texttt{Int}. We can do this as
+Scala). We want to convert this string into the corresponding
-follows using a semantic action
+\texttt{Int}. We can do this as follows using a semantic action
 \begin{center}
 \begin{lstlisting}[language=Scala,basicstyle=\small\ttfamily, numbers=none]
 (NumParser ==> (s => s.toInt)).parse("123abc")
 \end{lstlisting}
 \subsubsection*{Shorthand notation for parser combinators}
 Before we proceed, let us just explain the shorthand notation for
 parser combinators. Like for regular expressions, the shorthand notation
-will make our life much easier when writing actual parsers.
+will make our life much easier when writing actual parsers. We can define
+some implicits which allow us to write \pcode{p | q}, \pcode{p ~ q} and
+\pcode{p ==> f} as well as to use plain strings for specifying simple
+string parsers.
+The idea is that this shorthand notation allows us to easily translate
+context-free grammars into code. For example recall our context-free
+grammar for palindromes:
+\begin{plstx}[margin=3cm]
+: \meta{P} ::=  a\cdot \meta{P}\cdot a | b\cdot \meta{P}\cdot b | a | b | \epsilon\\
+\end{plstx}
+\noindent
+Each alternative in this grammar translates into an alternative parser
+combinator.  The $\cdot$ can be translated to a sequence parser
+combinator. The parsers for $a$, $b$ and $\epsilon$ can be simply
+written as \texttt{"a"}, \texttt{"b"} and \texttt{""}.
 \subsubsection*{How to build parsers using parser combinators?}
 The beauty of parser combinators is the ease with which they can be
 implemented and how easy it is to translate context-free grammars into
 code (though the grammars need to be non-left-recursive). To
-demonstrate this recall our context-free grammar for palindromes:
+demonstrate this recall the grammar for palindromes from above.
+The first idea would be to translate it into the following code
-\begin{plstx}[margin=3cm]
-: \meta{P} ::=  a\cdot \meta{P}\cdot a | b\cdot \meta{P}\cdot b | a | b | \epsilon\\
-\end{plstx}
-\noindent
-Given the parser combinators for alternatives and sequeneces, this grammar should be
-straightforward to implement. The first idea would be
 \begin{center}
 \begin{lstlisting}[language=Scala,basicstyle=\small\ttfamily, numbers=none]
 lazy val Pal : Parser[String, String] =
 (("a" ~ Pal ~ "a") | ("b" ~ Pal ~ "b") | "a" | "b" | "")
 \end{lstlisting}
 \end{center}
 \noindent
-Unfortunately, this does not work as it produces a typing error. The
+Unfortunately, this does not quite work yet as it produces a typing
-reason is that the parsers \texttt{"a"}, \texttt{"b"} and \texttt{""}
+error. The reason is that the parsers \texttt{"a"}, \texttt{"b"} and
-all produce strings and therefore can be put into an alternative
+\texttt{""} all produce strings as output type and therefore can be
-\texttt{...| "a" | "b" | ""}. But both \pcode{"a" ~ Pal ~ "a"} and
+put into an alternative \texttt{...| "a" | "b" | ""}. But both
-\pcode{"b" ~ Pal ~ "b"} produce pairs of the form
+\pcode{"a" ~ Pal ~ "a"} and \pcode{"b" ~ Pal ~ "b"} produce pairs of
-$(((\_, \_), \_), \_)$---that is how the sequence parser combinator
+the form $(((\_, \_), \_), \_)$---that is how the sequence parser
-nests results when \pcode{\~} is used between two components. The
+combinator nests results when \pcode{\~} is used between two
-solution is to use a semantic action that ``flattens'' these pairs and
+components. The solution is to use a semantic action that ``flattens''
-appends the corresponding strings, like
+these pairs and appends the corresponding strings, like
 \begin{center}
 \begin{lstlisting}[language=Scala,basicstyle=\small\ttfamily, numbers=none]
 lazy val Pal : Parser[String, String] =
 (("a" ~ Pal ~ "a") ==> { case ((x, y), z) => x + y + z } |
 "a" | "b" | "")
 \end{lstlisting}
 \end{center}
 \noindent
+Now in all cases we have strings as output type for the parser variants.
 The semantic action
 \noindent
 Important to note is that we must define \texttt{Pal}-parser as a

changeset 590	c6a1e19e9801
parent 589	0451b8b67f62
child 591	863e502f6a5c