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=0.0 required=3.0 tests=BAYES_40,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.5-pre1 X-Received: by 2002:a37:8c1:: with SMTP id 184mr8038343qki.472.1615601183413; Fri, 12 Mar 2021 18:06:23 -0800 (PST) X-Received: by 2002:a25:2654:: with SMTP id m81mr22348382ybm.405.1615601183197; Fri, 12 Mar 2021 18:06:23 -0800 (PST) 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: Fri, 12 Mar 2021 18:06:22 -0800 (PST) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=2601:193:4103:71a0:d84:b73e:e1e9:ac4b; posting-account=1tLBmgoAAAAfy5sC3GUezzrpVNronPA- NNTP-Posting-Host: 2601:193:4103:71a0:d84:b73e:e1e9:ac4b References: <89128f73-fcc5-4e57-8067-d09877ba0211n@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <6ca041f3-2669-4497-9548-2f17666702a6n@googlegroups.com> Subject: Re: array from static predicate on enumerated type From: Matt Borchers Injection-Date: Sat, 13 Mar 2021 02:06:23 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:61507 List-Id: I pretty much agree with Dmitry on this. The usefulness of this is very, v= ery low without better support from the language itself. However, Dmitry, = if programmers should not consider a feature of a language as an option for= a solution, then it begs the question on the quality of the language, qual= ity of the compiler, or questions the abilities of caretakers of Ada. Don'= t get me wrong, however, I think Ada is exceptional. I thought I read that 'Pred and 'Succ do work as one would expect for the P= redicated sub-type, but I did not try them as I did not need them. I did read the entire rationale and 'First_Valid and 'Last_Valid would allo= w the programmer to create an array with a range that guarantees inclusion = of all enumerated values of the statically predicated sub-type. But, this = leaves holes in the array as wasted memory. My actual use case is hundreds= of enumerated values and the sub-types have very few values each. Think o= f a case like a Unicode table where you might want to classify characters i= nto small non-contiguous groups and these character may be far apart from o= ne another. I do want a map or hash table, but in this case, I was hoping that Ada woul= d handle the mapping for me such that I did not have to instantiate such a = complexity for a simple example. I was a bit surprised after discovering S= tatic_Predicate that the Ada language syntax was essentially useless in dea= ling with it in a consistent way. I like the idea of creating non-contiguous enumerated sub-types. I've foun= d that I often want to do it and must seriously consider design decisions l= ike enumeration order that really should not be something that is that impo= rtant to program design. I think that if the language lets you define them= , then the rest of the supporting syntax of the language should also suppor= t them even if there is a small penalty of a double look-up through a mappi= ng table. I had a simple case many years ago with Ada 95, I think, when I was impleme= nting a checkers game. I wanted an enumeration of 5 items for the piece th= e occupied a square. type PIECE is ( EMPTY, RED, BLACK, RED_KING, BLACK_KING ); p : PIECE; This was a nice order because I could use the language syntax to determine = if piece was a King. subtype KING is PIECE range RED_KING..BLACK_KING; if p in KING then... However, I had to write a function to determine if a piece was Red or Black= and thus different calling syntax. The other order option was: type PIECE is ( EMPTY, RED, RED_KING, BLACK, BLACK_KING ); This order was nice because the language let me easily determine the Color = of a piece. subtype REDS is PIECE range RED..RED_KING; subtype BLACKS is PIECE range BLACK..BLACK_KING; if p in REDS then... but I'd have to write a function to determine if a piece was a King and sti= ll different calling syntax. Unfortunately, back then, the programmer couldn't have it both ways though = it would've been very convenient. It appears that Static_Predicate solves = this problem because "in" is updated to work with the Predicate. So if thi= s works, why was it decided that the rest of the language syntax be inconsi= stent? Surely a map table would have sufficed with a slight performance pe= nalty, but for the sake of language consistency you let the programmer deci= de. I can imagine an internally compiled map table would be much faster th= an the instantiation of the Map or Hash Container package. Matt