While trying to implement pdd03 inside the PIR assembler I'm not too sure if I get everything right from pdd03.
Currently I have this:
- a subroutine call can be prototyped or non_prototyped
- a subroutine definition can be both and un_prototyped. In the latter case it checks C<I0> and takes parameters either way.
- return values are prototyped only currently
Q: Should there be code to check the amount and types of function parameters? Always, or on demand (e.g. with a "check_params" in the sub def)?
Always. It's perfectly legal for a sub that gets arguments it doesn't expect, for example if it gets params in I registers and it takes only PMCs, to throw an exception.
Now to return conventions:
Q: Is the prototype specifier for return values independent or is it the same as that in the subroutine definition. Or has that to be checked at runtime (I3 has some info about expected return values, but not really, where to place return value(s))
The return prototype is independent of the paramter prototypes. I think this needs a little fleshing out as well, since the subs need to know what the caller is expecting back, which needs passing in. I'd rather not have to have some sort of hacked up inspection scheme to get the various perl want* parameters.
Q: And finally, how does the caller get the return value(s), again a runtime check of which prototype specifier is having that info?
The same WRT checking applies here.
Caller inspects the registers to see what it was handed back.
I think, parrot/imcc and any HL calling some (external) subroutines need header files, which have the information about function signatures and return values.
Q: Which format (C-like .h files?), in runtime/parrot/include?
I think C-like includes are fine. IMCC can emit typechecking code for PMCs if you want, or we can put that off for later.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
