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:

 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.

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:

 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 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.


The notation was just a suggestion. I would prefer =>, but it might be confused with >=. Other options are ==>, -->, and since we have UTF-8 support, why not &#8594; or &#8658;! 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:

 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);


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=


 But still, it isn't exactly the clearest notation.


 I can't think of a better way.

 <snip>
 Yea, it's easy, sure .. but -> has another totally different meanin=



 in
 C++. Not that I care about C++ anymore, but D, being a C-family
 language, IMHO, shouldn't do this.


The notation was just a suggestion. I would prefer =3D>, but it might =

 confused with >=3D. Other options are
 =3D=3D>, -->, and since we have UTF-8 support, why not &#8594; or &#86=

 I understand most people don't have the notion of 'implicance' so fres=

 in their heads as with other logical
 operators, but I believe this is a consecuence of the imposed operator=

 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:

 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 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.

and I can't think of a better way.
 <snip>
 Yea, it's easy, sure .. but -> has another totally different 

 C++. Not that I care about C++ anymore, but D, being a C-family
 language, IMHO, shouldn't do this.


The notation was just a suggestion. I would prefer =>, but it might be confused with >=. Other options are ==>, -->, and since we have UTF-8 support, why not &#8594; or &#8658;! 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:

 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 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.

and I can't think of a better way.
 <snip>
 Yea, it's easy, sure .. but -> has another totally different 

 C++. Not that I care about C++ anymore, but D, being a C-family
 language, IMHO, shouldn't do this.


The notation was just a suggestion. I would prefer =>, but it might be confused with >=. Other options are ==>, -->, and since we have UTF-8 support, why not &#8594; or &#8658;! 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

"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:

 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 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.

and I can't think of a better way.
 <snip>
 Yea, it's easy, sure .. but -> has another totally different 

 C++. Not that I care about C++ anymore, but D, being a C-family
 language, IMHO, shouldn't do this.


The notation was just a suggestion. I would prefer =>, but it might be confused with >=. Other options are ==>, -->, and since we have UTF-8 support, why not &#8594; or &#8658;! 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

"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 :-)

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 :-)

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
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 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
 ==>, -->, and since we have UTF-8 support, why not &#8594; or &#8658;!

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 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