Says Dave Mitchell:
> Closures ... can also be dangerous and counter-intuitive, espcially to
> the uninitiated. For example, how many people could say what the
> following should output, with and without $x commented out, and why:
>
> {
> my $x = "bar";
> sub foo {
> # $x # <-
From: Ken Fox [mailto:[EMAIL PROTECTED]]
>
> > You forgot the other example that someone raised:
> >
> > { my $x = 'X'; *h = sub { $H = sub {pr $h} }}
> > h(); $H->();
> >
> > Which prints:
> >
> > Z
>
> Did you mean this?
>
> { my $z = 'Z'; *h = sub { $H = sub {pr $z} }}
> h(); $H->();
>
>
Garrett Goebel wrote:
> From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> > Okay, to humour me for a mo', what should the following 2 examples
> > output if Perl were doing the "right" thing?
> >
> > sub pr { print $_[0] || 'undef', "\n" }
> >
> > { my $x = 'X'; sub f { $F = sub {pr $x} }}
> > f();
From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> Ken Fox <[EMAIL PROTECTED]> wrote:
>
> > You're speaking in Perl implementation terms. I've already told you
> > that if Perl acts the way you say it does, then Perl has buggy
> > closures. You don't need to explain a bug to know that one exists!
>
Ken Fox <[EMAIL PROTECTED]> wrote:
> You really need to learn what a closure is. There's a very nice book
> called "Structure and Interpretation of Computer Programs" that can
> give you a deep understanding. **
Quite possibly I do. Anyway, I've now got the book on order :-)
> You're speaking in
Dave Mitchell wrote:
> The whole point is that closed variables *aren't* 'just local variables'.
> The inner $x's in the following 2 lines are vastly different:
>
> sub foo { my $x= ... { $x } }
> sub foo { my $x= ... sub { $x } }
You really need to learn what a closure is. There's a
Ken Fox <[EMAIL PROTECTED]> wrote:
> We must be very careful not to confuse "closure" with "Perl's
> current implementation of closure". You've stumbled onto a bug in
> Perl, not discovered a feature of closures. Perl's "closures"
> were horribly buggy until release 5.004. (Thanks Chip!)
Er, no i
Dave Mitchell <[EMAIL PROTECTED]> wrote:
> John Porter <[EMAIL PROTECTED]> wrote:
> > Dave Mitchell wrote:
> > > I think closures are a lot harder (or at least subtler) than
> > > people think ...
> >
> > ... The scenario you gave seems rather far-fetched to me, in terms
> > of real-world program
Dave Mitchell <[EMAIL PROTECTED]> wrote:
> John Porter <[EMAIL PROTECTED]> wrote:
> > Dave Mitchell wrote:
> > > I think closures are a lot harder (or at least subtler) than
> > > people think ...
> >
> > ... The scenario you gave seems rather far-fetched to me, in terms
> > of real-world program
Dave Mitchell <[EMAIL PROTECTED]> wrote:
> John Porter <[EMAIL PROTECTED]> wrote:
> > Dave Mitchell wrote:
> > > I think closures are a lot harder (or at least subtler) than
> > > people think ...
> >
> > ... The scenario you gave seems rather far-fetched to me, in terms
> > of real-world program
As was mentioned earlier, a closure can as well be a named sub, not
necessarily an anonymous.
Ilya
-Original Message-
From: Paul Johnson
To: Dave Mitchell
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: 08/21/2001 11:39 AM
Subject: Re: explicitly declare closures???
On Tue, Aug 21, 2001
On Wed, Aug 22, 2001 at 10:34:49AM +0100, Dave Mitchell wrote:
> Paul Johnson <[EMAIL PROTECTED]> wrote:
> > Actually, foo() is not a closure. A closure is an anonymous subroutine
> > and foo() clearly has a name.
>
> Damain's definition of a closure includes named subs:
>
> "In Perl, a closure
On Tue, Aug 21, 2001 at 06:06:06PM +0100, Dave Mitchell wrote:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
> > > {
> > > my $x = "bar";
> > > sub foo {
> > > # $x # <- uncommenting this line changes the outcome
> > > return sub {$x};
> > > }
> > > }
> > > print foo()->();
> >
> > W
John Porter <[EMAIL PROTECTED]> wrote:
> Dave Mitchell wrote:
> > I think closures are a lot harder (or at least subtler) than people
> > think,
>
> It's hard for me to agree with you, because I've never had *any*
> problems with closures. (And yes, I use them all the time.)
> The scenario you g
Dave Mitchell wrote:
> I think closures are a lot harder (or at least subtler) than people
> think,
It's hard for me to agree with you, because I've never had *any*
problems with closures. (And yes, I use them all the time.)
The scenario you gave seems rather far-fetched to me, in terms
of real-
> "Dave" == Dave Mitchell <[EMAIL PROTECTED]> writes:
Dave> Paul Johnson <[EMAIL PROTECTED]> wrote:
>> Actually, foo() is not a closure. A closure is an anonymous subroutine
>> and foo() clearly has a name.
Dave> Damain's definition of a closure includes named subs:
Dave> "In Perl, a closu
Paul Johnson <[EMAIL PROTECTED]> wrote:
> Try changing your original example from
>
> sub foo {
>
> to
>
> *foo = sub {
>
> and you'll see that everything works "as expected".
add a BEGIN so that instantion happens at the same time that a named
sub would be:
BEGIN { * foo = sub { } }
> I guess you missed where I suggested that putting "my" on that
> declaration is also counter-sensical, not to mention redundant.
> "my" implies a brand-spanking-new lexical variable attached
> to this very scope. The semantics of "outer" (or "closed"...)
> can be defined to imply a lexical var
Paul Johnson <[EMAIL PROTECTED]> wrote:
> Actually, foo() is not a closure. A closure is an anonymous subroutine
> and foo() clearly has a name.
Damain's definition of a closure includes named subs:
"In Perl, a closure is just a subroutine that refers to one or more lexical
variables declared o
Dave Mitchell wrote:
> foo() is a closure created at compile time. By the time the main {} block
> has been executed (but before foo() is called), the $outer:x is undef,
> and $foo:x is 'bar' (standard closure stuff). When foo() is executed,
> the anon sub is cloned, and at that time, $anon:x is s
Piers Cawley <[EMAIL PROTECTED]> wrote:
> > {
> > my $x = "bar";
> > sub foo {
> > # $x # <- uncommenting this line changes the outcome
> > return sub {$x};
> > }
> > }
> > print foo()->();
>
> Well, I would expect it to output 'foo' on both occasions, and I'm
> more than a l
Dave Mitchell <[EMAIL PROTECTED]> writes:
> Just thought I'd run the following up the flagpole to see if anyone
> laughs at it
>
> Closures are useful, powerful things, but they can also be
> dangerous and counter-intuitive, espcially to the uninitiated. For example,
> how many people could
On Tue, Aug 21, 2001 at 09:21:35AM -0400, Eric Roode wrote:
> John Porter wrote:
> >
> >Dave Mitchell wrote:
> >> ie by default lexicals are only in scope in their own sub, not within
> >> nested subs - and you have to explicitly 'import' them to use them.
> >
> >No. People who write closures kno
John Porter wrote:
>
>Dave Mitchell wrote:
>> ie by default lexicals are only in scope in their own sub, not within
>> nested subs - and you have to explicitly 'import' them to use them.
>
>No. People who write closures know what they're doing.
>
>When's the last time someone "accidentally" wrote
Dave Mitchell wrote:
> ie by default lexicals are only in scope in their own sub, not within
> nested subs - and you have to explicitly 'import' them to use them.
No. People who write closures know what they're doing.
When's the last time someone "accidentally" wrote a closure?
--
John Porte
Just thought I'd run the following up the flagpole to see if anyone
laughs at it
Closures are useful, powerful things, but they can also be
dangerous and counter-intuitive, espcially to the uninitiated. For example,
how many people could say what the following should output,
with and without
26 matches
Mail list logo
