a < b < c revisited

[sommar@enea.se (Erland Sommarskog)]

In the autumn of 1989 there was some discussion on the desire
to write a < b < c in various language with the result you
would expect. The discussion, and particulary a mail from
I believe Peter Da Silva, inspired me to post a proposal to 
comp.lang.eiffel and submit a revision request (RR) for Ada 9X.

The main idea for both langauges was that

(1)     a <rel-op1> b <rel-op2> c ....

should be interpreted as

(2)     a <rel-op1> b AND b <rel-op2> c ....

At first Betrand Meyer adopted my idea for Eiffel 3.0, but was
later convinced by Kim Walden, also from Enea, that the idea
introduced special cases to Eiffel which were not worth the
feature, and I basically agree on this point. However, this
problem is quite Eiffel specific. (An infix operator in Eiffel
is just shorthand for a feature call. My idea would make
implicit feature calls hiding in the code in one special case.)
And adding an "in" feature to the COMPARABLE class gives most
the advantages of the original idea.

Now, reading the draft mapping document for Ada 9X, my RR don't
seem to have made it there. (But strangely other odd minor details 
like block exit(!) and RETURN...WHEN have.)

But maybe that is just as well. A while ago I looked the following
piece of code I had written (with longer names than a, b and c.)

(3)     IF a /= b AND b/=c THEN

I said to myself with my RR I could rewrite this to:

(4)     IF a /= b /= c THEN

But, wait, is that really the same thing? Well, with the definition
above it is the same thing, but would we expect it to be the same
thing? No. (3) is true if a = c, but we would expect (4) to say
false in this case. With other words, my RR as it stood would introduce 
a trap in the language, very clearly a non-goal of the Ada-9X revision.

Hm, if we to redefine the interpreation in (2) to:

(5)    a <rel-op1> b AND b <rel-op1> AND a <rel-op2> c ...

which also fixes the case when someone has overloaded "<" in
a way that a < b AND b < c  does not imply a < c. However, we 
then run in problems with things like:

(6)    a < b = c > d

(5) does not give any reasonable interpretation to this, whereas
(2) does. Not really a problem, though, since the use of such
expressions are limited. So let's require that rel-op1, rel-op2
must be the same. But that prohibits from writing:

(7)   a < b <= c

which is useful. Now we can define rules which permits this, but
preclude the obscure cases, but then I feel that the rules have
reached a level of complexity where they are not worth the feature 
any more. (And then I haven't discussed the problem when a relational
operator is redefined to return something else than boolean.)

So, all in all, while nice to have, there are some unpleasant
surprises hiding here which make me think that excluding my
tiny RR from Ada 9X was rather wise. (Now, if only Tucker will
do the same with block exits.)
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
Le fils du maire est en Normandie avec beaucoup de medecins.