Front page | perl.perl5.porters |
Postings from February 2013
Re: Salvaging lexical $_ from deprecation
From: Aaron Priven
February 26, 2013 01:24
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
then you might as well specify
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
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, firstname.lastname@example.org
On Feb 19, 2013, at 1:07 PM, Rafael Garcia-Suarez <email@example.com> 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
> 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.)