develooper Front page | perl.perl6.language | Postings from March 2005

Re: s/true/better name/

Thread Previous | Thread Next
Rod Adams
March 16, 2005 22:13
Re: s/true/better name/
Message ID:
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
>"or" either. 
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 
part of...

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

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About