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<Num>, 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
