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

Re: Salvaging lexical $_ from deprecation

Thread Previous | Thread Next
From:
Aaron Priven
Date:
February 26, 2013 01:24
Subject:
Re: Salvaging lexical $_ from deprecation
Message ID:
D09530DC-AF87-4219-8A50-9AB3938F9340@priven.com
I wanted to say something about the lexical $_ debate, even though the conversation mostly stopped a week ago.

$_ is useful only insofar as it avoids extra typing. There's no advantage over regular alphanumeric variables other than that. If you have to specify 

chomp $_;

then you might as well specify 

chomp $x;

and at least you have one letter's worth of description.

The whole point is that you don't have to type that. You can just type 

chomp;

And chomp knows you mean $_.

And that means that the "chomp" routine has to be able to see, and change, the value of $_. And if "my $_" acted the same way as "my $x", it couldn't do that. 

It's irrelevant that chomp is a built-in, and not an XS sub, or a perl sub. The language issues, if not the implementation issues, are exactly the same.

So implementing "my $_" has meant implementing a whole series of ways that called routines can access the caller's $_, using (I guess) various macros in C source and, imperfectly, the _ prototype in perl source.

And all this is a long, fancy way of duplicating the exact same feature that perl has always had: the global variable. $_ makes sense as a global, and not as a lexical, because the entire point of $_ is that it can be seen by called routines.

I don't think anybody disagrees that there is a real problem with $_ being clobbered *accidentally* by routines which don't use the caller's $_, but whose authors forgot to localize $_ before using it in the routine.  This is unfortunate, and I don't know if there's a way of fixing it that doesn't break all existing code that uses $_. 

But creating a whole separate new kind of "lexical" but really global $_ isn't a good solution. It complicates horribly both the use of $_ for its intended purpose and the maintenance of all the code that might need to use $_.

-- 
Aaron Priven, aaron@priven.com

On Feb 19, 2013, at 1:07 PM, Rafael Garcia-Suarez <rgs@consttype.org> wrote:

> Hi Porters,
> I notice that the lexical topicalizer "my $_" is deprecated in blead.
> At this point I assume that the reasons for the deprecation given in
> perl5177delta are exhaustive. All those reasons are pointing to
> implementation problems, notably at the XS interface level, which can
> be solved; there are no reasons given that pertain to language design
> issues.
> 
> In my opinion, the more important problem here is the impression that
> P5P is throwing away without much thought of a perfectly nice and
> modern language feature (for some value of modern that means
> "post-FORTRAN"). This could give the impression of a the lack of
> vision for Perl 5 (and reinforce the "perl is dead" death spiral as
> perceived by the outside world -- the Perl users).
> 
> While I totally understand that failed experiments in language design
> should be deprecated and removed (like the ~~ operator and the
> given/when keywords), I'm yet to be convinced that this is the case
> for "my $_". Lexical $_ could be marked experimental, as a number of
> other features are, but there is no reason to mark it deprecated. At
> the very contrary there are excellent reasons to keep working on
> improving it.
> 
> Let me advocate once again this language construct. $_ (or the ability
> to not specify an implicit topic, like in natural languages) is an
> essential part of the perlishness of perl. There is no intrinsic value
> in having $_ as a global at all; by essence a topic is local to its
> context. However $_ is global because, being a Perl 1 feature, it
> predates the very existence of lexical variables. In that aspect $_ is
> fundamentally different from most other punctuation variables, used to
> globally tune the interpreter, or give access to global or external
> resources ($0, $$, $^V, $^D, etc).
> 
> So, to be clear: $_ is still global by default due to the need for
> backwards compatibility. If something should be deprecated, it should
> be plain $_, not "my $_".
> 
> Having a global $_ creates a mismatch between the implementation (the
> _ glob) and the language design intent behind $_. In practice that is
> revealed by confusing action-at-distance bugs (either on $_ itself or
> via *_; or having "local $_" not working as intended).
> 
> Other punctuation variables do not suffer from this drawback. For
> example the $1, $2... capture variables are already automatically
> lexicalised. @_ is another piece of dubious implementation, but at
> least it's not a global either. I'll also add that for/foreach does
> the right thing with $_ (this remark does not include "given") and
> that it's an old but first step in the good direction.
> 
> In conclusion: think first about language design; think about having a
> vision for the future. Don't throw away language features just because
> they introduce difficult bugs you'd rather sweep under the rug.
> Deprecating $_ is laziness and impatience of the worst kind; do not
> forget to also display hubris, because only hubris makes the future
> promises shine.
> 
> Incidentally, I hastily pushed a branch rgs/undeprecate-lex-topic to
> remove the deprecation warning (since this has to be merged really
> quick before the deprecation escapes to a stable release.)

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