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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID 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: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Equality operator overloading in ADA 83 Date: 1997/04/25 Message-ID: #1/1 X-Deja-AN: 237286717 References: <01bc4e9b$ac0e7fa0$72041dc2@lightning> <335E0B1F.12C9@elca-matrix.ch> <335F5971.6375@elca-matrix.ch> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-04-25T00:00:00+00:00 List-Id: Matthew said <> Right, it is usually the case that if you do not see the argument on the other side, it is because you don't know what it is! Language design is seldom simple. Actually the way I look at it, the troublesome cases are all with discrete types, and I wonder whether the better scheme might not have been to disallow the redefinition of equality on discrete types, or at least restrict it. In the case of composite types, or access types, it seems like there are really no problems in allowing composition -- maybe that says tha the COmpose_Equality pragma that I suggested should apply only to composite types and access types, though on the other hand it is harmless for discrete types. One of the problems arises in the treatment of private types. I often find it a problem that I want to redefine operators in the public view for those who see only the private type, but in the body it is a nuisance to have these operators around anyway. For examle, if the full declaration of Address is a modular type, which is reasonable, then you get ambiguities in the body of children of system that use Storage_Elements, which is a pain. What I would really like is the ability to declare operators for the client who sees the private view and not have these visible to the body. If you had some such arrangement, then it would be completely harmless to allow equality to compose for a public operator of this type (since in the body, the equality operator would not be visible, so these embarrassing questions about case statements, generics etc, would not arise. Note that if you have shared generics, there is a real cost to having equality compose. It means you have to thunk equality operators for all types, which is really painful from an efficiency point of view -- that is another factor in the original decision, but it too applies only to discrete types (you would have to thunk the equality operators for other kinds of types, but at least for composites, this would be harmless). I guess the generic case also makes one requestion the statement above about access types -- these don't cause problems with implicit equalities, e.g. in case, but they do cause efficiency embarrassments in shared generics. A lot of the design is driven by wanting to preserve the possibility for shared generics. My taste and, I believe, Tuck's taste is to decide once and for all that generics are not shared, and design the lanuage accordingly, but two existing vendors (RR particularly) use shared generics extensively, and Randy Burkhardt (from RR) was always reminding us about shared generics, and the need for accomodaing them. My feeling is that trying to design the language so eithre shared generics or macro-inserted generics work is a mistake. The two styles of implementations may be semantically equivalent, but they have a huge effect on portability in practice. You code in a completely different way if you have shared generics, since there is no reason not to write giant generics, whereas if you don't have shared generics, then you factor out the generic parts. Actually it is not entirely semantially neutral, there is a problem with exceptions, in that in the shared model there is only one, and in the unshared case there are multiple exceptions -- the current Ada 95 solution in this area is not very appetizing, and also causes portability difficulties.