Front page | perl.perl6.language |
Postings from March 2005
Re: s/true/better name/
From: Rod Adams
March 16, 2005 22:13
Re: s/true/better name/
Message ID: 42391FE9.email@example.com
Larry Wall wrote:
>On Wed, Mar 16, 2005 at 01:22:06PM -0600, Rod Adams wrote:
>: 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
Well, "and" and "or" serve the purpose of being at a much lower
precedence level than "&&" and "||".
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.
> 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);
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
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