The various logical operators don't return an empty string, they return a false or true value in all three simple scalar types. It just looks like it returns an empty string because print forces a string context on its arguments:
#!/usr/bin/perl
use strict;
use warnings;
use Devel::Peek;
my $t = 5 > 4;
my $f = 5 < 4;
Dump $t;
Dump $f;
Output:
SV = PVNV(0x100802c20) at 0x100827348
REFCNT = 1
FLAGS = (PADMY,IOK,NOK,POK,pIOK,pNOK,pPOK)
IV = 1
NV = 1
PV = 0x100201e60 "1"\0
CUR = 1
LEN = 16
SV = PVNV(0x100802c40) at 0x100827360
REFCNT = 1
FLAGS = (PADMY,IOK,NOK,POK,pIOK,pNOK,pPOK)
IV = 0
NV = 0
PV = 0x100208ca0 ""\0
CUR = 0
LEN = 16
For those not familiar with the Perl 5 internals, a PVNV is a scalar structure that holds all three simple scalar types (integer IV, double precision float NV, and string PV). The flags IOK, NOK, and POK mean that the integer, double, and string values are all in sync (for some definition of in sync) so any one of them may be used (i.e. no conversions need to take place if you use it as an integer, double, or string).
I assume the empty string was chosen for the false string because it is smaller and is more in keeping with the idea of a false string than "0". Ignore my statement about it being smaller, both "" and "1" are the same size: sixteen characters. It says so right in the dump. Perl 5 adds extra space to strings to allow them to grow quickly.
Oh, and I hate you. In researching this I have found that I have lied in perlopquick and will now have to find a way to fix it. If only you had been like all of the other sheep and just accepted Perl 5's surface weirdness as fact, I would have less work to do.
Answers to the questions in the EDIT section:
How would using string which is true ("false" for instance) as a string representation of false values change the meaning of existing code?
The only special things about about PL_sv_yes and PL_sv_no (the canonically true and false values returned by comparison operators) are that they are read only and are created by perl not the program that is running. If you change them, it does not change the truthiness test, so a PL_sv_no that is set to "false" will be treated as true. You can even do this yourself (this code stops working at some point between Perl 5.18 and the latest Perl) using undocumented features of perl:
#!/usr/bin/perl
use strict;
use warnings;
use Scalar::Util qw/dualvar/;
BEGIN {
# use the undocumented SvREADONLY function from Internals to
# modify a reference to PL_sv_no's readonly flag
# note the use of & to make the compiler not use SvREADONLY's
# prototype, yet another reason prototypes are bad and shouldn't
# be used
&Internals::SvREADONLY(\!!0, 0);
# set PL_sv_no to a dualvar containing 0 and "false"
${\!!0} = dualvar 0, "false";
}
if (5 < 4) {
print "oops\n";
}
outputs
opps
This is because the truthiness test looks at strings first.
Could we say that code that changes semantics after such a change is less robust/correct than it could have been?
It will be straight up broken. Even if you restrict yourself to setting it to an int 0 or a string "0" (both of which are false), it will break some valid code.
I guess string context is so pervasive in Perl that the only option leading to sane semantics is if boolean value preserve its value after round tripping to and from a string...
Yes.
