Re: Re: $_ haters anonymou

[tilly]

Oh it gets better. I don't think anyone in that node mentioned the following interesting behaviour:

$_ = "Where did I come from?\n";
package Private;
print $_;

Isn't that odd? Try this the other way.

package Irrelevant;
$_ = "Bye, bye";
print $Irrelevant::_;

What is going on here? Quite simple. There is a small list of "special" symbols which are always in package main by default no matter what package you are in. *_ is one. *INC is another.

But what this really means is that you really share $_ with anything you call, making it easy to have a bad module wipe out $_ unexpectedly.

[repson]

<MODE TYPE="SILLY/STUPID">Why don't we just drop $_ and use things like $extremly_really_long_variable_name as our commonly used loop variables. This could allow programmers to write fully documented code without comments ie $variable_to_store_data_from_function_call_named_foo_and_mutate_it_with_many_operators. Think how easy it would be to write that type of code and all the time that could be saved not using punctuation like hmmm..$_, and making everything much clearer in the process. That way we could also allow all variables to be fully global because name collision should be quite difficult (hell you'll need reams of paper just to remember them, why not use a few common ones with a few character changed, such as adding _ on the end).</MODE>

Or maybe we need an automatic local $_; at the beginning of each sub and in each package (which would solve some/all of what you were saying).
You could put that in all your subs where you use $_ which can be called by other things.
Then when calling other people's code enclose it in its one block:

#....
my $var = Package::sub;
#....
# changed to
#....
my $var; { local $_; $var = Package::sub; }
#....

This is the only (?) way to make absolutly sure that other code won't accidently wipe $_.
There are also other cases where we need to keep the closest eye on what is happening with $_ (for both our brains and the compiler).

$_ = 'foo';
while (<>)
 for (grep {/$_/} @foo) {
  for (map {ord($_)} split //,$_) {
   while (--$h{$_}>10) {print $_}  
  }
  s/a/b/g;
  print 'middle' . $_;
 }
 print 'outer' . $_;
}
print $_;

There are 4 seperate $_'s there and while they mostly don't collide you need to keep an eye on where they are all going. This could be even worse if this kind of code is mixed in with lots of other statements.
So $_ is just one more thing perl programmers have to keep a close eye on (but still keep on using).

[tilly]

Well why not have $_ be automatically lexical?

Works perfectly well. But breaks backwards compatibility. But I think it will happen in Perl 6.

[dchetlin]

Enh, but then it's impossible to define subroutines that work like built-ins such as chomp.

I do that not infrequently.

However, I wouldn't mind having to go through hoops to get there. Perhaps a subroutine attribute would have to be set to allow you access to $_.

sub mychomp : getunderscore {
    s[${/}\z][];
}

That way, no one could clobber $_ without intending to. And we could also add a pragma to disallow code outside of your file (or perhaps package) from clobbering $_ even if it wanted to.

-dlc

[Dominus]

Says tilly:

> There is a small list of "special" symbols which are
> always in package main by default no matter what package you are in.
> *_ is one.

I thought that might be a useful thing to have, so I put a patch into 5.6.0 to add lots of those variables. So now if you want to have a variable that is always in package main for some reason, you can call it ${^_Ben_Tillys_Variable}, and no matter what package you are in, you always get the same thing.

It's documented at the very end of perlvar, as is the stuff Ben was discussing.

[redcloud]

Sayeth the Dominus:

> So now if you want to have a variable that is always in package main for some reason, you can call it
> ${^_Ben_Tillys_Variable}, and no matter what package you are in, you always get the same
> thing.

Forgive my ignorance -- and maybe it's just too early for me to be posting -- but I have to ask because it's confusing me: Why is this so much better than $main::Ben_Tillys_Variable? If it's just syntactic sugar, that's fine -- I just want to make sure I'm not missing something here....

(BTW, Brother Dominus, good to have you back. I noticed an absence of posts from you for a few days.)

[Dominus]

Says redcloud:

> Why is [${^_Ben_Tillys_Variable}] so much
> better than $main::Ben_Tillys_Variable?

That's a good question. It isn't that much better, but that wasn't the main point of the patch. The reason for the patch was that there are all these $^T, $^L, $^V, $^S variables already. They're all forced into package main::, which is what you want, because you don't want to have to say $main::^M everywhere. And we were starting to run out of letters! So I put the patch in so that the next time someone wants to make up a new feature and use a new $^M variable, they can call it ${^Emergency_Memory} instead. It will be forced into package main:: just like $^M is.

Since I was doing that anyway, I thought I might as well reserve some of those variables for the user, just in case they turned out to be useful for someone. If not, it's OK, because it didn't cost anything.