\documentclass[11pt,a4paper]{article}

\begin{document}
\title{\textbf{Development of the PEPA tools}}
\author{Stephen Gilmore}
\maketitle

\begin{abstract}
  This note details some improvements needed to the PEPA tools,
  primarily the PEPA Workbench.  The suggested improvements are listed 
  in my order of preference, which is to increase the usability of the 
  Workbench for naive users who download it from the PEPA Web page.
  Other orders of prioritisation would be possible, but the suggested
  one would deliver most benefit to most users, which is really the
  aim of the tools.
\end{abstract}

\section{Supporting the development of the Java version}

Any assistance given to Jon Hunter in developing his Java/Pizza
version of the PEPA Workbench counts as a top priority activity in
development of the PEPA tools.  All of the ML coding described below
should be shelved at any time in order to give preference to helping
Jon Hunter's Java development.

\section{Developing the ML version of the Workbench}

The future of ML compilers is very uncertain.  All of the commercial
compiler developments have now folded (Poly/ML, MLj, MLWorks).
Ultimately, but not yet, we should move the Workbench to Java but for
the meantime we will continue to develop the ML version and restrict
outselves to portable Standard~ML code.  This has the big restriction
of no use of functors (because Moscow~ML and MLj do not have them).

Some of the developments suggested below require modifying the PEPA
grammar used in the Workbench.  Obviously it is also tempting at the
same time to port the grammar to ML-Lex and ML-Yacc.  I'm very happy
about this provided that the grammar is itself still portable and can
go through both the New Jersey 110 and the Moscow~ML versions of
ML-Lex and ML-Yacc and that the (functor-free) code which comes out of
the Moscow~ML version can then go through MLj.  This would be a really 
good thing because the Workbench at present produces lousy error
messages for simple things like missing out the dot after the closing
bracket in a prefix.  Hopefully Yacc error messages would be better.


\subsection{Implementing expressions in rates}

In PEPA models in papers it is often the case that expressions are
used as rates, e.g. $(1 - p) \times \lambda$.  The PEPA Workbench does 
not support this syntax except in the very limited case that
\texttt{*} can be used as a character in identifiers!  This means that 
the text \texttt{p*lambda} can be used as a rate identifier which is
then passed through the Workbench and interpreted as a multiplication
by Maple.   Of course putting spaces around the operator breaks this
syntax and so a better solution is required.

The idea would be to ditch the use of \texttt{*} in identifiers and
implement simple expressions with addition, multiplication,
subtraction, division (and perhaps exponentiation) and use of
parentheses.  The usual rules of operator precedence should apply.
Long integer constants (i.e. if possible arbitrary precision) should
be available as well as real number constants conforming to the usual
IEEE standard.

As an extension, one could introduce a method of binding rates to
constants in PEPA models themselves.  For example:
\begin{verbatim}
    lambda = 0.01;
    mu = 2 * lambda;
\end{verbatim}

\subsection{Fixing the expansion of parallel components}

The PEPA Workbench documentation describes the grammar of the
Workbench as allowing uses of the parallel combinators only in the
model equation at the end of the file.  Of course, for a large model,
people prefer to structure their input by binding names to parallel
compositions of sequential components.  These are then composed in
parallel.  This is OK if there are no parallel components behind a
prefix.  Of course, $P = (\alpha, r).(P \parallel P)$ is not OK\@.

At present, the Workbench makes a small number of phantom transitions, 
when unrolling, say, $P = Q \parallel Q$ and counts $P$ and $Q
\parallel Q$ incorrectly as two separate states.  Fixing this by first 
expanding out all of the named parallel components would ensure that
the uses of the parallel combinator were safe and would correct the
small number of phantom states incorrectly counted by the Workbench.

\subsection{Improving the PEPA Workbench grammar}

It would be nice to allow some minor extensions to the PEPA grammar,
for example to allow identifiers to be bound to cooperation sets or
hiding sets.
\begin{verbatim}
    L = { put, get };
\end{verbatim}
Then of course one needs to distinguish (in the concrete syntax)
between cooperating on an activity called $L$ and cooperating on the
activities in the set~$L$\@.  One suggestion is to forbid the use of
any identifier as both a cooperation set identifier \emph{and} an
activity type identifier.  I would prefer this to a convention such as
forcing cooperation set identifiers to be uppercase only and forcing
activity type identifiers to be lowercase only.  One can always
suggest that a user should use this convention anyway, without forcing 
it on all users.

This is not a problem for hiding because one types the set braces
around the set element list at present.

%%%Another minor extension is allowing rated activities to be named:
%%%\begin{verbatim}
%%%    a = (alpha, rate);
%%%    P = a.P;
%%%\end{verbatim}
%%%I'm not sure that this one is particularly attractive.


\subsection{Pretty-printing \LaTeX\ output}

Of course, many people wish to publish their PEPA models in papers and 
theses.  A \texttt{.pepa} file is not suitable for inclusion directly
and so a translator which produced \LaTeX{} output would be a very
useful addition.

The \LaTeX{} formatted output could be written to a \texttt{.ptex}
file (to avoid clobbering a \texttt{.tex} file with the same basename
as the model).  A flag such as \texttt{-LaTeXonly} could be set just
for formatting purposes, without causing the invocation of the
computation of the derivation graph of the model.  This would be
useful for models which were too large to put through the Workbench.

The \LaTeX{} translation of identifers should be fairly obvious:
\begin{center}
  \begin{tabular}{|l|l|r|}\hline
   \texttt{Buffer}&
        \verb"\mathit{Buffer}"&
                (Any identifier)\\ \hline
   \verb"Buffer_1"&
        \verb"\mathit{Buffer}_{1}"&
                (Any numeric suffix)\\ \hline
   \verb"Buffer_Full"&
        \verb"\mathit{Buffer\_Full}"&
                (Any non-numeric suffix)\\ \hline
   \texttt{alpha}&
        \verb"\alpha"&
                (Any Greek letter)\\ \hline
   \texttt{infty}&
        \verb"\top"&
                (The rate ``top'')\\ \hline
  \end{tabular}
\end{center}
Dealing with whitespace and comments requires some thought.  Because
the Workbench cannot guess font sizes and page sizes the only option
is to require the user to decide on line breaking and indentation by
taking line breaks always literally and white space in the
\texttt{.pepa} input mostly literally.  (Here some decision needs to
be made about what TAB characters mean.)  This has the obvious
consequence that \LaTeX{} pretty-printing needs to be done
\emph{before} lexing and parsing.  This requires further thought but
presumably an \texttt{eqnarray} environment could be used to pretty up
the definitions with the white space at the start of a line taken
literally as white space to appear after the \verb"&\rmdef&" or the
\verb"&&" in a line in the \texttt{eqnarray}.

As regarding comments, people will want to interleave explanatory
prose around the definitions in their PEPA model.  I would suggest
introducing another comment syntax, e.g. \texttt{/*} \ldots
\texttt{*/} which can be used to delimit \LaTeX{} text embedded in the
PEPA model.  The \LaTeX{} comment syntax of \verb"%" can be retained
but it turns into a \LaTeX{} comment, of course.

\end{document}

