Okay, I've lost any free time I might have and the discussion's
gotten to the point where it's obvious that we're not going to get
anywhere. So, this is what we're going to do:

1) The changes I proposed are going in. We get arg counts for I/S/N
registers if they're used. Everyone can cope. (You may, if you
choose, whine about it for a bit--that's OK, if somewhat unbecoming)

2) I'm adding in an alternate, link-time, non-overridable subroutine
call sequence. This is for routines which may not change in any way
at runtime. They may or may not be sub-PMC based. Probably not. This
will cause some issues with perl/python/ruby code that would choose
to manipulate the subs, but there are ways around it, and people can
cope.

3) We're going to add some metadata (virtually to start) to note
library versions, sub signatures, and whatnot so we've some chance of
catching signature errors (which usually indicate a deeper versioning
problem) at link and, hopefully, runtime.

Not much more to say about #1 than "I disagree", and I think we've
dealt with that problem.

#2 will introduce, I think, a:

   call X, Y

op, where X is the start of the bytecode to call and Y is the
bytecode segment header, or something like that. *NOTE THAT THIS IS
NOT SET IN STONE!* or mud even. I'm fine with a completely different
format. Anyway, X and Y are resolved at link time which, for us, is
bytecode load time. (Unless we bring in a linker. Maybe for V2)

Since these are essentially addresses which are resolved at link time
there's no way that they can be overridden, which is arguably a Bad
Thing. Certainly will get in the way of folks looking to do exactly
that. Well... too bad. Wrap the non-overridable version in an
overridable version and be done with it.

#3 is going to be important so we can have signatures that we can
reliably mark as non-overridable (though I suppose just properties on
the sub PMCs that the compiler can note is OK. Still, we need to
define those), floor values for library versions so people can note
breaks in compatibility, signatures on functions and subs, *versions*
on subs and functions (potentially) all will be useful to make sure
that we can, hopefully, have some chance of noting that things have
changed.

Oh, and we need to make sure that the global stash that we're using
to store subs checks function signatures when existing
subs/methods/whatever are overridden, because we need to be able to
pitch a fit if that's the case, even if we don't complain by default.
--
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk