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
Just a basic compilation question, brought to mind by a recent thread, because the answer isn't obvious to me.
Jeff Clites <jcli...@mac.com> 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.
On Nov 8, 2004, at 2:47 AM, Leopold Toetsch wrote:
> Jeff Clites <jcli...@mac.com> 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?
On Nov 8, 2004, at 11:42 PM, Leopold Toetsch wrote:
> Jeff Clites wrote:
>> 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.
> Yes, I've already stated that this needs fixing and I've proposed a > scheme how to fix it.
Fine then, but in the scheme you recently mentioned, you were explicitly null-ing out the return register. That shouldn't be needed--unnecessary overhead. That is, unless we're assuming the semantics of references types--that the return register would hold a reference object to store into, always. But I don't think we can mix the behaviors--unless there's some special flag on a PMC to indicate that it's a reference type, but that seems awkward. But since the pie-thon output doesn't do that, I'll assume the plan is not to use such reference types, if that's meant to be the canonical example.
>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.
Right. PerlInt is wrong. The destination type for the intermediates should be Undef, which changes itself on assignment to the proper type. -- Dan
--------------------------------------it's like this------------------- Dan Sugalski even samurai d...@sidhe.org have teddy bears and even teddy bears get drunk
