Question from an old friend of mine ....
My friend Geoff Collyer just read the PyPy proposal. He said this: ------- Forwarded Message Return-Path: geoff@collyer.net Delivery-Date: Thu Nov 6 02:26:25 2003 Message-ID: <259f0c7ae0856ce884c9062e0e2c10c3@collyer.net> To: lac@strakt.com Subject: Re: PyPy From: Geoff Collyer <geoff@collyer.net> Date: Wed, 5 Nov 2003 17:26:22 -0800 In-Reply-To: <200311060104.hA614icL028140@ratthing-b246.strakt.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on theraft.strakt.com X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_01 autolearn=ham version=2.60 X-Spam-Level: It appears that compiler theory has advanced quite a bit while I wasn't looking. How much of what you propose has already been implemented at least once? How much of the rest (unimplemented) is covered by existing compiler theory? ------- End of Forwarded Message I don't know the precise answer, so I post it here .... Laura
Hi Laura, On Thu, Nov 06, 2003 at 02:40:54AM +0100, Laura Creighton wrote:
My friend Geoff Collyer just read the PyPy proposal.
He said this:
It appears that compiler theory has advanced quite a bit while I wasn't looking. How much of what you propose has already been implemented at least once? How much of the rest (unimplemented) is covered by existing compiler theory?
Sorry for not having answered this one earlier. I don't know much more about it than what is written in the proposal, and even there, much was Samuele's contribution. All I can say is that probably all bits we describe there have been already implemented here and there, I just don't think they have all been put together anywhere. Object spaces are abstract interpretation domains (though I don't know of any regular interpreter that can also do abstract interpretation just by changing the domain). Using an Object space for control flow analysis is probably not new but not widely used either. RPython and the static compilation to C is like R-Scheme, though we do it a bit differently. As far as I know our annotation-based type system is novel. The start of the theory for it is in trunk/doc/translator/annotation.txt :-) Weaving aspects at translation-time, like adding Stacklessness or GC-vs-refcount, is the spirit of aspect-oriented programming, but the latter has gone in different directions nowadays (which I find quite sad, independently of PyPy). But Stackless and GC systems themselves have been around for a long time, it's just the method to get them which is new. The same can be said about Psyco (though not the "long time" bit). A bientot, Armin.
Hi Armin, [Armin Rigo Tue, Nov 18, 2003 at 10:10:37AM +0000]
On Thu, Nov 06, 2003 at 02:40:54AM +0100, Laura Creighton wrote:
My friend Geoff Collyer just read the PyPy proposal.
He said this:
It appears that compiler theory has advanced quite a bit while I wasn't looking. How much of what you propose has already been implemented at least once? How much of the rest (unimplemented) is covered by existing compiler theory?
Sorry for not having answered this one earlier. I don't know much more about it than what is written in the proposal, and even there, much was Samuele's contribution. All I can say is that probably all bits we describe there have been already implemented here and there, I just don't think they have all been put together anywhere.
Object spaces are abstract interpretation domains (though I don't know of any regular interpreter that can also do abstract interpretation just by changing the domain).
Using an Object space for control flow analysis is probably not new but not widely used either.
Are you sure that something like the concept of Object Spaces (or an Operation library) has been tried before? Our current separation of an interpreter which dispatches and implements bytecodes by performing a series of operations via an Object Space on otherwise opaque app-objects. and an Object Space which manipulates app-visible objects and provides (in case of StdObjspace) the standard python type system or (in case of FlowObjSpace) uses the calls to record and transform the running program into a graph-representation which is then further processed by the Annotator and Translator which perform type inference on the graph and eventually generate either pyrex or lisp-sourcecode. This separation doesn't seem like anything i read about before (e.g. Squeak and other links provided by Samuele). Of course i am not so much saying that to you only as you know all this but i think it makes sense to recap our architecture for newcomers ...
RPython and the static compilation to C is like R-Scheme, though we do it a bit differently. As far as I know our annotation-based type system is novel. The start of the theory for it is in trunk/doc/translator/annotation.txt :-)
Weaving aspects at translation-time, like adding Stacklessness or GC-vs-refcount, is the spirit of aspect-oriented programming, but the latter has gone in different directions nowadays (which I find quite sad, independently of PyPy). But Stackless and GC systems themselves have been around for a long time, it's just the method to get them which is new. The same can be said about Psyco (though not the "long time" bit).
Of course, this is true, either way. cheers, holger
participants (3)
-
Armin Rigo -
holger krekel -
Laura Creighton