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,640b65cbfbab7216 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!wns13feed!worldnet.att.net!4.24.21.153!newsfeed3.dallas1.level3.net!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Ada.Strings.Bounded Date: Tue, 22 Apr 2008 12:08:49 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1wh7cbu67y4wz$.7iu8likx0fct.dlg@40tude.net> <144w648u50r6q.1erjxxu0cplbw.dlg@40tude.net> <611360e0-595c-43a7-b5cb-137a278ec0c1@s13g2000prd.googlegroups.com> <15389tuelo6x6$.1c1a6yixordts$.dlg@40tude.net> <4c1be2a2-0178-4c1f-8c96-526020550f42@w4g2000prd.googlegroups.com> <15514187-d7d0-4650-a058-13ec5684be2c@w5g2000prd.googlegroups.com> <07e98c4f-9b79-412f-9e95-94dd04082355@p39g2000prm.googlegroups.com> <81b0ae55-12a6-44e4-8481-3753b05d4464@f24g2000prh.googlegroups.com> <2b5c47f7-04f6-4530-b8d0-2a0b730a0fbd@y22g2000prd.googlegroups.com> <8ce7177e-fdf6-4942-ad5e-f64e92e34d16@l42g2000hsc.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1208880529 3271 192.74.137.71 (22 Apr 2008 16:08:49 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Tue, 22 Apr 2008 16:08:49 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:3bEzC7Tqq9l5AhP2GdRStY8huD0= Xref: g2news1.google.com comp.lang.ada:21036 Date: 2008-04-22T12:08:49-04:00 List-Id: Eric Hughes writes: > On Apr 21, 7:02 pm, Adam Beneschan wrote: >> The expected type is Z; therefore, in >> example C, the only possible meaning for "-" is the function that >> takes two arguments of type Z and returns Z. That, in turn, applies >> to "+". So it's 100% clear from the language rules what functions are >> called by this expression. The reason it doesn't raise >> Constraint_Error is 4.9(33), as I mentioned earlier. > > OK. But then what's the type of the subexpression "( Z0 + 1 )" within > the static expression "( Z0 + 1 ) - 1"? It can't be of type Z, since > it's outside the bounds of type Z. And the addition chosen can't be > the same addition as the declared one, which returns Z, and that > subexpression returns something that's not in Z. Ah, I see what might be confusing you. You need to understand the difference between types and subtypes. When you say: type Z is range ...; you are declaring a type and a subtype (the "first subtype"). The name Z refers to the firts subtype, and has the specified range. There is no way to refer to the type by name. Strange, but true! When I say "the type Z", I really mean "the type whose first subtype is Z". The RM sometimes uses the term "the type of subtype Z". The operators of the type Z can return results outside the range of Z. ^^^^^^ note sloppy/informal wording! Consider: type T is range 1..10; A : T := Read_From_Keyboard; B : T := Read_From_Keyboard; C : T := (A - 1) + B; Imagine Read_From_Keyboard reads a number between 1 and 10, and suppose we happen to get A = 1, and B = 5. C must equal 5, even though the intermediate result A-1 is out of range for T. The "base subtype", called T'Base, has an implementation-defined range, which covers at least -10..10, but might well be something like -2**31..2**31-1. At run time, operators will get the right answer if it's in the base range. If it's outside the base range, the compiler is ALLOWED to get the right answer, but is also allowed to overflow. >... The addition used > here has a different signature. > > It seems that the overload resolution rules don't apply when > universal_integer is involved. This seems a pretty obvious > consequence of 4.9(33). No, it's false, and is therefore obviously NOT a consequence of 4.9(33)! ;-) There are some special rules for univ_int (mainly, the implicit conversions), but the rules apply. - Bob