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=3.8 required=5.0 tests=BAYES_00,INVALID_MSGID, RATWARE_MS_HASH,RATWARE_OUTLOOK_NONAME autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c3a7c1845ec5caf9 X-Google-Attributes: gid103376,public From: "Nick Roberts" Subject: Re: Equality operator overloading in ADA 83 Date: 1997/04/26 Message-ID: <01bc5244$315f1560$28f982c1@xhv46.dial.pipex.com>#1/1 X-Deja-AN: 237516398 References: <01bc4e9b$ac0e7fa0$72041dc2@lightning> <335F5971.6375@elca-matrix.ch> Organization: UUNet PIPEX server (post doesn't reflect views of UUNet PIPEX) Newsgroups: comp.lang.ada Date: 1997-04-26T00:00:00+00:00 List-Id: Robert A Duff wrote in article ... [case example] > Ada's choice is to check those rules at compile time, but that's not > part of the "essence". [...] either way, it > doesn't require forbidding strings and other types. That decision is > based on ease-of-implementation and ease-of-efficient-implementation, I > think. I'm not arguing that Ada should have this feature -- it's a > useful feature, but doesn't really match the semantic level of Ada. > (When you start having super-high-level features, you can no longer > guess how efficient the implementation will be. E.g. if there are a lot > of branches, will the compiler generate a hash table of some sort? A > perfect has function? Who knows?) > The [case example] is clearer than: [an elsif sequence] > for two reasons: you know the case expression is evaluated exactly once, > so you needn't worry about side effects, and you know that exactly one > of the case alternatives applies, whereas with an "elsif" chain, it > might be the case that two of the alternatives are True, but the > programmer carefully ordered them so that you never get to the second > one. In other words, you know these useful facts when you see "case", > whereas with "elsif" chains, you need to study the code carefully to > know these facts, if they are true in a particular case (or rely on > comments, which might lie, or might not be there). The Ada language makes no specifications for the efficiency of the implementation of any construct anyway. Most programmers would be aware that a case statement applied to a non-discrete type would (probably) have to be implemented as a sequence of comparisons. As to the property of mutual exclusion - this is the 'essence' of the case statement - the implementation would probably have to test every choice at run time in order to check that only one choice evaluates to True (and raise an exception otherwise). In all other respects, I cannot see any reason why the suggested extension to the case statement would be impracticable. It would surely be a boon to programmers, as it would be a neat way express the mutual exclusion implied in certain situations, and, at the same time, have a runtime check (which could perhaps be removed by a pragma Suppress where necessary) to enforce this exclusion. Programmers would have to be taught not to use the facility inappropriately (as with many other Ada features). Maybe in a future revision. Nick.