Right now, in D (as well as C and C++), when you see the expression:

	if (a < b < c)

what is your first thought? Mine is that it was written by a newbie who didn't realize that (a < b) returns true or false, and that it does NOT mean ((a < b) && (b < c)). The odds approach certainty that this is a logic error in the code, and even if it was intentional, it raises such a red flag that it shouldn't be used anyway.

Andrei has proposed (and I agreed) that this should be done away with in the language, i.e. comparison operators should no longer be associative.  It's a simple change to the grammar. If one really did want to write such code, it could be done with parentheses:

	if ((a < b) < c)

to get the original behavior. At least, that looks intentional.

I don't think this will break existing code that isn't already broken.

Walter Bright wrote:
> Right now, in D (as well as C and C++), when you see the expression:
> 
>     if (a < b < c)
> 
> what is your first thought? Mine is that it was written by a newbie who didn't realize that (a < b) returns true or false, and that it does NOT mean ((a < b) && (b < c)). The odds approach certainty that this is a logic error in the code, and even if it was intentional, it raises such a red flag that it shouldn't be used anyway.
> 
> Andrei has proposed (and I agreed) that this should be done away with in the language, i.e. comparison operators should no longer be associative.  It's a simple change to the grammar. If one really did want to write such code, it could be done with parentheses:
> 
>     if ((a < b) < c)
> 
> to get the original behavior. At least, that looks intentional.
> 
> I don't think this will break existing code that isn't already broken.

For the record, (clears throat) let me add that I initially suggested to make them associative with the right meaning, but was shot down. Making the comparison operators (and that includes != and ==) nonassociative is the next best thing to do.


Andrei

On Wed, 07 Feb 2007 16:55:15 -0800, Walter Bright wrote:

> Right now, in D (as well as C and C++), when you see the expression:
> 
> 	if (a < b < c)
> 
> what is your first thought? Mine is that it was written by a newbie who didn't realize that (a < b) returns true or false, and that it does NOT mean ((a < b) && (b < c)). The odds approach certainty that this is a logic error in the code, and even if it was intentional, it raises such a red flag that it shouldn't be used anyway.
> 
> Andrei has proposed (and I agreed) that this should be done away with in
> the language, i.e. comparison operators should no longer be associative.
>   It's a simple change to the grammar. If one really did want to write
> such code, it could be done with parentheses:
> 
> 	if ((a < b) < c)
> 
> to get the original behavior. At least, that looks intentional.
> 
> I don't think this will break existing code that isn't already broken.

First thought: Yes, your proposed change makes sense.

Second thought: Why not make it do what the coder is wanting it to do?
   Namely, make the idiom:

     expression1 relopA expression2 relopB expression3

   translate as

     ( auto temp = expression2,
      (expression1 relopA temp) && (temp relopB expression3) )


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
8/02/2007 12:01:13 PM

Derek Parnell wrote:
> On Wed, 07 Feb 2007 16:55:15 -0800, Walter Bright wrote:
> 
>> Right now, in D (as well as C and C++), when you see the expression:
>>
>> 	if (a < b < c)
>>
>> what is your first thought? Mine is that it was written by a newbie who didn't realize that (a < b) returns true or false, and that it does NOT mean ((a < b) && (b < c)). The odds approach certainty that this is a logic error in the code, and even if it was intentional, it raises such a red flag that it shouldn't be used anyway.
>>
>> Andrei has proposed (and I agreed) that this should be done away with in the language, i.e. comparison operators should no longer be associative.   It's a simple change to the grammar. If one really did want to write such code, it could be done with parentheses:
>>
>> 	if ((a < b) < c)
>>
>> to get the original behavior. At least, that looks intentional.
>>
>> I don't think this will break existing code that isn't already broken.
> 
> First thought: Yes, your proposed change makes sense.
> 
> Second thought: Why not make it do what the coder is wanting it to do?
>    Namely, make the idiom:
> 
>      expression1 relopA expression2 relopB expression3
> 
>    translate as
> 
>      ( auto temp = expression2,
>       (expression1 relopA temp) && (temp relopB expression3) )

What's the intended meaning of:

a < b == c < d

?


Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> Derek Parnell wrote:
>> On Wed, 07 Feb 2007 16:55:15 -0800, Walter Bright wrote:
>>
>>> Right now, in D (as well as C and C++), when you see the expression:
>>>
>>>     if (a < b < c)
>>>
>>> what is your first thought? Mine is that it was written by a newbie who didn't realize that (a < b) returns true or false, and that it does NOT mean ((a < b) && (b < c)). The odds approach certainty that this is a logic error in the code, and even if it was intentional, it raises such a red flag that it shouldn't be used anyway.
>>>
>>> Andrei has proposed (and I agreed) that this should be done away with in the language, i.e. comparison operators should no longer be associative.   It's a simple change to the grammar. If one really did want to write such code, it could be done with parentheses:
>>>
>>>     if ((a < b) < c)
>>>
>>> to get the original behavior. At least, that looks intentional.
>>>
>>> I don't think this will break existing code that isn't already broken.
>>
>> First thought: Yes, your proposed change makes sense.
>>
>> Second thought: Why not make it do what the coder is wanting it to do?
>>    Namely, make the idiom:
>>
>>      expression1 relopA expression2 relopB expression3
>>
>>    translate as
>>
>>      ( auto temp = expression2,
>>       (expression1 relopA temp) && (temp relopB expression3) )
> 
> What's the intended meaning of:
> 
> a < b == c < d
> 
> ?
> 
> 
> Andrei

It's worth pointing out that Python handles these operations just like Derek suggests. Take the following from Python's interactive mode:

>>> a=1
>>> b=2
>>> c=2
>>> d=3
>>> a<b==c<d
True

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org

On Wed, 07 Feb 2007 17:09:35 -0800, Andrei Alexandrescu (See Website For
Email) wrote:

> Derek Parnell wrote:
>> On Wed, 07 Feb 2007 16:55:15 -0800, Walter Bright wrote:
>> 
>>> Right now, in D (as well as C and C++), when you see the expression:
>>>
>>> 	if (a < b < c)
>>>
>>> what is your first thought? Mine is that it was written by a newbie who didn't realize that (a < b) returns true or false, and that it does NOT mean ((a < b) && (b < c)). The odds approach certainty that this is a logic error in the code, and even if it was intentional, it raises such a red flag that it shouldn't be used anyway.
>>>
>>> Andrei has proposed (and I agreed) that this should be done away with in
>>> the language, i.e. comparison operators should no longer be associative.
>>>   It's a simple change to the grammar. If one really did want to write
>>> such code, it could be done with parentheses:
>>>
>>> 	if ((a < b) < c)
>>>
>>> to get the original behavior. At least, that looks intentional.
>>>
>>> I don't think this will break existing code that isn't already broken.
>> 
>> First thought: Yes, your proposed change makes sense.
>> 
>> Second thought: Why not make it do what the coder is wanting it to do?
>>    Namely, make the idiom:
>> 
>>      expression1 relopA expression2 relopB expression3
>> 
>>    translate as
>> 
>>      ( auto temp = expression2,
>>       (expression1 relopA temp) && (temp relopB expression3) )
> 
> What's the intended meaning of:
> 
> a < b == c < d

Well that *obvious*!

 (((a < b) && (b == c)) < d)  <G>

Okay, okay, I see your point. But it would be useful (one day) to easily
code the idiom  (a op b) && (b op c),  no?

How about someone knocking up a mixin template for expressions of this format? I haven't got a clue how it could be done as the mixin/template/meta-programming syntax and semantics of D is still so obtuse and confusing to me that I can only do the very simplest things and then only after many false starts.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
8/02/2007 1:28:00 PM

"Derek Parnell" <derek@nomail.afraid.org> wrote in message news:ytund437jnul$.1nx7qfyf3zj8u$.dlg@40tude.net...

> Second thought: Why not make it do what the coder is wanting it to do?

I'd really like to be able to say

if(0.5 <= x <= 1.5)
    ...

:)

Kirk McDonald wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Derek Parnell wrote:
>>> On Wed, 07 Feb 2007 16:55:15 -0800, Walter Bright wrote:
>>>
>>>> Right now, in D (as well as C and C++), when you see the expression:
>>>>
>>>>     if (a < b < c)
>>>>
>>>> what is your first thought? Mine is that it was written by a newbie who didn't realize that (a < b) returns true or false, and that it does NOT mean ((a < b) && (b < c)). The odds approach certainty that this is a logic error in the code, and even if it was intentional, it raises such a red flag that it shouldn't be used anyway.
>>>>
>>>> Andrei has proposed (and I agreed) that this should be done away with in the language, i.e. comparison operators should no longer be associative.   It's a simple change to the grammar. If one really did want to write such code, it could be done with parentheses:
>>>>
>>>>     if ((a < b) < c)
>>>>
>>>> to get the original behavior. At least, that looks intentional.
>>>>
>>>> I don't think this will break existing code that isn't already broken.
>>>
>>> First thought: Yes, your proposed change makes sense.
>>>
>>> Second thought: Why not make it do what the coder is wanting it to do?
>>>    Namely, make the idiom:
>>>
>>>      expression1 relopA expression2 relopB expression3
>>>
>>>    translate as
>>>
>>>      ( auto temp = expression2,
>>>       (expression1 relopA temp) && (temp relopB expression3) )
>>
>> What's the intended meaning of:
>>
>> a < b == c < d
>>
>> ?
>>
>>
>> Andrei
> 
> It's worth pointing out that Python handles these operations just like Derek suggests. Take the following from Python's interactive mode:
> 
>  >>> a=1
>  >>> b=2
>  >>> c=2
>  >>> d=3
>  >>> a<b==c<d
> True

Obligatory comment: it would return true also if it were interpreted as (a < b) == (c < d) or as ((a < b) == c) < d. So the example is unclear.

:o)


Andrei

Derek Parnell wrote:
> On Wed, 07 Feb 2007 17:09:35 -0800, Andrei Alexandrescu (See Website For
> Email) wrote:
> 
>> Derek Parnell wrote:
>>> On Wed, 07 Feb 2007 16:55:15 -0800, Walter Bright wrote:
>>>
>>>> Right now, in D (as well as C and C++), when you see the expression:
>>>>
>>>> 	if (a < b < c)
>>>>
>>>> what is your first thought? Mine is that it was written by a newbie who didn't realize that (a < b) returns true or false, and that it does NOT mean ((a < b) && (b < c)). The odds approach certainty that this is a logic error in the code, and even if it was intentional, it raises such a red flag that it shouldn't be used anyway.
>>>>
>>>> Andrei has proposed (and I agreed) that this should be done away with in the language, i.e. comparison operators should no longer be associative.   It's a simple change to the grammar. If one really did want to write such code, it could be done with parentheses:
>>>>
>>>> 	if ((a < b) < c)
>>>>
>>>> to get the original behavior. At least, that looks intentional.
>>>>
>>>> I don't think this will break existing code that isn't already broken.
>>> First thought: Yes, your proposed change makes sense.
>>>
>>> Second thought: Why not make it do what the coder is wanting it to do?
>>>    Namely, make the idiom:
>>>
>>>      expression1 relopA expression2 relopB expression3
>>>
>>>    translate as
>>>
>>>      ( auto temp = expression2,
>>>       (expression1 relopA temp) && (temp relopB expression3) )
>> What's the intended meaning of:
>>
>> a < b == c < d
> 
> Well that *obvious*!
> 
>  (((a < b) && (b == c)) < d)  <G>
> 
> Okay, okay, I see your point. But it would be useful (one day) to easily
> code the idiom  (a op b) && (b op c),  no? 
> 
> How about someone knocking up a mixin template for expressions of this
> format? I haven't got a clue how it could be done as the
> mixin/template/meta-programming syntax and semantics of D is still so
> obtuse and confusing to me that I can only do the very simplest things and
> then only after many false starts.

It's very easy to implement as a straight template function:

ordered(a, b, c)

returns true iff a <= b <= c, and

strictly_ordered(a, b, c)

returns true iff a < b < c. The functions can be nicely accommodate multiple arguments. Other functions can define STL-style in-range.


Andrei

On Wed, 07 Feb 2007 19:02:06 -0800, Andrei Alexandrescu (See Website For
Email) wrote:

> Derek Parnell wrote:
>> On Wed, 07 Feb 2007 17:09:35 -0800, Andrei Alexandrescu (See Website For
>> Email) wrote:
>> 
>>> Derek Parnell wrote:
>>>> On Wed, 07 Feb 2007 16:55:15 -0800, Walter Bright wrote:
>>>>
>>>>> Right now, in D (as well as C and C++), when you see the expression:
>>>>>
>>>>> 	if (a < b < c)
>>>>>
>>>>> what is your first thought? Mine is that it was written by a newbie who didn't realize that (a < b) returns true or false, and that it does NOT mean ((a < b) && (b < c)). The odds approach certainty that this is a logic error in the code, and even if it was intentional, it raises such a red flag that it shouldn't be used anyway.
>>>>>
>>>>> Andrei has proposed (and I agreed) that this should be done away with in
>>>>> the language, i.e. comparison operators should no longer be associative.
>>>>>   It's a simple change to the grammar. If one really did want to write
>>>>> such code, it could be done with parentheses:
>>>>>
>>>>> 	if ((a < b) < c)
>>>>>
>>>>> to get the original behavior. At least, that looks intentional.
>>>>>
>>>>> I don't think this will break existing code that isn't already broken.
>>>> First thought: Yes, your proposed change makes sense.
>>>>
>>>> Second thought: Why not make it do what the coder is wanting it to do?
>>>>    Namely, make the idiom:
>>>>
>>>>      expression1 relopA expression2 relopB expression3
>>>>
>>>>    translate as
>>>>
>>>>      ( auto temp = expression2,
>>>>       (expression1 relopA temp) && (temp relopB expression3) )
>>> What's the intended meaning of:
>>>
>>> a < b == c < d
>> 
>> Well that *obvious*!
>> 
>>  (((a < b) && (b == c)) < d)  <G>
>> 
>> Okay, okay, I see your point. But it would be useful (one day) to easily
>> code the idiom  (a op b) && (b op c),  no?
>> 
>> How about someone knocking up a mixin template for expressions of this format? I haven't got a clue how it could be done as the mixin/template/meta-programming syntax and semantics of D is still so obtuse and confusing to me that I can only do the very simplest things and then only after many false starts.
> 
> It's very easy to implement as a straight template function:
> 
> ordered(a, b, c)
> 
> returns true iff a <= b <= c, and
> 
> strictly_ordered(a, b, c)
> 
> returns true iff a < b < c. The functions can be nicely accommodate multiple arguments. Other functions can define STL-style in-range.

Right ...

class Foo { . . . }
class Bar { . . . }

Foo f = new Foo;
Foo g = new Foo;
Bar b = new Bar;

if (ordered( f,b,g ) ) ...

BANG! The template doesn't know about Foo and Bar, so there is no match. In fact, just getting a template for built-in types requires a few thousand combinations of a,b,c signatures and aliases to make it palatable.

That is why I thought mixin-expressions might be more useful in this case - working at the textual level rather than the template-matching level. But I do know how to do it.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
8/02/2007 2:39:20 PM