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:596:: with SMTP id 144mr5453109qkf.387.1615993737351; Wed, 17 Mar 2021 08:08:57 -0700 (PDT) X-Received: by 2002:a25:e4c4:: with SMTP id b187mr5000650ybh.92.1615993737106; Wed, 17 Mar 2021 08:08:57 -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: Wed, 17 Mar 2021 08:08:56 -0700 (PDT) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=146.5.2.231; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 146.5.2.231 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: Shark8 Injection-Date: Wed, 17 Mar 2021 15:08:57 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:61590 List-Id: On Tuesday, March 16, 2021 at 10:05:31 PM UTC-6, Matt Borchers wrote: > So, I understand why holey arrays are problematic and I'm not asking for = holey arrays here. > I was looking for elegant solution around the fact that Ada intentionally= does not provide a reasonable answer to 'First, 'Last, etc. when used on e= numerated sub-types with a Predicate. As I attempted to explain up-thread, the issue you are looking at *IS* the = issue with holey arrays. > In my cases, I have a lot of small (less than 5 rows and columns) multi-d= imensional 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 constant array of data is ideal because loading the Map cann= ot be guaranteed correct by the compiler whereas a table would be. Since you want holes, you could use the abstraction to your benefit: Subtype Letters is Character range 'A'..'Z'; Subtype Curved is Letters with Static_Predicate =3D> Curved in 'B' | 'C' | 'D' | 'G' | 'J'; Type Curved_2 is ('B', 'C', 'D', 'G', 'J') with Size =3D> Letters'Size; For Curved_2 use ( 'B' =3D> Character'Pos( 'B' ), 'C' =3D> Character'Pos( 'C' ), 'D' =3D> Character'Pos( 'D' ), 'G' =3D> Character'Pos( 'G' ), 'J' =3D> Character'Pos( 'J' ) ); -------------- --Private/Body part Actual_Map : Constant Array (Curved_2) of Integer; -- In Body Function Do_Map(C : Character) return Integer is Function Convert is new Ada.Unchecked_Conversion( Source =3D> Character, Target =3D> Curved_2 ); Begin Return (if C in Curved then Actual_Map(Convert(C)) --ELSIF other_condition then Another_Map(Another_Conve= rt(C)) else raise Constraint_Error with "Invalid Index: '"& C= &"'."); End Do_Map; An array might be "ideal", but only if the thing you're indexing by is cont= iguous, otherwise you literally ARE asking for a slice with holes. Another option you might have is this: Table : Array (Character range 'A'..'Z') of Integer:=3D (Others =3D> 12= ); K : Integer :=3D 7 with Address =3D> Table('K')'Address; >=20 > It feels like an unfinished addition or incomplete feature to actively pr= event 'First, 'Last, etc. from returning something reasonable about the sub= -type 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:=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. Read my post upthread, then Randy's, and you'll see that the absence of the= se features is tied to the holy-array/-slice problem. Think about how difficult it would be to define multidimensional slices, wh= ich by their nature must be holey, and in a manner conducive to "efficiency= " (in the C programmer's meaning). > Again, I don't know the inner workings of the compiler, but these respons= es (above) for CURVED_LETTERS seem like reasonable values related to the su= b-type that the compiler could handle easily allowing programmers who might= want to write:=20 >=20 > type ARR(CURVED_LETTERS) of BOOLEAN;=20 >=20 > but for strict legality purposes have to suffice with:=20 >=20 > type ARR(CURVED_LETTERS'Pos(CURVED_LETTERS'First)..CURVED_LETTERS'Pos(CUR= VED_LETTERS'Last)) of BOOLEAN;=20 >=20 > It sure is ugly and some of you will surely yell, but we can do this now = with a regular enumerated type and so it should be consistent for an enumer= ated sub-type. At least creating an array from this type can be do-able wit= h access to these attributes and it can also be verified correct by the com= piler. Do you want such an array to hold 256 bits? One for each character with a C= ONSTRAINT_ERROR on bad indexing? (Meaning some sort of automatically genera= ted function that is invisibly integrated into this object.) Or are you wanting an array with holey indexes, collapsed spacewise, so tha= t it's only 5 bits? These are the questions which must be answered to even start to consider th= e issues at hand.