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
