Dan Sugalski <[EMAIL PROTECTED]> wrote: > The reason to have them is compile-time uncertainty about call and return > types. Since we can't safely know with certainty what the definition of a > sub or method is, we need to pass into the sub/method a notation of what > parameters its getting. Otherwise we can run into the case where a sub is > expecting, say, three int and three string paramters but gets passed in > three num and one string parameter instead.
I,N,S are only used, if the call is prototyped. When its prototyped, registers are setup accordingly, that's it. Some run-time property with the signature can't help here. Registers have some value or not. There is no way to check, it something matches. All the checks are at compile time IMHO. When PMCs are passed, scalars get morphed to the appropriate type. When e.g. a Sub is passed, and the subroutine awaits a scalar only, the inexistent vtable pmc->get_<type> will catch this kind of error. > There's also the vararg issue ... and pass by value, r/o, by ref, copy and whatnot. Plus named arguments and pie-thonic default arguments, if a param is missing ... > I'll put together a proposed patch for PDD03 and post it to the list, and > we can hash it out. Good. > Dan leo
