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 19, 2013 21:53
Subject:
Re: Salvaging lexical $_ from deprecation
Message ID:
CAMoYMM-PjxErJCqUYjuR8P3Dj_ono=4wfaVBeTrqC6Sxa8_=Ug@mail.gmail.com
On 19 February 2013 22:41, Jesse Luehrs <doy@tozt.net> wrote:
> On Tue, Feb 19, 2013 at 10:37:31PM +0100, Rafael Garcia-Suarez wrote:
>> (resent due to email-button disability)
>>
>> On 19 February 2013 22:30, Jesse Luehrs <doy@tozt.net> wrote:
>> > On Tue, Feb 19, 2013 at 10:27:00PM +0100, Rafael Garcia-Suarez wrote:
>> >> On 19 February 2013 22:14, Jesse Luehrs <doy@tozt.net> wrote:
>> >> > On the contrary, $_ is basically useless except for the global form. Or
>> >> > are you saying that there shouldn't be any way to implement things like
>> >> > Try::Tiny (which does something along the lines of
>> >> > "sub catch (&) { local $_ = $@; $_[0]->() }") without using XS? The only
>> >> > serious use of $_ I have ever seen (or used personally) is when $_ is
>> >> > implicitly localized by some other code (whether that code is perl
>> >> > itself in a for loop, or in some other module). This cannot work when $_
>> >> > is lexical, and making $_ lexical in fact breaks any code like that.
>> >> > "my $_ = 'foo'; my @bar = any { $_ eq 'a' } qw(a b c)" for instance.
>> >> > That is why it has been deprecated.
>> >>
>> >> You're pointing at an incomplete implementation to dismiss the whole
>> >> feature. This short-sighted criticism might be valid for bug fixes, not
>> >> for new language features.
>> >
>> > I don't know how you would change the implementation without making it
>> > no longer lexical. The whole point of lexical scope is that code outside
>> > of the point of declaration cannot see the value at all. What are you
>> > referring to here?
>>
>> I'm referring to the behaviour of built-ins grep and map with regard to $_.
>
> I meant: how would you provide that functionality without requiring all
> existing code that just localizes $_ to be rewritten?

I'm not proposing that. For XS code (like any()) the UNDERBAR set of macros
would need to be fixed and used. It's not realistic to introduce new language
features without breakage at this level. For perl code I also expect adaptations
to be necessary. (Which is basically why I did not wanted to release 5.10
with "my $_" but without at least the _ prototype)

Let's not rush deprecating something without being sure it's useless,
costly and unfixable.

>> >> > Also on the contrary, both @_ and $1 are localized, not lexicalized.
>> >>
>> >> I agree for @_. I also agree that @_ is a kludge, please see the number
>> >> of bugs reported over the years about the stack not being refcounted;
>> >> so do not take a kludge as an example.
>> >> But the $<digit> variables are implicitly lexically scoped for a definition
>> >> of scope that includes a last sight of a pattern match. In other contexts
>> >> their behaviour is not guaranteed.
>> >
>> > But that isn't what "lexically scoped" means.
>> >
>> >   $ perl -E'sub foo { say $1 } "foo" =~ /(.)/; foo'
>> >   f
>> >
>> > $1 in this example is not in the lexical scope of the pattern match by
>> > any definition of the word "lexical". This is dynamic scope, which is a
>> > different thing entirely.
>>
>> No, it's not dynamic scoping: (I specified "for a definition of
>> scope..." because I'm aware of the weird lexical scoping rules applied
>> there)
>>
>> ~ยง perl -E'sub foo { say $1 || "nothing" } { "foo" =~ /(.)/ } foo'
>> nothing
>
> This is still exactly dynamic scoping, as far as I can see. Compare:
>
>   $ perl -E'sub foo { say $::foo } local $::foo = "f"; foo'
>   f
>
>   $ perl -E'sub foo { say $::foo || "nothing" } { local $::foo = "f" } foo'
>   nothing

I stand corrected. (Pretty sure the internals don't do a full
localisation though :)

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