%
% $Id: chap1.tex,v 1.6 1995/04/20 13:32:31 gaertner Exp $
%
% $Log: chap1.tex,v $
% Revision 1.6  1995/04/20  13:32:31  gaertner
% small corrections.
%
% Revision 1.5  1995/04/20  12:14:56  gaertner
% Small corrections proposed by JS.
%
% Revision 1.4  1995/02/24  09:04:03  gaertner
% A few typos.
%
% Revision 1.3  1995/02/23  10:26:04  gaertner
% Final revision (including figures and index).
%
% Revision 1.2  1995/02/21  09:12:45  gaertner
% First and final full rewrite of this chapter. Have to go over
% the details later.
%
% Revision 1.1  1995/02/16  11:11:08  gaertner
% Initial revision
%


\chapter{On Prettyprinting}
\label{one}


The term {\em prettyprinting} means the rearrangement of a program's
source code to illuminate it's logical structure and thus enhance
readability. The term goes back to Henry Ledgard and his ``Programming
Proverbs''~\cite{Ledgard75}. Prettyprinting has become a field of
interest because many of todays popular programming languages are so
called ``free-format'' languages, where there are basically no
column-position or line-boundary restrictions on statements,
declarations, or comments.

\index{Prettyprinting}\index{free format@``free format'' languages}
\index{Ledgard, Henry F.}

As a matter of fact, formatting and all other aspects of readability
depend heavily on personal taste and skill.  This has lead to a wide
range of suggestions and standards concerning the formatting of
programming languages, especially for the \PASCAL~\cite{Jensen85}
language~\cite{Arab92,Bailes84,Bates81,Bond79,Crider78,Grogono79,Gustafson79,Heckert85,Ledgard77,Marca81,Peterson77,Mohilner78}.\label{formattingstandards}
The consistency of these proposals has also enabled construction of
automatic formatting algorithms and tools that are usually called {\em
  prettyprinters\/} (or {\em indenting programs\/}).  In the
literature general examples of prettyprinters have been presented
among others for the languages \ALGOL~\cite{McKeeman65,Scowen71},
PL/I \cite{Conrow70},
\LISP~\cite{Goldstein73,Hearn79,Waters83,Waters92}, Ada
\cite{Norris84}, and of course for
\PASCAL~\cite{Hueras77,Jackel80,Bates81,Winter89,Arab92}.

\index{Personal taste}\index{Taste!personal}\index{pascal@\PASCAL}
\index{Formatting standards}\index{Formatting algorithms}
\index{Prettyprinters!for other languages} \index{Indenting
  programs|see{Prettyprinters}}
\index{algol@\ALGOL}\index{PL/I}\index{lisp@\LISP}\index{Ada}
\index{pascal@\PASCAL}

However, technological advance in the area of automatic typesetting
has led to a set of powerful formatting tools called {\em
typesetters}, or {\em typesetting systems}, of which
\TeX~\cite{TeXbook} is maybe the most apparent to computer scientists.
These tools allow the preparation of documents in high quality suited
for publication. Among the features of these systems are automatic
line- and page-breaking, powerful macro-processing facilities and
convenient devices for typesetting mathematical formulas. Seen in this
light, automatic program formatting is only a simple instance of
automatic typesetting \cite[p.~652]{Rose81}. So prettyprinting
algorithms that rely on professional typesetters can be simpler and
produce better results at the same time, because a lot of the
formatting problems (e.g.~alignment, line-breaking, typesetting
mathematical formulas) can be taken on by the typesetter.

\index{Automatic typesetting}\index{Typesetters}\index{Typesetting
  systems}\index{tex@\TeX}\index{Program formatting}

\smallskip In this chapter I will now present the prettyprinting
algorithm that is used in the \pretzel\ system. It is a simple, but
sophisticated method that relies on a typesetter. I have chosen a
rather straightforward approach to this presentation using a lot of
examples and leaving the discussion of this algorithm to the very end
of this chapter.





\section{Prettyprinting with Format Commands}
\label{fmt-commands}

\index{Format commands!explained|(}


The prettyprinting method presented here can be called {\em
  prettyprinting with format command primitives} and goes back to a
similar method used by Knuth in his original \WEAVE\ system for
\PASCAL\ (see section \ref{relatedwork} for details). Like most other
prettyprinting algorithms this method functions similar to a {\em
  compiler}, i.e.~an input file is processed and translated into an
output file according to special rules. Here, the input file is the
patch of source code that shall be prettyprinted and the output file
is the text suited for the typesetter. The translation rules represent
the special way in which source code should be formatted.

\index{pascal@\PASCAL}\index{weave@\WEAVE}\index{Knuth, Donald E.}
\index{Compilers!and prettyprinters}

The main assumption is that we have a text formatter that uses
{\em control sequences\/} (or {\em tags\/}) inside the actual text body
for specifying all the different ways of formatting (such as
fonts, indentation, spacing, etc.). Another term for this way of
formatting control is {\em in-text procedural markup\/} and systems
using this technique are commonly called {\em document compilers}
(though this might only refer to the way they work, not to viewing
text processing as programming). Common examples of such typesetting
systems are \TeX\ and the \UNIX\ tools Nroff/Troff.

\index{Control sequences}\index{Tags}\index{In-text procedural markup}
\index{Markup}\index{Procedural markup}\index{Document compilers}
\index{Compilers!for documents}\index{tex@\TeX}\index{unix@\UNIX}
\index{Nroff}\index{Troff}

So what does the prettyprinting algorithm presented here actually do?
During the processing of the input the only thing it does is to enrich
the stream of incoming information with special control sequences that
I will call {\em format commands} (or {\em format command
primitives}). These commands are tags that are left for the typesetter
to interpret. The set of format commands used here is basically the
initial set used by Knuth.

\index{Knuth, Donald E.!command set by}

To understand this procedure we don't have to go into the special
nitty-gritty details now. This will be done excessively
in the following chapter. It probably will be more instructive to
introduce the command set by way of example.

\index{Nitty-gritty details}\index{Details!nitty gritty}

Finally a word about the notation: In the following examples of input
text the format commands will be set in italics whereas normal strings
will be given in typewriter type. The corresponding output text of the
examples will reflect the input in a way similar to the output
obtained using \TeX\ as typesetter and the ``normal'' interpretation
of the format commands.

\index{Typesetting conventions}\index{Conventions!of typesetting}
\index{tex@\TeX}\index{Interpretation of format commands}
\index{normal interpretation@``normal'' interpretation}



\subsection{Controlling the Amount of Indentation}


So let's now have a look at a few small examples of how
prettyprinting works with the so called format commands. The first
interesting thing to consider is the contol of indentation. Suppose
we want to prettyprint a simple  \res{while}-\res{do}-statement of
\PASCAL\ and we want to indent the body of this statement a bit from
it's header keyword. The plain \PASCAL\ text of our first example
looks like this:
 %
\begin{inp}
while (i<size) do begin i:=i+1; end;
\end{inp}
 %
(Of course the \res{begin}\dots\res{end} pair is obsolete, but
don't bother at the moment.) What we have to do now to achieve our
goal is to insert the right format commands into this sequence of
strings and pass it on to the formatter to do the rest of the
work.

\index{pascal@\PASCAL}

We wanted to indent the body of the \res{while}-statement a
little, so we insert an \fmt{indent} command between the \res{do}
and the \res{begin}. If you imagine this \res{while}\,-statement
being part of a larger block of statements you probably don't want
the following statements to be indented as much as the body of the
\res{while}-loop. So the indentation must be taken back after the
\res{while}-body. This is done with the \fmt{outdent} command
(that rather should have been named ``de-indent'', but we`ll stick
with Knuth`s word creation). So now we have:
 %
\begin{inp}
while (i<size) do \fmt{indent} begin i:=i+1; end; \fmt{outdent}
\end{inp}
 %
If passed to the formatter this will probably yield:
 %
\begin{outp}
\res{while} $(\id{i} < \id{size})$ \res{do} \res{begin}
$\id{i} \ass{} \id{i} + 1; $ \res{end};
\end{outp}

So what happened? The format primitives don't seem to have any
effect on the output at all! Well, it only seems so. What the
formatter has really done cannot be concluded in detail from the
output above: It has increased the indentation after the \res{do}
sure enough, but this doesn't show, because the body of the
\res{while}-statement fits on the same line as it's header. We
would have expected something like this:
 %
\begin{outp}
\res{while} $(\id{i} < \id{size})$ \res{do} \myindent\myforce
\res{begin} $\id{i} \ass{} \id{i} + 1; $ \res{end}; \myoutdent
\end{outp}
 %
To get this result, one has to explicitly insert a line break
before the \res{begin}. This is done with the \fmt{force} command,
that denotes a {\em forced\/} line break. So the input
 %
\begin{inp}
while (i<size) do \fmt{indent} \fmt{force} begin i:=i+1; end;
\fmt{outdent}
\end{inp}
 %
would yield the expected result.

\index{Format commands!force@\fmt{force}}
\index{force@\fmt{force}}
\index{Forced line break}
\index{Format commands!indent@\fmt{indent}}
\index{Format commands!outdent@\fmt{outdent}}
\index{indent@\fmt{indent}}
\index{outdent@\fmt{outdent}}
\index{Indentation!controlling amount of}

So the \fmt{indent} and \fmt{outdent} primitives cause only future
lines to be in- or ``out''den\-ted and have no effect on the present
line that is just processed. The indentation shows only if there
is a forced line break after the amount of indentation has been
changed.

Why has Knuth chosen \fmt{indent} and \fmt{outdent} to behave in
this way? To understand this, we should consider the above example
without the keywords \res{begin} and \res{end} surrounding the
assignment. The result
 %
\index{Knuth, Donald E.}
 %
\begin{outp}
\res{while} $(\id{i} < \id{size})$ \res{do} \myindent\myforce
$\id{i} \ass{} \id{i} + 1; $ \myoutdent
\end{outp}
 %
really does look a bit stupid. In cases like this we would like
the controlled statement to stand on the same line as the header
because the program structure doesn't need to be visualized in
this simple case by indentation. The only thing one has to to here
is to remove the \fmt{force} command from the input sequence and
we will get:
 %
\begin{outp}
\res{while} $(\id{i} < \id{size})$ \res{do}
$\id{i} \ass{} \id{i} + 1; $
\end{outp}
 %
The interesting fact is that this doesn't change our global rule
that the body of a \res{while}-statement should be \fmt{indent}ed
from it's keyword. So the \fmt{indent} and \fmt{outdent} commands
can always be inserted before and after the controlled statement.
The only thing to worry about is whether or not to insert a
\fmt{force} (which is always recommended before a \res{begin},
since this nearly always starts a sequence of two or more
statements).



\subsection{Controlling Line-breaks}

\index{Line breaks!controlled}
\index{Controlling line breaks}

The \fmt{indent} and \fmt{outdent} commands together with \fmt{force}
are sufficient to control the alignment of similar syntactic
constructs.  But these three commands lack just one feature you will
surely miss if you try to format some code with only this
``triumvirate'' of commands at hand. Consider for example a long block
of statements in \PASCAL\ that contain extremely long names for
identifiers as in the following example:
 %
\index{pascal@\PASCAL}
\index{Triumvirate}
\index{Long names!extremenly}
 %
\begin{inp}
begin string_buffer[string_buffer_pointer]:=c;
string_buffer_pointer:=string_buffer_pointer + 1; end;
\end{inp}
 %
Handed over to the formatter, this may lead to the following
 %
% the following text should have a line break within the name
% of an identifier!
\begin{outp}
\res{begin}
$\id{string\_buffer}[\id{string\_buffer\_pointer}]\ass\id{c};
\id{string\_buffer\_poin-}$\myforce
$\id{ter}\ass\id{string\_buffer\_pointer} + 1;$
\res{end};
\end{outp}
 %
if the line width is unfavourable. This is okay if we had normal
text in front of us. But here we are writing text in a programming
language and breaking lines within an identifier violates the
syntax. But on the other hand, how would you like:
 %
\index{Violation of syntax}
 %
% this text should have a line break within a statement
\begin{outp}
\res{begin}
$\id{string\_buffer}[\id{string\_buffer\_pointer}]\ass\id{c};
\id{string\_buffer\_pointer}$\myforce
$\ass\id{string\_buffer\_pointer} + 1;$
\res{end};
\end{outp}
 %
This may look better than the first possibility, but still doesn't
look nice. We would prefer line breaks to occur only between two
adjacent statements (and usually also before the \res{end}) like in :
 %
\begin{outp}
\res{begin}
$\id{string\_buffer}[\id{string\_buffer\_pointer}]\ass\id{c};$
\myforce
$\id{string\_buffer\_pointer}\ass\id{string\_buffer\_pointer} +
1;$\myforce
\res{end};
\end{outp}
 %
So the conclusion is, that we have to tell the formatter, where it
is possible to break a line, if the current block of text should
exceed the right margin. This is done with the \fmt{break\_space}
primitive.
 %
\index{Format commands!break space@\fmt{break\_space}}
\index{break space@\fmt{break\_space}}

By inserting a \fmt{break\_space} amidst two statements (and even
after the \res{begin} and before the \res{end}) the above problem
cannot happen any more. A \fmt{break\_space} tells the typesetter,
to break a line at this point, if he is looking for a place to
break somewhere near it.

But even now just one feature is missing, that also has to do with
line breaking. Consider for example a \res{while}-loop or an
\res{if}-statement with a very long expression that governs it,
as in:

\begin{inp}
while (str\_buf[str\_buf\_ptr]<>c) and
(str\_buf\_ptr<=buf\_size) do
\end{inp}

Inserting \fmt{break\_space}s before and after the ``\t{and}''
would seem to be a good solution to this line-breaking problem.
But breaking the line after the ``\t{and}'', say, would result in
 %
\begin{outp}
\res{while} $(\id{str\_buf}[\id{str\_buf\_ptr}]<>\id{c})$ \andsign
\myforce
$(\id{str\_buf\_ptr}\leq\id{buf\_size})$ \res{do}
\end{outp}
 %
what of course is intolerable. We want a long continuous line to be
indented a little if it is broken, like in:

\begin{outp}
\res{while} $(\id{str\_buf}[\id{str\_buf\_ptr}]<>\id{c})$ \andsign
\myindent\myforce
$(\id{str\_buf\_ptr}\leq\id{buf\_size})$ \res{do}
\end{outp}
 %
Using the \fmt{indent}, \fmt{outdent} and \fmt{force} primitives
is no solution in this case. This becomes clear if you look at the
\res{while}-loop followed by its body:
 %
\begin{outp}
\res{while} $(\id{str\_buf}[\id{str\_buf\_ptr}]<>\id{c})$ \andsign
\myindent\myforce
$(\id{str\_buf\_ptr}\leq\id{buf\_size})$ \res{do}\myforce
\res{begin}\myforce
\dots\myforce
\res{end}
\end{outp}
 %
In case of a line break within a statement the indentation has to
be sufficiently different from the normal \fmt{break-space}d or
\fmt{force}d indentation. So the answer is: More space!

Therefore we need a new primitive, namely the {\em
optional line break} command \fmt{opt}. There are ten different
\fmt{opt}s that specify the badness of a line break at
the point of it's occurence. They are called \fmt{opt0},
\fmt{opt1},\dots, \fmt{opt9}. A smaller number encourages line
breaking at this point more than a higher number. So \fmt{opt0}
will nearly always lead to a line break whereas \fmt{opt9} leads
to a line break only if there is no \fmt{opt0},\dots, \fmt{opt8}
primitive somewhere near and the line {\bf has} to be broken
around this point. (In \TeX\ terms the digit $n$ in the name of
the \fmt{opt} command specifies the penalty associated with this
break point. The penalty in the default interpretation of \fmt{opt}
is about $10\cdot n$.)

\index{opt@\fmt{opt}}\index{Format commands!opt@\fmt{opt}}
\index{Optional line-break}

So the \fmt{opt} command denotes an optional line break with the
continuation line indented a little more with respect to the normal
indentation.

Returning to our example from above we should therefore say
 %
\begin{inp}
while (str\_buf[str\_buf\_ptr]<>c) and \fmt{opt4}
(str\_buf\_ptr<=buf\_size) do \fmt{indent} \fmt{force}
begin ...\fmt{force}
end
\end{inp}
 %
depending on whether we rather liked a line break before or after
the ``\t{and}''. This would then yield the correct way of formatting,
as in:
 %
\begin{outp}
\res{while} $(\id{str\_buf}[\id{str\_buf\_ptr}]<>\id{c})$ \andsign
\myindent\myindent\myindent\myforce
$(\id{str\_buf\_ptr}\leq\id{buf\_size})$ \res{do}\myoutdent\myoutdent\myforce
\res{begin}\dots\myforce
\res{end}
\end{outp}
 %
Note however that a \fmt{break\_space} is always
a better place to break a line than an optional line break denoted
by \fmt{opt}.
 %
\index{opt and break space@\fmt{opt} and \fmt{break\_space}}



\subsection{Additional Commands}

By choosing the examples in the way above, I hope to have made clear
that the format commands presented so far are sufficient to format
program text of any block structured programming language in a manner
according to most of the formatting standards referenced in the
introduction of this chapter on page~\pageref{formattingstandards}.
Readers, who are not yet convinced, are put off until section
\ref{relatedwork}, where the evolution of this method is
reconstructed.
 %
\index{Command set!sufficiency}

However, the list of format commands is not yet complete. There
are still a few more primitives to learn, but they are not as
important as the other commands that were presented up to this
point. The following primitives were introduced to achieve better
formatting results in special situations.

The first one is called \fmt{backup} and denotes a little negative
horizontal space. This command must be preceded by a
\fmt{force}, because it doesn't make sense to backup within a line
if it's beginning has already been output. So the two commands
``\fmt{force}, \fmt{backup}'' appearing in a row can be seen as a
short form for the sequence ``\fmt{outdent}, \fmt{force},
\fmt{indent}''. The \fmt{backup} command is used in cases where
statements are preceded by labels or simply where a line should
stick out to the left a bit in order to emphasize it.
 %
\index{Format commands!backup@\fmt{backup}}
\index{backup@\fmt{backup}}


The next additional command is called \fmt{big\_force}. As the
name implies this primitive acts like a \fmt{force}, but only on a
bigger scale. \fmt{big\_force} not only forces a line break; it
also inserts a little extra vertical space after the break. You
can use the \fmt{big\_force} primitive to separate two adjacent
lines that semantically do not belong together, like two function
declarations.
 %
\index{Format commands!big force@\fmt{big\_force}}
\index{big force@\fmt{big\_force}}


If you are trying to typeset \C\ or \CPP\ programs, you will need
a feature to typeset so called preprocessor directives. These are
commands beginning with a $\#$ that can influence the source code
before compilation. Normally these lines appear beginning at the
left margin so we want a command that can be used to typeset lines
like this. This command is called \fmt{no\_indent}. It causes the
{\bf current} line to be printed flushleft. So if you want to
prettyprint a \C\ or \CPP\ preprocessor line, you should say
 %
\index{c++@\CPP}
\index{c@\C}
\index{Preprocessor}
\index{c preprocessor@\C\ preprocessor}
\index{Format commands!no indent@\fmt{no\_indent}}
\index{no indent@\fmt{no\_indent}}
 %
\begin{inp}
\fmt{force} \fmt{no\_indent} $\#$PREPROCESSOR\_DIRECTIVE
\fmt{force}
\end{inp}
 %
and the line following this directive will be indented as much as
the line before the directive.

%cancel

Finally the last command of the present command set is called
\fmt{cancel}. To understand this command I have to mention a tricky
detail of the presented algorithm that I have omitted in the
intoduction of this section: There I said that format commands are
simply output by the prettyprinter one by one just like strings, only
that they are ``marked'' as typesetting commands.  Actually the
prettyprinter also does a little bit of interpretation in advance. But
these exceptions from the rule can be caught in two
phrases\label{two-phrases}. The first one is of global importance and
the second one is related to the \fmt{cancel} command:

\index{Format commands!cancel@\fmt{cancel}}
\index{cancel@\fmt{cancel}}
\index{Exceptions}
\index{Preprocessing of format commands}
\index{Tricky details}

\begin{enumerate}

\item A sequence of consecutive \fmt{break\_space}, \fmt{force},
and/or \fmt{big\_force} commands is replaced by a single command
(the maximum of the given ones).

\item The \fmt{cancel} command cancels any \fmt{break\_space},
\fmt{opt}, \fmt{force} or \fmt{big\_force} command that immediatly
precede or follow it and also cancels any \fmt{backup} command
that follows it.

\end{enumerate}

So it seems that the \fmt{cancel} command is a command that mixes
everything up again after we have put everything into a neat and tidy
form! But this only seems so. The interpretation done by the
prettyprinter according to the two rules stated above, was introduced
to be more generous and more flexible with the placement of format
primitives into the source code. Because, after all, the format
commands will not be inserted by hand (as the reader might think after
viewing the examples given above), but they will be inserted
automatically by the prettyprinter according to a {\em prettyprinting
grammar}.
 %
\index{Flexibility}
\index{Prettyprinting grammar}
\index{Format commands!explained|)}


\subsection{Summary of Format Commands}

\index{Format commands!summary}
\index{Summary of format commands}

Table \ref{command-table} shows a complete list of all the format command
primitives introduced in this chapter. The only command that
wasn't mentioned up to now is the \fmt{null} primitive that serves
as a neutral (or empty) command.

\index{Format commands!null@\fmt{null}}
\index{null@\fmt{null}}

\begin{figure}[htb]
\begin{center}
\begin{tabular}{lp{7cm}}
\fmt{null}    & empty command \\
\fmt{indent}  & indents the next line a little more \\
\fmt{outdent} & takes back the last indentation (de-indent) \\
\fmt{force}   & forces a line break \\
\fmt{break\_space} & denotes a possible space for a line break \\
\fmt{opt$\,n$}, $n \in \{0,\dots,9\}$ & denotes an optional line
     break with the continuation line indented a litte with
     respect to the normal starting position. This line break will
     score a penalty of $10n$.\\
\fmt{backup} & denotes a small backspace\\
\fmt{big\_force} & forces a line break and inserts a little extra
     space \\
\fmt{no\_indent} & causes the current line to be output
     flushleft\\
\fmt{cancel} & obliterates any \fmt{break\_space}, \fmt{opt},
     \fmt{force} or \fmt{big\_force} command that immediatly
     precedes or follows it and also cancels any \fmt{backup}
     command that follows it.
\end{tabular}
\end{center}
\caption{List of format command primitives}
\label{command-table}
\end{figure}





\subsection{The Prettyprinting Grammar}
\label{grammar-idea}

The functionality of the format command primitives from the previous
subsection is only half of the work of the prettyprinting process. The
second point is the way how these commands are automatically inserted
into the source code. This is done using a so called prettyprinting
grammar. To get an idea of how formatting with such a grammar works, I
will give a short and low-level introduction now. The exact way in
which this grammar is specified to work with \pretzel\ is a topic that
will be discussed in detail in chapter \ref{three}.

\index{Prettyprinting grammar}

The idea of formatting with a prettyprinting grammar is to insert
format commands during a bottom up parse of the programming
language text. Taking, say, a context free grammar to describe
something similar to \PASCAL, a grammar rule for a \res{while}
loop might look like this:
 %
\index{pascal@\PASCAL}\index{Context free grammar}
 %
\begin{inp}
WHILE expr DO stmt $\longrightarrow$ stmt
\end{inp}
 %
This means that a \t{WHILE} token followed by an expression, followed
by a \t{DO} token, followed by a statement can be reduced to a
statement again (and can be used for example within a second
\res{while}-loop that surrounds it). Here the tokens \t{WHILE} and
\t{DO} are non-terminal symbols of the grammar and \t{expr} and
\t{stmt} are terminals.

The simple trick that converts a normal grammar to a prettyprinting
grammar goes back to Knuth's idea of ``attribute grammars''. In such
a grammar every token has a so called {\em translation} that reflects
certain semantic properties about it. (For example, the translation of
an identifier token could be its name.) The translations of tokens are
constructed from the translations of the tokens that it has reduced.
The translation of the \t{stmt} token in our example would be put together
from the translations of the \t{WHILE}, \t{expr}, \t{DO} and the
other \t{stmt} token on the left side of the rule.

\index{Knuth, Donald E.}\index{Attribute grammar}\index{Translation}

A prettyprinting grammar is an attribute grammar. As seen in the
previous section, it is our aim, to insert format commands into
certain spaces within syntactic constructs of the programming
language.  Now think of the translation of a token to be the actual
printed output of the token, that can be sent to a typesetter.
Inserting format commands into the translation can be achieved by
defining the special ways of how to build the translation of certain
constructs during rule reduction.  So, for instance we could say:
``Every time I reduce a \t{WHILE}-loop to a \t{stmt}-token, I should
insert an \fmt{indent} and an \fmt{outdent} format command around the
body of the \res{while}-loop. Additionally a \fmt{force} command
should be inserted behind the \fmt{outdent}.'' This can be expressed
by the following notation, that uses ``pseudo-tokens'' (that can be
imagined of being non-terminal tokens that match the empty string):
 %
\index{Prettyprinting grammar}\index{Pseudo tokens}
 %
\begin{inp}
WHILE expr DO \fmt{indent} stmt \fmt{outdent} \fmt{force}
$\longrightarrow$ stmt
\end{inp}
 %
This rule states, that the statement controlled by the \res{while}
loop should be indented a little from it's header if this
statement happens to begin on a new line. The indentation is taken
back (\fmt{outdent}) and there will always be a line break at the
end of such a statement (if the \fmt{force} isn't \fmt{cancel}ed).

As a matter of fact, this way of expressing the formatting of a
programming language within its own grammar is very intuitive and
powerful. It would be possible to code a prettyprinting grammar in
this way into machine readable form. However, for reasons of
simplicity of design the author has chosen to use a slightly different
way of expressing such grammars in \pretzel, but this will be
discussed in the following chapter (see also chapter \ref{five} on
future work).

The fact that such a grammar will solemnly be used to create a
``prettyprinted'' translation of a bit of source code has a great
impact on the resulting grammar. In \PASCAL\ for instance, \res{for}-,
\res{while}- and \res{else}less \res{if}-statements are normally
formatted in a very similar way; so the grammar mustn't distinguish
between the three constructs. This results in prettyprinting grammars
that can be quite different from the normal grammars of the
programming languages. Mostly they are smaller. But if you want to
design a prettyprinting grammar yourself, it is always easier to start
with a normal language syntax and simply enhance every rule to suit
the occasion.

\index{Translation}\index{pascal@\PASCAL}




\section{A Short History of Prettyprinting}
\label{relatedwork}

In this section I will give a brief chronological overview over the
area of prettyprinting, try to structure the field, and will show, how
the present system fits into it.

\index{History of prettyprinting}\index{Prettyprinting!history}



\subsection{Historical Notes}

The prettyprinting of code has a long tradition that not only
originates from the compulsion to typeset programs for publication.
The readability or even the sheer beauty of a prettyprinted algorithm
have also been a key motivation to this part of computer science.

\index{Tradition}\index{Beauty}

The first people to call special attention to formatting issues were
probably Peter Naur, Myrtle Kellington and William McKeeman. While
Myrtle Kellington, as executive editor of ACM publications, helped to
develop high quality programming-language typography standards, Naur
was the first to include such formatting standards into his report on
the \ALGOL~60 language \cite{ALGOL-Report} and McKeeman was the first
to present a prettyprinting algorithm for it \cite{McKeeman65}. This reaches
back to the early 60s. In fact, McKeeman`s algorithm is the first
actual prettyprinter to be found in the literature. Its purpose was
 %
\index{Naur, Peter}\index{Kellington, Myrtle}\index{McKeeman, William}
\index{ACM}\index{algol@\ALGOL}\index{Prettyprinter!first}
 %
\begin{quote}

``[\dots] to edit \ALGOL~60 text that is difficult to read
because, for example, the \ALGOL\ has been transcribed from
printed documents, or written by inexperienced programmers [\dots]''

\end{quote}
 %
Later, other prettyprinters were presented for PL/I~\cite{Conrow70},
\LISP~\cite{Goldstein73}, and finally \PASCAL~\cite{Hueras77}.
These systems simply looked at the input text searching for special
keywords. When encountering a keyword (which could be a \res{begin} or
an opening brace, for example) a certain action would be triggered
which would result in a line break, change of indentation, etc.

\index{PL/I}\index{lisp@\LISP}\index{pascal@\PASCAL}
\index{Prettyprinters!running on keywords}

In these first approaches  to the issue of prettyprinting the basic
actions that prettyprinting includes were already visible. These
concern (in order of importance):\footnote{In the late 70s there was
  one additional point on this list, namely the introduction of `connector
  lines' into the prettyprinted output \cite{Clifton78,Ramsdell79}. But
  this method hasn't found too much support since.}

\index{Connector lines}\index{Prettyprinters!basic actions}
\index{Basic actions of prettyprinters}

\label{basic-actions}

\begin{itemize}

\item indentation and folding (i.e.~determining line breaks) of source code

\item the additional spacing of syntactic constructs (like expressions)

\item using additional typographic means (e.g.~different fonts)

\end{itemize}

\index{Indentation}\index{Folding}\index{Spacing!additional}
\index{Additional spacing}

The main disadvantage of the early systems was their language
dependence.  The style of prettyprinting was hard-wired into the
system, which was basicly a big ``case'' switch over all known
constructs that were to be treated specially. The main advantage of
them, however, was their simplicity and their error handling
capabilities (which is also the reason why such and similar tools are
still widely used today). But it was soon clear that this approach
wasn't adequate and that structural changes had to be made to the
concept.

\index{case@``case'' construct}\index{Early prettyprinters}
\index{Prettyprinters!early systems}

In their paper titled ``A One-pass Prettyprinter'' \cite{Hearn79}
Hearn and Norman introduce a fundamentally new idea into this area.
They simplify the whole concept of prettyprinting by introducing
structure.

\index{Hearn, A. C.}\index{Norman, A. C.}

\begin{quote}

  ``The new method that we propose here will be described in terms
  of a pair of coroutines. One of these will be responsible for
  producing a stream of characters that represent the program
  being printed, the other makes decisions about how these characters
  should be displayed.'' \cite[p.~52]{Hearn79}

\end{quote}

This is a fundamental distinction, namely that between {\em formatting
  policy\/} and {\em formatting algorithm\/} \cite{Bailes84} and is a
vital step on the road to language independence.\footnote{This idea
  however has also introduced a slight blur in the
  terminology, as some authors refer to prettyprinting as consisting
  only of the actual ``printing'' on paper (i.e.~the formatting
  algorithm) \cite{Oppen80,Jokinen89} and others still mean the entire
  process.}

\index{Formatting policy}\index{Formatting algorithm}
\index{Algorithm-policy distinction}\index{Policy-algorithm distinction}
\index{Coroutines}

A problem that arises from this separation is: how do the two coroutines
communicate? Hearn and Norman use a simple FIFO buffer in which the first
coroutine inserts text and ``special markers'' that indicate its
decisions on the policy. These markers were mainly special blanks that
indicate possible line breaks.

\index{FIFO buffer}\index{special markers@``special markers''}

\begin{quote}

  ``The markers will contain enough information for the formatting
  process to discover what level of indentation would be appropriate
  to use were a line break to be inserted at that point.''

\end{quote}

This resembles a special kind of `communication protocol' and is the
first hint to a thing that I have called `format command primitive'
throughout this chapter. Other authors
\cite{Jackel80,Oppen80,Waters83,Blaschek89,Rubin83,Rose81,Jokinen89}
have taken up this idea and have introduced different sets of format
commands that change and increase the communication facilities between
these two processes.  The two most elaborate to date are those of
Rubin \cite{Rubin83} and that of Knuth and Levy \cite{Knuth:CSS93},
that is used here.

\index{Communication protocol}\index{Format commands}
\index{Rubin, Lisa F.}\index{Knuth, Donald E.}\index{Levy, Silvio}

The separation introduced by Hearn and Norman is an example of `separation
of concerns': the language dependent parts of prettyprinting are
separated from the actual typesetting issues that arise, when putting
text to paper. Blaschek and Sametinger \cite{Blaschek89} call this
a distinction between ``language dependent front end and language independent
back end''.

\index{Hearn, A. C.}\index{Norman, A. C.}\index{Separation of concerns}
\index{Language (in)dependence}\index{Prettyprinting!language (in)dependence}
\index{Blaschek, G.}\index{Sametinger, J.}
\index{Front end}\index{Back end}\index{Language dependent front end}
\index{Language independent back end}





\subsection{The Language Dependent Front End}

The earliest suggestions how to build the language dependent front end
go back to Oppens fundamental paper on prettyprinting \cite{Oppen80}. Though
his main concern is the language independent back end, he makes suggestions
about the ``preprocessor'' that should drive it. The main idea is
to make a full syntactic parse of the prettyprinted code and to use
the resulting parse tree to drive the prettyprinter. The format commands
are either assumed to be implicit in the tree (i.e.~every single branch
is treated as a structural block) or they are explicitly inserted into the
tree during the parse. Oppen writes:
 %
\index{Oppen, Derek C.}\index{preprocessor@``preprocessor'' for prettyprinting}
\index{Parse tree}\index{Implicit format commands}\index{Explicit format
  commands}\index{Format commands!explicit}\index{Format commands!implicit}
 %
\begin{quote}

  ``First, notice that the information needed by the prettyprinter
  can often conveniently be represented directly in the grammar [\dots].
  We modify the grammar of the language to contain prettyprinting information
  as above, where [\dots] [the formatting commands] are nonterminals
  mapping only the empty string.'' \cite[p.~475]{Oppen80}

\end{quote}

This aspect has at last enabled people to use formal methods to
describe layout rules. Mateti's paper \cite{Mateti83a} is another
approach in the same direction and is the first to adapt this method
to \PASCAL.\footnote{ It is interesting that Mateti's solution was the
  result of formalization (due to verification needs) and that Oppen's
  proposals emerged from the language independent nature of his
  approach.} The fact that rules for layout and grammar are often
closely related \cite{Leinbaught80} also is a strong indication that
this method is in fact adequate. The trend towards formal
specification in this area has indeed been ``very fortunate''
\cite{Woodman86} and has also proved to be useful in other areas, such
as syntax-directed editors \cite{Rubin83}.

\index{Formal methods}\index{Mateti, P.}\index{pascal@\PASCAL}
\index{Oppen, Derek C.}
\index{Syntax-directed editors}\index{Editors!syntax directed}

To this end Rose and Welsh \cite{Rose81} have advocated the integration
of format rules within the language syntax on the language design level.
They state that ``program format decisions [should be put] in the domain
of the language's designer, rather than its several implementators or
numerous users, which implies uniformly formatted programs of improved
readability and therefore usability.'' \cite[p.~651]{Rose81} Their idea
does {\em not} try to impose rigid formatting rules on users of
existing or future languages. Instead they propose a metasyntax and a
set of guidelines that constrain and direct the language designer in
the placing of format commands. These format commands include commands for
indentation, as well as for line breaks and optional line breaks (so
called ``fold options''). The metasyntax and the guidelines only effect
rather global issues of formatting but ensure consistency across language
borders. They also present a folding algorithm that implements the format
commands from their list.

\index{Rose, G. A.}\index{Welsh, J.}\index{Rigid formatting rules}
\index{Metasyntax (Rose and Welsh)}\index{Guidelines (Rose and Welsh)}
\index{Folding algorithm (Rose and Welsh)}

This last approach by Rose and Welsh is currently the `state of the
art' in program layout issues. Woodman has published a thorough
discussion of this scheme and has proposed refinements
\cite{Woodman86} that however do not alter the main points. It is an
approach that in some way surpasses the area of prettyprinting in that
it forces the formatting grammar to be equal to the language reference
grammar. However, Knuth shows that a prettprinting grammar can be much
simpler than a full-size language grammar, because it is able to treat
semantically different contructs equally as they are formatted in the
same way (e.g.~\res{if}, \res{for} and \res{while} statements).

\index{State of the art}\index{Woodman, M.}\index{Knuth, Donald E.}



\subsection{The Language Independent Back End}

The language independent back end implements the formatting algorithm.
It actually makes the formatting decisions that the formatting policy
has outlined and communicated to it via the format commands. The main
concern of most algorithms is line breaking (or {\em folding\/}). The
proposals by Rose and Welsh \cite{Rose81} and Oppen \cite{Oppen80} have
been the most influential ones on other systems
\cite{Waters83,Jokinen89,Blaschek89} in the literature. However, in
both articles the authors refer to the future of their proposals for
the formatting algorithm:
 %
\index{Formatting policy}\index{Folding}\index{Language independent back end}
\index{Rose, G. A.}\index{Welsh, J.}\index{tex@\TeX}
 %
\begin{quote}

  ``The changes advocated must be seen in the light of current technological
  advances. Automatic program formatting is a very simple instance of automatic typesetting, as that provided by Knuth's TEX system for technical or
  mathematical text.'' \cite[p.~652]{Rose81}

  ``It [the algorithm] is not, however, as sophisticated as it might be,
  and certainly cannot compete with typesetting systems (such as TEX) for
  preparing text for publication.'' \cite[p.~466]{Oppen80}

\end{quote}

As the \WEB\ system shows, \TeX\ has been used as a back
end for a prettyprinter, but it has remained the only one that I am aware
of. This leads to the question, why so little prettyprinters faciliate
typesetters as back ends for their output? This question is very striking,
as typesetters offer powerful capabilities, and for example, \TeX's line
breaking algorithm has been advocated to be very suitable for exactly
this task \cite{Knuth-Plass81}.

\index{web@\WEB}\index{tex@\TeX}

Oppen gives an answer to this in his paper:
 %
\begin{quote}

  ``However, it [the algorithm] seems to strike a reasonable balance
  between sophistication and simplicity, and to be appropriate as a
  subcomponent of editors and the like.'' \cite[p.~466]{Oppen80}

\end{quote}

\noindent It is surely the question whether you are prettyprinting on
screen or preparing a publication.  But the other part of the answer is
maybe not so obvious and has to do with the traditional fears in the
programming community.

A lot of prettyprinters have been built as parts of larger
programming environments and were constituent parts of this larger
system. A lack of modularity in the design (as for example the
fundamental distinction presented in these sections and visialized
in figure \ref{pp-concept}) often
makes the resuing of subcomponents impossible. The prettyprinters
hide somewhere in the larger system and are difficult to extract.

\index{Reuseability}\index{Modularity}

Another point is that an old habit of programmers is their strive
for independence. They do not want their systems to rely on other
systems. But this habit is hopefully getting less frequent today.


\begin{figure}[htb]
  \begin{center}
    \leavevmode
    \input{../figures/pp-concept.latex}
  \end{center}
  \caption{The module structure of modern prettyprinters}
  \label{pp-concept}
\end{figure}



\subsection{The Set of Format Commands}

The format commands passed between the front end and the back end of
the prettyprinter are the only means to convey the formatting policy
to the actual formatter (see figure \ref{pp-concept} that visualizes
the modularity of a prettyprinter). This means that every typesetting
feature must be expressible in them. In conjunction with this work it
is important to ask, if the command set provided in the current
\pretzel\ system is sufficient to format every desired feature that we
can possibly think of. The answer is clearly `No!', as there still are
open prettyprinting problems. We will have a look at them later. But
just how sufficient is the command set?

\index{no@``No''}\index{Sufficiency of command set}
\index{Command set!sufficiency}

First we'll look at whether it allows full control over line breaks
and indentation. A detailed comparison shows that the command set used
by Rose and Welsh is a subset of Knuth's command set (\fmt{indent},
\fmt{outdent}, \fmt{force}, \fmt{breakspace}, \fmt{opt}).\footnote{
  The commands used by Rose and Welsh are denoted by the special
  symbols {\em m, o, r, i} and {\em s}.  A stack is used to keep track
  of the indentation of the preceding lines. The symbol $m$ pushes the
  current horizontal print position onto the stack and the symbol $o$
  pops the stack again. The metasyntax insists that every string
  produced from a non-terminal is bracketed by an $m$\dots$o$ pair. As
  no $m$ and $o$ are allowed elsewhere in a rule body, the amount of
  indentation is always restored to the prevoius value during
  formatting.

  The symbol $r$ denotes a line feed and a carriage return to the
  margin that is stored in top of the stack, whereas $i$ increments
  the top-of-stack margin value and then performes an $r$. The $s$
  symbol is used to emphasize strings produced from a rule of the
  grammar. It is only allowed at the beginning of a rule body and
  directs the folding algorithm to force line breaks before and after
  the string produced from this rule. Optional line breaks (so called
  {\em folding options\/}, denoted `[$i$]' or `[$r$]') can be inserted
  between the non-terminals in the rule body.

  The most obvious analogy is the $i$ symbol. It corresponds to the
  sequence \fmt{indent}, \fmt{force} and since every indent is
  followed by a \fmt{force} or made superfluous by a matching
  \fmt{outdent} you may transform every occurence of \fmt{indent} into
  an optional $i$.  The $r$ symbol, performed inside the $i$, denotes
  a \fmt{force} command. By popping the margin stack, the $o$ symbol
  plays the role of the \fmt{outdent} command. The two fold options
  `[$r$]' and `[$i$]' correspond to \fmt{break\_space} and \fmt{opt}.}
Rose and Welsh in fact show by example, that any language syntax can
be transformed into a formatted syntax that in itself is capable of
specifying all desirable folds and changes of indentation. The main
precondition for this transformation is, that the starting grammar is
context free.  None of the five basic commands is superfluous (as we
have seen in the first part of this chapter) so we can call these
basic commands the {\em necessary command set\/}.

\index{Knuth, Donald E.}\index{Welsh, J.}\index{Rose, G. A.}
\index{Context free grammar}\index{Necessary command set}

The necessary command set enables the first point of the basic actions
of a prettyprinter mentioned on page \pageref{basic-actions}. The
other two points (additional local spacing of syntactic constructs;
using different fonts) are things that depend on the capabilities of
the typesetter and are not so much a question of the format command
set.  Thanks to procedural markup, as long as the prettyprinter allows
us to insert strings between any two tokens at lexical level we are
able to handle these two points too.  However, in Rubin's rather
assembler like command set \cite[p.~122]{Rubin83} we see that the
necessary command set still lacks full control over vertical and
horizontal spacing. One can argue over what parts of this issue belong
into the domain of the typesetter and what should be left to the
user's control, but there surely is an obvious need to express
additional vertical separation in terms of a simple format command. In
our case this is the \fmt{big\_force} command.

\index{Procedural markup}\index{Markup}\index{Lexical level}
\index{Rubin, Lisa F.}\index{Assembler like command set}
\index{Command set!assembler like}\index{Spacing!vertical}
\index{Spacing!horzontal}
\index{Format commands!big force@\fmt{big\_force}}
\index{big force@\fmt{big\_force}}

The other command that gives better control over horizontal space is
\fmt{backup}. Both \fmt{backup} and \fmt{big\_force} can be simulated
by sequences of commands from the necessary command set.\footnote{The
  sequence `\fmt{force}, \fmt{backup}' is equal to `\fmt{outdent},
  \fmt{force}, \fmt{indent}' and `\fmt{big\_force}' is something like
  `\fmt{force}, \fmt{null}, \fmt{force}', depending on the exact
  interpretation of the typesetter.} So they are not necessary but
convenient short-hands. We will call them, together with the basic
commands the {\em convenient command set\/}.

\index{Format commands!backup@\fmt{backup}}\index{backup@\fmt{backup}}
\index{Convenient command set}\index{Command set!convenient}

Typesetting lines of code flushleft is not a feature commonly needed
in modern structured programming languages, except in \C/\CPP\ when
using preprocessor directives (and still they do not belong to the
actual language itself).  The \fmt{no\_indent} command caters for them
but it is hardly necessary in other languages, where alone the idea of
excluding single lines from the overall indentation frame violates all
rules of good program layout.

\index{c@\C}\index{c++@\CPP}\index{Format commands!no indent@\fmt{no\_indent}}
\index{no indent@\fmt{no\_indent}}

Finally the \fmt{cancel} command does not add any striking new
features to the command set. It just allows more flexibility in the
placement of format commands in the output.  A well placed
\fmt{cancel} command can obliterate a dozen rules of your
prettyprinting grammar and thus can deflate prettyprinting grammars
very much. So if you define sufficiency as incorporating convenience
and flexibility we could call this whole set of presented commands a
{\em sufficient command set}. This, however, naturally excludes the
open problems mentioned in the next subsection. The two subsets of
this sufficient command set are summarized in table \ref{command-set}.

\index{Prettyprinting grammar!deflating}\index{Deflating prettyprinting
  grammars}\index{Format commands!cancel@\fmt{cancel}}\index{Sufficient
  command set}\index{Command set!sufficient}\index{cancel@\fmt{cancel}}


\begin{figure}
\begin{tabular}{rl}

necessary command set $N\quad =$ & \{ \fmt{indent}, \fmt{outdent}, \fmt{force},
        \fmt{break\_space}, \fmt{opt} \} \\
convenient command set $C\quad =$ & $N$ $\cup$ \{ \fmt{backup}, \fmt{big\_force} \} \\
sufficient command set $S\quad =$ & $C$ $\cup$ \{ \fmt{cancel}, \fmt{no\_indent} \} \\

\end{tabular}
\caption{Naming of subsets of the command set.}
\label{command-set}
\end{figure}






\subsection{Open Prettyprinting Problems}

If you have ever tried to use a prettyprinter for your own code you
will surely have come across problems concerning user control. Yehudai
states, that
 %
\index{Prettyprinting!problems}\index{User control}
\index{Yehudai, A.}
 %
\begin{quote}

  ``[\dots] it is not clear that any automated indentation scheme will
  be adequate, as I may choose different ways to lay out the same
  construct in different parts of my program.''
  \cite[p.~85]{Yehudai80}

\end{quote}
 %
Woodman gives an example for this point that he calls ``adaptive
combs'' \cite[p.~616]{Woodman86}, where a long \res{if}/\res{elsif}
statement in Modula-2 is cited as:
 %
\index{Woodman, M.}\index{adaptive combs@``adaptive combs''}
\index{Modula-2}
 %
\begin{outp}
  \res{if} \id{longexpression1} \res{then}\myindent\myforce
    \id{longstatement1}\myoutdent\myforce
  \res{elsif} \id{expr2} \res{then} \id{stmt2}\myforce
  \res{elsif} \id{longexpression3} \res{then}\myindent\myforce
    \id{longstatement3}\myoutdent\myforce
  \res{else}\myindent\myforce
    \id{longstatement4}\myoutdent\myforce
  \res{end}\myforce
\end{outp}
 %
Here the statement \id{stmt2} appears on the ``tooth'' of the comb,
whereas the context rather suggests that it should appear between
the teeth like all other statements. This is a question of {\em context
  sensitive formatting\/} and it is an open question, how to deal
with this problem in terms of format commands.\footnote{
  Woodman proposes the idea of ``linked folds'', i.e.~a special
  set of format commands that force a number of consecutive folds
  to be treated equally, but doesn't elaborate on it.}

\index{Tooth}\index{Context sensitive formatting}
\index{Linked folds}

Another open problem falls into the same domain, but deals with horizontal
spacing instead of line breaking.  Blaschek \cite[p.~701]{Blaschek89} points
out that his system is not able to align constructs horizontally, as
for example in:
 %
\index{Horizontal spacing}\index{Spacing!horizontal}\index{Blaschek, G.}
 %
\begin{outp}
  \res{with} \id{stmt} $\hat{ }$ \res{do}\myindent\myforce
    \begin{tabular}{ll}
      \id{position} & \ass\ \id{pos} \\
      \id{decLabel} & \ass\ \id{label} \\
      \id{next}     & \ass\ \res{nil} \\
    \end{tabular}
    \myforce
  \res{end}\myforce
\end{outp}
 %
This is a problem that no prettyprinter to date has mastered in an
automatic fashion.

It is an open question whether these problems could be solved using
intelligent algorithms that learn a layout style by example, like for
instance the `intelligent' prettyprinter by Winter and Cook
\cite{Winter89}. But maybe the worst (and oldest) prettyprinting
problem is how to typeset comments! Papers as early as those of
Mohilner \cite{Mohilner78} and Jackel \cite{Jackel80} address this topic
and the core of the problem surely lies in the nature of comments. The
paper ``Programming languages should NOT have comment statements'' by
Kaelbling \cite{Kaelbling88} and that by Grogono \cite{Grogono89}
strongly argue that at last comments should be treated equally as
parts of the language, not as an add-on that is forgotten at first
point during compilation. Grogono brings this to the point by stating
that ``Comments are second class citizens.'' \cite[p.~80]{Grogono89}
They are mostly allowed anywhere in the source code and prettyprinters
who want to preserve them in the output have severe problems doing
that without destroying the program's format, because they have to be
incorporated into the prettyprinting grammar.

\index{Winter, K.}\index{Cook, C.}\index{Prettyprinter!intelligent}
\index{Intelligent prettyprinter}\index{Typesetting comments}
\index{Comments}\index{Prettyprinting problems!worst and oldest}
\index{Mohilner, Patricia R.}\index{Jackel, M.}
\index{Kaelbling, M. J.}\index{Second class citizens}\index{Equality}
\index{Grogono, P.}\index{Prettyprinting grammar!and comments}

There have been attempts to do this in a structured way, i.e.~to
divide comments into classes and to treat each class differently
\cite{Richard77,Rubin83,Fritzson83,Rorbillard89}. Rose and Welsh
distinguish between pre- and postcomments and state that comments must
move with the syntactic elements that they refer to
\cite[p.~660]{Rose81}. Kaelbling even goes as far as to demand ``scoped
comments'', i.e.~comments that explicitly show to which part of the
program they belong.

\index{Rose, G. A.}\index{Welsh, J.}\index{Classes of comments}
\index{Comments}\index{precomments@``precomments'' (Rose and Welsh)}
\index{postcomments@``postcomments'' (Rose and Welsh)}
\index{Kaelbling, M. J.}\index{scoped comments@``scoped comments'' (Kaelbling)}

All these attempts have the same goal, but the problem of prettyprinting
comments will only be solved, if they are treated as an equal part of
a programming language and thus are included in the reference grammar.








\section{Summary}

As this has been quite a long chapter I will try to recall
the main points of it now:
 %
\index{Long chapter}

In this chapter I have introduced the way of formatting that \pretzel\
uses in the generated prettyprinter. This method uses format commands
that are intermixed with the text strings of the source code according
to a prettyprinting grammar and interpreted by the typesetter. A few
examples were given.

In the second part I have tried to reconstruct the evolution of this
formatting algorithm by giving a brief overview over the history of
prettyprinting. This has shown the main points that structure the
field (distinction between formatting policy and formatting algorithm,
formalization of formatting policy through a prettyprinting grammar,
different sets of format commands).  From this overview I have shown
how the algorithm used be the \pretzel\ system fits into the field and
how sufficient its command set is.




