[pypy-dev] Re: appspace considerations and genrpy

[Armin Rigo]

Hi Christian,

On Thu, Nov 25, 2004 at 09:04:18PM +0200, Christian Tismer wrote:
> If you look at md5.py, you'll see that it *is* already almost
> restricted Python. I can just move almost all functions
> over to the interpreter level.

Yes, only some code is "essentially" application-level code.  Some other code
is quite "C-ish" already, and doesn't in any essential way need to correspond
to space.xyz() calls.  It can just "do its job" and return a result.

In this respect md5.py and sha.py are similar to _formatting.py: they are all
general Python code (so meant for app-level) that is almost RPythonic enough
that we could put the code at interp-level with only some amount of uglifying.

Didn't your mind go a full circle back to its starting point?  I seem to
remember that you started work on genrpy precisely to avoid to uglify
_formatting.py by hand.  Now you say that md5.py should better be put to
interp-level manually...

While this is of course possible, the idea of genrpy was to do it
automatically.  I know the generated code must look incredible right now,
because it's just calls to space.xyz().  But the idea is to run the annotation
stuff over the graphs -- which assumes some restrictions, which are generally
fine for the kind of app-level code we are considering.  Then genrpy can be
extended to use the annotations, e.g. when it knows that a given variable is
an integer, it should use a real integer in the produced code too, instead of
a space.wrap(value), and real '+' '-' etc operations instead of space.add(),
space.sub(), etc.

In this way we produce interp-level code that will be:

* unreadable
* fast
* automatically integrated with the rest of the interp-level code
* still containing some space.xyz() operations if needed -- i.e. we can still
   use app-level code as a "macro language" to compactly write things like
   space.is_true(space.eq(space.getitem(w_list, space.wrap(i)), w_value)).


A bientôt,

Armin