\section{The past and future of \cmix}
\label{limitations}

\subsection{Historic background}
The original C-Mix was written by Lars Ole Andersen in 1991 as a
prototype implementation of the theory in his master's
thesis. The system evolved over the years, maintained by Lars Ole
Andersen and Peter Holst Andersen, who both continued to develop
theory and techniques---after C specialization had earned Lars Ole
his Ph.D. and he left DIKU, Peter Holst Andersen kept extending the
system.

But the old C-Mix was primarily a research prototype and its user
interface did not have top priority. The system never became very
easy to use, and it had a disturbing tendency to revenge bitterly
on its user when faced with a construct it couldn't make sense of
(whether because its input was actually illegal C or the feature
had just not been implemented properly).

In early 1997 we began a project of rewriting C-Mix from scratch
with emphasis on stabiltiy and an easy-to-use interface. This effort
concluded late in February 1999 with the release of C-Mix 2.0.0.

\subsection{Future improvements}
These are the improvements to \cmix{} we're planning to make in
later releases:
\begin{itemize}
\item\textbf{Utilizing liveness information} to reduce the
	number of locations that are considered when comparing
	spectime states. This will improve the running times of
	the generating extension, in addition to reducing code
	blowup in the residual program.

\item\textbf{The ability to ``lift'' strings} so they can
	be computed at spectime and used in the residual program. This
	is not always safe, and we need to develop analyses or
	annotations to determine when.

\item\textbf{Structures with mixed binding time}. We already
	have most of the machinery to support structures where
	some members are spectime and others are residual. This
	can be implemented with rather little extra effort.

\item\textbf{Better, more coherent documentation}

\item\textbf{Beautifying post-processing of the residual
program}. The current \cmix{} outputs a residual program in a very
low-level programming style: a lot of very simple statements, and
»goto«s as the primary control structure.

If we could implement heuristics for expressing the control
structure with Cs looping and branching primitives, it would make
the residual programs much more readable for human readers. That
would make it easier to verify that one has got the expected result
from partial evaluation, and it would make \cmix{} more useful as
a general introduction to partial evaluation.

Additionally it turns out---rather to our surprise, actually---that
several C compilers actually generate better machine code from a
»for« loop than from the same loop when it has been translated into
»goto«s.

Similar considerations can be made about the very simple statements
that make up the computations in the residual program. It would be
nice to be able to combine
\example{iTmp = f(42); a = iTmp + b;}
into
\example{a = f(42)+b;}

\item\textbf{Polyvariant specialization}. The ability to specialize
a function, not only to different spectime values, but to totally
different binding times, would make it a lot easier to get good
performance out of specialized program without modifying the subject
program's text too much. As one can imagine this is going to require
substantial changes to \cmix's internals, so don't hold your breath.

\end{itemize}
