A few more ideas to put down, lest I lay wake all night, thoughts churning...
One.
Presumably, there will be an op for the actual calling of the subroutine.
That op can take an (extra) argument, with one of three values, that the
prototype checking can get to.
The first value indicates that these arguments were checked at compile time,
and there is no variable wrangling that needs to be done. The runtime
checking would be skipped. So foo($a,$b) calls for sub foo ($$) {} would be
skipped, but not calls by reference, or calls if the prototype was sub foo
(my $a, my $b) {}.
The second value indicates that these arguments have not been checked, check
them now. Inject those variables, etc., etc. This is for calls by
reference, calls where magic assignments need to be made, etc.
The third value is a "peek" value. Do the runtime checking, but don't do
any magic variable stuff. As a matter of fact, don't run any user-code at
all. Simply return a true or false value if the arguments *would* match.
(This allows us to check incoming coderefs, to see that they take the
arguments that *they* expect. Similar to the whole "pointer to a function
that takse a pointer to a function, and an int." Of course, no checking the
return value. But they're supposed to handle your want()s.)
Two.
Secondly, there's another issue with the prototyping code - magic.
Specifically, tied variables, (which some will say aren't magical. They're
pretty magical to me.)
Anyway, to do some checking, one could conceivably (depends on how specific
prototyping could go - you could say something as detailed as (my $a < 4;)
to handle bounds checking on your input as well....) call FETCH on a
variable for which the FETCH is.... what's the word I'm thinking of? - the
FETCH just to check the code could change what the actual value to be used
later on would have been. Like a self-incrementing counter.
Anyway, the tie interfaces need to add a PEEK, which would return what the
next FETCH will return, when it is called. That will allow us to safely
test tied variables without screwing things up.
(Generally speaking, that should probably be done now for exactly the same
reason.)
Three.
We need to decide what happens when someone attempts to replace a prototyped
sub with another sub - whether that sub is not-prototyped, prototyped
exactly the same, or prototyped differently. Multiple dispatch on functions
could alter our approach to the third. Direct calls have already been
attested to at compile time. The call has just changed...
--
Bryan C. Warnock
[EMAIL PROTECTED]
