> 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)?

Larry spoke of a double entry point to every Perl function, at least.
The first is the "untrusted" entry point, which would do checking and
all of that.  The second is the "trusted" entry point, which the
compiler can call if it knows for sure everything is right, so time
isn't wasted checking.  I don't know how much you want this to affect
the imcc level.

It would be nice to have everything prototyped, actually.  Every sub
would also have an unprototyped entry point by a different name, which
would convert things to the way the prototyped sub wanted them.

In fact, it's probably a mistake to think that the sub itself knows
whether it's prototyped or not.  It's really the caller who should be
saying that (consider a perl sub defined in the middle of a file,
unprototyped above, prototyped below).

Luke

> 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))
> 
> 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.
> 
> 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?
> 
> Thanks,
> leo

Reply via email to