Joel C. Salomon wrote:
> Russell Lewis wrote:
>>> The chain that I'm concerned about is this:
>>>     a==b == c==d
>>> which (the spacing makes clear) is meant to be
>>>     (a==b) == (c==d)
>>> but which could me misread as
>>>     (a==b) && (b==c) && (c==d)
>>> and which is probably (I'm not sure) currently implemented by the compiler as:
>>>     ((a==b) ==c) ==d
>>>
>>> IMHO, C should have allowed comparison chaining from the start, but since it didn't, I don't think that it would be a good idea to start allowing it.  There will always be the newbies from C who will misread it.  (sigh)
>>
>> Addendum: I would be ok with making the less than/greater than operators be chainable (since those operators are nonsense when used with boolean values), but I would ask that no expression be able to mix less-than and greater-than.  It would be ok to mix < with <=, but not < with >.
> 
> Why this prejudice?  With the chaining as people have discussed it,
>     a < b > c
> expands to
>     (a < b) && (b > c)
> — why would you prohibit this?

I would assume the reason is because it's not used in math.

--bb

> > With the chaining as people have discussed it,
> >     a < b > c
> > expands to
> >     (a < b) && (b > c)
> > — why would you prohibit this?
> 
> I would assume the reason is because it's not used in math.

I’ve used it — and hairier stuff besides.
	∅ ≠ A ⊆ (Ω ∋ α) ⊆ℝⁿ
(No, I don’t actually expect any programming language to accept this.)

	“I do it all because I’m evil…” — Voltaire, “When you’re evil”

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.

I'd like to have

	if (a < b < c) ...

automatically expanding to

	if ((a < b) && (b < c)) ...

and
	if ((a < b) < c)

raising some exception. Well, i can't give you any serious reasons for
why, but i'm used to a < b < c from math.
I tried to find something else that would make it possible to write
something like

	if (b in [a,c])

where [a,b] is a compact interval (that means a <= b <= c). But this would let it not be distinguished from an interval's declaration as well as you wouldn't be able to write something like:

	if (b in (a,c])		// a < b <= c

Perhaps someone has a nice, good looking, easy readable solution.

On Thu, 8 Feb 2007 09:49:56 +0100
Henning Hasemann <hhasemann@web.de> wrote:

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

If I remember correctly this is also what eiffel does btw,
AND it whould be possible to realize additionally to the chaining.
see:

a < b < c means (a < b) && (b < c)
a == b == c == d means (a == b) && (b == c) && (c == d)

if you whould want to test if a == b yields the same boolean value as c == d,
i.e. (a == b) == (c == d)
you would write

(a == b) <-> (c == d)

note how clear this reads, you see at a first glance that results
of boolean expressions are compared, which, as it is not used very often
can not happen by accident (as up to now in a < b < c) anymore.

I'm not that sure if the <-> - Symbol is a good idea though, but Im sure it whould be possible to find alternatives to it.

Henning