Basic compilation example (a + b)?
Jeff Clites
(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
Leopold Toetsch
> 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.
> JEff
leo
Jeff Clites
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
Leopold Toetsch
> % cat pythonClass.py
> class A:
> def __add__(x,y) : return "boo"
Only a few standard methods are implemented. __add__ IIRC isn't.
> 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.
leo
Jeff Clites
> 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.
JEff
Dan Sugalski
>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