Okay, maybe I should have gone to bed, but I kept thinking about this.
I'm starting to suspect it's time to haul out the operator I've
been holding in reserve for lo these many years now, the unary =.
Suppose we say that it iterates iterators, but also it recognizes
certain things that aren't iterators and turns them into iterators
and iterates them. So you can say
for =$*IN {...}
for =$*ARGS {...}
if you like, but it also recognizes filenames, and lists of filehandles,
and lists of filenames, and in list context turns them into lists of
lines:
for =<foo.c> {...}
for =<foo.c foo.h> {...}
for =«$foo.c $foo.h» {...}
for =['foo.c', 'foo.h'] {...}
for =['.myrc', @*ARGS] {...}
for [EMAIL PROTECTED] {...}
You can think of the = as a picture of the lines in the file, and
read it "lines of". Well, in list context anyway. In scalar context,
it would do a slurp:
$file = =<foo.c>;
But here's the kicker. The null filename can again represent the
standard filter input, so we end up with Perl 5's
while (<>) {...}
turning into
for =<> {...}
It's just all the magic is done by the = operator rather than the
<>, which is just a plain old ordinary null string inside newfangled
angle quotes. I suppose =() or =[] or ="" would work just as well,
but somehow =<> is what I expect convention to settle on, for certain
values of hysterical and raisins.
And yes, I've looked at every other character on the keyboard, and
several that aren't on the keyboard. And no, I don't think it'll
cause many parsing difficulties since we changed the parsing rules
on methods to require parentheses if there are arguments. It's only
a problem after 0-or-1-ary operators, and not really a problem there,
since the default is to look for a term, and there aren't many 0-or-1-ary
operators you'd want to assign to anyway. In particular, you can say
things like:
print =<foo.c>;
And I don't think it'll be visually confusing to people who put spaces
on both sides of their assignment operators.
Larry
