Patrick R. Michaud wrote:
Also, I've been working under the assumption that it's generally
better (faster/more efficient) for frequently used integer and
string values to be held and manipulated in I and S registers rather
than PMCs. Perhaps this assumption is invalid.
The assumption is of course true.
=head3 Type Conversions
Unlike the C<set_*> opcodes, the C<get_*> opcodes must perform
conversion from one register type to another. Here are the conversion
rules:
* When the target is an I, N, or S register, storage will
behave like an C<assign> (standard conversion).
However, according to Leo's journal, the I, N, and S registers
do not convert among themselves but instead perform type checking
and throw an exception on mismatches. (cf. "Type checking"
at http://use.perl.org/~leo/journal/25491.)
I've just misinterpreted this para and thought that we convert only
to/from PMCs but not between native types. I'll fix that.
I think it would be much more useful -- and result in cleaner PIR
code -- if all parameters were positional, with Parrot automatically
converting values among the register types as needed, similar to
how Perl (5) handles arguments.
Thanks for the long explanation, showing the troubles of the current
state. The problem mostly arises from the switch of the old scheme to
the new one of course. I found code in libraries that had e.g. call
arguments swapped:
foo(I, S) # .sub foo (S, I)
This worked fine in the old scheme but is of course at least strange, if
you compare it to other programming languages.
So on the way to first fix existing code and tests, type checking isn't
that bad, but wrong still in the long run.
The only sane way to go is strictly positional, with conversions and
maybe optional warnings or errors.
Lastly, while on the topic of calling conventions, has there been
any thought given as to a standard convention for named argument passing
in Parrot subroutines? There are a number of places in PGE where
that would be really useful (and necessary...).
The plan is to support named arguments. There is already a Pair PMC in
the tree for that.
Pm
leo
