On Fri, Sep 15, 2000 at 03:11:47PM -0600, Nathan Torkington wrote:
> Perl6 RFC Librarian writes:
> > This RFC proposes two-stage autoloading: one stage may be registered
> > to act when the symbol is encountered at compile time, the other
> > when the subroutine is called. Autoloading on the second stage does not
> > I<call> the subroutine, only I<loads> it.
>
> You have a beautiful mind, Mr Zakharevich. I'd like to frame it on my
> wall.
I can see that the nail that attaches it to my wall is already shaky...
When it is falls down, feel free to pick it...
> 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
> }
This is just a user-defined operator (which see on p5p). You register
foo() as a user-defined operator (with the precedence/etc of a
function call - or of a unary or nullary function). Then your handler
gets the OP trees for the arguments.
By the way, if you do not need to inspect the argument OP trees at
compile time, you may extend the discussed proposal to allow the
compile-time action to return EITHER prototype, OR a subroutine
reference.
Getting arguments at compile time is tricky: you cannot get them
unless you know the prototype already. RFC18 and user-defined
operators avoid this since they specify the prototype *before* the
call is encountered.
> Context-coercion:
>
> sub foo_handler {
> my $token_stream = shift;
> my $arg_1 = $token_stream->next; # assuming passed as strings?
> return eval "sub { scalar($arg_1) }";
This is the part of my proposal for user-defined-operators: you can
force context for your arguments. Keep in mind that UDO are at least
partially orthogonal w.r.t. RFC18: they see already compiled trees
(but can modify them if needed), and not the string arguments.
This is the problem with RFC18: you cannot "partially compile"
things. How many arguments for f() in
f($a, $b, g my $c, $d);
3 or 4? This depends on the arity of g(). But you cannot find this
arity until you compile the call frame for g(), and then lexical $c is
already introduced! So you cannot make f() to be a "comment", just
the act of determining the arguments to f() has side-effects.
Ilya
