From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.5-pre1 X-Received: by 2002:ac8:7b23:: with SMTP id l3mr399146qtu.165.1616006668171; Wed, 17 Mar 2021 11:44:28 -0700 (PDT) X-Received: by 2002:a25:6b44:: with SMTP id o4mr3807028ybm.161.1616006667893; Wed, 17 Mar 2021 11:44:27 -0700 (PDT) Path: eternal-september.org!reader02.eternal-september.org!news.uzoreto.com!news.muarf.org!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 17 Mar 2021 11:44:27 -0700 (PDT) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=192.160.103.146; posting-account=1tLBmgoAAAAfy5sC3GUezzrpVNronPA- NNTP-Posting-Host: 192.160.103.146 References: <89128f73-fcc5-4e57-8067-d09877ba0211n@googlegroups.com> <6ca041f3-2669-4497-9548-2f17666702a6n@googlegroups.com> <26c44e00-a899-455a-a929-1e23c7935fe3n@googlegroups.com> <9abb081d-a323-466d-9ae8-a2fc8fa24725n@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: array from static predicate on enumerated type From: Matt Borchers Injection-Date: Wed, 17 Mar 2021 18:44:28 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:61596 List-Id: Dimitry, I understand what you are saying. But, we don't pass CURVED_LETTERS to Cou= nt, we pass a value of CURVED_LETTERS to Count. In my mind, the value shou= ld then assumed to be of the type as declared in the parameter to Count -- = which is LETTERS in your example. Obviously any value of CURVED_LETTERS is= actually a value of LETTERS. This is how Ada treats this case now. To your question, I would say that the compiler treat the argument for A : = LETTERS as a member of LETTERS such that A'First =3D 0 and A'Last =3D 11 ev= en if a value of CURVED_LETTERS was passed in (as it does now). Runtime dispatching wouldn't work obviously. It is also not legal to write= two Count routines, one with A : LETTERS and the other with A : CURVED_LET= TERS within the same scope. If Count was written with a parameter A: CURVED_LETTERS then it can be assu= med that A is a member of CURVED_LETTERS and A'First =3D 0 and A'Last =3D 4= and it would be up to the programmer to know that the sub-type Predicate h= as introduced additional constraints. However, this would be different fro= m all prior behavior of sub-types where the result of 'Pos (and the like) o= n both the enumerated type and the sub-type produce the same result. In th= is sense, the introduction of the Predicate would alter the behavior and th= us could, in some sense, be considered inconsistent. I now see that implem= enting this could cause run-time errors in existing code that used 'Pos and= the rest on a sub-type to which a Predicate was added. This discussion is helpful as I am now understanding that what I'm thinking= is perhaps also equally inconsistent. My current thinking is that I prefe= rred a value of a sub-type to continue to be comparable (with =3D) to a val= ue of the parent type, but I also wanted it to behave like a full-fledged t= ype when using its attributes. Nevertheless, it still feels like an unfini= shed feature as it is now. Regards, Matt On Wednesday, March 17, 2021 at 3:08:38 AM UTC-4, Dmitry A. Kazakov wrote: > On 2021-03-17 05:05, Matt Borchers wrote:=20 >=20 > > It feels like an unfinished addition or incomplete feature to actively = prevent 'First, 'Last, etc. from returning something reasonable about the s= ub-type in question. Return SOMETHING, even if it pertains to the parent ty= pe, and let the programmer decide how it can be useful to them. Using my LE= TTERS and CURVED_LETTERS example, I still don't see why the following would= be problematic:=20 > >=20 > > A <=3D LETTERS'First=20 > > K <=3D LETTERS'Last=20 > > 11 <=3D LETTERS'Length=20 > > 1 <=3D LETTERS'Pos(B)=20 > > 10 <=3D LETTERS'Pos(J)=20 > >=20 > > B <=3D CURVED_LETTERS'First=20 > > J <=3D CURVED_LETTERS'Last=20 > > 5 <=3D CURVED_LETTERS'Length=20 > > 0 <=3D CURVED_LETTERS'Pos(B)=20 > > 4 <=3D CURVED_LETTERS'Pos(J)=20 > >=20 > > I didn't address 'Succ and 'Pred, but these also seem reasonable. > Consider this:=20 >=20 > function Count (A : LETTERS) return Natural is=20 > Count : Natural :=3D 0;=20 > begin=20 > for I in A'First..A'Last loop=20 > Count :=3D Count + 1;=20 > end loop;=20 > end Count;=20 >=20 > How this supposed to be compiled? Note that CURVED_LETTERS is a subtype= =20 > of LETTERS. So you can pass CURVED_LETTERS to Count.=20 >=20 > Count cannot use LETTERS'First, 'Succ etc in its body, they might be=20 > overridden they are like in CURVED_LETTERS.=20 >=20 > In short it must either dispatch on the actual argument or else the=20 > argument must be converted to LETTERS in a way that LETTERS operations=20 > would yield the correct result.=20 >=20 > Neither is possible. > --=20 > Regards,=20 > Dmitry A. Kazakov=20 > http://www.dmitry-kazakov.de