=head1 TITLE More defaulting to $_ =head1 VERSION Maintainer: Kenneth C. Rich Date: 10 Sep 2000 Last Modified: 13 Sep 2000 Mailing List: perl6-language@perl.org Number: 215 Version: 2 Status: Developing =head1 ABSTRACT C<$_> is the default variable for some operations and functions. Other operations would benefit from similar use of C<$_> to reduce clutter. =head1 DESCRIPTION $_ is the default scalar for a small set of operations and functions. Most of these operations and functions are ones that use C<=~>. If we decouple C<$_> from C<=~>, then can we profitably use C<$_> elsewhere? =head2 1: For <> An inconsistency between "C" and "<>" bugs me: "C" means "C" so it seems like "<>" should mean "C<$_ = > <>". 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 "C" meant "print nothing." I was tempted to title this RFC "Make C and <> consistent." Problem: since <> has a different behavior in a list context, does "C<(> <> C<);>" break, or does it mean something like "C<@_ => <>c<;>" ? =head2 2: For List Functions I also would like making "C" mean C<"push( @_, $_ );>" and "C" mean "C<$_ = pop;>" but I B 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 "C" into "C" etc. Which ugliness is more preferable? I like the idea of a "wasting" C or C looking explicitly wasteful, at least some days. I am not taking an assertive stance on this shaky sub-proposal. =head2 3: For Functions In General "C;", "C", and many others could use C<$_>. The downside I see is that the parser gets bigger. =head2 And So On: Parts of this proposal may work nicely with RFC 170: "Generalize =~ to a special-purpose assignment operator". =head1 IMPLEMENTATION ... =head1 REFERENCES 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