develooper Front page | perl.perl5.porters | Postings from August 2021

Re: `local` on lexicals

Thread Previous | Thread Next
August 10, 2021 14:06
Re: `local` on lexicals
Message ID:
From the keyboard of Matthew Horsfall (alh) [10.08.21,08:54]:

> On Mon, Aug 9, 2021 at 8:03 PM shmem wrote:
> A “local my $foo” blurs that difference and introduces a “timely” scoping
> for lexicals. Or wouldn’t it? Anyways, aliasing a lexical would need another
> metaphor and a different keyword than “local”. Perhaps “alias”?
> I don’t understand your concerns here. This is already something you
> can basically do:

My concerns (and entirely mine) are just this: I have a mental model
about what perl is and how it works ("that might be entirely wrong,
you tomfool!" I says to me), and localizing a lexical wasn't - for me -
in sync with that, violated an idea or metaphor or whatever, which isn't
worth telling here. Well, since you could ask: in my head, "local" means
giving another value¹ to a global in the current codepath, without at all
touching the global for other parts of the program, and without having to
restore the original at paths end; while lexicals pertain only to their
scope. So the change proposed seemed inconsistent to me.

So I was about to raise hand. Composed that mail halfway through, let it
sit and went to #p5p on, where LeoNerd, Grinnz and xenu did
very kindly and with great patience discuss the issue with me, until I
got the point you are making (thanks LeoNerd):

> use strict;
> use warnings;
> my $x = { x => "outer" };
> if (1) {
>  local $x->{x} = "cond inner";
>  foo();
> }
> sub foo {
>  print "$x->{x}\n";
> }
> foo();
> __END__
> cond inner
> outer
> Why would localizing a scalar $x = 1 be any more confusing than
> localizing a slot in an array or hash?

It is not. Relevant bits of that chat:

< LeoNerd > Compare also with  my @x = ("outer"); ... { local $x[0] =
     "cond inner" ...   etc
< shmem > LeoNerd: ah, I see. In a my @array, slots can be localized
     despite the container being a lexical
< shmem > which doesn't work for plain SVs
< LeoNerd > Quite
< LeoNerd > Exactly
< shmem > that's inconsistent! says the referee and shows his teeth
< shmem > got it now, thanks LeoNerd, Grinnz and xenu
< LeoNerd > :)

So, after re-wiring myself, I went back to the open mail sitting there
in vi (courtesy of alpine), and after cancelling the editor I was about
to cancel the entire, now meaningless, mail. Alas, I hit Ctrl-x instead
of Ctrl-c (the keys are next to each other) and the message was sent.
Sorry for that.

Insight obtained (personal note): I am getting old, and the past has now
more weight than an imagined, thriving future - but I am still able to
learn and widen my ideas. Best with folks like you all.

That said, +1 for the proposal. It is indeed as consistent and perlish as
"our", and I wonder why it wasn't there in the first place.
Ah, metaphors.

Again, sorry for the glitch.

¹) in fact it moves away the variable, I have been told. I haven't thought
through the difference between both, for now it looks to me that either
restoring the variable or the value have the same effect in programming.
It might be different for intrinsics (implementation).

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                               /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About