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

Re: Salvaging lexical $_ from deprecation

Thread Previous | Thread Next
From:
Rafael Garcia-Suarez
Date:
February 20, 2013 07:24
Subject:
Re: Salvaging lexical $_ from deprecation
Message ID:
CAMoYMM_AEve9suT6hSFjBHv8iZ8J0GTW1EwPaX+U2JkCZE+TZw@mail.gmail.com
On 20 February 2013 07:51, Jesse Luehrs <doy@tozt.net> wrote:
[...]
> And this is exactly what breaks things. How is B any different from
> something like
>
>   my $_ = ...;
>   # ...
>   try {
>       require Foo;
>   }
>   catch {
>       die $_ unless /Can't locate .* in \@INC/;
>   }
>
> This will not work as expected, because the catch block will close over
> the lexical $_. This catches people up very regularly, I've received
> many, many bug reports about it. How can we resolve this? Currently,
> perl does not make any distinction between "foo(sub { ... })" and
> "foo { ... }" (if foo in the second case is declared with a prototype of
> (&)). How then do we write user-defined things that behave like map or
> grep in terms of how they interact with $_?

How would you expect this flavour of try-catch work in all cases
*without* a proper lexical $_? how would you guarantee without it that
the $_ you're using in the catch block hasn't been clobbered from
anywhere else ? (Remember the old $@ woes with eval and destructors.
$@ is another example of a variable that should be lexicalized, but
isn't, and had caused much bugs because of that.)

Really, it sounds like a proper (improved) lexical $_ is a solution,
and a quite elegant one, as possible as it can be; not a problem.

As I mentioned before we need a mechanism to mimic map and grep for
XSUBs (like UNDERBAR, but that works) and for subs. What we don't need
is to throw the baby away even before having tried to put water in the
tub.

Thread Previous | Thread Next


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