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:a37:9c4d:: with SMTP id f74mr2792842qke.202.1615953930197; Tue, 16 Mar 2021 21:05:30 -0700 (PDT) X-Received: by 2002:a25:9303:: with SMTP id f3mr2633624ybo.165.1615953930022; Tue, 16 Mar 2021 21:05:30 -0700 (PDT) Path: eternal-september.org!reader02.eternal-september.org!news.mixmin.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: Tue, 16 Mar 2021 21:05:29 -0700 (PDT) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=2601:193:4103:71a0:bc1e:8a1c:4fb7:fe79; posting-account=1tLBmgoAAAAfy5sC3GUezzrpVNronPA- NNTP-Posting-Host: 2601:193:4103:71a0:bc1e:8a1c:4fb7:fe79 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 04:05:30 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:61569 List-Id: So, I understand why holey arrays are problematic and I'm not asking for ho= ley arrays here. I was looking for elegant solution around the fact that A= da intentionally does not provide a reasonable answer to 'First, 'Last, etc= . when used on enumerated sub-types with a Predicate. In my cases, I have = a lot of small (less than 5 rows and columns) multi-dimensional static data= . It appears instantiating a Map and populating it at program start-up is = the recommended solution. However, it sure seems to me that a static const= ant array of data is ideal because loading the Map cannot be guaranteed cor= rect by the compiler whereas a table would be. It feels like an unfinished addition or incomplete feature to actively prev= ent 'First, 'Last, etc. from returning something reasonable about the sub-t= ype in question. Return SOMETHING, even if it pertains to the parent type,= and let the programmer decide how it can be useful to them. Using my LETT= ERS and CURVED_LETTERS example, I still don't see why the following would b= e problematic: A <=3D LETTERS'First K <=3D LETTERS'Last 11 <=3D LETTERS'Length 1 <=3D LETTERS'Pos(B) 10 <=3D LETTERS'Pos(J) B <=3D CURVED_LETTERS'First J <=3D CURVED_LETTERS'Last 5 <=3D CURVED_LETTERS'Length 0 <=3D CURVED_LETTERS'Pos(B) 4 <=3D CURVED_LETTERS'Pos(J) I didn't address 'Succ and 'Pred, but these also seem reasonable. Again, I don't know the inner workings of the compiler, but these responses= (above) for CURVED_LETTERS seem like reasonable values related to the sub-= type that the compiler could handle easily allowing programmers who might w= ant to write: type ARR(CURVED_LETTERS) of BOOLEAN; but for strict legality purposes have to suffice with: type ARR(CURVED_LETTERS'Pos(CURVED_LETTERS'First)..CURVED_LETTERS'Pos(CURVE= D_LETTERS'Last)) of BOOLEAN; It sure is ugly and some of you will surely yell, but we can do this now wi= th a regular enumerated type and so it should be consistent for an enumerat= ed sub-type. At least creating an array from this type can be do-able with= access to these attributes and it can also be verified correct by the comp= iler. Matt