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

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

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.

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/

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?

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

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

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
> ==>, -->, 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.)

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

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
>>> ==>, -->, 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
> 
> 
> 
> 
SORRY...

"a!=null -> a[5]==2"

is not the same than

"a!=null && a[5]==2"...

my fault :-(