As said, the lexer uses a \Yard{} parser. The parser takes a list of characters
and returns a list of \CI{Token}s. A token is a \CI{TokenValue} accompanied
with a position and the \emph{ADT} used is show in Listing~\ref{lst:lextoken}.
-Parser combinators make it very easy to account for arbitrary white space and it
-is much less elegant to do this in a regular way. By choosing to lex with
-parser combinators the speed of the phase decreases. However, since the parsers
-are very easy this increase is very small.
+Parser combinators make it very easy to account for arbitrary white space and
+it is much less elegant to do this in a regular way.
+Listing~\ref{lst:lexerwhite} shows the way we handle white space and recalculate
+positions. By choosing to lex with parser combinators the speed of the phase
+decreases. However due to the simplicity of the lexer this is barely
+measurable.
+
+\begin{lstlisting}[
+ language=Clean,
+ label={lst:lexerwhite},
+ caption={Lexer whitespace handling}]
+lexProgram :: Int Int -> Parser Char [Token]
+lexProgram line column = lexToken >>= \t->case t of
+ LexEOF = pure []
+ LexNL = lexProgram (line+1) 1
+ (LexSpace l c) = lexProgram (line+l) (column+c)
+ (LexItemError e) = fail <?>
+ PositionalError line column ("LexerError: " +++ e)
+ (LexToken c t) = lexProgram line (column+c)
+ >>= \rest->pure [({line=line,col=column}, t):rest]
+\end{lstlisting}
\begin{lstlisting}[
language=Clean,
and is composed of as complex subparsers. A \CI{FunDecl} parser exactly one
complete function.
-First we do the non consuming \CI{peekPos} to make sure the positionality of
+First we do the non consuming \CI{peekPos} to make sure the position of
the function is guaranteed in the \AST{}, after that the identifier is parsed
which is basically a parser that transforms an \CI{IdToken} into a \CI{String}.