---+ SHORT ANSWER
Here are two self-consistent schemes for Booleans in Perl:
1/0 - printable and portable1/!!0 - most like Perl's native boolean functions
1/0is probably most familiar to programmers from other languages, like C or Python. You can print 1/0 Boolean values, add them, and so on. But... Perl's native Boolean operators are not 1/0 values, return $a<0 is NOT the same as return 1 if $a<0; return 0.
1/0!! is my attempt to create an abbreviated name for the scheme that Perl's native Boolean operators use: 1 for true, an empty string that is specially marked so that it does not produce warnings when used in arithmetic or interpolated into strings. !!0 is one of the easiest ways to produce this special Perl false value, and should be familiar to programmers in many languages like C as a way of standardizing Boolean values. You can add 1/0!!, and you can print 1/0 Boolean values, so long as you don't care if the false value may be invisible, i.e. an empty string.
Avoid accidentally mixing numeric 1/0, Perl's native conditions, undef, and other schemes in the same function or library.
When deliberately mixing, use conversion operators such as
!!$bool_0or1 to convert to a traditional 1/!!0Perl value(0+($a<0)) to convert a Perl relational result to 1/0(!!any_other_boolean())(0+any_other_boolean())($other_bool?1:()) to convert to 1/() from the other boolean schemes ($other_bool?1:undef) to convert to 1/undef from the other boolean schemes
Q: are there any shorter or prefix-ish notations, other than ?:?
There are some more possible schemes
1/() - more precisely, return 1 or nothing -- which can catch
some Perl-ish errors like returning a boolean scalar false like 0 or
undef in a list context, where it would become true(1)/(0) - return a list of length 1 conrtaining 1, or an empty
list. Similar to 1/(), consistent in the sense that both true and
false are arrays.1/undef - another possibility, catches errors that 1/() return 1
or nothing may cause
I hesitate to recommend these. At the very least, 1/() is inconsistent in that But... they certainly have been used by Perl programmers, so you should be prepared to deal with code that uses these schemes. I.e. be prepared to debug bugs caused by these schemes.
1/() is my attempt to create an abbreviated name for a scheme where functions that return true return 1;, and functions that return false do return;, i.e. a return with no operand value. I.e. return 1 or nothing. I believe that return nothing is equivalent to return ();. This scheme protects you against bugs caused by a programmer evaluating your function in a list context rather than a scalar context. But it exposes you to bugs such as {1=>return_nothing_if_false(),2=>return_nothing_if_false()} (snce you probably do not want {1=>2}.
BTW I think that it might be more consistent to do the scheme (1)/(). This would allow you to consistentl;y have variables of this Boolean type, admittedly @array variables.
Note that 1/undef is NOT equivalent to any of the above. 1/undef Boolean variables give warnings when false=undef is printed or interpolated or used in arithmetic, but not when true=1 is so-manipulated, and evaluates to true in a list context. One might be tempted to say that it has the worst features of all the schemes.
I hesitate to hesitate these schemes 1/(), (1)/(), or 1/undef. At the very least, 1/() is inconsistent in that
All three of these schemes 1/(), (1)/(), or 1/undef expose you to bugs such as {1=>f1_return_nothing_if_false(),2=>f2_return_nothing_if_false()} , since you probably do not want {a=>"b"} if both are false, and {a=>1,b=>1} if both are true. At least if f1 returns true and f2 returns false, or vice versa, you will get a warning about odd sized hash.
The programmer calling a function can control whether it is evaluated in list or scalar context, but she may not be able to control whether it returns true or false.
IMHO, if you do 1/(), (1)/(), or 1/undef you cannot safely call such functions in array context, like building keyword arguments foo(kw=>boolfunc(),...) or foo({kw=>boolfunc(),kw2=>...},...). Not without having to scatter !! or 0+ all over.
---+ MEDIUM LENGTH ANSWER
Generalizing original answer:
Perl has many ways of representing truth; or, rather, Perl interprets many different values as true or false.
If you are creating a family of related functions, i.e,. a library, you are advised choose one of the following well-known schemes, and to use it consistently in your library:
Truth 1/0 - numeric - most portable to/from other languages, and more printable
Truth 1/!!0 - most like standard Perl relational operators, less portable, less printable (unless you want false to be invisible)
This answer emphasizes Boolean functions or methods, predicates. It is not trying to discuss non-Boolean functions, that return actual things like numbers or strings or refs - except briefly below.
@DaveCross suggests an additional interesting scheme
return 1 / return nothing (almost 1/(), the empty list)
a scheme that I remember from the early days of Perl - before refs, I think even before undef was a value that could be returned. But IIRC there are problems with this scheme and use warnings, possibly also ?:, so I hesitate to recommend it fully until somebody explains better how to avoid such problems. Possibly using wantarray.
---++ Choose 1/0 or 1/0!! (native Perl) and be consistent
I recommend that you choose one of these Boolean schemes, and use that scheme consistently.
The 1/0 boolean scheme is probably most portable to other languages.
The 1/!!0 scheme will make your code more closely resemble native Perl operators.
If you are using the 1/!!0 scheme, don't say "return 0", say return !!0.
If you are using the 1/0 scheme, don't say return $a < $b, instead say return 0+($a < $b)
If you are calling code that uses a different Boolean scheme (or, possibly, no consistent scheme), convert to the Boolean scheme that you use in your code, using operators such as
!! to normalize a standard Perl 1/0!! Boolean 0+ or 1* to convert to a more portable 1/0 boolean from a standard Perl 1/0!! boolean?: and all the rest of Perl's arsenal for undefs and strings that may or may not want to be considered false or failures
If looking at the return value of a function that returns a ref or undef
If 1/!!0 Perl-like Booleans, say return !!ref_retval_func() or defined ref_retval_func()
If 1/0 more portable Booleans, say return 0+!!ref_retval_func() or 0+(defined ref_retval_func())
Way too much detail below.
---++ Possible?: return 1 or return nothing scheme (possibly 1/()?)
@DaveCross makes an interesting suggestion:
return 1 for a Boolean true value.
return nothing for a Boolean false value. That's because a bare
return will return an appropriate value depending on how the
subroutine has been called. The documentation for return says this:
If no EXPR is given, returns an empty list in list context, the undefined value in scalar context, and (of course) nothing at all in void context.
---++ Anti-Recommendation: do not mix Boolean schemes
E.g., in the same function or library, do NOT do
return $arg1 < $arg2; # returning a standard Perl 1/!!0 Boolean
in one place, and then somewhere else, or in later evolutions of the same code, do
return 0;
return undef;
return '';
return ();
I.e. choose one Boolean scheme, and be consistent. Mainly, this involves being consistent about the false value; to a lesser extent the true value.
---+ EXCESSIVE MESSY DETAIL
---++ Discussion elsewhere about Perl's many values of truth
Posts such as What do Perl functions that return Boolean actually return and Why does Perl use the empty string to represent the boolean false value? discuss what Perl boolean functions and operators actually return. Basically special values, whose behavior is specified by the Perl manuals.
@cim links to the perl manuals: http://perldoc.perl.org/perlsyn.html#Truth-and-Falsehood
Truth and Falsehood
The number 0, the strings '0' and "" , the empty list () , and undef
are all false in a boolean context. All other values are true.
Negation of a true value by ! or not returns a special false value.
When evaluated as a string it is treated as "" , but as a number, it
is treated as 0. Most Perl operators that return true or false behave
this way.
Similarly http://perldoc.perl.org/perlop.html#Relational-Operators
Relational Operators
Perl operators that return true or false generally return values that
can be safely used as numbers. For example, the relational operators
in this section and the equality operators in the next one return 1
for true and a special version of the defined empty string, "" , which
counts as a zero but is exempt from warnings about improper numeric
conversions, just as "0 but true" is.
Unfortunately, the accepted answer for What do Perl functions that return Boolean actually return
discusses the internals, but then recommends
my $formatted = $result ? '1' : '0';
which is back to where we started.
@amon shows us the light (!!) in a comment on the question What do Perl functions that return Boolean actually return
Sidenote: you can turn any value into its corresponding boolean with
double negation. This leads to the !! pseudo-operator. Very useful for
returning the generic truthy or falsey value instead of some magic
number. – amon Nov 22 '12 at 22:11
There does not seem to be any literal for these special Booleans. There are, however, many ways of producing them: (0<0), (0<1), etc. (!!1) and (!!0) are probably the nicest - especially since in some C/C++ programming circles they are used for a similar purpose. Plus, !! can be applied to an incoming truth value to "normalize" it to this "Perl standard" boolean.
---++ Anti-Recommendation: do not mix Boolean schemes
E.g., in the same function or library, do NOT do
return $arg1 < $arg2; # returning a standard Perl 1/!!0 Boolean
in one place, and then somewhere else, or in later evolutions of the same code, do
return 0;
return undef;
return '';
return ();
I.e. choose one Boolean scheme, and be consistent. Mainly, this involves being consistent about the false value; to a lesser extent the true value.
e.g. Avoid evolving code from
return $arg1 < $arg2; # returning a standard Perl 1/!!0 Boolean
to
if( $arg1 < $arg2 ) {
log_or_print('found $arg1 <$arg2');
# other stuff to do if less-than
return 1;
} else {
log_or_print('found not( $arg1 < $arg2)');
# other stuff to do if not-less-than
# which may not be the same thing as greater-than-or-equal
return 0;
}
or
if( $arg1 < $arg2 ) {
...
} else {
...
return undef;
}
Coming to Perl from somewhere else, you may think that these are equivalent, and they mostly are, but if you do things like printing boolean return values in tests you will get differences.
If you evolve code from a Perl-ish boolean operator
return $arg1 < $arg2; # returning a standard Perl 1/!!0 Boolean
evolve it to
if( $arg1 < $arg2 ) {
log_or_print('found $arg1 <$arg2');
# other stuff to do if less-than
return 1;
} else {
log_or_print('found not( $arg1 < $arg2)');
# other stuff to do if not-less-than
# which may not be the same thing as greater-than-or-equal
return !!0;
}
If you want behavior to be as close to the same. Note the !!0 on the return of false, As far as I know, there is no simpler way to construct Perl's special return value for false.
Conversely, if you want to use the 1/0 Boolean scheme, them the original code should have been written as
return 0+($arg1 < $arg2); # returning a standard Perl 1/!!0 Boolean
---++ Creating a predicate from value / undef
Similarly, you may be tempted to take a function such as
sub find_string_in_table {
# returns string value if found, undef if not found
return $lookup_table->{$_[0]};
}
and refactor it to a predicate
sub is_string_in_table {
return find_string_in_table(@_);
}
and then later evolve to, perhaps, have a sanity check or performance optimization.
sub is_string_in_table {
return 0
# don't even bother for long strings
if 1000000 < length($_[0]);
return find_string_in_table(@_);
}
This is neither 1/0 nor 1/!!0, and is not consistently value/undef either.
(Note: I am not saying this pre-check is a performance optimization --- but I am saying that performance optimizations might look like the above. Performance optimization is one of my specialties, and you want such optimizations to be refactoring. It sucks when optimized code performs better, but breaks in some of the places it is used. Hence my interest in code that performs as exactly like ... whatever it is replacing, like native Perl relational operators. Exactly means exactly.)
Instead do something like the following if you are using standard Perl-ish booleans.
sub is_string_in_table {
return !!0
# don't even bother for long strings
if 1000000 < length($_[0]);
return (defined find_string_in_table(@_));
}
or if you are using 1/0 Booleans
sub is_string_in_table {
return 0
# don't even bother for long strings
if 1000000 < length($_[0]);
return 0+(defined find_string_in_table(@_));
}
If instead of find_string_in_table it was find_object_ref_in_table, you might do just return 0+!!find_string_in_table(@_) because you would not need to worry about strings like q() and "0".
If you want boolean functions in code you write to behave like native Perl operators return (!!1) for true and (!!0) for false.
I.e. 0/1, but logically negate twice using the ! operator to convert your 1 or 0 into Perl's 'native' boolean.
e.g.
sub my_boolean_function {
...
return !!1; # true
...
return !!0; # false
}
**---+ 0/1 --> 1/!!0 conversion **
If you consider !! as a conversion from "meta-boolean" to "special boolean",
consider 1* or 0+ as a conversion from special boolean to ordinary 0/1 boolean.
E.g. print "test".(1*($a eq $b))."\n"
E.g. print "test".(0+($a eq $b))."\n"
?: is more general, but more verbose.
---++ Non-Boolean error returns
This question and answer emphasizes Boolean functions or methods, predicates. It is not trying to discuss non-Boolean functions, that return actual things like numbers or strings or refs - except briefly below.
It is "nice" to have the return value extended to indicate special conditions such as failure, invalid input, etc., and which may be evaluated in the context of IF statements or other control flow such as and and or operators, typically to handle such errors, e.g. to provide default values.
We will limit our discussion of non-Boolean functions to this short list:
ref / undef : for functions that return a typical http://perldoc.perl.org/perlobj.html object, a ref to a blessed hash or other type. Return undef on error, not found, etc.
any value / undef : for functions that return any type of value, scalar number or string, scalar ref whether blessed or unblessed.
value/undef works best when undef is not a legitimate return value and can be problematic when undef is a legitimate value.n E.g. imagine an accessor function that returns the value of a hash field, $hash->{field} -- the field might legitimately have the value { field => undef }, so returning undef dfoes not distinguish between the field not existing and the field existing but having an undef value.
- Arbitrary strings, that may contextually be interpreted as numbers or booleans.
- "0 but true" - I really don't want to get into this, but look at What does "0 but true" mean in Perl? for the special handling of string "0 but true". Other strings give warnings on conversion to a number, but "0 but true" does not.
- "0E0" - Similarly, some Perl code returns the string "0E0" which evaluates to 0 as a number, but true as a Boolean
GLEW personal opinion: since I write code that often needs to be ported to other languages, I prefer not to take advantage of Perl-specific tricks like 0+"0 but true". "0E0" at least is more portable, if you imagine that in some other language like C a function convert_string_to_float("0E0") or convert_string_to_int("0x0"). I prefer "0x0" because it looks special with the x, and 0x0 is an integer value, whereas 0E0 is interpreted as a float in some languages, so is more likely to give an error.
---++ Possible?: return 1 or return nothing scheme (possibly 1/()?)
@DaveCross makes an interesting suggestion:
return 1 for a Boolean true value.
return nothing for a Boolean false value. That's because a bare
return will return an appropriate value depending on how the
subroutine has been called. The documentation for return says this:
If no EXPR is given, returns an empty list in list context, the undefined value in scalar context, and (of course) nothing at all in void context.
This is important as true and false values can differ subtly between scalar and list context. Imagine a subroutine like this: ...
@DaveCross goes on to show how returning any value other than the empty list results in loss of false-ness if a boolean function is evaluated in array context. Even @array=(undef) evaluates as true.
I would like this scheme to work. I think that I used it years ago, in Perl 4 or earlier, but gave up on it when use warnings started becoming the thing to do.
Insofar as I recall, I also had problems with conditional exprtessions ?: wigth this convention.
I have tried both "return;" and "return();"
Consider
% perl -wle 'print "a()=<<".a().">>\n"; sub a {if(@_) {return 1} else {return}}'
Use of uninitialized value in concatenation (.) or string at -e line 1.
a()=<<>>
% perl -wle 'print "a()=<<".a().">>\n"; sub a {if(@_) {return 1} else {return ()}}'
Use of uninitialized value in concatenation (.) or string at -e line 1.
a()=<<>>
% perl -wle 'print "a()=<<".a().">>\n"; sub a { return @_ } '
a()=<<0>>
% perl -wle 'print "a()=<<".a().">>\n"; sub a { return !!@_ } '
a()=<<>>
%
---+ BOTTOM LINE
Use 1/0 (printable and portable), 1/0!! (most like Perl's native boolean functions).
Possibly return 1 or return nothing, which is almost the same as 1/(). (But I have had problems with this approach.)
Avoid mixing numeric 1/0, Perl's native conditions, undef, and other schemes in the same function or library.
Finally, if you have ever done
$> perl -wle 'print false && true'
you may have received
Unquoted string "false" may clash with future reserved word at -e line 1.
Unquoted string "true" may clash with future reserved word at -e line 1.
Bareword found in conditional at -e line 1.
true
so it appears likely that some day Perl may have an "official" scheme for Booleans, with values true and false.
I wonder how those will behave?
'0 but true'is a good one to know. It's recognized by Perl as a "special" 0, so even when you havestrictandwarningsenabled (that would object to a string with non-numeric contents being used in a numerical context), it silently gets treated as numeric 0, but as boolean true. – Cambraireturn 0is true in list context? – Yunyunfei