Re: Basic compilation example (a + b)?

[Jeff Clites]

On Nov 8, 2004, at 2:47 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
What pasm is supposed to correspond to this snippet of Python code
(assume this is inside a function, so these can be considered to be
local variables):

        a = 7
        b = 12
        c = a + b
Run it through pie-thon. It should produce some reasonable code. For
leaf-functions (w/o introspection i.e. calls to locals()), the lexical
handling would get dropped. And a better translator would use lexical
opcodes by index and not by name.
It doesn't do-the-right-thing in the cases I'm interested in:
% cat pythonClass.py
class A:
        def __add__(x,y) : return "boo"
x = A()
y = x + 3
print y
% python pythonClass.py
boo
% perl pie-thon.pl pythonClass.py | ./parrot --python -
Can't find method '__get_number' for object 'py::A'
It looks like it's trying to get the float-value of x, rather than 
calling x's __add__ method.

But the part I was really wondering about is the "a + b". This is what 
pie-thon.pl produces for that (you can just run it on the code fragment 
"a + b"--it doesn't matter the context):

        $P1 = new PerlInt               # BINARY_ADD
        $P1 = a + b
corresponding pasm:
        find_global P18, "a"
        find_global P17, "b"
        new P16, 32      # .PerlInt
        add P16, P18, P17
That's what worries me, and what prompted the question. You don't know 
at compile-time that the return type should be a PerlInt. It could be 
anything--it's really up to "a". This is regarding my concern that the 
p_p_p ops aren't very useful (in Python at least), and I can't figure 
out what we should be using instead.

So I'm still left wondering, how *should* this compile?
JEff