On Monday 03 September 2001 10:46 pm, Dan Sugalski wrote:
> At 10:32 PM 9/3/2001 -0400, Bryan C. Warnock wrote:
> >On Monday 03 September 2001 10:27 pm, Dan Sugalski wrote:
> > > >To me, that seems only a language decision. This could certainly
> > > > handle that.
> > >
> > > Ah, but calling in the first way has two PMCs in as parameters, while
> > > the second has only one. Potentially at least. A world of difference
> > > there.
> >
> >A single PMC? (A list of pointers to PMCs?)
> >
> >Or, to think of it another way, how are you going to pass two scalars, or
> > an array of two scalars, to a sub with *no* prototype?
>
> We create a list, stuff our bits into the list, and pass the list. @_ will
> point to the list.
>
> Lists can access their contents as if they were a list of scalars even if
> they're not. (So we can avoid flattening in cases we don't need to)
>
Well, then that's how. Remember, this prototype idea, besides allowing
automatic variable setting and such, was really just a musing on how to get
prototype checking at runtime, where compile-time checking isn't possible.
{
my $a = sub ($$) { code };
gork($a);
}
sub gork {
my ($a) = shift;
$a->(@some_list); # <- Here
}
The reason prototypes aren't checked at "Here" is because there really isn't
a way to know what the prototype was. So you're just passing the list like
you normally would. Having the prototype checking code as part of the code
doesn't change anything above at all.
In other words, you can't think about how a prototype would affect the
calling convention, because, by definition, you don't know of any prototype
unless is a direct named sub call that you've checked at compile time.
Of course, I suppose that by default the runtime checking would be done even
for sub calls that have been compiled-time checked... Which defeats the
second purpose of compile-time checking (saving time during the run), but I
think we can find away around that...
--
Bryan C. Warnock
[EMAIL PROTECTED]
