Chip Salzenberg wrote:
> On Tue, Aug 23, 2005 at 07:15:41PM -0400, Sam Ruby wrote:
>
>>Leopold Toetsch wrote:
>>
>>>I've stated several times that calling conventions need changes to
>>>properly support HLLs with minor success at these times.
>>
>>With the diversity of HLLs out there, I'm not certain that it is wise to
>>declare one set of semantics "proper", thereby implicitly declaring all
>>others "improper".
>
> Well, let's try "more coherent and less confusing", then, or maybe
> just "better". HLLs don't have to expose the 'self' parameter if
> they don't want to. Just extract it into a PMC register that's
> never used.
Let me try again to move the discussion from subjective adjectives to
objective code. Consider:
def f(x,y):
return y
class Foo:
f = f
def g(self,y):
return y
foo = Foo()
g=foo.g
print f(0,1)
print foo.f(2)
print g(3)
If you run this, you will get 1,2,3.
When called as a function, f will return the value of the second
parameter. When called as a method, the same code will need to return
the value of the first parameter.
I'm open to suggestions as to what PIR code should be emitted by Pirate
to correspond to the above code.
The way this currently works with Pirate and the existing Py*.pmc
closely follows the Python definition, which you can find here:
http://users.rcn.com/python/download/Descriptor.htm#functions-and-methods
To illustrate how this works today, lets consider the call to foo.f(2)
above. This involves both a find_method and an invoke. Lets consider
each in turn:
* pyclass.find_method first calls getprop on "f".
* pyclass.find_method then calls "__get__" on the pyfunc returned,
passing the object on which this method was called on.
* pyfunc.__get__ creates a new PyBoundMeth object, saving both the
original function and the object.
* This PyBoundMeth object is then returned
then:
* pyboundmeth.invoke shifts all registers right, inserts the original
object as the first parameter, and then calls invoke on the original
function.
Needless to say, this doesn't necessarily show off Parrot to its best
advantage from a performance perspective. I tried a number of times to
argue for a combined "find_and_invoke" VTABLE entry as much of the above
can be optimized if you know that result of the find_method will only be
used a single time for an invoke. If you like, you can scan the
archives to see what reception this suggestion received.
Precisely emulating the behavior above is an important part of
distinguishing a "Python-like" language from a true Python language, and
is necessary to pass the b0 pie-thon test (grep for __get__ to see what
I mean).
As to whether this is "more coherent and less confusing", then, or maybe
just "better"... well, lets just say that I'll leave the adjectives to
others.
- Sam Ruby
