headers
Armin Rigo | 1 Oct 2005 19:59
Favicon

Re: Re: Project suggestions

Hi Aurelien,

On Sat, Oct 01, 2005 at 02:44:50PM +0200, Aur?lien Camp?as wrote:
> I would tend to provide a huge prelude implemeting a close aprox. of 
> those in CL (it is my plan).

Yes, this would be possible.  I suppose even dark corners like
dictionary with user-specified ways of computing the hash of keys could
be done this way.

> >and then there are
> >rather more obscure annotations like SomePBC() that are quite involved.
> >Just to frighten you a bit, you'd also need at some point to do
> >something like pypy/rpython/normalizecalls.py :-)
> 
> I can't really be frightened by something I don't know about nor 
> understand ...

That's the problem, I suppose.  RPython is larger and more delicate than
it seems to be at first.  After a lot of trashed efforts in GenC, we
eventually found out the correct approach, which is:

> >What we have in mind is to support targets like CL by a modified RTyper
> >(pypy/rpython/r*.py); it means that there would be an additional
> >processing step between the graph-with-annotations and the CL backend
> >which would simplify the graphs and replace complex operations and
> >annotations with more primitive ones.  This will make the task of the
> >backend far easier.

Compare the flow graphs after annotation and after rtyping (e.g. with
(Continue reading)

Permalink | Reply |
headers
Aurélien Campéas | 1 Oct 2005 21:58
Picon
Favicon

Re: Re: Project suggestions

Armin Rigo a écrit :
> Hi Aurelien,
> 
> On Sat, Oct 01, 2005 at 02:44:50PM +0200, Aur?lien Camp?as wrote:
> 
>>I would tend to provide a huge prelude implemeting a close aprox. of 
>>those in CL (it is my plan).
> 
> 
> Yes, this would be possible.  I suppose even dark corners like
> dictionary with user-specified ways of computing the hash of keys could
> be done this way.

Yes, thru sxhash probably

Well, rarely used obscure corner cases are not my priority, I need to 
get going on to more basic stuff :)

> 
>>>and then there are
>>>rather more obscure annotations like SomePBC() that are quite involved.
>>>Just to frighten you a bit, you'd also need at some point to do
>>>something like pypy/rpython/normalizecalls.py :-)
>>
>>I can't really be frightened by something I don't know about nor 
>>understand ...
> 
> 
> That's the problem, I suppose.  RPython is larger and more delicate than
> it seems to be at first.
(Continue reading)

Permalink | Reply |
headers
Armin Rigo | 1 Oct 2005 22:23
Favicon

Re: Re: Project suggestions

Hi Aurelien,

On Sat, Oct 01, 2005 at 09:58:00PM +0200, Aur?lien Camp?as wrote:
> Yes, i'm sorry, the rpython stuff is currently beyond me and will remain 
> so for a while. The current value of pypy for me is the existence of a 
> nice python source code -> AST transformer usable from python.

That's rather a by-product.  The basic source code -> AST transformer is
already in the standard Python library, where it's available with a
simple 'import compiler'.  We just cleaned up a bit (or rather a lot, as
it was quite buggy).

> As a final by-product of this work, i'd like to get an embedded-in-lisp 
> python compiler.
> Someone earlier said it was not a goal of pypy to proceed like that. 
> We'll see.

I'm sorry I scared you off flow graphs.  I can only refer you again to
Michael's e-mail earlier in this thread.  People commonly underestimate
the problems he mentioned; this has led to a number of projects of
Python-in-Insert-Language-Here, all aborted for basically the same
reason: the basic built-in types and semantics are easy enough, but
supporting the complete Python semantics is rather more involved and
impossible to add incrementally on top of a simple and fast approach.

PyPy is born from realizing this; we (painfully) wrote the complete
semantics once and won't start duplicating that logic.

Instead, we rewrite support for the infinitely simpler RPython
semantics, and even then we try to share code between back-ends (which
(Continue reading)

Permalink | Reply |
headers
Armin Rigo | 2 Oct 2005 10:50
Favicon

Re: Re: Project suggestions

Hi,

On Sat, Oct 01, 2005 at 10:23:31PM +0200, Armin Rigo wrote:
> Anyway, instead of hand-waving, I guess we really need to implement a
> non-C back-end soon enough, just to show that we *can*.  It's the whole
> point of the rather complicated translation architecture we've built.

BTW, I didn't forget LLVM here -- LLVM is very similar to C.  I meant
that we are missing a back-end for a higher-level language that comes
with its own complex VM, with its own concepts closer to RPython -- e.g.
the RPython strings, instances and classes typically have more direct
equivalents.

A bientot,

Armin
_______________________________________________
pypy-dev <at> codespeak.net
http://codespeak.net/mailman/listinfo/pypy-dev
Permalink | Reply |
headers
Aurélien Campéas | 2 Oct 2005 03:02
Picon
Favicon

Re: Re: Project suggestions

Armin Rigo a écrit :
> Hi Aurelien,
> 
> On Sat, Oct 01, 2005 at 09:58:00PM +0200, Aur?lien Camp?as wrote:
> 
>>Yes, i'm sorry, the rpython stuff is currently beyond me and will remain 
>>so for a while. The current value of pypy for me is the existence of a 
>>nice python source code -> AST transformer usable from python.
> 
> 
> That's rather a by-product.  The basic source code -> AST transformer is
> already in the standard Python library, where it's available with a
> simple 'import compiler'.  We just cleaned up a bit (or rather a lot, as
> it was quite buggy).

Well I'm glad Pypy brings that :)

> 
> 
>>As a final by-product of this work, i'd like to get an embedded-in-lisp 
>>python compiler.
>>Someone earlier said it was not a goal of pypy to proceed like that. 
>>We'll see.
> 
> 
> I'm sorry I scared you off flow graphs.  

You didn't ; only pointed compactly some of the complexity one perceives 
reading the code. I need an understandable entry point anyway, so 
beginning with the "easy" stuff and rediscovering already known mistakes
(Continue reading)

Permalink | Reply |
headers
Armin Rigo | 2 Oct 2005 11:23
Favicon

Re: Re: Project suggestions

Hi Aurelien,

On Sun, Oct 02, 2005 at 03:02:48AM +0200, Aur?lien Camp?as wrote:
> >Instead, we rewrite support for the infinitely simpler RPython
> >semantics, and even then we try to share code between back-ends (which
> >is the purpose of the RTyper).  Using the RTyper is not mandatory for
> >back-ends, but you definitely cannot analyse RPython code from the AST
> >for the good reason that it's a language without source code.
> 
> Can you expand on this ? I tend to see the AST as a programmatically 
> manageable representation of the source code. Is this expectation wrong ?

No, you are right, but RPython has neither a source nor an AST
representation:

* first, we take a normal Python program and we import it in CPython.
  During the import, lots of initialization stuff happens.  We may even
  call more initialization functions that will set up more stuff.  This
  phase creates module, class, function and even user instances -- e.g.
  in the case where the normal Python program is the PyPy interpreter,
  we build a complete object space during this phase, which is highly
  non-trivial and creates a lot of instances of our own classes,
  referencing each other in complex ways.

* if all this is carefully done, then the resulting set of objects
  (classes, functions, prebuilt instances) may conform to the RPython
  rules.  This is what an "RPython program" really is: it's a point in
  time, a snapshot, a set of objects referencing each other in such a
  way that the functions left in this set of objects will no longer
  perform dynamic stuff after this point in time.
(Continue reading)

Permalink | Reply |

Gmane