AUTOLOAD, this time distinct from AUTOSUB etc (and spelt correctly)
OK, that last discussion was productive, but I think we all (including myself) overlooked the fact that the AUTOLOAD and AUTOSUB methods are implied to have different calling conventions; There is still an AUTOLOAD hook that behaves as in Perl 5. The (AUTO*) routines are expected to return a reference to an object of the proper sort (i.e. a variable, subroutine, or method reference), or undef if that name is not to be considered declared. So, here are the prototypes of the (new) AUTO* methods: subtype Symbol of Str; sub AUTOSCALAR( Symbol $sym ) returns Ref of Scalar; sub AUTOARRAY ( Symbol $sym ) returns Ref of Array; sub AUTOHASH ( Symbol $sym ) returns Ref of Hash; sub AUTOSUB ( Symbol $sym ) returns Code; sub AUTOMETH ( ::$type: Symbol $sym ) returns Code(::$type: *); uh-oh, another sticky one; the implication is that AUTOMETH has an invocant, which is either a Type or the object, and is expected to return a sub whose signatute has the right type, but we don't care to type check anything more than the invocant type. And that's even before we look at MMD, so for now we'll think of it as; sub AUTOMETH ( Symbol $sym ) returns Ref of Code; So, those are all well and good. They can still do anything, including return little micro-subs that perform arbitrary munging of the argument stack before passing them on, or define the sub/variable that was referred to, to avoid the AUTOFOO call the next time around. And they're being invoked at compile time so that we can get their signatures, but that isn't a problem with people doing selective loading because they're clever enough to know what to do. Great, we can all start using those. But what about AUTOLOAD? It has to behave as in Perl 5, which had different calling conventions and expected you to make the loaded function call yourself. This has some side-implications; the signature used for a Class' AUTOLOAD will be used as the signature for all unknown function calls; so, defining; sub AUTOLOAD { ... } Will forfeit your right to apply signatures to the arguments of an auto-loaded method, which is probably an acceptable penalty for someone who is just expecting P6 to work like P5 did. Method calls, too. 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? Sam.
Re: AUTOLOAD, this time distinct from AUTOSUB etc (and spelt correctly)
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)
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.