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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.66.66.1 with SMTP id b1mr23533722pat.38.1411844072880; Sat, 27 Sep 2014 11:54:32 -0700 (PDT) X-Received: by 10.182.230.232 with SMTP id tb8mr1354obc.13.1411844072739; Sat, 27 Sep 2014 11:54:32 -0700 (PDT) Path: border1.nntp.dca1.giganews.com!nntp.giganews.com!h15no8185236igd.0!news-out.google.com!rp1ni712igb.0!nntp.google.com!h15no8185231igd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 27 Sep 2014 11:54:32 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=68.4.154.23; posting-account=KSa2aQoAAACOxnC0usBJYX8NE3x3a1Xq NNTP-Posting-Host: 68.4.154.23 References: <98f0066e-4b5c-4b00-b811-dcbb13ed0fcf@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Integers and Mathematical Correctness From: Adam Beneschan Injection-Date: Sat, 27 Sep 2014 18:54:32 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.dca.giganews.com comp.lang.ada:189192 Date: 2014-09-27T11:54:32-07:00 List-Id: On Saturday, September 27, 2014 9:32:52 AM UTC-7, Niklas Holsti wrote: > On 14-09-27 12:01 , AdaMagica wrote: >=20 > > Adam, > > Na, you forget > > A: Rational :=3D 1/3+1/4; > > This will be 0 for your function. >=20 > That seems not to be the case. With the definition >=20 > type Rational is record > Numerator, Denominator : Integer; > end record; >=20 > and the obvious definitions of "+", "/", and Image for Rational, the > program fragment >=20 > R : Rational :=3D 1/4 + 3/2; > begin > Put_Line (Image (R)); >=20 > results in the output >=20 > 7 / 2 Well, it should be 7/4 as Jeff pointed out, but yes, that's what I'd expect= as long as there are no versions of "+" that take one Integer and one Rati= onal parameter and return Rational. If there is a visible "+" like that, t= he program would be rejected as ambiguous. But 0 (or 0/1 or any Rational n= umber representing 0) is not a possible result. Christoph did point out that having those versions of "+" is important. De= fining another integer type to use as parameters to those functions is one = way of eliminating ambiguity--I assume that this type would use "is abstrac= t" to nullify all of the standard operator declarations that this type defi= nition would create. =20 function "+" (Left, Right : Whole_Number) return Whole_Number is abstra= ct; etc. But it's not the only way; you can manage without defining a new integer ty= pe. If=20 R : Rational :=3D 1/4 + 3/2 is ambiguous, you can disambiguate like this: R : Rational :=3D Rational'(1/4) + Rational'(3/2); which forces the compiler to use the versions of "/" that have a Rational r= esult, and ignore the declarations in Standard that return Integer. I thin= k there's a tradeoff. Having to add this in some places could be inconveni= ent. But the solution of defining another integer type is probably going t= o require some type conversions to and from that integer type (since you wo= uld not be able to use other arithmetic operations on that type), which cou= ld also be inconvenient. I don't know which is the better solution. Finally, I want to reiterate the point I made earlier: when it comes to ove= rload resolution, the *location* where the operators are declared (in a USE= 'd package, in Standard, in the local scope or an enclosing scope or a pare= nt package) is not relevant. It's relevant when you have two or more decla= rations that have the same name, AND the same parameters AND the same resul= t type. When that happens, the location is used to determine which declara= tion takes precedence over all other declarations THAT HAVE THE SAME PARAME= TER AND RESULT TYPES. Once that's done, there is at most one of each opera= tor with the same parameter/result types, but there can still be more than = one that have different parameter and/or result types. Deciding which of t= hose is used is called overload resolution or name resolution, and the loca= tions where the operators are declared has no effect on overload resolution= . -- Adam