> for reality here. That should be written more like:
>
> 1 while <FH>; $burp = $.;
>
> or even:
>
> for ($burp = 0; my $line = <FH>; $burp++) {}
I'd go for
my $burp = 0; $burp++ while <FH>;
> This proposal should be dropped.
I read your message and agree. Not that I liked the idea that much even
before considering the ramifications. But do you agree that even
seasoned perlers have trouble anticipating how a list/array is going to
be converted to a scalar?
I'd vote for no C<list> operator, but for adding a count operator and a
last element operator. I suggest ()= for the first and C<peek> for the
second. I wouldn't mind if the first were spelled C<count>, either. Tom,
does this make sense, or am I confusing "lists" with "the comma operator
in parentheses" again?
And would we want a C<first> to make shift/first, pop/peek?
> One should eschew the temptation to write
>
> () = <FH>; $burp = $.;
>
> for the memory concerns given above.
I'd also vote for $burp = () = <FH> to be recognized by the optimizer,
just to encourage *all* counting to be done via ()=. It makes assigning
<FH> to () in scalar context a special case, but only to the optimizer,
and that's what an optimizer is there for -- optimizing special cases.
Or it could be extended to assigning <FH> to a finite-sized list, I
guess? Ack! Okay, I admit it, lvaluable list assignments make my head
hurt.
