in reply to Re^2: What could make "()" a good value for boolean false?
in thread What could make "()" a good value for boolean false?

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.

  • Comment on Re^3: What could make "()" a good value for boolean false?

Replies are listed 'Best First'.
Re^4: What could make "()" a good value for boolean false?
by Anonymous Monk on Mar 29, 2016 at 09:18 UTC
    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.