\section{Towards a Usable Language}\label{futureWork-sect}

  As already pointed out, RPython was initially designed for the specific purpose of
  implementing PyPy, a Python interpreter written in Python,
  therefore its implementation is still premature for being used as a
  full-fledged programming language.
  In this Section we discuss some issues both at the design and
  implementation level that should be addressed in the future in order
  to make RPython a more usable and useful language.

  Short term future work concerns some implementation details
  aiming at making the front-end more user-friendly, completing the
  JVM back-end, and improving code optimization.
 
  More challenging issues include support for separate compilation and
  interoperability, more refined forms of type analysis to increase the
  expressive power of the language without compromising its
  efficiency.

\subsection{Separate compilation and interoperability}

Since the Flow Graph Generator and the Annotator perform a global
analysis and require an entry point, typechecking is not compositional.
Indeed, the main drawback of this approach is that
a function or class declaration might be accepted or rejected as
correct RPython code depending on the context where it is used. 
For the same reason, separate compilation is barely supported. 

To avoid this problem we could adopt at least two different approaches:
the first would consist in requiring the programmer to add some type
annotations; this could be implemented in a simple way, but would be
against the ``Python philosophy''. The second solution would be more 
Python-oriented, but also more difficult to achieve, since it would imply a major
revision of the Annotator in order to implement a compositional 
type inference algorithm, as done, for instance, for JavaScript
\cite{And+Gia+Dro:ECOOP-2005}.

For what concerns interoperability between Python and C\#/Java,
the compiler already supports the use of  C\# classes in RPython
programs, and we are confident that, once the Java back-end is completed,  the 
same feature will be available for Java classes.

On the other hand, the possibility of using RPython classes inside
C\#/Java code has not been investigated yet, and at the moment we do
not know how this feature could be implemented. 


\subsection{Increasing the expressive power}

The type system of RPython was designed to be expressive enough to
allow compilation of the Python interpreter, so its expressivity
can be enhanced to make RPython less restricted and more flexible.

One of the main limitations of the current type system of RPython 
is that it does not directly support generic methods/functions.
Let us consider, for instance, the following code:
\begin{lstlisting}
def id(x):
    return x

print id("one"),id(1)
\end{lstlisting}
It can be compiled by the RPython compiler only if
the programmer gives some suggestions to the Annotator, and however
the performed translation is heterogeneous: a different version of  
\lstinline!id! is generated for each possible use in the program
with incompatible values (as it is the case for integers and strings).

Fortunately this limitation can be overcome by introducing 
polymorphic types for functions, without compromising the efficiency
of the programs.
 
On the other hand, other kinds of extension to the type system would imply a
partial re-design of the Annotator and would have a negative impact on
the performance of RPython programs.
For instance, it would be possible to define a more sophisticated type
inference algorithm to allow dynamic addition of methods to RPython
classes, as done, for instance,  for JavaScript
\cite{And+Gia+Dro:ECOOP-2005}. However, invocation of dynamically
added methods would incur a significant time penalty.
We do not know how this problem would benefit from the introduction of new bytecode for directly supporting
dynamically typed languages (see for instance the Java Specification
Request for a new instruction \lstinline!invokedynamic! \cite{JSR292}).