Wouldn't it be nice to have an ''implies'' operator?
if(A -> B)
I know this can be written as
if(!A || B)
but the implication makes it far more clear for common day speach
if( check_boundaries -> a.length <= max_int )
process(a);
makes more sence than
if( !check_boundaries || a.length <= max_int )
process(a);
or
if( ! (check_boundaries && a.length > max_int ) )
process(a);
besides, I don't think the '->' notation should be a big problem for
the parser, and the front end can easily convert this structure to
the corresponding not + or/and.
There is, of course, still the issue of precedence, but I think it
should match that of || and &&.
And since Walter likes Wikipedia links: http://en.wikipedia.org/wiki/
Logical_implication
Mariano
Wouldn't it be nice to have an ''implies'' operator?
if(A -> B)
I know this can be written as
if(!A || B)
I don't recall ever being in a situation like that ..
I'm not saying I've never had a conditional of the form if(!a || b) but
I never thought about it as a logical implication ...
Plus, "logical implication" only makes sense for rules and theorems, not
variables.
but the implication makes it far more clear for common day speach
if( check_boundaries -> a.length <= max_int )
process(a);
makes more sence than
if( !check_boundaries || a.length <= max_int )
process(a);
What does that mean? what's 'a' and what's 'check_boundaries'?
or
if( ! (check_boundaries && a.length > max_int ) )
process(a);
besides, I don't think the '->' notation should be a big problem for
the parser, and the front end can easily convert this structure to
the corresponding not + or/and.
Yea, it's easy, sure .. but -> has another totally different meaning in
C++. Not that I care about C++ anymore, but D, being a C-family
language, IMHO, shouldn't do this.
There is, of course, still the issue of precedence, but I think it
should match that of || and &&.
And since Walter likes Wikipedia links: http://en.wikipedia.org/wiki/
Logical_implication
Mariano
but the implication makes it far more clear for common day speach
if( check_boundaries -> a.length <= max_int )
process(a);
makes more sence than
if( !check_boundaries || a.length <= max_int )
process(a);
What does that mean? what's 'a' and what's 'check_boundaries'?
Presumably it's obvious within the context from which the example has
been snipped.
What this notation is saying is: If check_boundaries is true, then we
need to check whether a.length <= max_int - otherwise we needn't bother.
But still, it isn't exactly the clearest notation.
<snip>
Yea, it's easy, sure .. but -> has another totally different meaning in
C++. Not that I care about C++ anymore, but D, being a C-family
language, IMHO, shouldn't do this.
<snip>
Taken the words out of my mouth there.
Stewart.
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------
My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.
== Quote from Stewart Gordon (smjg_1998 yahoo.com)'s article
Hasan Aljudy wrote:
Mariano wrote:
<snip>
but the implication makes it far more clear for common day speach
if( check_boundaries -> a.length <= max_int )
process(a);
makes more sence than
if( !check_boundaries || a.length <= max_int )
process(a);
</snip>
What this notation is saying is: If check_boundaries is true, then we
need to check whether a.length <= max_int - otherwise we needn't bother.
But still, it isn't exactly the clearest notation.
Yes, it was just an example out of the blue. I think it is clearer, and I can't
think of a better way.
<snip>
Yea, it's easy, sure .. but -> has another totally different meaning in
C++. Not that I care about C++ anymore, but D, being a C-family
language, IMHO, shouldn't do this.
<snip>
The notation was just a suggestion. I would prefer =>, but it might be confused
with >=. Other options are
I understand most people don't have the notion of 'implicance' so fresh in
their heads as with other logical
operators, but I believe this is a consecuence of the imposed operators by
languages. Having an extra logical
operator would give an edge for the programmer used to it, and won't hurt the
one who doesn't whant to use it.
What's more, this operator is far more coherent with the behaviour of not
revising the second condition if not
needed.
Who knows, if implemented, it might even become widely used one day.
Mariano.
On Thu, 16 Nov 2006 13:46:08 +0200, Mariano <rotoshi yahoo.com> wrote:
=3D=3D Quote from Stewart Gordon (smjg_1998 yahoo.com)'s article
Hasan Aljudy wrote:
Mariano wrote:
<snip>
but the implication makes it far more clear for common day speach
if( check_boundaries -> a.length <=3D max_int )
process(a);
makes more sence than
if( !check_boundaries || a.length <=3D max_int )
process(a);
</snip>
What this notation is saying is: If check_boundaries is true, then we=
need to check whether a.length <=3D max_int - otherwise we needn't bo=
ther.
But still, it isn't exactly the clearest notation.
Yes, it was just an example out of the blue. I think it is clearer, an=
d =
I can't think of a better way.
<snip>
Yea, it's easy, sure .. but -> has another totally different meanin=
g =
in
C++. Not that I care about C++ anymore, but D, being a C-family
language, IMHO, shouldn't do this.
<snip>
The notation was just a suggestion. I would prefer =3D>, but it might =
be =
confused with >=3D. Other options are
58;!
I understand most people don't have the notion of 'implicance' so fres=
h =
in their heads as with other logical
operators, but I believe this is a consecuence of the imposed operator=
s =
by languages. Having an extra logical
operator would give an edge for the programmer used to it, and won't =
hurt the one who doesn't whant to use it.
What's more, this operator is far more coherent with the behaviour of =
=
not revising the second condition if not
needed.
Who knows, if implemented, it might even become widely used one day.
Mariano.
I haven't used implication anywhere; I'm not 'able' to think x implies y=
. =
But that's probably because there is no implication operator.
Now when I think about it, I have to say that 'x implies y' is a lot =
easier to understand than '!x || y'.
I cannot say how much I would use it, if there was one. (I'm still not =
used to such an operator.)
On Thu, 16 Nov 2006 13:46:08 +0200, Mariano <rotoshi yahoo.com> wrote:
== Quote from Stewart Gordon (smjg_1998 yahoo.com)'s article
Hasan Aljudy wrote:
Mariano wrote:
<snip>
but the implication makes it far more clear for common day speach
if( check_boundaries -> a.length <= max_int )
process(a);
makes more sence than
if( !check_boundaries || a.length <= max_int )
process(a);
</snip>
What this notation is saying is: If check_boundaries is true, then we
need to check whether a.length <= max_int - otherwise we needn't bother.
But still, it isn't exactly the clearest notation.
Yes, it was just an example out of the blue. I think it is clearer,
and I can't think of a better way.
<snip>
Yea, it's easy, sure .. but -> has another totally different
meaning in
C++. Not that I care about C++ anymore, but D, being a C-family
language, IMHO, shouldn't do this.
<snip>
The notation was just a suggestion. I would prefer =>, but it might be
confused with >=. Other options are
I understand most people don't have the notion of 'implicance' so
fresh in their heads as with other logical
operators, but I believe this is a consecuence of the imposed
operators by languages. Having an extra logical
operator would give an edge for the programmer used to it, and won't
hurt the one who doesn't whant to use it.
What's more, this operator is far more coherent with the behaviour of
not revising the second condition if not
needed.
Who knows, if implemented, it might even become widely used one day.
Mariano.
I haven't used implication anywhere; I'm not 'able' to think x implies
y.. But that's probably because there is no implication operator.
Now when I think about it, I have to say that 'x implies y' is a lot
easier to understand than '!x || y'.
I cannot say how much I would use it, if there was one. (I'm still not
used to such an operator.)
The most common example is the null check...
if( a!=null && a[5]==2 ) {
}
we assume "&&" operator is optimized and evaluates left to right... but
it's really "dirty" because we use a compiler optimization as a logic
functionality.
for this example, I really will prefer to write
if( a!=null -> a[5]==2 ) {
}
that uses left to right optimized evaluation, but it's more "clean"
following this, why not
if( a[5]==2 <- a!=null ) {
}
( "<-" optimized evaluation is right to left )
One question about && and || optimization:
Is there some way to specify that I need to evaluate the 2 sides of the
comparer?
(something like &&& or ||| )
note: "if( And( left() , right() ) )" or similar is not a solution :-)
Thanks
On Thu, 16 Nov 2006 13:46:08 +0200, Mariano <rotoshi yahoo.com> wrote:
== Quote from Stewart Gordon (smjg_1998 yahoo.com)'s article
Hasan Aljudy wrote:
Mariano wrote:
<snip>
but the implication makes it far more clear for common day speach
if( check_boundaries -> a.length <= max_int )
process(a);
makes more sence than
if( !check_boundaries || a.length <= max_int )
process(a);
</snip>
What this notation is saying is: If check_boundaries is true, then we
need to check whether a.length <= max_int - otherwise we needn't
bother.
But still, it isn't exactly the clearest notation.
Yes, it was just an example out of the blue. I think it is clearer,
and I can't think of a better way.
<snip>
Yea, it's easy, sure .. but -> has another totally different
meaning in
C++. Not that I care about C++ anymore, but D, being a C-family
language, IMHO, shouldn't do this.
<snip>
The notation was just a suggestion. I would prefer =>, but it might
be confused with >=. Other options are
I understand most people don't have the notion of 'implicance' so
fresh in their heads as with other logical
operators, but I believe this is a consecuence of the imposed
operators by languages. Having an extra logical
operator would give an edge for the programmer used to it, and won't
hurt the one who doesn't whant to use it.
What's more, this operator is far more coherent with the behaviour of
not revising the second condition if not
needed.
Who knows, if implemented, it might even become widely used one day.
Mariano.
I haven't used implication anywhere; I'm not 'able' to think x implies
y.. But that's probably because there is no implication operator.
Now when I think about it, I have to say that 'x implies y' is a lot
easier to understand than '!x || y'.
I cannot say how much I would use it, if there was one. (I'm still not
used to such an operator.)
The most common example is the null check...
if( a!=null && a[5]==2 ) {
}
we assume "&&" operator is optimized and evaluates left to right... but
it's really "dirty" because we use a compiler optimization as a logic
functionality.
for this example, I really will prefer to write
if( a!=null -> a[5]==2 ) {
}
that uses left to right optimized evaluation, but it's more "clean"
following this, why not
if( a[5]==2 <- a!=null ) {
}
( "<-" optimized evaluation is right to left )
One question about && and || optimization:
Is there some way to specify that I need to evaluate the 2 sides of the
comparer?
(something like &&& or ||| )
note: "if( And( left() , right() ) )" or similar is not a solution :-)
Thanks
SORRY...
"a!=null -> a[5]==2"
is not the same than
"a!=null && a[5]==2"...
my fault :-(
On Thu, 16 Nov 2006 13:46:08 +0200, Mariano <rotoshi yahoo.com> wrote:
== Quote from Stewart Gordon (smjg_1998 yahoo.com)'s article
Hasan Aljudy wrote:
Mariano wrote:
<snip>
but the implication makes it far more clear for common day speach
if( check_boundaries -> a.length <= max_int )
process(a);
makes more sence than
if( !check_boundaries || a.length <= max_int )
process(a);
</snip>
What this notation is saying is: If check_boundaries is true, then we
need to check whether a.length <= max_int - otherwise we needn't
bother.
But still, it isn't exactly the clearest notation.
Yes, it was just an example out of the blue. I think it is clearer,
and I can't think of a better way.
<snip>
Yea, it's easy, sure .. but -> has another totally different
meaning in
C++. Not that I care about C++ anymore, but D, being a C-family
language, IMHO, shouldn't do this.
<snip>
The notation was just a suggestion. I would prefer =>, but it might
be confused with >=. Other options are
I understand most people don't have the notion of 'implicance' so
fresh in their heads as with other logical
operators, but I believe this is a consecuence of the imposed
operators by languages. Having an extra logical
operator would give an edge for the programmer used to it, and won't
hurt the one who doesn't whant to use it.
What's more, this operator is far more coherent with the behaviour of
not revising the second condition if not
needed.
Who knows, if implemented, it might even become widely used one day.
Mariano.
I haven't used implication anywhere; I'm not 'able' to think x implies
y.. But that's probably because there is no implication operator.
Now when I think about it, I have to say that 'x implies y' is a lot
easier to understand than '!x || y'.
I cannot say how much I would use it, if there was one. (I'm still not
used to such an operator.)
The most common example is the null check...
if( a!=null && a[5]==2 ) {
}
we assume "&&" operator is optimized and evaluates left to right... but
it's really "dirty" because we use a compiler optimization as a logic
functionality.
for this example, I really will prefer to write
if( a!=null -> a[5]==2 ) {
}
that uses left to right optimized evaluation, but it's more "clean"
following this, why not
if( a[5]==2 <- a!=null ) {
}
( "<-" optimized evaluation is right to left )
One question about && and || optimization:
Is there some way to specify that I need to evaluate the 2 sides of the
comparer?
(something like &&& or ||| )
note: "if( And( left() , right() ) )" or similar is not a solution :-)
Thanks
SORRY...
"a!=null -> a[5]==2"
is not the same than
"a!=null && a[5]==2"...
my fault :-(
Nov 16 2006
"Unknown W. Brackets" <unknown simplemachines.org> writes:
Does that mean this isn't an option either?
int r = right();
if (left() && r)
...
-[Unknown]
One question about && and || optimization:
Is there some way to specify that I need to evaluate the 2 sides of the
comparer?
(something like &&& or ||| )
note: "if( And( left() , right() ) )" or similar is not a solution :-)
Thanks
One question about && and || optimization:
Is there some way to specify that I need to evaluate the 2 sides of the
comparer?
(something like &&& or ||| )
note: "if( And( left() , right() ) )" or similar is not a solution :-)
One question about && and || optimization:
Is there some way to specify that I need to evaluate the 2 sides of the
comparer?
(something like &&& or ||| )
note: "if( And( left() , right() ) )" or similar is not a solution :-)
& and | should do the trick :)
xs0
Well, the '&' doesn't always work, considering the ambibalence between integers
and booleans.
For instance:
cmp(a,b) & cmp(b,c)
will be considered false even if the 3 strings are different, if they return
values (for example) 1 and 2; 1 & 2 is 0
(01 & 10). Same thing with XOR. Nevertheless, the OR would work, and you could
use !(!a | !b) instead if &.
Mariano.
One question about && and || optimization:
Is there some way to specify that I need to evaluate the 2 sides of the
comparer?
(something like &&& or ||| )
note: "if( And( left() , right() ) )" or similar is not a solution :-)
& and | should do the trick :)
xs0
Well, the '&' doesn't always work, considering the ambibalence between
integers and booleans.
For instance:
cmp(a,b) & cmp(b,c)
will be considered false even if the 3 strings are different, if they return
values (for example) 1 and 2; 1 & 2 is 0
(01 & 10). Same thing with XOR. Nevertheless, the OR would work, and you could
use !(!a | !b) instead if &.
Yup. I just assumed the operands were bools in the first place..
Other workarounds include
cast(bool)a & cast(bool)b
!!a & !!b
a?b?1:0:b?0:0 // just kidding
Though, I think that if I wanted to always execute both sides, I'd put
that execution outside the if expression, it makes it far more obvious
what's going on.
auto a = something();
auto b = somethingElse();
if (a && b) {
...
}
xs0
Yup. I just assumed the operands were bools in the first place..
Other workarounds include
cast(bool)a & cast(bool)b
!!a & !!b
a?b?1:0:b?0:0 // just kidding
Though, I think that if I wanted to always execute both sides, I'd put
that execution outside the if expression, it makes it far more obvious
what's going on.
auto a = something();
auto b = somethingElse();
if (a && b) {
...
}
xs0
It's true: the "correct" way is not to put "process" into "decission
blocks".
But there is some cases where I prefer to do something like
Recordset rd = new Recordset()
Recordset rd2 = new Recordset()
while( rd.Read() &&& rd2.Read() ) {
doSomething( rd, rd2 );
}
// at this point, the number of Read()'s MUST BE the same
// in rd and rd2
it's equivalent to:
RecordSet rd = new RecordSet()
RecordSet rd2 = new RecordSet()
bool exists = rd.Read();
bool exists2 = rd2.Read();
while( exists && exists2 ) {
doSomething( rd, rd2 );
exists = rd.Read();
exists2 = rd2.Read();
}
Ok... you say it could be wrote as
while( rd.Read() & rd2.Read() ) {
But & is "bit" tester, not a Logic evaluator... We are talking about a
hight level programming language... we can use "invariants"
"preconditions" "postconditions" and.... SURPRISSE... I have to use a
"bit test" for "logic comparations"... no thanks..
Otherwhise... bit test could be "optimized" (if left side is 0, "&"
allways evaluates to 0).
Sorry... I continue with my very poor english :-(.
Yup. I just assumed the operands were bools in the first place..
Other workarounds include
cast(bool)a & cast(bool)b
!!a & !!b
a?b?1:0:b?0:0 // just kidding
Actually, for the "follows" operation, isn't that the same as:
auto x = a; // evaluate a
if(x ? b : !x){
// do something
}
It makes me wonder if the '?' could be granted a shorthand to cover this?
Something like:
a ? b
Which would be the same as:
a ? b : !a
Only without the redundant evaluation of a.
--
- EricAnderton at yahoo
It's true: the "correct" way is not to put "process" into "decission
blocks".
But there is some cases where I prefer to do something like
Recordset rd = new Recordset()
Recordset rd2 = new Recordset()
while( rd.Read() &&& rd2.Read() ) {
doSomething( rd, rd2 );
}
// at this point, the number of Read()'s MUST BE the same
// in rd and rd2
it's equivalent to:
RecordSet rd = new RecordSet()
RecordSet rd2 = new RecordSet()
bool exists = rd.Read();
bool exists2 = rd2.Read();
while( exists && exists2 ) {
doSomething( rd, rd2 );
exists = rd.Read();
exists2 = rd2.Read();
}
Ok... you say it could be wrote as
while( rd.Read() & rd2.Read() ) {
But & is "bit" tester, not a Logic evaluator... We are talking about a
hight level programming language... we can use "invariants"
"preconditions" "postconditions" and.... SURPRISSE... I have to use a
"bit test" for "logic comparations"... no thanks..
Well, for what it's worth - in Java, & | and ^ are called both "Integer
Bitwise Operators" when used on integers and "Boolean Logical
Operators", when used on booleans. && and || are called "Conditional
And/Or".
Anyhow, when used on bools & is effectively a completely normal AND
operator, equivalent to your &&&, nothing low-level about it, at least
IMHO :) The only thing I'd change was that instead of always converting
to integer (like the current spec says), if both sides are of bool type,
the result is also bool.
Otherwhise... bit test could be "optimized" (if left side is 0, "&"
allways evaluates to 0).
I disagree.. a valid optimization never changes the meaning of code, so
if the right side could have side-effects, it can't be optimized away
(and if it doesn't have side effects, it doesn't matter anyway). Also
note that short-circuit evaluation of && and || is not a matter of
optimization, the two operators are defined to behave that way.
xs0
On Friday, 17 November 2006 at 13:24:01 UTC, xs0 wrote:
Mariano wrote:
One question about && and || optimization:
Is there some way to specify that I need to evaluate the 2
sides of the
comparer?
(something like &&& or ||| )
note: "if( And( left() , right() ) )" or similar is not a
solution :-)
...
Other workarounds include
cast(bool)a & cast(bool)b
!!a & !!b
a?b?1:0:b?0:0 // just kidding
...
auto a = something();
auto b = somethingElse();
if (a && b) {
...
}
There is another way which I choose for bitwise-operable types:
```
if (a != 0 & b != 0) { ... } // no short-circuit behaviour
if (a != 0 ^ b != 0) { ... }
```
For me it's better to read than `cast(bool)a & cast(bool)b` but
it has same semantics.
This *could* probably generate better performing code than `!!a &
!!b`.
Sep 12 2021
Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Sunday, 12 September 2021 at 09:08:12 UTC, Elmar wrote:
On Friday, 17 November 2006 at 13:24:01 UTC, xs0 wrote:
Mariano wrote:
One question about && and || optimization:
Is there some way to specify that I need to evaluate the 2
sides of the
comparer?
(something like &&& or ||| )
note: "if( And( left() , right() ) )" or similar is not a
solution :-)
...
Other workarounds include
cast(bool)a & cast(bool)b
!!a & !!b
a?b?1:0:b?0:0 // just kidding
...
auto a = something();
auto b = somethingElse();
if (a && b) {
...
}
There is another way which I choose for bitwise-operable types:
```
if (a != 0 & b != 0) { ... } // no short-circuit behaviour
if (a != 0 ^ b != 0) { ... }
```
\<source>(14): Error: `num != 0` must be surrounded by
parentheses when next to operator `&`
& ^ and | have higher prio than comparison ops. => parenthesis
required.
For me it's better to read than `cast(bool)a & cast(bool)b` but
it has same semantics.
This *could* probably generate better performing code than `!!a
& !!b`.
== Quote from antonio (antonio abrevia.net)'s article
Kristian Kilpi wrote:
Now when I think about it, I have to say that 'x implies y' is a lot
easier to understand than '!x || y'.
Yeap, it only takes a minute or two to get use to it.
antonio wrote:
The most common example is the null check...
Yes, both -> and <- could be used.
For instances, in order to decide weather to show an error or not regarding its
level and the
user-option of showing mild errors or not, we could decide to write it one way
or the other
considering which on is ''cheaper'' to do first.
if( hideMildErrors -> GetErrorLevelFromFarAway() > 3 ) writefln(err);
and
if( error.level>3 <- readLongConfigFile("hideMildErrors") ) writefln(err);
Of course, all this could be again used with only ! and || (or &&).
I see only answers regarding the notation instead of the matter of having such
operator or not.
As I said, there are several ways to write it, be it ->, --> or ==>, none of
which represent
any comflict with the lexic of current version of the language.
Mariano.
== Quote from antonio (antonio abrevia.net)'s article
Kristian Kilpi wrote:
Now when I think about it, I have to say that 'x implies y' is a lot
easier to understand than '!x || y'.
Yeap, it only takes a minute or two to get use to it.
antonio wrote:
The most common example is the null check...
Yes, both -> and <- could be used.
Implication is no harder to implement in software than bitwise and logic
operators, which have been around from the start of computing languages.
Likewise, they have been implemented in hardware right from the start.
Computers have existed for the last half century. New architectures and
new programming languages have been under development, by the best of
minds, every single day of this time.
Now, since implication is not a genuine part of any significant
programming language, or any well-known processor architecture, doesn't
that make you wonder?
The notation was just a suggestion. I would prefer =>, but it might be
confused with >=. Other options are
We don't have Unicode *operator* "support" in D, they must all be ASCII
(and they can only have one name each, so you can't have both at once)
It has been suggested before for other operators, and always ignored:
http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList/UnicodeOperators
I don't think it has any technical reasons, just a matter of preference.
(using non-ascii for variables and functions doesn't always work either)
It should probably be in the D FAQ:
Q: Can we have unicode operators ?
A: No, you can't. US-ASCII only.
We need a list of "features rejected"...
--anders
PS.
Yes, I know that the spec says that all Universal Alphas are allowed
for identifiers. Let's just say that it doesn't *always* work, since
the assembler does choke on the names in some implementations of D...
(but I write my own code with ASCII identifiers and English comments)
but the implication makes it far more clear for common day speach
if( check_boundaries -> a.length <= max_int )
process(a);
makes more sence than
if( !check_boundaries || a.length <= max_int )
process(a);
What does that mean? what's 'a' and what's 'check_boundaries'?
You can view it as:
if( check_boundaries )
if( a.length <= max_int )
process(a);
Ciao
---
http://www.mariottini.net/roberto/
SuperbCalc: http://www.mariottini.net/roberto/superbcalc/
but the implication makes it far more clear for common day speach
if( check_boundaries -> a.length <= max_int )
process(a);
makes more sence than
if( !check_boundaries || a.length <= max_int )
process(a);
What does that mean? what's 'a' and what's 'check_boundaries'?
You can view it as:
if( check_boundaries )
if( a.length <= max_int )
process(a);
Actually, no... that would be
if ( check_boundaries && a.length <= max_int )
which is different. For the logical implication
if ( !check_boundaries || a.length <= max_int )
the corresponding code would be
if( check_boundaries )
{
if( a.length <= max_int )
process(a);
}
else
process(a);
But back to the proposal... I've had a few occasions where I've needed a
logical implication; it's a pain to look up the corresponding and-or logic
for it. However, I find the need for it to be so rare that including it in
the language would make very little sense.
Wouldn't it be nice to have an ''implies'' operator?
I'm not so sure: many people forget that in 'x imply y', if x is False then 'x
imply y' is True, they use imply as an equivalent of and.
At least with !x || y, there is no such error.
In theory imply is not ambiguous, in practice it is, so we should avoid it.
RenoX
On Tuesday, 14 November 2006 at 13:04:20 UTC, Mariano wrote:
Wouldn't it be nice to have an ''implies'' operator?
if(A -> B)
I know this can be written as
if(!A || B)
but the implication makes it far more clear for common day
speach
if( check_boundaries -> a.length <= max_int )
process(a);
makes more sence than
if( !check_boundaries || a.length <= max_int )
process(a);
or
if( ! (check_boundaries && a.length > max_int ) )
process(a);
besides, I don't think the '->' notation should be a big
problem for the parser, and the front end can easily convert
this structure to the corresponding not + or/and.
There is, of course, still the issue of precedence, but I think
it should match that of || and &&.
And since Walter likes Wikipedia links:
http://en.wikipedia.org/wiki/ Logical_implication
Mariano
There is a cruel answer to this request.
For boolean type values, this operator exists in all C-like
languages. The problem however only is, the **arrow points into
the wrong direction**!
You might get what I'd like to say:
```
if (a implies b) { ... }
```
is
```
if (a <= b) { ... }
```
in C-derived languages. I wouldn't call Java to be C-derived.
It's opposite to logic which would write
```
if (a => b) { ... }
```
to mean the same thing.
You also could write
```
if (b >= a) { ... }
if (!a >= !b) { ... }
if (!(a > b)) { ... }
```
If you would define an "implies" operator like which is available
in current generation programming languages then the definition
would look like:
```
a => b := !(cast(bool)a >= cast(bool)b)
```
Funny enough though, the IEC logic gate symbols use `>= 0` to
denote the OR-gate.
The bi-implication works better:
```
if (a == b) { ... } // eqv. to if (a >= b && a <= b) { ... }
if (a != b) { ... } // negated bi-implication
```
We would need to get used to writing the arrow in the wrong
direction! Probably possible, but I find the confusion pretty
terrible. At least, there is a mnemonic to say, that the symbol
`=>` does not exist and therefore `<=` is reused instead and
implication always is from left to right (in my university it
really is).
Or we use this close notation instead:
```
if (a ? b : true) { ... }
```
The best syntax for an implication probably would be
```
if (a ? b) { ... }
```
and less
```
if (a !| b) {} := if (!a || b ) { }
```
which is equivalent.
Only dumb that the null-coalescing operator `if (a ?? b) ...` in
other languages already has the meaning `if (!a ? b) ...` (which
is equivalent to the `or` operator like in Python).
My guess is though, that rather C++ would come up with something
like `=>` than D would. C++ now introduced the spaceship operator
which is useful when working with comparators:
```a <=> b := (int(a > b) - int(a < b))```
(Looks like `>-<` would have described the meaning better.)
---
A last solution would be adding this to your global utility
functions:
```
pragma(inline) pure safe nogc nothrow
bool implies(in bool a, in bool b) {
return a <= b;
}
unittest {
static assert(false .implies (false));
static assert(false .implies (true));
static assert(! true .implies (false));
static assert(true .implies (true));
}
```
The operator precedence is still wrong.
Sep 12 2021
Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/12/21 7:36 AM, Elmar wrote:
On Tuesday, 14 November 2006 at 13:04:20 UTC, Mariano wrote:
FYI this thread is FIFTEEN years old. Please do not resurrect zombie
threads. Instead, link to them (as the forum UI no doubt told you, and
offered a button to click to actually fix it instantly).
-Steve
On Monday, 13 September 2021 at 13:45:51 UTC, Steven
Schveighoffer wrote:
FYI this thread is FIFTEEN years old. Please do not resurrect
zombie threads. Instead, link to them (as the forum UI no doubt
told you, and offered a button to click to actually fix it
instantly).
-Steve
I have not seen any other posts by this account in other threads.
Could it be that the server just lagged half a generation with
processing his post?
On Monday, 13 September 2021 at 19:00:44 UTC, Dukc wrote:
I have not seen any other posts by this account in other
threads. Could it be that the server just lagged half a
generation with processing his post?
Stupid me, can't be:
```
pragma(inline) pure safe nogc nothrow
bool implies(in bool a, in bool b) {
return a <= b;
}
unittest {
static assert(false .implies (false));
static assert(false .implies (true));
static assert(! true .implies (false));
static assert(true .implies (true));
}
```
` nogc` was accepted in 2014 according to
https://wiki.dlang.org/DIP60. And `pragma(inline)` in 2015. So
that's it, this was a necrobump of at least 9 years.
On Monday, 13 September 2021 at 13:45:51 UTC, Steven
Schveighoffer wrote:
On 9/12/21 7:36 AM, Elmar wrote:
On Tuesday, 14 November 2006 at 13:04:20 UTC, Mariano wrote:
FYI this thread is FIFTEEN years old. Please do not resurrect
zombie threads. Instead, link to them (as the forum UI no doubt
told you, and offered a button to click to actually fix it
instantly).
-Steve
Thanks Steve. Sorry for bothering you.
Is there a specific advantage in starting a new thread for an old
thread, for a topic which might be relevant for different people
from time to time?
On Friday, 17 September 2021 at 00:12:32 UTC, Elmar wrote:
Thanks Steve. Sorry for bothering you.
Is there a specific advantage in starting a new thread for an
old thread, for a topic which might be relevant for different
people from time to time?
It's Forum Etiquette 101. Many forums forbid it completely,
others allow it under specific circumstances. Some even go so far
as to automatically lock threads after a certain amount of time
has passed.
The term "necroposting" refers to bumping old threads just to get
them to the top again. That's probably the original motivation
for such forum rules, but over time it has come to be viewed as a
common courtesy not to resurrect old threads. Here's how I view
it.
Generally, when people reply to a post they expect that they are
replying to a current conversation and often don't pay attention
to the date of the thread. Most of the time they are, because
forum etiquette across the internet generally guarantees it. So
it's extremely annoying to subsequently realize that a new post
you just replied to is in a thread that is 15 years old. Were
there other threads in the intervening years that made this one
irrelevant? Was replying to the post that resurrected the thread
a waste of time?
It's especially annoying when the old thread has several pages of
posts. I can follow a current as it develops since I usually
check the forums several times a day. For a resurrected thread, I
have to go back through the whole thread for context. Even if
it's a thread I participated in or read in the past, the
discussion is long gone from my memory. If the thread is old
enough, the web interface/newsreader/email client may show me
several unread posts, clueing me in to check the dates. But if
I've already marked the old posts as read at some point in the
past, I can easily overlook it and not realize it until I've
already invested time I wouldn't otherwise have invested.
By creating a new thread and linking to the original, it's clear
from the beginning that you are continuing an old (in this case,
very old) conversation, and readers can then make a conscious
decision to view the older thread.
I think it's justifiable to resurrect an old thread if: the
thread is no more than two or three years old; you are *certain*
the topic is still relevant; the thread is not more than a couple
of pages on the web interface. I mean, it's a fuzzy boundary and
people will disagree on where it lies, and this is just where I
think it lies. Some people will argue that it's a stupid bit of
etiquette anyway. But I'm pretty sure many will agree that 15
years is much too old.
Sep 16 2021
Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/16/21 8:12 PM, Elmar wrote:
On Monday, 13 September 2021 at 13:45:51 UTC, Steven Schveighoffer wrote:
On 9/12/21 7:36 AM, Elmar wrote:
On Tuesday, 14 November 2006 at 13:04:20 UTC, Mariano wrote:
FYI this thread is FIFTEEN years old. Please do not resurrect zombie
threads. Instead, link to them (as the forum UI no doubt told you, and
offered a button to click to actually fix it instantly).
Thanks Steve. Sorry for bothering you.
Is there a specific advantage in starting a new thread for an old
thread, for a topic which might be relevant for different people from
time to time?
Sorry for the irritated tone. As Mike said, my biggest problem with
resurrecting really old threads is all of a sudden people start reading
the whole thread thinking it's new, and start responding to posts
thinking people are asking questions that have probably long been
answered, or making arguments that are long moot (often to people who
are no longer paying attention to the forum). In short, it wastes
people's time.
I'm sure you meant well, but do try and read the forum warnings when you
try to reply to an old thread, it stops you, tells you that the thread
is old, and offers to fix it by posting a link to the original (along
with your quoted text) instead of pulling the entire thread to the top.
Thanks
-Steve
antonio <antonio abrevia.net> 