Nathan Torkington wrote:
> Actually, I think I'd like to see this extended. I'd like to be able
> to hook into the parser so that when it sees a function call:
>
> foo()
>
> I can have it call my subroutine.
>
> foo_handler( $token_stream )
>
> foo_handler can access the token stream that may or may not be part of
> the argument list, decide what is, and then return the code to be
> executed at runtime (normally just a call to foo()):
>
> sub foo_handler {
> return sub { foo() }; # *not* an infinite loop, please
> }
>
> The anonymous subroutine returned by the foo_handler() is then inlined
> into the optree.
The above is very, very similar to the effect of defining foo as an
"immediate" sub, per RFC 18.
> Perhaps this is no longer the point at which we think of it as
> autoloading, but rather as part of the compilation process. Just as
> we can intercept strings and regexes with overloaded strings and
> regexes, this would let us intercept functions.
That's the sense in which RFC was defined. This is one of the things that has
given FORTH so much extensibility. I'd vote for RFC 18. It would also let me
implement RFC 229 as approximately... depending on how the "parameters" to the
immediate sub are dealt with at immediate time (you called it token stream,
and that's probably the right word, or compile time parameters... I think the
need is for the text of the parameters, not the values: call by name not call
by value or reference.)
sub interpolate : immediate { return qq/eval "qq\000"/.join('',@_).qq/"\0"/; }
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_____NetZero Free Internet Access and Email______
http://www.netzero.net/download/index.html
