Re: Auto generated methods (was Re:The S29 Functions Project)
Leopold Toetsch wrote:
No. The above "lowlevel" C isn't aware of C nor of C<$_> and
nothing is autogenerated in Parrot. The C is something like:
class __parrot_core::Float {
multi sub cos(Float x) returns Float ...
}
This is presumably inherited by C (the Parrot PMC) and
bound to:
multi sub *cos(Num $x) returns Num
at the Perl6 level.
That's all fine for the Parrot side of things, AFAICT.
But it doesn't answer my question about how Perl is going to
autogenerate methods, as alluded to in A/S12, and Larry's previous post.
For now, I'm assuming that I can define just the base multi sub, without
all the associated multi methods
-- Rod Adams
Re: Auto generated methods (was Re:The S29 Functions Project)
Rod Adams <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>>the method call in PIR can be written as:
>>
>> d = x."cos"() # normal method call
>> d = Float."cos"(x) # class method, argument shifted down
>> d = P6Num."cos"(x) # same
>> d = cos x # PIR opcode syntax [1]
>> cos d, x # PASM opcode syntax [1]
>>
>>There'll be a table of such builtins with name, namespace, signature, so
>>that the current opcodes can be transparently replaced by methods.
>>
>>
> This looks like it's taking
> multi method Num::cos (Num|Str +$base) returns Num
> and generating
> multi sub cos (Num $x, Num|Str +$base) returns Num
No. The above "lowlevel" C isn't aware of C nor of C<$_> and
nothing is autogenerated in Parrot. The C is something like:
class __parrot_core::Float {
multi sub cos(Float x) returns Float ...
}
This is presumably inherited by C (the Parrot PMC) and
bound to:
multi sub *cos(Num $x) returns Num
at the Perl6 level.
leo
Re: Auto generated methods (was Re:The S29 Functions Project)
Leopold Toetsch wrote:
Rod Adams <[EMAIL PROTECTED]> wrote:
While that's a nice feature to have in general, I feel better about
going ahead and predefining that the builtins are already members of
Num, Str, Array, Hash for the shear performance and documentation values
of it.
That's exactly the plan, when it comes to Parrot. I'd like to have a lot
of function-like opcodes factored out into classes/*.pmc as methods.
Given:
pmclass P6Num extends Float { # the P6Num isa("Float")
...
}
pmclass Float {
METHOD cos() { ... } # return cosine of Float SELF
the method call in PIR can be written as:
d = x."cos"() # normal method call
d = Float."cos"(x) # class method, argument shifted down
d = P6Num."cos"(x) # same
d = cos x # PIR opcode syntax [1]
cos d, x # PASM opcode syntax [1]
There'll be a table of such builtins with name, namespace, signature, so
that the current opcodes can be transparently replaced by methods.
This looks like it's taking
multi method Num::cos (Num|Str +$base) returns Num
and generating
multi sub cos (Num $x, Num|Str +$base) returns Num
Which I believe is the opposite direction of what Larry was doing, and
doesn't seem to address the $_ issue.
Part of me wants get rid of all the C< ?$x = $CALLER::_ >'s and tell
people if they want to use $_, they need to say C< .cos >. Then the
other part of me turns around and beats up the part that thought that.
The other issue in my head is
multi sub split (Rule $r, Str $s, Num +$limit) returns List of Str
I would want the following to be implied from it:
multi method Rule::split (Str $s, Num +$limit) returns List of Str
multi method Str::split (Rule $r, Num +$limit) returns List of Str
So what I'm thinking of for a solution is to have a
my Foo $bar;
$bar.baz;
call that gets past all the Foo AUTOMETHs is to then scan all the subs
in scope named baz, find the one with a required parameter of type most
compatible to Foo, ties being broken by appearing earlier on the
parameter list, and use that parameter as the invocant.
-- Rod Adams
Re: Auto generated methods (was Re:The S29 Functions Project)
Rod Adams <[EMAIL PROTECTED]> wrote:
> While that's a nice feature to have in general, I feel better about
> going ahead and predefining that the builtins are already members of
> Num, Str, Array, Hash for the shear performance and documentation values
> of it.
That's exactly the plan, when it comes to Parrot. I'd like to have a lot
of function-like opcodes factored out into classes/*.pmc as methods.
Given:
pmclass P6Num extends Float { # the P6Num isa("Float")
...
}
pmclass Float {
METHOD cos() { ... } # return cosine of Float SELF
the method call in PIR can be written as:
d = x."cos"() # normal method call
d = Float."cos"(x) # class method, argument shifted down
d = P6Num."cos"(x) # same
d = cos x # PIR opcode syntax [1]
cos d, x # PASM opcode syntax [1]
There'll be a table of such builtins with name, namespace, signature, so
that the current opcodes can be transparently replaced by methods.
I'm not quite sure if the same scheme should apply to:
op cos(out NUM, in NUM)
i.e. to opcodes that take natural types. But eventually such opcodes can
be recompiled inline with the help of the JIT subsystem, so that there's
no function call overhead at all. For now they probably remain as
opcodes.
> The other problem with case 5 is that the long name would be &cos<>, not
> &cos, since the first parameter is optional. So you'd have to
> expand the search beyond just the long name, which can get expensive.
The method lookup will be done just once per call site, it shouldn't
really matter.
> -- Rod Adams.
leo
[1] PMC versions aren't implemented
Auto generated methods (was Re:The S29 Functions Project)
Larry Wall wrote: On Sun, Mar 13, 2005 at 01:15:52AM -0600, Rod Adams wrote: : =item multi sub cos (?Num) returns Num : : =item multi method Num::cos () returns Num It would be nice if we could just say the first implies the second. I guess what that effectively means is that even if you take the default, it's only the value that's optional, not the type. And, in fact, you'd have to put the ? on the variable, not on the type, so you might write those =item multi sub cos (Num ?$n = $CALLER::_) returns Num instead. Let me see if I'm following this correctly. What you're saying is that when you do: my Foo $bar; $bar.baz(...); Perl performs the following searches for baz(): 1) Foo and it's MMD table 2) Foo's isas and roles 3) Foo's AUTOMETH/AUTOLOAD 4) Foo's isas' and roles' AUTOMETH/AUTOLOAD 5) look in current scope for a &baz 6) AUTOSUB/AUTOLOAD &baz In case 5, you'd then be creating a temporary (sub lexical?) method that's a curried form of &baz, and then call it. While that's a nice feature to have in general, I feel better about going ahead and predefining that the builtins are already members of Num, Str, Array, Hash for the shear performance and documentation values of it. And can't it be implemented as a straightforward: multi sub cos (Num ?$x = $CALLER::_, Num|Str +$base) returns Num &Num::cos<> := &*cos<>.assuming:x($self) hmm. Not sure about that currying there, since I'm trying to assume the invocant. The other problem with case 5 is that the long name would be &cos<>, not &cos, since the first parameter is optional. So you'd have to expand the search beyond just the long name, which can get expensive. hmm. I'm not sure I'm seeing all the pieces here. -- Rod Adams.
