\section{Introduction}\label{intro-sect} 

Java and .NET are two widespread and successful platforms:
they are both based on two high performance, very reliable
virtual machines, respectively the JVM and the CLI, which
allow the development of portable and interoperable applications. One of the common
denominators of them is that they have been designed with statically
typed languages in mind, and their native object model force objects to have a fixed set of
fields and methods.  While these static guarantees enable earlier error detection and efficiency,
they also come at the cost of a loss of expressive power.

On the other hand, information technology is quickly moving to 
scenarios where computing needs to be ubiquitous, pervasive, and highly
dynamic \cite{fp7}.  In order to thrive in this environment, modern software systems 
must be dynamically adaptable and updatable.  This fact explains the
growing interest in dynamically typed languages, 
like Python, Javascript and Ruby.  Both the JVM and the CLI have also
felt the pressure to become add dynamic features, such as support
for dynamic typing\cite{JSR292}.

There have been several implementations of dynamically typed languages
for both the JVM and the CLI, such as \cite{Jython}, \cite{IronPython},
\cite{JRuby}, and \cite{Rhino}.  While these implementations are very usable,
and generally feature well-developed integration with their hosting
environments, they are significantly slower than Java or C\# (see 
Section~\ref{benchmarks}).
This is generally because the primitives
provided by the JVM and the CLI are not sufficiently dynamic to be directly
usable, and so the implementors are forced to emulate the dynamic
object model in an interpreter-like fashion.

\emph{Restricted Python} (subsequently called \emph{RPython}) is an
attempt to, in the words of Mejier and Dryton, ``seek the golden middle
way between dynamically and statically typed languages'' \cite{MeijerDrayton04}.
It is a proper subset of Python, restricted in a way that enables easy
analysis and efficient code generation, but still maintains many of
Python's hallmark features.  The result is a language that is more expressive than
C\# and Java, but which does not compromise runtime efficiency.  
RPython was initially designed for the specific purpose of
implementing PyPy\cite{D05.1} (a Python interpreter written in Python), but
it has grown into a full-fledged language in its own right.  

The main restrictions that must be obeyed for a Python program to
be considered RPython are:
\begin{itemize}
\item Dynamic features like class modification can be used in full, but only
	during an initial, boot-strapping phase which is used to construct the
	final RPython program that is actually executed. 
	
\item The final program to be executed must have static types which can 
	be inferred by the PyPy toolchain.
	
\item Only single inheritance is permitted, though there is support for 
	mixins\ref{PythonMixIn}, which offer many of the advantages of multiple inheritance.
\end{itemize}

The contributions of this paper are two-fold.
First, we present an overview of RPython and give
several examples which demonstrate the many 
meta-programming techniques made possible by its 
preprocessing step.  
  
Second we describe the design and
implementation of the JVM and CLI backends we have developed,
and show how RPython's structure allows it to be
easily mapped to these environments.

The paper is structured as follows.
Section~\ref{rpython-intro} gives an overview of RPython and shows
by some examples that it is a quite expressive language, despite the
limitations imposed by its  static type system. The next two sections
describe the architecture of the RPython compiler:
Section~\ref{frontend-sect} outlines the design of the front-end,
whereas Section~\ref{backend-sect} describes some of the details of
our implementation of the JVM and CLI back-ends.
Section~\ref{futureWork-sect} discusses 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.
Finally, Section~\ref{conclusion-sect} draws some conclusions.