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 10:22
Subject:
Re: Salvaging lexical $_ from deprecation
Message ID:
CAMoYMM8dS5_PnzSMV=jhA===3fkxPU0SHj21xqZGc5OtoM0rAA@mail.gmail.com
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)

> [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.

Sounds like a nice idea. Pointless without lexical $_, though.

> 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.

I'm reluctant at the idea a general-purpose upper keyword. The point
of lexical variables, including lexical $_, is to give the user some
assurance that the variables are not going to be messed up with at a
distance -- which is a good thing.

On a more general note, it's disappointing (but not totally
unexpected) to see some subscribers to P5P dragging back any
innovation or improvement proposal solely on the grounds of tradition
and not on technical merits. Stagnation and fear of change is not far
from that special biologist word for 'stable'. It's not surprising to
see the topic of a "perl 7" popping up regularly given the
anti-innovation mindset of many regulars here.

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