in reply to Re^4: nested <FILE> read returns undefined?
in thread nested <FILE> read returns undefined?

I don't think there is a right/wrong way of doing things in this case, just the way a particular language (version) does it. Perl 6 is a very different beast from Perl 5 and I'd guess that what duff describes works because Perl 6 is able to lazily evaluate some things that Perl 5 can't (that's just an uninformed guess though and may be wrong).

Just a note on the documentation though, the Camel is a great book and invaluable when learning and programming Perl. But it is not AFAIK the reference documentation for Perl, that is in the perldocs and you're really missing out if you don't read those.


All dogma is stupid.

Replies are listed 'Best First'.
Re^6: nested <FILE> read returns undefined?
by argv (Pilgrim) on Apr 01, 2006 at 18:56 UTC
    just to bring closure on this-- I wasn't necessarily trying to argue that there was a "right way" or "wrong way" so much as saying that there is ambiguity about whether for $scalar (@array) would cause <FILE> to be read in its entirety, or line-by-line. there are many cases where perl looks at lvalue to determine what to do on the right side, and this seems like just such a case at first blush.

    $line = <FILE>; # reads one line from FILE; @lines = <FILE>; # slurps up the whole thing. for $line (<FILE>) ... # which of the above applies?

    The thing that really makes the visual assessment ambiguous is the placement of $line in the for statement, which is the source of the perceived ambiguity. Granted, I only saw it as the scalar form, and I do realize that it'd be more like saying

    for $line (@lines)

    which clarifies how perl is reading it (and thus, what happens with <FILE>), but seeing both ways now makes the ambiguity more understandable.