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:550b:: with SMTP id j11mr1688656qtq.360.1616031018452; Wed, 17 Mar 2021 18:30:18 -0700 (PDT) X-Received: by 2002:a25:6b44:: with SMTP id o4mr6083675ybm.161.1616031018197; Wed, 17 Mar 2021 18:30:18 -0700 (PDT) Path: eternal-september.org!reader02.eternal-september.org!news.uzoreto.com!fdc3.netnews.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!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 18:30:18 -0700 (PDT) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=2601:193:4103:71a0:956a:5c4a:8722:ccd9; posting-account=1tLBmgoAAAAfy5sC3GUezzrpVNronPA- NNTP-Posting-Host: 2601:193:4103:71a0:956a:5c4a:8722:ccd9 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: <9933c99a-46b1-4541-aa15-f5c23e92b037n@googlegroups.com> Subject: Re: array from static predicate on enumerated type From: Matt Borchers Injection-Date: Thu, 18 Mar 2021 01:30:18 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 5102 Xref: reader02.eternal-september.org comp.lang.ada:61603 List-Id: On Wednesday, March 17, 2021 at 3:41:16 PM UTC-4, Dmitry A. Kazakov wrote: > On 2021-03-17 19:44, Matt Borchers wrote:=20 >=20 > > I understand what you are saying. But, we don't pass CURVED_LETTERS to = Count, we pass a value of CURVED_LETTERS to Count. > You cannot pass that value. It is type violation as type operations and= =20 > the values set are different. [Predicate does not create a new type, it= =20 > only breaks the old one.] So the value must be converted to the expected= =20 > type (the conversion can be null) or else the operation must be=20 > overridden or inherited with type conversion or else be class-wide and=20 > then the value must be converted to a class-wide value. So what I think I hear you saying is that values of a sub-types with a stat= ic predicate are not valid values of the parent without explicit type conve= rsion -- like values of Natural are valid values of Integer without explici= t type conversion. Is that correct? So, I certainly would expect B to be = valid without a cast when assigned to a variable of type LETTERS or CURVED_= LETTERS. I need to verify this. > > In my mind, the value should then assumed to be of the type as declared= in the parameter to Count -- which is LETTERS in your example. Obviously a= ny value of CURVED_LETTERS is actually a value of LETTERS. This is how Ada = treats this case now. > Yes and it is no different to how Ada treats arrays of CURVED_LETTERS=20 > right now. Given: subtype HEX_LETTERS is LETTERS range A..F; When I create an array over Natural Ada does not create an array over Integ= er. So I would expect that WITHOUT Static_Predicate, Ada would not create = an array over the parent enumeration LETTERS when defined on the sub-type H= EX_LETTERS. So, this was my expectation for CURVED_LETTERS with the Static= _Predicate before I read the rules. > > 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 1= 1 even if a value of CURVED_LETTERS was passed in (as it does now). > Then why you expect a different behavior from an array of CURVED_LETTERS? I think you misunderstood me. Given the following, function L_POS( x : LETTERS ) return NATURAL is (LETTERS'Pos(x)); and function CL_POS( x : CURVED_LETTERS ) return NATURAL is (CURVED_LETTERS'Pos= (x)); I would have expected the following results: 1 <=3D l_pos(B) 0 <=3D cl_pos(B) 4 <=3D l_pos(E) exception <=3D cl_pos(E) > > This discussion is helpful as I am now understanding that what I'm thin= king is perhaps also equally inconsistent. My current thinking is that I pr= eferred a value of a sub-type to continue to be comparable (with =3D) to a = value of the parent type, but I also wanted it to behave like a full-fledge= d type when using its attributes. > You cannot have it both ways. Of course, and I'm not requesting what my expectations were. But, I'm stil= l trying to understand why it can't be done because, after all, if a progra= mmer can write it, then a compiler could code-generate it. > > Nevertheless, it still feels like an unfinished feature as it is now. > It is not unfinished. It is irreparably broken. And this does not make for good advertising for Ada. Regards, Matt