Steve Fink <[EMAIL PROTECTED]> wrote:
> Just to be sure we're talking about the same thing:
> sub f ($a, $b, $c) { ... }
> $x = phase_of_moon('waxing') ? \&f : \&CORE::print;
> $x->(3, [EMAIL PROTECTED], [EMAIL PROTECTED]);
I don't expect such contrived functions calls happen too often, but
anyway ...
> i.e., I'm calling f() without a prototype.
> A builtin that took three parameters would expect them in P5, P6, and
> P7. But how do I do that in IMCC for $x->(3, [EMAIL PROTECTED], [EMAIL PROTECTED])?
> I am
> suggesting
> .arg 3
> .args _AV_x
> .args _AV_y
> with some deep magic going on under the hood to get them into the
> correct registers, most probably by means of a new, specialized op
> because the current way of doing it is ugly and slow.
The current way is to flatten @x and @y and pass the 2 lists, that's it.
That is you pass (3, _AV_x[0], ... _AV_x[i], _AV_y[0], ...).
I'm not against a specialized ".args" directive, but first, we need the
"normal" cases. Then, we can think of optimizations.
> You seem to be suggesting something like:
No. My suggestion didn't cover splat arrays. When you don't know, what
sub you are calling, you just have to flatten the splatted args -
currently.
Another question: E6 seems to indicate that splat flattening happens
before parameter binding:
,--[ E6 ]-----------------------------------------------------------------
| This operator (known as "splat") simply flattens its argument into a
| list. Since it's a unary operator, it does that flattening before the
| arguments are bound to their respective parameters.
`-------------------------------------------------------------------------
Before is of course not a definition, when the flattening should happen,
but it seems to indicate, that flattening is done in the caller.
And can the flattening have side effects? What about tied arrary
splats? I can imagine, that the called sub can't flatten the array
because of tieing.
All that stuff has to be defined first, then - when needed - we can
think of optimizations.
leo
