%
% $Id: chap5.tex,v 1.4 1995/04/20 13:18:48 gaertner Exp gaertner $
%
% $Log: chap5.tex,v $
% Revision 1.4  1995/04/20  13:18:48  gaertner
% Corrections proposed by JS
%
% Revision 1.3  1995/02/24  09:58:18  gaertner
% Final revision (including figures and index).
%
% Revision 1.2  1995/02/21  09:37:28  gaertner
% Changes \mkWEAVE, \makeWEAVE, \preFLEX, \preBISON, preFLEX and
% preBISON to the relevant terms.
%
% Revision 1.1  1995/02/21  09:31:12  gaertner
% Initial revision
%



\chapter{Future Work}
\label{five}

\label{future-work}

\index{Future work}

After having finally implemented and tested the \pretzel\
program I have noticed, that the program doesn't do very much at
all, although it suits the specifications that belonged to this
project. To enjoy beautifully formatted source code you
still have to construct your prettyprinting grammar. As is seems,
the work of fine tuning such a grammar that the prettyprinter is
able to handle the last formatting detail you desire is quite
tedious and time-consuming, especially if you start to build your
grammar from scratch. But after constructing such a grammar for
\PASCAL\ and applying it to a few everyday-example \PASCAL\ source
codes, I was astonished how easy it was to change the looks of the
prettyprinted text. I think that starting with a formal grammar of
your favourite language and trying to enhance it and transform it
into a prettyprinting grammar is surely a better way to reach your
goal. I suppose that the \pretzel\ program could be the right tool
to help you with this task.

\index{Omissions}\index{Prettyprinting grammar}\index{pascal@\PASCAL}
\index{pretzel@\pretzel}

However, since only few people have used \pretzel\ until today there
will surely be a lot of things people miss when using the program. Now
I will list a number of omissions that I have thought of during the
last phase of the implementation. I have listed them in order of
increasing severity.

\begin{description}

\item[Allow \t{/*}\dots\t{*/} comments.]  In places where the user has
  an empty production in the formatted grammar file or an empty token
  definition in the formatted token file file, it would be nice to
  have a C like commenting feature with opening and closing
  delimiters. The `\t{//}' comment delimiter isn't nice if you want to
  add an attribute definition to an empty production.

  \index{Empty tokens}\index{-@\t{/*}\dots\t{*/} comments}
  \index{--@\t{//} comments}

\item[Copy comments.]  It surely would make the generated flex and
  Bison files more readable, if \pretzel\ would copy the comments from
  the formatted token and the formatted grammar files into them.

  \index{Copy comments}

\item[Generate \t{\%token} definitions.]  If one would impose the
  restriction to use only uppercase identifiers as terminal token
  names \pretzel\ could automalically generate the list of \t{\%token}
  definitions needed to identify terminals in the formatted grammar
  file.

  \index{token definitions@\t{\%token} definitions}

\item[Using more than one prettyprinter at the same time.] This
  problem is closely related to the question whether you can use two
  seperate Bison parsers in your program. As this is the case in newer
  versions of Bison using more than one prettyprinter at the same time
  should be possible. However, you have to use the relevant Bison
  options to enable this and it would be nice to circumvent these
  problems in a nicer way.

  \index{Bison!using more than one parser}


\item[Include code in attribute definitions.] If you want to
  generate an index of identifiers during the prettyprinting and you
  don't want to do this through text markup, one would have to have a
  way of smuggling additional \C\ code into the actions of the flex
  and/or Bison files. A clean way of doing this would be to include
  the code in the formatted token and formatted grammar files using
  special delimiters like `\t{[[}' and `\t{]]}' that normally don't
  appear in todays programming languages.

  \index{c@\C}\index{---@\t{[[}\dots\t{]]} delimiters}
  \index{Including \C\ code into rules}

\item[Change prettyprinting grammar format.] It would be nice to
  be able to insert format commands directly into the grammar rules,
  like for example in:

\begin{inp}
  WHILE expr DO \fmt{indent} stmt \fmt{outdent} \fmt{force}
  $\longrightarrow$ stmt
\end{inp}

This is a point that effects fundamentals of the \id{build\_pparse}
function. Other parts of \pretzel\ are not involved. This is a change
that would be good for new users, since this way of specifying the
grammar is much more intuitive.

\index{Inituitive grammar format}\index{build pparse@\id{build\_pparse}}
\index{Prettyprinting grammar}


\item[Allow changing output formats.] To present, the \id{Output}
  class that does all the interpretation of the format commands exists
  only in a version that produces \TeX\ text.  Though it is easy to
  change the implementation and thus the interpretation of the output
  class, it would be nice to be able to have a library of different
  output versions that can be chosen from at run-time. So if you want
  to prettyprint code with a prettyprinter, you not only mention in-
  and output streams, but also how the format commands could be
  interpreted.

  \index{tex@\TeX}\index{Interpretation}\index{Changing output formats}
  \index{Language independent back end}

  Joachim Schrod suggested to design a new \CPP\ class for this
  purpose called ``\id{Interpretation}'' or something similar. There
  should be a default interpretation as abstract base class (what
  would it look like?) and subsequent interpretation versions would be
  derived from this standard. The prettyprinting function would then
  turn to

\begin{outp}
  \res{void} \id{myparse} (\id{istream}$\ast$,\id{Interpretation},
  \id{ostream}\&);
\end{outp}

\item[Include files for grammars.] As parts of prettyprinting
  grammars occur frequently in many different programming languages
  (such as the formatting of expressions) it would be nice to be able
  to include files that contain these definitions with a simple
  command in the formatted token and formatted grammar files. On a
  more abstract level one could think of a notion of modules of
  grammars, i.e.~parts of a grammar that can be called with arguments
  to suit local demands (``grammar templates''?). But it is still an
  unanswered question whether this is practical, because of the lack
  of method to specify the interface of such a module.

  \index{Include files for grammars}\index{Prettyprinting
    grammar!include files}


\end{description}


\noindent Looking back at the project it is quite striking why the
prettyprinter generated by pretzel is not built in a modular kind of
fashion that is described in chapter \ref{one} and visualized in
figure \ref{pp-concept} on page \pageref{pp-concept}. This lack of
modularity possibly has something to do with the fact, that chapter
\ref{one} was written {\em after} the project was in the design phase.
But this lack of modularity has the advantage of not having to define
the interface between the language dependent front end and the
language independent back end, as this part is hidden within the
\id{Output} class (see figure \ref{pretzel-in-concept} on page
\pageref{pretzel-in-concept} for how the \pretzel\ prettyprinter fits
into this scheme). This makes the implementation more efficient but
less understandable. The extension proposed in the above list to
introduce ``interpretations'' would possibly only blur the concept
further. A new design, based on the fundamental distinction of
modules, seems a little more promising to me. It is clear that still a
lot of work has to be done.

\index{Lack of modularity}\index{Design phase}\index{New design}
\index{Work!a lot of}

\begin{figure}[htb]
  \begin{center}
    \leavevmode
    \input{figures/pretzel-in-concept.latex}
  \end{center}
  \caption{How the prettyprinter generated by \pretzel\ fits into the module structure of modern prettyprinters.}
  \label{pretzel-in-concept}
\end{figure}


