hi,

I've been playing a bit with the new set_*/get_* ops that implement the new calling conventions, according to pdd03.

If the number of passed arguments is larger than the number of parameters the function takes, an exception is thrown (this is the overflow case described in PDD03) (except when the final target is a P register with the FLATTEN bit, then it just works like "foldup")

I wonder what the reason is to throw an exception. With dynamic languages, you can't be sure what function you are calling (you can set them dynamically, I must admit I don't know Perl, and therefore don't know if this is an issue with Perl). Wouldn't it be easier to just discard the values that are passed to the function? Obviously, the function has only use for the number of parameters it has defined, so it doesn't care about the extra values.

(I know, one could just put an extra P target in all function definition -- with the FLATTEN bit set --, and this exception wouldn't occur, but this seems a bit a waste of copying the args to the targets, another possibility is to catch the exception and do nothing, but that too, is not very efficient I think).

The same is true for underflow: why wouldn't you just set the targets for which there is no value left (so too few arguments were passed) to None?



Yet another question, but not directly relating to the new pdd03, but in fact a question in general wrt calling conventions: pass by ref/pass by value.

If I understood correctly, I, N and S registers are passed by value, but P registers are passed by reference. I couldn't find any possibility to pass PMCs by value; one would have to create a new PMC in the called subroutine, and _assign_ the passed-in argument to this newly created PMC. This may of course be the desired behaviour for Perl and friends, but wouldn't it be neat to have a possibility to pass PMCs by value as well? (This could easily be indicated by the flags of the new opcodes set_args/returns and get_params/results, I think).
This possibility would make Parrot more general.

Kind regards,
klaas-jan







Reply via email to