When does while() test for defined vs truth

[blakem]

Sometimes while(...) magically deparsed to while(defined(...)), but sometimes it doesn't. How is this decision made?

#### GLOBS cause defined to show up
  # while(<*.pl>) {}         DEFINEDNESS
  % perl -MO=Deparse -e 'while(<*.pl>) {}'
  while (defined($_ = CORE::GLOBAL::glob('*.pl', 0))) {
      ();
  }

  # 1 while (<*.pl>)         DEFINEDNESS
  % perl -MO=Deparse -e '1 while(<*.pl>)'
  '???' while defined($_ = CORE::GLOBAL::glob('*.pl', 0));

#### Simple vars dont
  # while($x) {}             TRUTHFULNESS
  % perl -MO=Deparse -e 'while($x) {}'
  while ($x) {
      (); 
  }
  # '1 while($x)'            TRUTHFULNESS
  % perl -MO=Deparse -e '1 while($x)'
  '???' while $x;

#### Why do these two behave differently????
  # 'while($x = <*.pl>) {}   DEFINEDNESS
  % perl -MO=Deparse -e 'while($x = <*.pl>) {}'
  while (defined($x = CORE::GLOBAL::glob('*.pl', 0))) {
      ();
  }

  # '1 while($x = <*.pl>)    TRUTHFULNESS
  % perl -MO=Deparse -e '1 while($x = <*.pl>)'
  '???' while $x = CORE::GLOBAL::glob('*.pl', 0);

I looked for documentation on this behaviour but couldn't find any. Flow control keywords aren't listed in perlfunc, do they have their own perldoc page?

-Blake

[wog]

Quoth perlop (update on seeing reply: or maybe perlop2):

....

I/O Operators

....

If and only if the input symbol is the only thing inside the conditional of a "while" statement (even if disguised as a "for(;;)" loop), the value is automatically assigned to the global variable $_, destroying whatever was there previously....

...

In these loop constructs, the assigned value (whether assignment is automatic or explicit) is then tested to see whether it is defined....

....

As with filehandle reads, an automatic "defined" is gener ated when the glob occurs in the test part of a "while", because legal glob returns (e.g. a file called 0) would otherwise terminate the loop....

....

[blakem]

Ah, no wonder I couldn't find it... its actually in perlop2.

That still doesn't explain the difference between the last two examples I gave:

# This tests for definedness
while($x = <*.pl>) {}

# This tests for truthfulness
1 while($x = <*.pl>)

Is that a bug, or should the two forms of while() behave differently?

-Blake

[japhy]

When Perl sees you using <FH> or $var = <FH> in a while (or until), it will insert the defined() for you. From perlop in bleadperl:

The following lines are equivalent:

    while (defined($_ = <STDIN>)) { print; }
    while ($_ = <STDIN>) { print; }
    while (<STDIN>) { print; }

(...)

In these loop constructs, the assigned value (whether assignment is automatic or explicit) is then tested to see whether it is defined. The defined test avoids problems where line has a string value that would be treated as false by Perl, for example a "" or a "0" with no trailing newline.

_____________________________________________________
Jeff[japhy]Pinyan: Perl, regex, and perl hacker.
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

[raptnor]

I think you will find an excellent explanation on pages 80 and 81 of the Camel book (3rd edition).

Cheers,
Raptnor

[robin]

Update: Jarkko has now applied this patch, so it'll be fixed in the next version of perl.

As several other respondents have noted, certain constructs should always be treated as implicit definedness tests when used in the loop condition of a while loop. Those constructs are:

• <FILEHANDLE>
• glob(...)
• $variable = <FILEHANDLE>
• $variable = glob(...)

What blakem pointed out is that this isn't working consistently, and if you write a loop of the form 1 while $variable = glob('*.pl'), then the test isn't wrapped in a defined() call, as it should be.

It's a bug in perl. A typo in the newLOOPOP function of op.c, to be precise. It can be fixed by applying the following patch (against bleadperl). I'll send the patch to p5p, and it ought to go into 5.8. Well spotted, blakem!

--- op.c.orig   Mon Dec 17 13:51:32 2001
+++ op.c        Mon Dec 17 13:55:47 2001
@@ -4073,7 +4073,7 @@
              case OP_SASSIGN:
                if (k1->op_type == OP_READDIR
                      || k1->op_type == OP_GLOB
-                     || (k1->op_type == OP_NULL && k1->op_targ == OP_
+NULL)
+                     || (k1->op_type == OP_NULL && k1->op_targ == OP_
+GLOB)
                      || k1->op_type == OP_EACH)
                    expr = newUNOP(OP_DEFINED, 0, expr);
                break;

[impossiblerobot]

You should check perlop; this is a side-effect(?) of the magic between the angle-bracket input operator and while loops.

Impossible Robot