Re: AUTOLOAD, this time distinct from AUTOSUB etc (and spelt correctly)

2005-06-20 Thread Rod Adams

Sam Vilain wrote:



It seems these requirements are still in conflict;

   - Preserving AUTOLOAD thou-shalt-make-the-call semantics
   - Keeping the new $AUTOLOAD off the argument stack for AUTOLOAD()
   - Use of $_ as an out-of-band way of passing arguments to a function
 cannot be localised due to the non-stack-like characteristic of
 the call stack, in the face of continuations and coroutines
   - disallowing explicit out-of-band arguments

Time to re-think the out-of-band arguments idea?



I never liked the idea of out-of-band arguments. Either something is 
passed, is available due to being in a broader scope, or can be gleamed 
from introspection.


In this case, I think introspection is the answer. Hang the info off 
?SUB or caller. Something like ?SUB.Invocation or caller.call 
could be made to return something useful, I think. Also makes the info 
available for more than just AUTO.* methods, which opens the door up for 
all kinds of useful perversions, especially in the age of bindings and such.


I leave the definition of something useful to others.

-- Rod Adams



Re: AUTOLOAD, this time distinct from AUTOSUB etc (and spelt correctly)

2005-06-20 Thread Sam Vilain

Rod Adams wrote:
I never liked the idea of out-of-band arguments. Either something is 
passed, is available due to being in a broader scope, or can be gleamed 
from introspection.


ok.  First of all, I agree with the basic sentiment.

However, to play devil's advocate and re-interpret what you just said, it
does imply that there are some implicit lexicals being passed around -
? twigil variables.

These are effectively out-of-band arguments to a function, but not user-
modifyable.

So what we're saying is that out-of-band arguments must be passed via
language/grammar special variables, so to do that from Perl code you'll
have to extend the interpreter, quite a challenging task at present.
That'll stop them being used Where We Don't Want Them To Be Usedâ„¢.  :-

In this case, I think introspection is the answer. Hang the info off 
?SUB or caller. Something like ?SUB.Invocation or caller.call 
could be made to return something useful, I think. Also makes the info 
available for more than just AUTO.* methods, which opens the door up for 
all kinds of useful perversions, especially in the age of bindings and 
such.


Sure.  Structurally, and architecturally, I like this too.
But syntactically, $?LASTQUOTEDPARA.idea is a little overweight.  But no
big problem.

Perhaps the problem here is that sometimes you want to explicitly
specify which available lexical variable the topic refers to on an
arbitrary block.

Personally I'm of the leaning that there is no global $_ at all. There is
no such thing as a global topic of a program, after all.  I don't think
I'm contradicting the Synopses there, either.  ie, in the main program $_
should not be in scope.

In this manner, $_, instead of actually being a real variable, is simply
an alias which always has lexical scope and happens to be normally bound
to $?SELF in method calls, and to @_[0] in bare blocks, and an anonymous
temporary variable in for loops.

And in AUTOLOAD blocks, it's bound to the $?SUB.called_as (or whatever)
lexical, out-of-band variable.

But how does that happen?  What makes the AUTOLOAD sub special to get
this action?

Clearly, we don't want people to have to explicitly say so in their
AUTOLOAD signature:

  sub AUTOLOAD($_ = $?SUB.called_as) {

  }

Plus, the above still wouldn't do what we want because it's still
specifying a positional argument.

I'm seeing something like this; however it's still a bit awful for
various reasons.

  package Package;
  sub dispatcher {
  ...
  %symtable::AUTOLOAD.assuming($_ = $method)(@args);
  ...
  }

Perhaps it is simply a mistake to assume that the package dispatcher
will itself be simple, accessible Perl like that.

Anyone got any bright ideas?  :)

Sam.