In #perl6, Freenode, after again having to explain that "true" is the opposite of "not" and NOT the value for "true", and that "false" doesn't exist, and that the real true value is "bool::true" and shouldn't be used much, and that no, it isn't "true", and no, "true" doesn't always return "bool::true", but despite its name can also return "bool::false", and then explaining everything again, we kind of agreed that "true" is a misleading name. In my opinion, it's the biggest violation of the whole least surprise thing in Perl 6's current design.
Autrijus suggested "indeed" or "id", of which I like "indeed" better, because I'd like to continue using "id" with databases.
On Tue, Mar 15, 2005 at 10:51:57 +0100, Juerd wrote: > Autrijus suggested "indeed" or "id", of which I like "indeed" better, > because I'd like to continue using "id" with databases.
whether?
-- () Yuval Kogman <nothingm...@woobling.org> 0xEBD27418 perl hacker & /\ kung foo master: /me beats up some cheese: neeyah!!!!!!!!!!!!!!!!!
> On Tue, Mar 15, 2005 at 08:23:19AM -0800, Larry Wall wrote: > > I'd go with either "istrue" or "so". "ok" is another possibility, > > though that seems to connote definedness more than truth. > Hmm, "so" is so good. So can we make it so? :)
On Tue, Mar 15, 2005 at 12:13:52PM +0200, Yuval Kogman wrote:
: On Tue, Mar 15, 2005 at 10:51:57 +0100, Juerd wrote: : : > Autrijus suggested "indeed" or "id", of which I like "indeed" better, : > because I'd like to continue using "id" with databases. : : whether?
That's an interesting possibility, though I think about half the people would misspell it. Maybe that's a feature. It works well for:
$yesno = whether any(@foo) == @any(@bar);
I don't mind it being long.
I should point out I'm rethinking the idea of whether or not whether and not should be list operators. "not @foo" would have unexpected consequences if it forces list context, so I think we better let people hyper those manually if needed. I think we can leave "not" at the precedence of list operators without actually making it one, but maybe we should make a separate precedence level for it to keep list op precedence "pure".
On Tue, Mar 15, 2005 at 08:23:19AM -0800, Larry Wall wrote: > I'd go with either "istrue" or "so". "ok" is another possibility, > though that seems to connote definedness more than truth.
> On Tue, Mar 15, 2005 at 12:13:52PM +0200, Yuval Kogman wrote: > : On Tue, Mar 15, 2005 at 10:51:57 +0100, Juerd wrote: > : > Autrijus suggested "indeed" or "id", of which I like "indeed" better, > : > because I'd like to continue using "id" with databases. > : whether? > That's an interesting possibility, though I think about half the people > would misspell it. Maybe that's a feature. It works well for: > $yesno = whether any(@foo) == @any(@bar);
Seeing it in an example, I love this suggestion.
And re its spelling, that's a very good feature, because it'll slowly teach me how to spell this word. And when I know how to spell it, I can use it on IRC without dict(1)ing to see if I remembered correctly. This will eventually save me hours! :)
> I should point out I'm rethinking the idea of whether or not whether and > not should be list operators.
Nice use of both languages.
I've wondered today how their being list ops would work in practice. Does it work like any(), all(), or is only one of the elements evaluated?
On Tue, Mar 15, 2005 at 05:57:57PM +0100, Juerd wrote: > And re its spelling, that's a very good feature, because it'll slowly > teach me how to spell this word. And when I know how to spell it, I can > use it on IRC without dict(1)ing to see if I remembered correctly. This > will eventually save me hours! :)
One problem you may find with dict is that one common misspelling, "wether", is also a valid English word, which any decent word list should contain. (It's a castrated ram)
> On Tue, Mar 15, 2005 at 05:57:57PM +0100, Juerd wrote: > > And re its spelling, that's a very good feature, because it'll slowly > > teach me how to spell this word. And when I know how to spell it, I can > > use it on IRC without dict(1)ing to see if I remembered correctly. This > > will eventually save me hours! :) > One problem you may find with dict is that one common misspelling, "wether", > is also a valid English word, which any decent word list should contain. > (It's a castrated ram)
Dict uses dictionaries, not just word lists. It outputs the definition(s), so this misspelling is easily detected.
I know both words exists. I just can't manage to remember which one is which, and maybe Perl 6 can help me :)
Larry Wall wrote: >On Tue, Mar 15, 2005 at 12:13:52PM +0200, Yuval Kogman wrote: >: On Tue, Mar 15, 2005 at 10:51:57 +0100, Juerd wrote: >: >: > Autrijus suggested "indeed" or "id", of which I like "indeed" better, >: > because I'd like to continue using "id" with databases. >: >: whether?
>That's an interesting possibility, though I think about half the people >would misspell it. Maybe that's a feature. It works well for:
> $yesno = whether any(@foo) == @any(@bar);
>I don't mind it being long.
>I should point out I'm rethinking the idea of whether or not whether and >not should be list operators. "not @foo" would have unexpected consequences >if it forces list context, so I think we better let people hyper those >manually if needed. I think we can leave "not" at the precedence of >list operators without actually making it one, but maybe we should make >a separate precedence level for it to keep list op precedence "pure".
I don't see the point of making them list ops. Leaving them at that precedence level makes sense, but leave them unary. For a list version, you can write C<?any(...)> or C<?none(...)> to do the same thing.
On Tue, Mar 15, 2005 at 08:23:19AM -0800, Larry Wall wrote: > On Tue, Mar 15, 2005 at 10:51:57AM +0100, Juerd wrote: > : Autrijus suggested "indeed" or "id", of which I like "indeed" better, > : because I'd like to continue using "id" with databases.
> "id" is too heavily overloaded with identifiers and identities and such. > But "indeed" doesn't work right in context, "while indeed..."
> I'd go with either "istrue" or "so". "ok" is another possibility, > though that seems to connote definedness more than truth.
It also breaks a huge percentage of the testing code that we would like to be able to automagically port from P5 to P6.
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.
Additionally I question whether this is truly a case improving to the point of least surprise? After all, I don't know a programmer who's going to be surprised by what true means. There are still *some* things you may have to learn in software dev 101 ;)
Marcus Adair writes: > Additionally I question whether this is truly a case improving to the > point of least surprise? After all, I don't know a programmer who's > going to be surprised by what true means. There are still *some* things > you may have to learn in software dev 101 ;)
The problem is this (common) one:
if answer() == true { # do something }
We want to give the programmer no good way to do that, because it's wrong.
Either that, or we could define true to be the disjunction of all things true. Then that would work correctly, even when answer() is returning something more interesting than a bare bool.
Juerd writes: > Nicholas Clark skribis 2005-03-15 17:53 (+0000): > > On Tue, Mar 15, 2005 at 05:57:57PM +0100, Juerd wrote: > > > And re its spelling, that's a very good feature, because it'll slowly > > > teach me how to spell this word. And when I know how to spell it, I can > > > use it on IRC without dict(1)ing to see if I remembered correctly. This > > > will eventually save me hours! :) > > One problem you may find with dict is that one common misspelling, "wether", > > is also a valid English word, which any decent word list should contain. > > (It's a castrated ram)
> Dict uses dictionaries, not just word lists. It outputs the > definition(s), so this misspelling is easily detected.
> I know both words exists. I just can't manage to remember which one is > which, and maybe Perl 6 can help me :)
Meany other hackers halve trouble remembering witch is witch to. I'm all ways perfectly rite thou.
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.
: Additionally I question whether this is truly a case improving to the : point of least surprise? After all, I don't know a programmer who's : going to be surprised by what true means. There are still *some* things : you may have to learn in software dev 101 ;)
The point is that most people coming from other languages would expect "true" to be a true value, not a function testing whether some other value is true. It would be particularly confusing if we made it default to testing $_, in which case
$_ = 0; if 1 == true { say "true" } else { say "false" }
would say "false". It is a little less confusing in
given $value { when true {...}
except that, in fact, both of those cases would be syntax errors if true were a function, since it would parse the following block as an argument to true.
So if we really want to test a value for whether its .bit property returns the bool::true value, we will probably require you to use the method syntax:
when .true {...}
and then it's obvious that there's some object involved. (And it parses right, because .true would require parens if there were arguments.) On the other hand, these also do the same thing underneath, at least in the abstract:
when ?$_ {...} if $_ {...}
The optimizer is likely to bypass actually calling the .bit/.true method on known types, however.
Luke Palmer wrote: > Marcus Adair writes: > > Additionally I question whether this is truly a case improving to the > > point of least surprise? After all, I don't know a programmer who's > > going to be surprised by what true means. There are still *some* things > > you may have to learn in software dev 101 ;)
> The problem is this (common) one:
> if answer() == true { > # do something > }
> We want to give the programmer no good way to do that, because it's > wrong.
What do you mean "wrong"? It looks perfectly valid to me. It's redundant, since answer() by itself would suffice as a condition with no comparison, but does that make it wrong?
On Wed, Mar 16, 2005 at 01:41:56PM -0500, Mark J. Reed wrote: : Luke Palmer wrote:
:
: >Marcus Adair writes:
: >> Additionally I question whether this is truly a case improving to the : >> point of least surprise? After all, I don't know a programmer who's : >> going to be surprised by what true means. There are still *some* things : >> you may have to learn in software dev 101 ;) : > : >The problem is this (common) one: : > : > if answer() == true { : > # do something : > } : > : >We want to give the programmer no good way to do that, because it's : >wrong. : > : : What do you mean "wrong"? It looks perfectly valid to me. It's : redundant, since answer() by itself would suffice as a condition with no : comparison, but does that make it wrong?
It could be forced to work if MMD is smart enough to call an == function that we were smart enough to define that is smart enough to look at the .bit property of the left argument to coerce that value to 0 or 1. But the naive implementation ends up comparing 42 == 1 and returning false. Unfortunately, == is one of those things we'd like to optimize heavily, and it's hard if there's a lot of MMD cruft in the way.
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?
On Wed, Mar 16, 2005 at 12:09:40PM -0800, Larry Wall wrote: > whereas as a native English speaker would probably expect
> $x = whether($a or $b);
> 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.
But "true()" reads weird, and it does not read like an unary (or list) operator at all to me. As the bikeshedding is still going on, may I suggest "aye()"? It is the same length as "not()", both are adverbs, and is rare enough to not conflict with user-defined subs.
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. 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);
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.
On Wednesday 16 March 2005 15:40, Autrijus Tang wrote:
> On Wed, Mar 16, 2005 at 12:09:40PM -0800, Larry Wall wrote: > > 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.
> But "true()" reads weird, and it does not read like an unary (or list) > operator at all to me. As the bikeshedding is still going on, may I > suggest "aye()"? It is the same length as "not()", both are adverbs, > and is rare enough to not conflict with user-defined subs.
A shotgun brainstorming of possible operator names:
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.
Larry Wall wrote: > $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);
Reading this makes me wanting:
$x = either $a or $b; $y = neither $a nor $b;
And of course binary \ and \\ for the latter :)
> 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.
What is so bad of having a proper type bool? I mean one that gives a type error or warning for 'answer() == true' if &answer returns Int because bool { not .does Comparable }? This type would be rather lightweight, compile time only with representation bit. The .bit property would then actually become a call of 'as bool'.
> On Wed, Mar 16, 2005 at 12:09:40PM -0800, Larry Wall wrote: > > whereas as a native English speaker would probably expect
> > $x = whether($a or $b);
> > 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.
> But "true()" reads weird, and it does not read like an unary (or list) > operator at all to me. As the bikeshedding is still going on, may I > suggest "aye()"? It is the same length as "not()", both are adverbs, > and is rare enough to not conflict with user-defined subs.
