[% setvar title More defaulting to $_ %]
Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
More defaulting to $_
Maintainer: Kenneth C. Rich <xkenrich@mail.rochester.edu> Date: 10 Sep 2000 Last Modified: 13 Sep 2000 Mailing List: perl6-language@perl.org Number: 215 Version: 2 Status: Developing
$_
is the default variable for some operations and functions.
Other operations would benefit from similar use of
$_
to reduce clutter.
$_ is the default scalar for a small set of operations and functions.
Most of these operations and functions are ones that use =~
.
If we decouple $_
from =~
, then can we profitably use $_
elsewhere?
An inconsistency between "print
" and "<>" bugs me: "print;
" means
"print $_;
" so it seems like "<>" should mean "$_ =
<>".
This would break code prompting for "Press any key" and wasting the
input.
Would this have an advantage in making the
while( <> ) { }
construction less magical?
Actually, some days I wish "print;
" meant "print nothing." I was tempted
to title this RFC "Make print
and <> consistent."
Problem:
since <> has a different behavior in a list context, does
"(
<> );
" break, or does it mean something like "@_ =
<>c<;>" ?
I also would like making "push;
" mean "push( @_, $_ );
" and
"pop;
" mean "$_ = pop;
" but I can think of code this would
break. The same wish and problem applies to other list operators. But
maybe the problems are easily fixed with the 5-to-6 converter changing
perl5 "pop;
" into "undef = pop;
" etc. Which ugliness is more
preferable? I like the idea of a "wasting" pop
or shift
looking explicitly wasteful, at least some days. I am not taking an
assertive stance on this shaky sub-proposal.
"stat
;", "length;
", and many others could use $_
. The
downside I see is that the parser gets bigger.
Parts of this proposal may work nicely with RFC 170: "Generalize =~ to a special-purpose assignment operator".
...
RFC 2: Request for new pragma: Implicit
RFC 51: Angle brackets should accept filenames and lists
RFC 56: Optional 2nd argument to pop() and shift()
RFC 139: Allow Calling Any Function With a Syntax Like s///
RFC 164: Replace =~, !_, m//, s///, and tr// with match(), subst(), and trade()
RFC 170: Generalize =~ to a special-purpose assignment operator