s/true/better name/
Juerd
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.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Yuval Kogman
> Autrijus suggested "indeed" or "id", of which I like "indeed" better,
> because I'd like to continue using "id" with databases.
whether?
--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /me beats up some cheese: neeyah!!!!!!!!!!!!!!!!!
Juerd
> 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? :)
So is great for Perl poetry too.
Larry Wall
: 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".
Larry
Larry Wall
: 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.
Larry
Autrijus Tang
> though that seems to connote definedness more than truth.
Hmm, "so" is so good. So can we make it so? :)
Thanks,
/Autrijus/
Juerd
> 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?
Nicholas Clark
> 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)
Nicholas Clark
Juerd
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 :)
Rod Adams
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.
-- Rod Adams
David Storrs
It also breaks a huge percentage of the testing code that we would
like to be able to automagically port from P5 to P6.
--Dks
Marcus Adair
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
Luke Palmer
> 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.
Luke
Luke Palmer
> 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.
Luke
Larry Wall
: Isn't saying "false doesn't exist" like saying, "dark doesn't exist"?
:
: 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.
Larry
Mark J. Reed
> 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?
Larry Wall
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
Rod Adams
>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?
-- Rod Adams
Autrijus Tang
> 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.
Thanks,
/Autrijus/
Larry Wall
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.
Larry
John Macdonald
A shotgun brainstorming of possible operator names:
determine
ponder
query
consider
examine
veracity
inquire
bool
boolean
bin
binary
propriety
Rod Adams
>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
Thomas Sandlaß
> $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'.
Regards,
--
TSa (Thomas Sandlaß)
Aldo Calpini
> A shotgun brainstorming of possible operator names:
well, I didn't follow this thread very closely (and I don't know if it
is "officially" closed :-) but I suddenly thought about "yes". what about:
$x = not $a or $b; # vs
$x = yes $a or $b;
$yesno = yes any(@foo) == any(@bar);
may not be gramatically correct English, but isn't it intuitive enough?
cheers,
Aldo
Brian Ingerson
'Tis a pity nobody suggested `tis()`.
Cheers, Brian
Luke Palmer
It's wrong in the same way that:
if (ref $obj eq 'MyClass') {...}
Is wrong. If answer() decides that it should start returning a more
interesting value of true, then the test fails.
Luke
Yuval Kogman
> Is wrong. If answer() decides that it should start returning a more
> interesting value of true, then the test fails.
I think the only name for this function, from which you can actually
understand what it does, is
bool(?:ean)?
as a context enforcer.
It's got the following properties:
- well known and accepted semantic meaning
- no associated action (it doesn't do anything)
- relatives (scalar, list, hash)
- it maps to '?', which is also the prefix to certain
operations, thus unambiguating further
As I see it 'so', 'whether', 'true', 'is', 'id', etc all have too
much english cargo, or are not exactly what it does.
The only one that I can see fitting here, as an action instead of a
context disambiguation is 'istrue', which takes an expr, and returns
a bool if expr is true.
--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /me sneaks up from another MIME part: neeyah!!!!!
Juerd
> 'Tis a pity nobody suggested `tis()`.
That sounds more like a smart match on the topic:
if tis 'foo' { ... }
if $_ ~~ 'foo' { ... }
't => $_,
is => ~~