Leopold Toetsch wrote:
>
> Above Parrot interface function tries to locate Sub objects in the
> namespace of the invocant's class and in the MRO of it. When you go back
> to the PIR translation of your code there is e.g.
>
> class Foo:
> def g(self,y):
>
> I have translated this to:
>
> .
On Wed, 24 Aug 2005, Sam Ruby wrote:
[huge cut]
> Below is from the sample that Leo provided.
>
> > # print foo.f(2)
> >
> > # emulate python find_name, which checks attributes too
> > push_eh m_nf
> > $P0 = foo."f"(2)
> > clear_eh
> > goto m_f
> > m_nf:
> > # getattri
On Aug 24, 2005, at 23:34, Sam Ruby wrote:
Leopold Toetsch wrote:
Note that you would then be caching the results of a curried function
call. This result depends not only on the method string, but also on
the particular object upon which it was invoked.
No the "inner" Parrot_find_method_
Leopold Toetsch wrote:
>
>> Note that you would then be caching the results of a curried function
>> call. This result depends not only on the method string, but also on
>> the particular object upon which it was invoked.
>
> No the "inner" Parrot_find_method_with_cache just caches the method fo
On Aug 24, 2005, at 19:45, Sam Ruby wrote:
Leopold Toetsch wrote:
Sam Ruby wrote:
The return value is a callable sub.
More precisely: a curried function call. This is an important
distinction; to see why, see below.
A callable sub may be of course a curried one - yes.
The interest
Leopold Toetsch wrote:
> Sam Ruby wrote:
>
>> Leopold Toetsch wrote:
>
>>> A stripped down PIR-only, pythonless translation is below.
>
>> (example: classes aren't global in Python),
>
> Yes, of course. The stripped down means essential the absence of any
> lexical handlings. But as you say,
Sam Ruby wrote:
Leopold Toetsch wrote:
A stripped down PIR-only, pythonless translation is below.
(example: classes aren't global in Python),
Yes, of course. The stripped down means essential the absence of any
lexical handlings. But as you say, this doesn't matter for these sub and
m
I agree this following would be cool.
However in the general case this type of code inference is HARD to do.
I believe that the optimizations you are looking for would require a
combination of type inference and graph reduction.
PyPy may be the eventual answer.
Don't get me wrong, I think it is gre
Leopold Toetsch wrote:
> Sam Ruby wrote:
>
>> Let me try again to move the discussion from subjective adjectives to
>> objective code. Consider:
>
> [ example code ]
>
>> If you run this, you will get 1,2,3.
>>
>> When called as a function, f will return the value of the second
>> parameter. W
Sam Ruby wrote:
Let me try again to move the discussion from subjective adjectives to
objective code. Consider:
[ example code ]
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 nee
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 cert
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
> decl
Leopold Toetsch wrote:
>
> On Aug 23, 2005, at 22:48, Sam Ruby wrote:
>
>>> From December 16, 2004:
>>
>> http://tinyurl.com/8smmq
>
> Sounds like a really ugly misunderstanding, the more that I've proposed
> not to pass the object (P2 in old parlance) out of band. I've stated
> several times
On Aug 23, 2005, at 22:48, Sam Ruby wrote:
From December 16, 2004:
http://tinyurl.com/8smmq
Sounds like a really ugly misunderstanding, the more that I've proposed
not to pass the object (P2 in old parlance) out of band. I've stated
several times that calling conventions need changes to
Chip Salzenberg wrote:
> I apologize to Leo for accidentally making this reply to the list.
> It was supposed to be private mail, but I hit 'y' just a _little_
> too soon. I had no intention of embarassing anyone. Sorry.
You did, however, cause me to cancel the email I was composing. If
people
I apologize to Leo for accidentally making this reply to the list.
It was supposed to be private mail, but I hit 'y' just a _little_
too soon. I had no intention of embarassing anyone. Sorry.
On Tue, Aug 23, 2005 at 01:04:58PM -0700, Chip Salzenberg wrote:
> On Tue, Aug 23, 2005 at 09:58:21PM +0
16 matches
Mail list logo
