[% setvar title More defaulting to $_ %]

This file is part of the Perl 6 Archive

Note: these documents may be out of date. Do not use as reference!

To see what is currently happening visit http://www.perl6.org/

TITLE

More defaulting to $_

VERSION

  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

ABSTRACT

$_ is the default variable for some operations and functions. Other operations would benefit from similar use of $_ to reduce clutter.

DESCRIPTION

$_ 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?

1: For <>

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<;>" ?

2: For List Functions

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.

3: For Functions In General

"stat;", "length;", and many others could use $_. The downside I see is that the parser gets bigger.

And So On:

Parts of this proposal may work nicely with RFC 170: "Generalize =~ to a special-purpose assignment operator".

IMPLEMENTATION

...

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