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:ad4:5887:: with SMTP id dz7mr25075613qvb.12.1615817483741; Mon, 15 Mar 2021 07:11:23 -0700 (PDT) X-Received: by 2002:a25:c943:: with SMTP id z64mr38553030ybf.73.1615817483509; Mon, 15 Mar 2021 07:11:23 -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: Mon, 15 Mar 2021 07:11:23 -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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <26c44e00-a899-455a-a929-1e23c7935fe3n@googlegroups.com> Subject: Re: array from static predicate on enumerated type From: Matt Borchers Injection-Date: Mon, 15 Mar 2021 14:11:23 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:61522 List-Id: So, what I'm taking away from this discussion is that instantiating a Map i= s pretty much the best option when using a sub-type with a Static_Predicate= to map a parent value to a sub-type. The simple example I gave here is a = one-dimensional array and what I actually have implemented is a multi-dimen= sional array. I will have to do tests on the performance of a map of a map= of a map of a... The IN and INDEX operations (in this case sub-type'Pos) are very closely re= lated and so in my mind and it would seem that if IN works, then indexing s= hould work as well given a mapping function. A map function in this case, = to me at least, is a black box that takes an Integer input and outputs an I= nteger. Doesn't a memory array (contiguous memory, not Ada array, possibly= using a binary search) do this very quickly and a function or some other d= ata structure a bit slower? It seems the compiler could create this for th= e programmer if necessary. I was only trying to suggest that when a new sy= ntax feature is added, that it is very surprising that it would break seemi= ngly simple things like attributes and arrays. If using Static_Predicate i= nduces a run-time cost in some instances then so be it -- the programmer ca= n decide if the cost is unreasonable. That is the nature of all programmin= g -- finding the ideal solution to a problem given the constraints of the s= ystem in which it operates be it speed, memory footprint, etc. I would not= argue that speed is always of utmost importance. It seems like the Ada community is always chasing higher adoption and bette= r recognition of the Ada language. If the community truly wants this, then= Ada needs to be accessible as a general purpose language with very few sur= prises. I evangelize for Ada when I can but I am of the opinion that langu= age rules like these only frustrate people when create seemingly inconsiste= nt usability. There may be a good technical reason to break the behavior, = but in this example and in my opinion, the technical excuse is not good eno= ugh when there is a very simple solution that the programmer should not hav= e to implement. My 2 cents. Matt