Explaining Perl truth to beginners

shemp has asked for the wisdom of the Perl Monks concerning the following question:

I've been writing extensive documentatin about some of my code at work, and just stumbled across a need to properly define truth for Perl. I remember the concept being a little foreign to myself when i first learned Perl, even with over 10 years of other languages behind me. At its simplest, there are three false values for scalars:

empty string

undef

But then there are situations where a value was defined as "0.0", which is true, but then if you treat it as a number, in certain contexts if becomes "0", which is false. For instance:

my $string = "0.0";
print "true\n" if $string; # true
my $x = 3 + $string;
print "true\n" if $string; # true
$string += 0; 
print "true\n" if $string; # false
[download]

I guess maybe this gets beyond the scope of truth vs. false and gets into Perl's loose variable typing, and how they interact. Anyway, any advice for how to properly explain Perl's concepts of truth and false?

Update:
Someone mentioned that i might want to test $x in the second example. Actually, i want to test string. That one is an example of using $string in a numeric context, but it doesn't set the internal falg for $string to say that it was most recently used as a number. (sorry for butchering this explanation, i don't know exactly how the internals work for scalars in perl)

I use the most powerful debugger available: print!

Comment on Explaining Perl truth to beginners Download Code

Replies are listed 'Best First'.
Re: Explaining Perl truth to beginners by davidrw (Prior) on Nov 21, 2005 at 19:03 UTC
True or False? A Quick Reference Guide is a very good tutorial and discussion (currently tied for #12 of Best Nodes of the year), and also has a few other threads listed in its References section. It does include "0.0" in its charts, as well.	[reply]
Re: Explaining Perl truth to beginners by Tanktalus (Canon) on Nov 21, 2005 at 19:06 UTC
Performing a Super Search on titles of 'truth', I got What is truth? (Curiosity corner) which is robin's attempt to talk at great length about this. That may help. That wasn't the one I was looking for, so again with the Super Search - this time on text of 'truth table', where I found bobf's True or False? A Quick Reference Guide. That, too, may help, although I think robin's was a bit more of a gem find. Random node walking ... via Super Search. Fun. :-)	[reply]
Re: Explaining Perl truth to beginners by merlyn (Sage) on Nov 21, 2005 at 20:26 UTC
The way we used to explain it in the Learning Perl class keeps it simple. Convert the value to a string (if it isn't already). If it's the empty string, or a string consisting only of a single 0 digit, it's false. Otherwise, it's true. Of course, this ignores overloaded values, which can define their own boolean interpretation, but the strategy was written before that was possible. -- Randal L. Schwartz, Perl hacker Be sure to read my standard disclaimer if this is a reply.	[reply]
Re: Explaining Perl truth to beginners by Roy Johnson (Monsignor) on Nov 21, 2005 at 19:05 UTC
For beginners: the output of a boolean operation is reliably interpreted as true or false. Everything else should be tested by comparison. The one idiomatic exception I can think of is `while (<INPUT>) { ...` [download] which has an implicit boolean test in it. Nothing else springs to my mind. Caution: Contents may have been coded under pressure.	[reply] [d/l]
Re^2: Explaining Perl truth to beginners by ysth (Canon) on Nov 22, 2005 at 12:51 UTC
which has an implicit boolean test in it. Actually, an implicit defined() test in it: `$ perl -MO=Deparse -e'while (<INPUT>) {}' while (defined($_ = <INPUT>)) { (); } -e syntax OK` [download] so that e.g. a 0 with no following newline at the end of a file still goes into the body of the loop.	[reply] [d/l]
Re: Explaining Perl truth to beginners by philcrow (Priest) on Nov 21, 2005 at 19:05 UTC
I usually use a series of examples. I try to make them as practical as possible. It helps if the readers are active and writing their own code as they read. Formal descriptions are helpful AFTER readers understand how things normally work and even then examples of actual tricky cases are necessary. Draw all examples from your shop's code base. Phil	[reply]


"be consistent"
	PerlMonks