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

Re: Salvaging lexical $_ from deprecation

Thread Previous | Thread Next
Aristotle Pagaltzis
February 20, 2013 10:00
Re: Salvaging lexical $_ from deprecation
Message ID:
* Rafael Garcia-Suarez <> [2013-02-20 08:25]:
> On 20 February 2013 07:51, Jesse Luehrs <> 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 $_.
> 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.

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?

[Long parenthetical while I try to entertain the idea anyway follows:]

While I don’t know how UNDERBAR is used, I do know that the underscore
prototype is the wrong interface. I have written subs that operate on $_
in addition to stuff they expect in @_ with good reason. Consider, for
example, Plack::Middleware::Rewrite.

If you are really going to attempt this, I would rather figure out some
kind of `upper` declarator to give Perl a built-in PadWalker of sorts.
Then the above would read

    catch {
        die upper $_ unless /Can't locate .* in \@INC/;

which, while still far uglier than the global-topic version to me, would
at least be a saner interface to modifying the scope of a variable: it
is honest and explicit about being a new scoping mechanism rather than
obscuring that fact by pretending to be about arguments and the topic.

But really, I would just rather lexical $_ would go away instead of
having to invent anything this far-reaching just to make `my $_` work.

Another option, which I am more predisposed to, is to introduce light-
weight blocks that work the way that blocks in `map` and `grep` do.

Note however that this doesn’t entirely relieve the need for some kind
of `upper`. So I’d like to see those, and for other reasons, and still
I would rather just that lexical $_ would go away.

Aristotle Pagaltzis // <>

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About