'Chained' operators

[DGDanforth]

In Component Pascal one can write

x := 2+5-10*32+6/11;

but one can not write
b := (0 <= x < 1)
nor can one write
a := b := c := 6;

Only arithmetic operators can be 'chained' (for want of a better word).
I would dearly love to have that restriction lifted such that expressions of the form

e = v {op v} (zero or more of)

are allowed where (at least) one has
op = {assignment op, Boolean op} (set of)

Comments requested.
-Doug

[ReneK]

IMHO, though this would reduce txping,it would also reduce readabilty.

[DGDanforth]

IMHO, though this would reduce txping,it would also reduce readabilty.

Rene,
I think (0<x) & (x <1) is harder to read than (0 < x < 1)

-Doug

[cfbsoftware]

IMHO, though this would reduce txping,it would also reduce readabilty.

Rene,
I think (0<x) & (x <1) is harder to read than (0 < x < 1)

-Doug

The problem with the concept of 'readability' is that it is very subjective. It can be affected by culture, personality, previous experience, ingrained habits etc. etc. Somebody with a mathematical background is likely to have a different opinion to somebody with an electronics background; an expert in C is likely to have a different opinion to an expert in Ada etc. etc.

Any proposal to introduce a change to the language design has to have a lot more going for it than just 'it is more readable' to be given serious consideration.

[DGDanforth]

Chris,
I agree that one needs strong reasons for any language redesign.
I must point out that 'chained operators' would be a super set.
Old programs would not be effected.
-Doug

[Josef Templ]

the 'chaining' for arithmetic operations follows from associativity.
Se 8.2: "Operators of the same precedence associate from left to right"
Thus, a + b + c is computed as (a + b) + c.
This does not apply to comparison operators, which yield a boolean result.
For = and # it could be done but may lead to surprises because
a = b = c may be different if computed as (a = b) = c versus (a = b) & (b = c),
for example when a is FALSE, b is TRUE and c is FALSE.

- Josef

[DGDanforth]

the 'chaining' for arithmetic operations follows from associativity.
Se 8.2: "Operators of the same precedence associate from left to right"
Thus, a + b + c is computed as (a + b) + c.
This does not apply to comparison operators, which yield a boolean result.
For = and # it could be done but may lead to surprises because
a = b = c may be different if computed as (a = b) = c versus (a = b) & (b = c),
for example when a is FALSE, b is TRUE and c is FALSE.

- Josef

Hence boolean operators do not satisfy associativity. If a, b, and c are numeric
then grouping does not make sense. (a=b) is a boolean but (a=b)=c is comparing a
boolean with a numeric. Hence no grouping. Chained operators are to be taken as
a gestalt, all at once whose implementation is (a op b) op' (b op c) where op' depends
upon the type of (a op b). For a := b := c the order of evaluation is right to left and
op' =';'. That is b:=c; a := b

[DGDanforth]

My goal in mentioning chained operators is to move closer to the syntax used in
mathematics and physics publications.