sommar@enea.se (Erland Sommarskog) (04/15/91)
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.
gudeman@cs.arizona.edu (David Gudeman) (04/16/91)
In article <3195@enea.se> Erland Sommarskog writes:
]
](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.
I wouldn't expect (4) to say false. Frankly, I wouldn't know what to
think of such an expression unless I had a clear definition like the
one you gave -- which strikes me as a perfectly sound one.
The definition
a <op1> b <op2> c ==> a <op1> b & b <op2> c
gives the correct meaning for transitive relations and a consistent
(but otherwise arbitrary) meaning for non-transitive relations. Since
I can't think of any non-arbitrary meaning for that construct for
non-transitive relations, I see no problem with the def above.
--
David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman