in reply to What could make "()" a good value for boolean false?

If the objective of the hook is to return a Boolean, return 1; or return 0;. I find the idea of sometimes returning 1 and in the case of "false" returning nothing a bad idea.

Yes, a "bare return" return;, will return "nothing" which can be interpreted as "undef" in the caller's code.

"return 0;" is crystal clear. I am returning a false value and I expect you as the caller to check this value. A simple "return;" is also used in the context where there is NO return value and I do not expect the caller to check it. I argue to make the code crystal clear. Geez if this code returns a Boolean, then there must some code somewhere like "return 1;", mirror that for the false value with "return 0;".

Replies are listed 'Best First'.
Re^2: What could make "()" a good value for boolean false?
by Anonymous Monk on Mar 29, 2016 at 06:43 UTC
    return 0 is not false in list context! It suffers from the same problem as return undef described elsewhere in this thread. And ...==0 is not how you check for falsehood in Perl! If you really, really wanted to explicitly return a false value that is not undef and avoid the above problem, you'd have to write "return wantarray?():!1". But since you're writing a function that is evaluated in boolean context, that's unnecessary, since undef is just as false. So I suggest that if you don't like the looks of "return;", write "return; # return false" instead.
[reply]
[d/l]
[select]

      A list with one element is true

      Nope. It's impossible to evaluate whether it's true or false.

      return 0 is not false in list context!

      It's not true either. The concept of truth of something in list context makes no sense.

[reply]

        …Maybe this is what is meant?

        perl -le 'sub bingo { return 0 }; @a = bingo(); print @a ? "True" : "F
+alse"'
True

        [download]
[reply]
[d/l]

        Okay, I'll concede this one:

        $ perl -wMstrict -le 'if((2,1,0)) {print"true"}else{print"false"}'
Useless use of a constant (2) in void context at -e line 1.
false

        [download]

        Although that's the comma operator operating in scalar context, (2,1,0) might be what people might think of when they think "list". But:

        $ perl -wMstrict -le 'if(()=(2,1,0)) {print"true"}else{print"false"}'
true

        [download]

        although admittedly that's the result of a list assignment in scalar context.

        In this thread we're talking about return, and I haven't yet found a way for a return 0; in some kind of list context to be evaluated as false:

        $ perl -wMstrict -le 'sub foo { print wantarray?"list":"scalar";
  return (0); }; if(foo) {print "true"} else {print "false"} '
scalar
false
$ perl -wMstrict -le 'sub foo { print wantarray?"list":"scalar";
  return (0); }; if(()=foo) {print "true"} else {print "false"} '
list
true
$ perl -wMstrict -le 'sub foo { print wantarray?"list":"scalar";
  return (0); }; my @x=foo;if(@x) {print "true"} else {print "false"}'
list
true

        [download]

        Although those last two are respectively, a list assignment and an array, not exactly a list.

        So in the above examples, it's never really the lists which are directly in boolean context, so I kind of get what you are saying. But then again, the way I see it conceptually, in Perl, when you evaluate lists/arrays in a scalar context they evaluate to one of two things: their last element (although that one is usually the result of the comma operator in scalar context), or a count of their elements - and at least in my mind that's the underlying principle why a list with >0 elements is always "true". I haven't yet been able to come up with a counterexample where a list with at least one element somehow fiddled into a boolean context evaluates to false; if you've got one, I don't mind being proven wrong.

        For my final argument, perlsyn, emphasis mine:

        The number 0, the strings '0' and "", the empty list (), and undef are all false in a boolean context. All other values are true.
[reply]
[d/l]
[select]
        The concept of truth of something in list context makes no sense.
        As fas as I understand it truth - as fas as perl is concerned - is the result of evaluating something in boolean context.

        In boolean context an array evaluates just like in scalar context to it's length.

        Therefore I would claim that the statement above ("A list with one element is true") is actually correct.

[reply]
      This list context idea doesn't appear to have anything to do with the requirements for a "hook" for this terminal emulator. The hook returns something that is evaluated in a scalar context. When the hook fails, it should: return 1;. The suggestion for when the hook succeeds is to end the sub with simply (), instead of even a return! Ok, if that is what you want to do, then I would agree that "return;" is better than a simple "()". Perl will return the value of the last statement in a sub if there is no explicit return. I argue that return (0); is better than a simple () or bare "return;" when the objective is to return a simple scalar true/false.

      One of the pages that talks about this: Hooks. You can see some examples of code at Example Hook Code. It is clear to me that the intent is a simple true/false that will be evaluated in a scalar, not list context.

[reply]
        I argue that return (0); is better than a simple () or bare "return;"

        Why? What would the advantage of that be?? The disadvantage has been discussed in this thread.

        One of the pages that talks about this: Hooks.

        Sorry, but that page only contradicts your argument. Nowhere is a guarantee made as to which context the hooks are called in (the documentation of the callback on_osc_seq even explicitly says "The default should be to return an empty list."). The page explicitly says "All of these hooks must return a boolean value. ... When in doubt, return a false value (preferably ())." As per Truth and Falsehood, the false values in Perl are: "The number 0, the strings '0' and "", the empty list (), and undef". A list with one element is true, and so again, return 0 is not always false!

        Further I argue that your interpretation of the intent is wrong. If the author of the documentation wanted you to return 1 or 0, or if the hooks were always evaluated in scalar context, he/she would have said so. By deliberately telling users to return the empty list (), they are, for example, keeping the door open for the hooks API to be more easily extended in the future - hooks could return multiple values.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom