On Sat, Mar 15, 2003 at 12:19:18PM -0500, Uri Guttman wrote:
> >>>>> "AP" == Andrew Pimlott <[EMAIL PROTECTED]> writes:
>
> AP> On Fri, Mar 14, 2003 at 09:59:42PM -0500, Uri Guttman wrote:
> >>
> >> my $c;
> >> sub foo() {
> >> my $a;
> >> my $b;
> >>
> >> my sub bar() {
> >> $b = $a + $c;
> >> }
> >>
> >> bar();
> >> }
> >>
> >> is that close enough?
>
> AP> I think it's absolutely fine, assuming that &bar is a real closure
> AP> that can be returned or passed to other functions. I think nested
> AP> subs should default to "my", since there's no other point in using
> AP> them, but if Larry likes the "my", it can stay.
>
> i don't see why you would want to return a named closure when you can
> return an anon one.
Well, why not? What if I want to call it and return/pass it? I
guess that's not all that common, though.
> the implication (to me) of a named one is that it
> can be called inside foo() directly and it has access to foo() variables
> on the stack. those vars are not copied to a private pad for bar() like
> a anon closure would do. they are different animals IMO.
Suppose I do return/pass it, what will it do? It has to have some
behavior, and the only alternatives I see to closure are utterly
confusing and error-prone. If perl6diag contains the text "will not
stay shared", I will be quite sad.
The very idea of "two kinds of closure" seems confusing.
If you are worried about efficiency, there is a simple optimization:
If no reference is ever taken to the named lexical sub, it doesn't
need it's own copy of the pad.
> AP> ... well, just to be sure, here are a couple test cases:
>
> AP> my foo() {
> AP> my sub helper1() { ... helper2() ... $a ...}
> AP> my sub helper2() { ... helper1() ... $a ...}
> AP> my $a;
> AP> helper1();
> AP> }
>
> AP> helper1 and helper2 should be mutually recursive and enclose $a, ie
> AP> when compiling helper1 it shouldn't bind helper2() and $a to
> AP> whatever's in the outer/global scope.
>
> you don't return a sub there rather you made a call to it. so it is not
> the same as p5 closures. that should work fine but it doesn't need pads
> and local copies of $a in helper1/2().
ok.
> also that can be done with a plain block surrounding two subs. no need for
> nesting subs there. show me a case where you need named nesting subs and
> you return one of them to the outside.
>
> AP> my foo() {
> AP> ... helper() ...
> AP> my $a;
> AP> my sub helper { ... $a ... }
> AP> }
>
> AP> The call to helper() should work and $a should be enclosed (of
> AP> course, it will be undef when helper() is called, but helper can set
> AP> it). It's often nice to put the helpers at the end--and note that
> AP> this cannot be achieved with the Perl 5 glob trick.
>
> this is a compiler issue as to whether it can handle foward
> references. if you declared helper with a signature first (of course
> inside foo()), it would work for sure. i am not sure otherwise.
Right. I just think that since Perl can normally handle forward
references, it should be able to do so in this case.
> my point is that nested named subs are supported but they are not the
> same as anon closures returned from an outer sub. but who knows what
> larry would want there. i will ask on p6l.
Thanks.
Andrew
_______________________________________________
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
