Paul Boddie wrote: > Kay Schluehr wrote: > > Paul Rubin wrote: > > > "Kay Schluehr" <[EMAIL PROTECTED]> writes: > > > > I talked to Richard Emslie recently and he told me that the PyPy team > > > > works on a mechanism to create CPython-extension modules written in > > > > RPython i.e. a statically translateable subset of Python. > > > > > > Sounds great but is that a whole lot different from pyrex? > > I've wondered that as well. > > > RPython is Python code not a different language. In a sense RPython > > consists of a set of rules usual Python has to conform to make complete > > type-inference feasible. Here is an overview of those rules. > > > > http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#restricted-python > > But does that make it "proper Python"? Having, for example, only one > type associated with a name (they use the term "variable", though) at > any given time makes it more like various statically typed or > functional languages, although I can fully understand why you'd want > this restriction. > > Paul
I would say yes, it is still "proper Python" in that each RPython program is also a CPython program. That does not tell us much though, because a simple calculator providing basic arithmetic operations in infix notation fits the definition as well. The reason why RPython is not formally defined may be that it is dedicated to be a maximal sublanguage of Python that can be accepted by a reasonable type-inferencer that translates code into a statically typed language. I find this idea fascinating. Extending the type system by structural types ( e.g. duck-typing a la C++ ) or algebraic types ( ML -like type constructors including recursive types ) is a declarative way to extend the languages power. Another one is extremely-late-binding enabling arbitrary mutability. Now think for a moment about Guidos idea of optional type annotations. How would this fit into the whole picture? Kay -- http://mail.python.org/mailman/listinfo/python-list
