On Wed, 12 Nov 2003, Leopold Toetsch wrote:
> 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.
YHO would be incorrect here. There's a lot of runtime mutability, and
there's no guarantee that a sub or method has the same prototype at
runtime that it did at compiletime. (Though arguably methods are less of
an issue, as method signatures will almost never be known at compiletime)
> 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.
Which is fine for all-PMC calls. Its the ones with mixed types that I'm
concerned with.
> > 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 ...
All of which live at a somewhat higher level than this.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
