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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,461276586f65363c X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!t31g2000cwb.googlegroups.com!not-for-mail From: "Adam Beneschan" Newsgroups: comp.lang.ada Subject: Re: Predefined equality, reemergence Date: 4 Apr 2006 16:57:22 -0700 Organization: http://groups.google.com Message-ID: <1144195041.057113.231640@t31g2000cwb.googlegroups.com> References: <1144179013.753791.169830@u72g2000cwu.googlegroups.com> <1144179981.495938.321410@e56g2000cwe.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1144195048 5397 127.0.0.1 (4 Apr 2006 23:57:28 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 4 Apr 2006 23:57:28 +0000 (UTC) User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: t31g2000cwb.googlegroups.com; posting-host=66.126.103.122; posting-account=cw1zeQwAAABOY2vF_g6V_9cdsyY_wV9w Xref: g2news1.google.com comp.lang.ada:3723 Date: 2006-04-04T16:57:22-07:00 List-Id: Randy Brukardt wrote: > "Adam Beneschan" wrote in message > news:1144179981.495938.321410@e56g2000cwe.googlegroups.com... > > I wrote: > > > Hi, everyone, > > > > > > I'm having trouble understanding how the language rules about > > > predefined equality, specifically 4.5.2(24), behave when the component > > > type involved may be seen as "tagged" or "untagged" depending on > > > whether you're inside an instance........... > > > > I mistakenly posted this before thoroughly checking the AI's. I found > > that AI-123 appears to address this question. I've been looking over > > this AI and I still don't know the answer to my question. > > I don't think AI-123 covers quite the same question. Yeah, that one appears to apply only to language-defined types. > But let me take a quick > stab at it. > > If in doubt, generics in Ada follow a substitution model; that is, the > result is the same if you wrote a non-generic equivalent. As such, I > certainly would not expect "=" (or anything else for that matter) to behave > differently depending on the location of the call. After all, you have a > *real* subprogram "=" (as opposed to an implicit one), and that subprogram > is going to have only one body of code. > > Now, it might be interesting to find language rules to back up this > conclusion. :-) Personally, I find this as a case of Dewar's Rule (the > standard doesn't mean to say anything stupid, even if the actual words can > be read to come to a stupid conclusion). I'll leave finding wording as an > exercise for someone else... The reason I thought that "=" might mean something different in an instance was because of the reemergence rules and how shared-code generics (something that I know is a concern of yours) would be difficult to implement without those rules. For example, generic type INT is range <>; package Genpack is..... Inside Genpack, anywhere you refer to "+" on objects of type INT, you get the predefined addition operation even if "+" has been overridden for the actual type. Code sharing would be very difficult otherwise, since you'd have to do an indirect call for every arithmetic operation. My first impression was that the same would apply to "=" on a generic formal (untagged) private type---for shared-code generics, you'd want the ability to compare two objects of your private type by doing a straight bit comparison. (Yeah, I know this causes problems for types with holes in them. So maybe this doesn't work anyway.) Anyway, I did a little more digging, and found that the rule that causes this reemergence is 12.5(8), which says, "In an instance, the copy of such an implicit declaration declares a view of the predefined operator of the actual type, even if this operator has been overridden for the actual type". This actually leads to some probably unintended results if you compare objects of type T in the instance. The rule says that saying Left=Right in the instance, if both objects have type T, means using the predefined equals operator, which is defined in 4.5.2. Reading this section closely, it appears that if the actual type for T is ACT, and ACT is a tagged record type, and there is a user-defined primitive operator "=" on ACT, then: if ACT is a private type, the predefined "=" is the user-defined "=" (4.5.2(15)), but if ACT is not a private type, the user-defined "=" isn't used, and instead we do a component-by-component equality operator as defined in 4.5.2(22-24). Thus, you get *neither* the user-defined "=" *nor* the straight bit comparison. Is this really what was intended? Should an exception be made in 12.5(8) for "=" on generic formal private types? Or at least when the actual type is tagged? Finding this wording still doesn't strictly answer my question. 12.5(8) tells us what "=" means on objects of type T in an instance, because it refers to an implicit declaration that gets copied. But it doesn't quite tell us what "=" means on a record that contains objects of type T (i.e. Rec in my example)---I don't think 4.5.2 gives a clear answer on this. If "=" on objects of type T may mean something different inside an instance than it does on objects of the actual type outside the instance, then which "=" should be used to compare components of type T, when we use "=" on objects of type Rec inside the instance---and when we use "=" on objects of type Rec outside the instance? -- Adam