Re: AUTLOAD and $_
Sam Vilain skribis 2005-06-20 12:54 (+1200):
sub AUTOLOAD($_ = $CALLER::$_, [EMAIL PROTECTED]) {
In a way, $_ forms part of the prototype definition, but is out of band
to the regular arguments on @_; it can't interfere with positional
characteristics, or you have to shift it off before you goto the right
sub.
(...)
Perhaps to avoid that mess, the AUTOLOAD function is simply expected to
call func.goto if it wants all the effects of the presence of the
AUTOLOAD sub to go away. Assuming that the prototype is re-checked on a
goto, to ensure that type guarantees specified in the function signature
are honoured, then the necessary side effects should just happen.
I think there exists an even simpler way to avoid any mess involved.
Instead of letting AUTOLOAD receive and pass on arguments, and instead
of letting AUTOLOAD call the loaded sub, why not have AUTOLOAD do its
thing, and then have *perl* call the sub?
sub AUTOLOAD ($whatever) { # but no [EMAIL PROTECTED]
my $s = get_subref_for $whatever;
our ::($whatever) := $s;
return $s; # non-subref indicates failure
}
If you want to load it again each time, remove the := line.
The line can be shortened to
sub AUTOLOAD ($w) { return our ::($w) = get_subref_for $w }
or just
sub AUTOLOAD { our ::($^a) = get_subref_for $^a }
Re arguments: I think a single positional argument makes more sense than
requiring that its name be $_.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: AUTLOAD and $_
Juerd skribis 2005-06-20 12:11 (+0200):
sub AUTOLOAD ($w) { return our ::($w) = get_subref_for $w }
sub AUTOLOAD { our ::($^a) = get_subref_for $^a }
That's :=, of course.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: proposal: binding with a function
Hi,
I'm still interested in, why alias wouldn't be a native Perl 6 term?
I think, there are several reasons for alias:
- in natural languages, synonims are very often - alias is a synonim
- in Perl 6, currently there's no way to create a reference to a
variable, _with the context of the variable_, too (binding just give
me possibility to bind a variable into another, but the new variable
won't be automatically have the same context, as the binded one)
Some new examples, maybe better than before:
sub kilobytes ($value:) is export {
return $value*1024;
}
alias kilobytes, kilobyte;
So both routines will be an exported one. You can use this code then:
say 1.kilobyte;
say 2.kilobytes;
Bye,
Andras
BÁRTHÁZI András wrote:
Larry,
You can always write a macro that does that.
[...] That won't work on a method name anyway unless you do it in the
dispatch class.
[...]
You'll have to write your own macro if you want to do that.
As I understood, you wrote down, how I can workaround it with macros,
and why it wouldn't work well. As I see, there's no a nice solution to
alias a method or a sub, even with macros.
But you didn't wrote, why are you against the 'alias'?
Bye,
Andras
proposal: 404 method
Hi,
Is there a way, to catch, if I call a method, that doesn't exists, to
run a default one? I'm thinking about an error handler method. If not,
I would like to propose this:
class MyClass {
method example ($self: $var) {
say HELLO;
}
method default ($self: $method_name, %parameters)
is method_not_found {
say $method_name called;
}
}
$mc = new MyClass;
$mc.example(var)
$mc.helloworld(var, var);
--
and it outputs:
HELLO
helloworld called
The above is maybe not the best (and not the most valid) syntax for my
proposal, but I think you can get the idea. It would be very useful the
hide parameters into the method name, like this:
save_the_world();
save_the_captain();
And the default method will match the method name with
/^save_the_(.*)$/, and saves $1.
I hope, you will like it. As I know, it's not possible currently.
Bye,
Andras
Re: proposal: 404 method
BÁRTHÁZI András skribis 2005-06-20 17:18 (+0200): Is there a way, to catch, if I call a method, that doesn't exists, to run a default one? I'm thinking about an error handler method. See all the AUTO subs. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: proposal: 404 method
András,
I think you have just discovered AUTOLOAD :-)
OTOH I don't know how the AUTOLOAD mechanism will work in Perl6 compared
to Perl5, or if it has been imlemented in Pugs (yet), but as far as I
remember, in Apocalypse 12 somewhere it says it will work the same(?) as
in Perl5, and what you have described works in Perl5 (if I understood
you correctly, which might not be the case).
- Fagzal
Hi,
Is there a way, to catch, if I call a method, that doesn't exists, to
run a default one? I'm thinking about an error handler method. If
not, I would like to propose this:
class MyClass {
method example ($self: $var) {
say HELLO;
}
method default ($self: $method_name, %parameters)
is method_not_found {
say $method_name called;
}
}
$mc = new MyClass;
$mc.example(var)
$mc.helloworld(var, var);
--
and it outputs:
HELLO
helloworld called
The above is maybe not the best (and not the most valid) syntax for my
proposal, but I think you can get the idea. It would be very useful
the hide parameters into the method name, like this:
save_the_world();
save_the_captain();
And the default method will match the method name with
/^save_the_(.*)$/, and saves $1.
I hope, you will like it. As I know, it's not possible currently.
Bye,
Andras
Re: proposal: 404 method
Hi, Is there a way, to catch, if I call a method, that doesn't exists, to run a default one? I'm thinking about an error handler method. See all the AUTO subs. Cool! Where? Is it working currently with Pugs? Bye, Andras
Re: proposal: binding with a function
On Mon, 20 Jun 2005, BÁRTHÁZI András wrote:
Hi,
I'm still interested in, why alias wouldn't be a native Perl 6 term?
I think, there are several reasons for alias:
I am not arguing against alias, but just wanted to point out something.
- in Perl 6, currently there's no way to create a reference to a
variable, _with the context of the variable_, too
unless you bind immediately where you declare the original variable:
Some new examples, maybe better than before:
sub kilobytes ($value:) is export {
return $value*1024;
}
alias kilobytes, kilobyte;
replace the last line with:
kilobytes := kilobyte;
and the scoping is not an issue.
And with synonyms, binding as soon as declaring seems prudent.
--abhijit
Abhijit Mahabal http://www.cs.indiana.edu/~amahabal/
Re: proposal: 404 method
BÁRTHÁZI András skribis 2005-06-20 17:34 (+0200): Cool! Where? Is it working currently with Pugs? S10. I don't know how much of that is supported by Pugs. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: proposal: 404 method
On Mon, 20 Jun 2005, BÁRTHÁZI András wrote: Hi, Is there a way, to catch, if I call a method, that doesn't exists, to run a default one? I'm thinking about an error handler method. See all the AUTO subs. Cool! Where? Is it working currently with Pugs? Synposis 10... abhijit Abhijit Mahabal http://www.cs.indiana.edu/~amahabal/
Re: proposal: binding with a function
On 6/20/05, BÁRTHÁZI András [EMAIL PROTECTED] wrote: - in natural languages, synonims are very often - alias is a synonim Perl is modeled on natural languages, but that doesn't mean it is one. At its core, Perl is a limited, artificial language being explicitly designed with certain goals. One of those goals is that it should be as small as possible given the feature set we want it to support; an `alias` built-in that essentially duplicates an existing feature goes against that goal. - in Perl 6, currently there's no way to create a reference to a variable, _with the context of the variable_, too (binding just give me possibility to bind a variable into another, but the new variable won't be automatically have the same context, as the binded one) I'm not sure what you mean by context here. Context has a very specific meaning in Perl, representing the type a function's caller is expecting; this doesn't seem to be what you're talking about here. alias kilobytes, kilobyte; This is a couple punctuation symbols short of: kilobytes := kilobyte; Or maybe: kilobytes ::= kilobyte; I'm not really sure what behavior you have in mind for alias. (By the way, a simple name like alias is ambiguous about argument order, where an operator isn't.) -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: proposal: binding with a function
Hi, - in natural languages, synonims are very often - alias is a synonim Perl is modeled on natural languages, but that doesn't mean it is one. At its core, Perl is a limited, artificial language being explicitly designed with certain goals. One of those goals is that it should be as small as possible given the feature set we want it to support; an `alias` built-in that essentially duplicates an existing feature goes against that goal. I can agree with it, but I think it would be a great feature. And it doesn't depends on Perl 6, but it depends on Parrot, as I think. - in Perl 6, currently there's no way to create a reference to a variable, _with the context of the variable_, too (binding just give me possibility to bind a variable into another, but the new variable won't be automatically have the same context, as the binded one) I'm not sure what you mean by context here. Context has a very specific meaning in Perl, representing the type a function's caller is expecting; this doesn't seem to be what you're talking about here. alias kilobytes, kilobyte; This is a couple punctuation symbols short of: kilobytes := kilobyte; Or maybe: kilobytes ::= kilobyte; I'm not really sure what behavior you have in mind for alias. kilobytes := kilobyte; will not work for you (try it), because you have to declare the variable kilobytes - in the default strict mode. But you can't say for ex. my kilobytes, if you want to export it. I would like to copy if the subroutine/variable is local, or exported, or... etc. Oh, I have the term: I would like to copy the _scope_ of it, too. Forget the context. Simple binding shouldn't have to copy the scope, too. Anyway, alias is a Ruby term, and if Parrot will be able to support Ruby, then it will be able to support this function, too. Bye, Andras
Re: proposal: binding with a function
On 6/20/05, BÁRTHÁZI András [EMAIL PROTECTED] wrote: Hi, - in natural languages, synonims are very often - alias is a synonim Perl is modeled on natural languages, but that doesn't mean it is one. At its core, Perl is a limited, artificial language being explicitly designed with certain goals. One of those goals is that it should be as small as possible given the feature set we want it to support; an `alias` built-in that essentially duplicates an existing feature goes against that goal. I can agree with it, but I think it would be a great feature. And it doesn't depends on Perl 6, but it depends on Parrot, as I think. - in Perl 6, currently there's no way to create a reference to a variable, _with the context of the variable_, too (binding just give me possibility to bind a variable into another, but the new variable won't be automatically have the same context, as the binded one) I'm not sure what you mean by context here. Context has a very specific meaning in Perl, representing the type a function's caller is expecting; this doesn't seem to be what you're talking about here. alias kilobytes, kilobyte; This is a couple punctuation symbols short of: kilobytes := kilobyte; Or maybe: kilobytes ::= kilobyte; I'm not really sure what behavior you have in mind for alias. kilobytes := kilobyte; will not work for you (try it), because you have to declare the variable kilobytes - in the default strict mode. But you can't say for ex. my kilobytes, if you want to export it. So you say `our kilobytes ::= kilobyte` (or `:=`, you still haven't said if alias works at compile time or runtime) and call it a day. IIUC, traits like `is exported` are attached to the container, not the name; since aliasing connects a name to a container, you should be fine on that front. (If it doesn't work, that's because `is exported` does something funky that `alias` would have to treat as a special case; certainly other traits like `is rw` would follow a `:=`-binding.) Anyway, alias is a Ruby term, and if Parrot will be able to support Ruby, then it will be able to support this function, too. As I've said before, Perl supports `alias`--it's just spelled `:=`. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Re: proposal: binding with a function
Hi, kilobytes := kilobyte; will not work for you (try it), because you have to declare the variable kilobytes - in the default strict mode. But you can't say for ex. my kilobytes, if you want to export it. So you say `our kilobytes ::= kilobyte` (or `:=`, you still haven't said if alias works at compile time or runtime) and call it a day. IIUC, traits like `is exported` are attached to the container, not the name; since aliasing connects a name to a container, you should be fine on that front. (If it doesn't work, that's because `is exported` does something funky that `alias` would have to treat as a special case; certainly other traits like `is rw` would follow a `:=`-binding.) Anyway, alias is a Ruby term, and if Parrot will be able to support Ruby, then it will be able to support this function, too. As I've said before, Perl supports `alias`--it's just spelled `:=`. If you're right, then I'm happy. I don't want alias, I would like to get it's behaviour. In Ruby, I think it's a compile time feature, but don't know, I'm not programming in Ruby. I'm not (yet) an expert in Perl 6, so sorry if I'm not right, but is exported is about the name, not the container, as I think. If you attach an is exported to a class method, you can reach it from everywhere, just using it's name. If you say _in your class_ that our mysub ::= exportedsub, then you can reach the mysub sub just in the class, not from everywhere in your program (as a plain sub). I'm really not sure, if I'm right, so please tell me, that I lost, and I will be happy. :) Bye, Andras
Re: AUTLOAD and $_
Juerd wrote:
I think there exists an even simpler way to avoid any mess involved.
Instead of letting AUTOLOAD receive and pass on arguments, and instead
of letting AUTOLOAD call the loaded sub, why not have AUTOLOAD do its
thing, and then have *perl* call the sub?
sub AUTOLOAD ($w) { return our ::($w) := get_subref_for $w }
I like that. Makes it more consistent with the AUTOSCALAR, etc methods -
returning a reference to the result (variable ref/code ref/sub name) rather
than the actual result (variable value/calling the sub).
After all, presumably the compiler might sometimes call the AUTOLOAD at
compile time; to get its signature. So, for instance, you could AUTOLOAD
all the methods you optionally export, which are all pulled in at once when
a module imports a function and tries to use it in some code (as the
signature will need to be checked then). I was going to bring that up
next, but I think this has already answered it.
Sam.
Re: AUTLOAD and $_
On Mon, 2005-06-20 at 12:11 +0200, Juerd wrote: I think there exists an even simpler way to avoid any mess involved. Instead of letting AUTOLOAD receive and pass on arguments, and instead of letting AUTOLOAD call the loaded sub, why not have AUTOLOAD do its thing, and then have *perl* call the sub? Who says AUTOLOAD will always either call a loaded sub or fail? -- c
Re: AUTLOAD and $_
chromatic wrote: Who says AUTOLOAD will always either call a loaded sub or fail? Maybe it should be passed a continuation too, then? Then it could choose exactly what to do with it. Sam.
Re: AUTLOAD and $_
On 6/20/05, chromatic [EMAIL PROTECTED] wrote: On Mon, 2005-06-20 at 12:11 +0200, Juerd wrote: I think there exists an even simpler way to avoid any mess involved. Instead of letting AUTOLOAD receive and pass on arguments, and instead of letting AUTOLOAD call the loaded sub, why not have AUTOLOAD do its thing, and then have *perl* call the sub? Who says AUTOLOAD will always either call a loaded sub or fail? Uh, what else can it do? It doesn't have to load a sub to return a code reference. Luke
Re: AUTLOAD and $_
chromatic skribis 2005-06-20 14:56 (-0700):
Who says AUTOLOAD will always either call a loaded sub or fail?
I don't recall any clearl spec of Perl 6's AUTOLOAD. If there is
something I missed, say so and please do provide example code. Questions
like the one quoted tend to irritate me.
There is almost always either success or failure. Programming would get
very hard if it weren't as black and white as that, at this level. If
there is anything in between success and failure, indicating success is
probably still the better idea in such cases.
Returning a closure avoids having to lookup the sub again before it is
executed, and it allows for not installing the sub, so that AUTOLOAD is
called again, the next time the same name is used. It also allows doing
nothing: just return sub { }.
I don't think there is anything that this setup cannot do, but I do
think this way is necessary. Because context is dictated by signature,
and signature may not be known for a not-yet loaded sub, AUTOLOAD has to
be called before the arguments are evaluated. Because they're not
evaluated, they cannot be passed, and they cannot be used by AUTOLOAD to
be fed to the (supposedly) newly loaded sub.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: AUTLOAD and $_
On Mon, 2005-06-20 at 16:37 -0600, Luke Palmer wrote:
On 6/20/05, chromatic [EMAIL PROTECTED] wrote:
Who says AUTOLOAD will always either call a loaded sub or fail?
Uh, what else can it do? It doesn't have to load a sub to return a
code reference.
I think:
class NullObject
{
sub AUTOLOAD {}
}
is better than:
class NullObject
{
sub AUTOLOAD { return sub {} }
}
Or have I misunderstood the proposal and the purpose of AUTOLOAD?
-- c
Re: AUTLOAD and $_
chromatic skribis 2005-06-20 15:58 (-0700):
I think:
sub AUTOLOAD {}
is better than:
sub AUTOLOAD { return sub {} }
It's nicer to type, but I think that your preferred syntax means that
the AUTOLOAD sub itself has to call any loaded code, which can mean that it
has to fit arbitrary given arguments to an arbitrary signature, which I
think is way too hard.
One alternative, that I don't like, is to ignore non-subref returns, but
call a returned subref. Then something else has to indicate failure, and
that thing is probably fail. The problem that I have with that is that
you lose the free verbose, clear and standard error message you could
otherwise have. Unless fail here uses a default that isn't $_ or $!, and
I do not like special cases like that.
Note that as long as empty closures can be typed without the sub
keyword, and the return keyword is optional for the last statement, the
following is perhaps a syntactically more satisfying solution for you:
sub AUTOLOAD {{}}
If I understand things correctly, a null closure will have such small
overhead that you can pass it around just as freely as integers. Of
course, calling the empty closure can be optimized away, although I hope
I also understand correctly that the overhead of calling something is
also so drastically reduced since Perl 5, that {}() is not much heavier
than do {} or the null statement between two semicolons: ;;.
Or have I misunderstood the proposal and the purpose of AUTOLOAD?
Well, the purpose I think you have misunderstood, as your example
doesn't LOAD anything. But then, I have always thought AUTOLOAD was a
bad name, because it is so much more powerful than that. Perhaps
DEFAULT, FALLBACK or MISSINGSUB would be more appropriate.
I also don't see the symmetry between AUTOLOAD and AUTOMETH. Two things
bother be about that: LOAD versus METH, while it should be SUB versus
METH, and that METHOD is abbreviated while in the method keyword it is
not. Either it should be abbreviated everywhere: meth foo { ... }, or
nowhere: AUTOMETHOD. I personally like the meth foo { ... }.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
On 6/18/05, Juerd wrote: Why exactly is the slash not acceptable for you? Almost everyone has said they like it. I personally find ./method prettier and easier to type than any of the alternatives. I don't like it because I think method calls should look like method calls, and the slash separating the dot and name makes it look like something else entirely. On 6/19/05, Juerd wrote: David Storrs skribis 2005-06-19 13:45 (-0400): All that said, I still agree with John... './' does not look like method call syntax to me. That's good, because it's different from all other method syntax anyway, because it does not have any left hand side -- not even implied. I don't think it's good. A method call should look like a method call. Frankly, I don't understand the objection to using a keyword for $?SELF, such as `self`. Most other object-oriented languages use such a keyword, if not exactly the same one, so it will be a familiar concept. Certainly more readily understood for a newcomer than `./method`. As a bonus, `self` is easily searchable within the documentation, whereas `./` is not. The argument that this keyword cannot then be defined by user code is weak, as it would be rather hostile to use `self` for any other meaning inside of a class. I presume it could be overridden anyway, as with the other core built-ins, so it is not even an eternal loss, should the need actually arise. I missed responding to the thread the last time this subject came up, but the more I see this syntax the less I like it, so I wanted to add another voice to the dissention. However, if it remains official, I expect I'll simply be naming my invocants, as chromatic has suggested. Kurt
Re: ./method defunct
Kurt skribis 2005-06-20 19:34 (-0400):
However, if it remains official, I expect I'll simply be naming my
invocants, as chromatic has suggested.
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: ./method defunct
On 6/20/05, Juerd wrote:
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
And you could do the same for `./`.
Kurt
Re: ./method defunct
Kurt skribis 2005-06-20 19:46 (-0400):
On 6/20/05, Juerd wrote:
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
And you could do the same for `./`.
Certainly.
However, there has proven to be much demand for something like ./method,
and in such cases, having it by default is probably the best thing.
I personally don't think it's either necessary or too much. I care about
.method using $_, and many other people care about having short syntax
for self.method too. ./method was something that would work for me, so I
shared that idea, and it was generally accepted.
Apart from the personal joy of seeing something I invented become part
of the official language, I don't really care if ./method is eventually
part of Perl 6 or not. I have always named my invocants, and don't mind
continue to do so. On the other hand, if there is a shorthand, I will
use it, because regardless of whether you think it's pretty or ugly, and
regardless of whether you think it looks enough like a method call,
having a short two character operator for this is in fact very
convenient.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: AUTLOAD and $_
Juerd wrote:
I also don't see the symmetry between AUTOLOAD and AUTOMETH. Two things
bother be about that: LOAD versus METH, while it should be SUB versus
METH, and that METHOD is abbreviated while in the method keyword it is
not. Either it should be abbreviated everywhere: meth foo { ... }, or
nowhere: AUTOMETHOD. I personally like the meth foo { ... }.
S10 talks about how it is AUTOSUB vs AUTOMETH (and others), but AUTOLOAD
is still around. S10 doesn't mention it, but I think it's been said that
AUTOLOAD only gets called as a last resort.
S10 also mentions that the 'goto' is implicit. I think I like the return
of a ref better, since you're not always going to want to build the
function out and store it. But the call can be hijacked, so I guess
that's okay.
-- Rod Adams
Re: AUTLOAD and $_
On Mon, Jun 20, 2005 at 04:37:31PM -0600, Luke Palmer wrote: On 6/20/05, chromatic [EMAIL PROTECTED] wrote: On Mon, 2005-06-20 at 12:11 +0200, Juerd wrote: I think there exists an even simpler way to avoid any mess involved. Instead of letting AUTOLOAD receive and pass on arguments, and instead of letting AUTOLOAD call the loaded sub, why not have AUTOLOAD do its thing, and then have *perl* call the sub? Who says AUTOLOAD will always either call a loaded sub or fail? Uh, what else can it do? It doesn't have to load a sub to return a code reference. Luke I recall Damian using AUTOLOAD (in perl5) to evaluate the result of the function call without loading a function with the given name. This was to allow arbitrary names to be invoked, when the same name is unlikely to be used again. This was basically a method that took a string contant argument, but it used the method name as the constant and didn't need to specify a name for the actual ccmmon method. I'm not certain that this is actually a worth supporting, it's more of a golf/obfuscation technique than a significant tool, unless there are additional clever uses of the technique that go beyond this basic trick. --
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.
