Larry Wall wrote:
On Wed, Mar 16, 2005 at 01:22:06PM -0600, Rod Adams wrote:Well, "and" and "or" serve the purpose of being at a much lower precedence level than "&&" and "||".
: Larry Wall wrote:
: : >On Tue, Mar 15, 2005 at 12:28:15PM -0700, Marcus Adair wrote:
: >: Isn't saying "false doesn't exist" like saying, "dark doesn't exist"? : >: Why have a word for that?
: >: : >: I'm really afraid I'm missing something obvious here, but I'm worried : >: that neither "whether" nor "indeed" work very well in many contexts. It : >: seems to me that testing trueness exists in so many contexts that it's : >: going to be hard to find an English word that fits all the important : >: ones.
: >
: >Most of those contexts are implicitly boolean, and this function would
: >be redundant there. The main use for this function is to provide a
: >boolean context for its argument and return 0 or 1 when you really
: >do want 0 or 1 for some context that isn't directly boolean. This
: >is actually relatively rare.
: > : >
: Doesn't C< +?(...) > take care of those cases?
: : Sure, it's line noise, but do we really need a new keyword for something : that's "relatively rare"?
: Especially when that keyword is likely to confuse people a lot more than : the application of two unary operators?
Well, sure, but by a similar argument we don't need "not", "and", or
"or" either.
I would see the value in alphabetic "not" as serving the same relation to "!". But I would still see it returning a Bool, not a numified 0 or 1. I could see a "boolean" operator serving the same relation to "?".
But for those cases where someone absolutely has to have a 1 or 0, not some Boolean object, sticking a "+" or "int" in front of a "!", "?", "not", or "boolean" seems to cover that case fine.
You're going to have that problem with any word you come up with, given "and" and "or"'s relationship with assignment. Unless you make the word magically alter the operator precedence table for any statement it's a part of...I think an acknowledgement of its rarity could show up in making it something relatively long like "whether". On the other hand, I have a linguistic problem with "whether" in that in English it seems to be looser than "and", and "or", while as a "positive not" in Perl, it would be classified as tighter. That is,
$x = whether $a or $b; $x = not $a or $b;
would actually be parsed as
$x = whether($a) or $b; $x = not($a) or $b;
whereas as a native English speaker would probably expect
$x = whether($a or $b);
Which could happen if you make it a macro that adds some strategic parens for the user. But that jumps way over the "least surprise" line....
So I'm thinking we'll just go back to "true", both for that reason,
and because it does syntactically block the naughty meaning of true as
a term (as long as we don't default true() to $_), as Luke reminded us.
Wouldn't a warning cover that?
-- Rod Adams
