with "wantarray" and "ref" we have polymorphism but it has to be very late.
During official RFC time I (and others) suggested ways to do polymorphic
optimizations early, like in C/C++.
A few days ago I came up with a way to defer the optimization but make it
if it is needed, entirely under programmer control.
This method relies on subroutine calls getting clarified to (1) a jump/return
point and (2) a subroutine address. The idea is, to expose the subroutine
address programmaticly, and introduce a new keyword ("become") which would
be used to not only make the current routine call call a different routine,
as with the &NAME version of subroutine calls, but sets \&NAME as the
routine which will be called directly the next time the point in the code
tree which brought us here gets called.
This might be best to include into the language not as a new keyword, but
as a new read/write attribute of the "caller" object. "become" would then
simply be shorthand for something like
caller->subroutine_called = \&NAME;
&NAME;
This kind of thing would also allow the constant optimization to appear
late, when the programmer knows the values will change no longer, for
instance.
It would also be most handy to have semantic analysis tools available
to peek back up the context to see if a particular argument is blessed
to a (trivially) lexically predictable type.
This way, the optimization/selection of different subroutines with the same
name could happen without introducing a language of extended prototypes.
Situatations where it is clear which routine is needed would not have
to bother with the selection code every time through,
the situations triggering optimization would be up to the programmer.
According to the Kraaske-Trump theorem, RFC period will never really end.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Send $25.00 for handy leaflet on how to make money selling leaflets
