From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.lang.misc:7421 comp.lang.ada:5236 comp.lang.eiffel:1503 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!enea!sommar From: sommar@enea.se (Erland Sommarskog) Newsgroups: comp.lang.misc,comp.lang.ada,comp.lang.eiffel Subject: a < b < c revisited Message-ID: <3195@enea.se> Date: 14 Apr 91 22:10:45 GMT Followup-To: comp.lang.misc Organization: Enea Data AB, Sweden List-Id: 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 b c .... should be interpreted as (2) a b AND b 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 b AND b AND a 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.