Larry wrote: » Indeed, that preference is why Perl 6 can (we hope) get away with » autochomping, where Perl 5 can't (as easily). Or more accurately, » we choose not to special-case "while (<>)" as Perl 5 does (because » even Perl 5 has difficulties with files that are accidentally » "autochomped" by omitting the final newline in the file).
I don't understand what you mean, Larry. Sure, Perl *4* had such difficulties, since having only chop(), not an RS-aware chomp(), you'd get a: substr($line,-1) = q() whether you "needed" it or not (although it returns the old LHS not the new RHS). It's not conditional, except that it won't give you negatively lengthed null lines. And so those folks who deemed textfiles as \n-SEPARATED sequences of lines, not \n-TERMINATED sequences, would therefore shorten their files by a character if they didn't check first. But with Perl *5*, since chomp() is RS-aware in that it instead looks for it leaps--er, checks before it chomps--so I'm don't at all understand what you mean when you say » even Perl 5 has difficulties with files that are accidentally » "autochomped" by omitting the final newline in the file). I don't see where you see Perl 5 having that problem. This seems safe enough, which to a first approximation about this: $line =~ s[ ${RS} \z ][]x; Even when $RS = q!!, making for squishy record terminators for both readline() and also for chomp(), I see no destructive action. Often enough I set $RS = "%%\n", and sometimes I remember to put a %% at the end, and sometimes I don't, but no harm done. The only place I can see there being a "problem" is with something like % perl -i'IBACKUP/*' lpe 's/foo/bar/g' file* and some of those files start out without their terminator. Here though the problem is opposite what you mention, in that once Perl's had its way with them, all files are canonically terminated whether they began that way or not. » But we're trying very hard to get rid of most such special » cases in Perl 6. Usually we can get the recommended Perl » 6 code to just DWYM as a fallout of the general semantics, » but in this particular case, if you really want to read » your input with while, there's a slight "regression" from » Perl 5 insofar as you must explicitly use defined(). This » de-huffmanization is intended as a subtle encouragement to » move from Item-Think towards List-Think. :) Oh. You mean like for directories containing a file whose name is the 1-char string, "0", and that file pre-emptively terminating a readdir loop the way it used to. Whereas nowadays, our compassionate compiler, spotting an incorrectly tested assignment governing a while's conditional: while ( $thingie = <read{dir,lin[ke]}>() ) { ;;; } graciously inserts a defined() opcode for you. Wasn't the reasoning that whenever there's something each and every program must without fail do if it's to be a correct program, that something is too important to be left up to the programmer to forget? Is this rationale no longer sound? It still makes sense to me. Then again, folks can still confuse interating using a while with iterating using foreach. They often appear act the same, so the wrong mental model is held. People grow complacent, having seen the misleading apparent interchangeability between while ( $src = <*.[Cchy]> ) { } foreach $src ( <*.[Cchy]> ) { } or while ( $datum = <$yafh> ) { } foreach $datum ( <$yafh> ) { } They then get quite hung up when these aren't the same: foreach $item (@someitems) { ;;; } while ( $item = shift(@someitems) ) { ;;; } I guess removing special awareness for <read{dir,lin[ke]}> might prod them into thinking more about the whole thing. After all, no special blessing of an inserted defined() op can save them here, condering that this: while ( defined( $item = shift(@someitems) ) ) { ;;; } still isn't the same as this: while (@someitems) { $item = shift(@someitems); ;;; } Still, whenever there's something everyone has to do for a program to function correctly, shouldn't Perl be doing it for them whenever possible, lest they sometimes forget? Think of the Python programs that die because they forget to pre-extend their lists to grow it by one. Perl after all never makes you write: if ($#someitems < $index) { $#someitems = $index; } $sometimes[$index] = $value; EACH AND EVERY $...@%&* time you want to write $sometimes[$index] = $value; but Python does. But perhaps this is something for the <ITERATOR> to see to tkaing care of, or the I/O aka line-discipline, or whatever model you prefer. --tom