[pypy-dev] Support for __getitem__ in rpython?

[Paolo Giarrusso]

On Tue, Dec 23, 2008 at 15:59, Antonio Cuni <anto.cuni at gmail.com> wrote:
> Paolo Giarrusso wrote:
>
>> There are at least two ways, once you have a singleton (maybe static)
>> None object around:
>> - box all integers and use only pointers - the slow one;
>> - tagged integers/pointers that you already use elsewhere. So integers
>> of up to 31/63 bits get represented directly, while the other ones are
>> through pointers.
>
> I think you are confusing level: here we are talking about RPython, i.e. the
> language which our Python interpreter is implemented in.  Hence, RPython
> ints are really like C ints, and you don't want to manipulate C ints as
> tagged pointer, do you?

I understood the difference, but writing "there's no way to represent
both of them in a machine word" was a statement that prompted me to
write something - actually, I was thinking to just the return
convention of __add__ and __radd__.
If those method start returning NotImplemented or None, any _sound_
static type analysis won't assign type "int" to them, so it looks (to
me, who ignore the content of RPython, I'm aware of that) that it may
be possible to do this without tagging _all_ integers. And there are
examples of compiled languages with tagged integers (I know at least
of OcaML).
But can you currently live in RPython without anything which could be
a pointer or an integer? Can you have a list like [1, None] in
RPython?

Then I wonder how do you get an omogeneous call interface for all
__add__ methods (i.e. how to force the one returning just integers to
also have type NotImplementedOrInteger). And I also wonder if the
RPython compiler can inline the __add__ call and optimize the tagging
away.

That said, I do not know if what I'm suggesting is implementable in
RPython, or if it would be a good idea. Just my 2 cents, since this
might be what Hakan is looking for.

Regards
-- 
Paolo Giarrusso