develooper Front page | perl.perl5.porters | Postings from February 2013

Re: Salvaging lexical $_ from deprecation

Thread Previous
From:
Nicholas Clark
Date:
February 20, 2013 13:10
Subject:
Re: Salvaging lexical $_ from deprecation
Message ID:
20130220131004.GY5653@plum.flirble.org
On Wed, Feb 20, 2013 at 11:22:37AM +0100, Rafael Garcia-Suarez wrote:
> On 20 February 2013 10:59, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:
> > So you are saying that the above will eventually be correct if and only
> > if it is instead written like so?
> >
> >     catch sub (_) {
> >         die $_ unless /Can't locate .* in \@INC/;
> >     }
> >
> > How is that less ugly than the use of `local $_`? Is inventing a one-off
> > selective lexical-to-dynamic scope connection mechanism for exactly one
> > single variable in all of Perl reasonable, modern, nice language design?
> 
> Why are you assuming that the library that provides catch() cannot be
> modified to accomodate this? (in a way to be specified later)

I think because it's not obvious to anyone what that "way to be specified
later" is - ie it's not clear that a way exists at all.

It seems to me that the problem from pure-Perl space is roughly that it's
not possible to write all forms of subroutines that provide callbacks or
that emulate builtins, once you have lexical $_ too.

Because sometimes the implicit or explicit use of $_ is intended to mean
"the $_ that I find from my lexical scope", and sometimes the implicit or
explicit use is intended to mean "the $_ that is found from my caller's
lexical scope". But any use of a $_ that is lexical creates a closure.
Which defeats the intent of "the $_ that is found from my caller's lexical
scope"

It sort of feeling like what is needed is syntax to mean "late binding $_",
where the $_ lookup is delegated to the caller.

And it's not clear if it's possible to do that without being ugly, or being
a special case.

Nicholas Clark

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About