SPUG: "Boolean" return values

Colin Meyer cmeyer at helvella.org
Tue Oct 14 08:51:21 PDT 2008


On Tue, Oct 14, 2008 at 12:21:15AM -0700, Michael R. Wolf wrote:
> 
> Thanks for the reply.  It helped me reformulate my question (even if I 
> don't understand all nuances of the underlying C code as reported by 
> Devel::Peek).

Er, yeah. I guess that everyone doesn't have the same level of curiosity
about the internal workings of Perl. I'm compelled to use tools like
Devel::Peek to enhance my understanding of what is occurring when I ask
Perl to do various things. My curiosity level is still small, relative
to some folks, like Josh, who has sacrificed several of his precious and
limited sanity points to further his understanding of what is happening
and how Perl does it.

One thing to keep in mind is that Perl scalars are not the simple values
that they handily appear to be, when you are using them. In fact, they
are complex objects that behave differently in different contexts. They
are also super-optimized, both for speed and for reasonably small memory
use (given their capabilities). In fact, Perl scalars are not one class
of object, but a whole family of classes, the best one being used at any
moment, but might morph into one of the other scalar types, when it
becomes necessary. 

So, a Perl scalar may have several values, an integer, a floating point
number, a string value or a reference. This is a simplification, really.
Perl overloads these values like crazy (really, crazy). In order to keep
track of how the values have been used, and which are still valid,

Or, you could not keep all that nonsense about scalars in mind, and
perhaps save your sanity. :)

If your 401k is already so low that you've already lost all sense of
caution, then you might be interested in perusing:

    perldoc perlguts 

> 
> Boolean (err, 'logical') operator return values, Take 2:

The concept of boolean, while quite natural to any logical thinker, is
something that got a little muddled in Perl5. The perlsyn manpage says,

    The number 0, the strings '0' and '', the empty list "()", and
    "undef" are all false in a boolean context. All other values
    are true.

This is the most important thing to keep in mind whenever dealing with
"boolean" values or using "boolean" / "logical" operators or conditional
constructs.

> 
> The 6 relational operators (both the stringy and numy flavors), and 
> various other logical operators seem to return reasonable values in the 
> IV and NV slots (specifically 1 for "true" and 0 for "false").  I don't 
> understand why the PV slot is "1" for true and "" for false.  Why not 
> "1" and "0" so that the stringy value corresponds to the numy value?

Ah, that's a good question. I really don't know the answer.

> 
> It's especially confusing to folks (me included) who write code like this:
> 
> $true = 1 < 100;
> $false = 100 < 1;
> 
> print "true is '$true' and false is '$false'\n";
> 
> It seems non-parallel, or imbalanced.  Can you reframe it for me in a 
> way that makes sense, creates balance, and seems consistent (for some 
> definition of consistent)?

I guess that it makes sense to me. In regular code, I don't have the
desire to print out the values of $true and $false. I'd be more inclined
to use them in a boolean context, and write something like:

    print 'Your number is ',
        ( $num < 100 ? 'less' : 'greater' ),
        ' than 100';

If I'm feeling more curious or unsane, I'll use a tool like Devel::Peek
to have a look at what the thing really is.

-Colin.


More information about the spug-list mailing list