Lionello Lunesu wrote:
> 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)). 
> 
> So your first thought, the newbie's first thought and my first thought all agree: it means a<b && b<c
> 
> As was pointed out already, let's make it that way. Adding these chained comparisons improves readability* and adds another popular feature from scripting languages.
> 
> L.
> 
> * compare with: if (a < b && c > b)

I personally would like that. It is a good example of a dwim feature that doesn't add to the complexity of the language.

Andrei

Another way to solve this problem might be the following:

- Say Comparsion operators are not defined for booleans
- Instead define a few new operations on booleans such as
  Aequivalence (for example "<->" instead of "==").
  Note for example that xor (is it ^^ in D too?) already has
  the same meaning as != for booleans.

implications whould be:
- new operator symbols may have to be introduced
- this change might break some code, but the compiler
  should spot every line thats affected by the change
- it should lead to a much 'cleaner' grammar, think of
  the reason why its "hello " ~ "world" not "hello " + "world"!

Henning

Walter Bright napisał(a):
> 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.

It's cool when language makes it easy not to make mistakes (maybe not as java by not letting programmer to do anything serious but still handy idea) but isn't it (on small scale but always) losing compatibility with C, which could complicate making bindings etc? Libraries creators could have used them in the right meaning for some strange reason...

As if making "the real meaning". "The real meaning" can be different for each person. some would like to use a<b<c in c style, some in python, some will have own ideas. and if i understand correctly, macros will do it. every man could write his own macro to change it in any way he like.

So if it will not make problems with C compatibility vote ++ with no "real meanings"

---------------------------
Peter Modzelewski
www.team0xf.com
www.keyer.team0xf.com

Steve Horne wrote:
> On Wed, 07 Feb 2007 17:06:07 -0800, "Andrei Alexandrescu (See Website
> For Email)" <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Walter Bright wrote:
> 
>>> 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.
>  
>> 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.
> 
> Agreed, but with an extra note - once the operators have been
> nonassociative for a while, maybe making them associative again (but
> with the right meanings) might be more palatable.

My thoughts exactly.

Frits van Bommel wrote:
> Steve Horne wrote:
>> On Wed, 07 Feb 2007 17:06:07 -0800, "Andrei Alexandrescu (See Website
>> For Email)" <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> Walter Bright wrote:
>>
>>>> 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.
>>  
>>> 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.
>>
>> Agreed, but with an extra note - once the operators have been
>> nonassociative for a while, maybe making them associative again (but
>> with the right meanings) might be more palatable.
> 
> My thoughts exactly.

Never thought of that. Very interesting. The good cop/bad cop routine all over again :o).

Andrei

On Thu, 8 Feb 2007 16:36:47 +1100, Derek Parnell wrote:

> On Wed, 07 Feb 2007 19:51:06 -0800, Andrei Alexandrescu (See Website For
> Email) wrote:
> 
> 
>> It's really simple:
>> 
>> bool ordered(T, U, V)(T a, U b, V c)
>> {
>>    return a < b && b < c;
>> }
>> Expanding this to multiple arguments is also quite simple, but left as
>> an exercise. :o)
> 
> Okay, I'll give it a go, but I'm not confident.

I give up. I can't work out how to create this functionality for an arbitary number of arguments.

 e.g. When I code ...

  ordered(a,b,c,d,e)

I want generated ...

  (a < b) && (b < c) && (c < d) && (d < e)

I can't work out how to loop through the tuple.

I started with

  template ordered(T ...)
  {
  }

And everything I tried after that just didn't work.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

> I give up. I can't work out how to create this functionality for an arbitary number of arguments.

You need to use recursion, not loops. I'm not sure how the syntax works exactly, but it might look something like this:

bool ordered(T1, T2, Trest ...)(T1 first, T2 second, Trest rest) {
    return (first < second) && ordered(second, rest);
}

Peter Modzelewski wrote:
> some would like to use a<b<c in c style

Find me one person :)

You may use google code-search: find one example where a<b<c is not a bug. (Challenge #4 :D )

L.

Michiel wrote:
>> I give up. I can't work out how to create this functionality
>> for an arbitary number of arguments.
> 
> You need to use recursion, not loops. I'm not sure how the syntax works exactly,
> but it might look something like this:
> 
> bool ordered(T1, T2, Trest ...)(T1 first, T2 second, Trest rest) {
>     return (first < second) && ordered(second, rest);
> }

How about:


bool ascending(T ...)(T t) {
	static if (t.length > 0) {
		foreach (i, x; t[0..$-1]) {
			if (x >= t[i+1]) return false;
		}
	}
	return true;
}


void main() {
	assert (ascending(1, 2, 3, 4));
	assert (ascending(1, 2));
	assert (ascending(1.2, 2.1, 3.5, 4.7, 8.6));
	assert (!ascending(1.2, 1.0));
	assert (!ascending(1.2, 1.5, 0.5));
	assert (ascending(1));
	assert (ascending());
}


?


--
Tomasz Stachowiak

On Thu, 8 Feb 2007 10:50:56 +0000 (UTC), Michiel wrote:

>> I give up. I can't work out how to create this functionality for an arbitary number of arguments.
> 
> You need to use recursion, not loops. I'm not sure how the syntax works exactly, but it might look something like this:
> 
> bool ordered(T1, T2, Trest ...)(T1 first, T2 second, Trest rest) {
>     return (first < second) && ordered(second, rest);
> }

Maybe ... I tried many combinations based on that. Still no luck.

Show me something that compiles and runs, anyone?

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell