www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Implies operator

reply Mariano <rotoshi yahoo.com> writes:
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
Nov 14 2006
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
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)
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
Nov 14 2006
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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);
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.
Nov 14 2006
parent reply Mariano <rotoshi yahoo.com> writes:
== 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.
Nov 16 2006
next sibling parent reply "Kristian Kilpi" <kjkilpi gmail.com> writes:
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.)
Nov 16 2006
parent reply antonio <antonio abrevia.net> writes:
Kristian Kilpi wrote:
 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
Nov 16 2006
next sibling parent antonio <antonio abrevia.net> writes:
antonio wrote:
 Kristian Kilpi wrote:
 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
prev sibling next sibling parent antonio <antonio abrevia.net> writes:
antonio wrote:
 Kristian Kilpi wrote:
 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
prev sibling next sibling parent "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
 
 
 
 
Nov 16 2006
prev sibling next sibling parent reply xs0 <xs0 xs0.com> writes:
 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
Nov 17 2006
parent reply Mariano <rotoshi yahoo.com> writes:
== Quote from xs0 (xs0 xs0.com)'s article
 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.
Nov 17 2006
parent reply xs0 <xs0 xs0.com> writes:
Mariano wrote:
 == Quote from xs0 (xs0 xs0.com)'s article
 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
Nov 17 2006
next sibling parent reply Antonio <antonio abrevia.net> writes:
 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 :-(.
Nov 17 2006
next sibling parent Pragma <ericanderton yahoo.removeme.com> writes:
Antonio wrote:
 
 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
Nov 17 2006
prev sibling parent xs0 <xs0 xs0.com> writes:
Antonio wrote:

 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
Nov 17 2006
prev sibling parent reply Elmar <chrehme gmx.de> writes:
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
parent 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`.
Sep 13 2021
prev sibling parent reply Mariano <rotoshi yahoo.com> writes:
== 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.
Nov 17 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
Mariano wrote:
 == 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?
Nov 17 2006
prev sibling parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Mariano wrote:

 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)
Nov 17 2006
prev sibling parent reply Roberto Mariottini <rmariottini mail.com> writes:
Hasan Aljudy wrote:
 Mariano wrote:
 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/
Nov 15 2006
next sibling parent "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
If

   if( check_boundaries -> a.length <= max_int )
       process(a);
is equal to
   if( check_boundaries )
     if( a.length <= max_int )
       process(a);
than it is also equal to if( check_boundaries && a.length <= max_int ) process(a); and *not* equal to
   if( !check_boundaries || a.length <= max_int )
       process(a);
Did I miss something?
Nov 15 2006
prev sibling parent "Rioshin an'Harthen" <rharth75 hotmail.com> writes:
"Roberto Mariottini" <rmariottini mail.com> wrote:
 Hasan Aljudy wrote:
 Mariano wrote:
 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.
Nov 15 2006
prev sibling next sibling parent %u <renosky free.fr> writes:
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
Nov 19 2006
prev sibling parent reply Elmar <chrehme gmx.de> writes:
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
parent reply 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
Sep 13 2021
next sibling parent reply Dukc <ajieskola gmail.com> writes:
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?
Sep 13 2021
parent Dukc <ajieskola gmail.com> writes:
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.
Sep 13 2021
prev sibling parent reply Elmar <chrehme gmx.de> writes:
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?
Sep 16 2021
next sibling parent Mike Parker <aldacron gmail.com> writes:
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
prev sibling parent 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
Sep 16 2021