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:a05:620a:78b:: with SMTP id 11mr26306998qka.0.1615830489564; Mon, 15 Mar 2021 10:48:09 -0700 (PDT) X-Received: by 2002:a25:4ce:: with SMTP id 197mr1170789ybe.462.1615830489391; Mon, 15 Mar 2021 10:48:09 -0700 (PDT) Path: eternal-september.org!reader02.eternal-september.org!feeder1.feed.usenet.farm!feed.usenet.farm!tr2.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!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 10:48:09 -0700 (PDT) In-Reply-To: <26c44e00-a899-455a-a929-1e23c7935fe3n@googlegroups.com> 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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <9abb081d-a323-466d-9ae8-a2fc8fa24725n@googlegroups.com> Subject: Re: array from static predicate on enumerated type From: Shark8 Injection-Date: Mon, 15 Mar 2021 17:48:09 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:61529 List-Id: On Monday, March 15, 2021 at 8:11:24 AM UTC-6, Matt Borchers wrote: > So, what I'm taking away from this discussion is that instantiating a Map= is pretty much the best option when using a sub-type with a Static_Predica= te 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-dime= nsional array. I will have to do tests on the performance of a map of a map= of a map of a...=20 Map is the best thing to use, because that's what you're doing. There's some fundamental problems with how Ada's multidimensional arrays ar= e vs what your mental-model likely is: namely because they're contiguous on= the underlying type you cannot have an array with indices at, say, 3,5,7 l= eaving out the non-primes of 3..7. HOWEVER, you could have a type (Steve, J= ames, Dave) with the representation of (Steve =3D> 3, James =3D> 5, Dave = =3D> 7), and functionally achieve the same thing. This is because the stati= c-predicate is *NOT* a new type, but the addition of constraints upon the b= ase. -- This sort of problem comes along when talking about slices: suppose= you have a 5x5x5 three-dimensional array. Given that the memory locations = must be contiguous this means that (0,5,5) and (1,0,0) are adjacent so havi= ng some slicing like (2..3,2..3,2..3) would involve some tedious math/mappi= ng and also result in something that has non-contiguous memory. -- This was= either overlooked in Ada83 or considered too complex to do correctly and e= fficiently, overly burdening compiler creators. So, in Ada, there's no good choice for how to actually DO an array with gap= s in the index: do you make arrays possibly non-contiguous and force a more= complex model onto compilers, or do you eat up all the space where the mis= sing indices would have gone, completely destroying what indexing on an Ada= 83..Ada2005 RANGE-constrained subtype would be expected to do? (The same "n= o good choice" is why 'Succ and 'Pred are disallowed.) > The IN and INDEX operations (in this case sub-type'Pos) are very closely = related and so in my mind and it would seem that if IN works, then indexing= should work as well given a mapping function. But Array *isn't* a map, though often it is substituted as one. Array has further constraints, like the contiguous memory labeled above. Just like Array is different than Function, and the two can sometimes be sw= itched, so too is the relationship between Array and Map. (And also Functio= n and Map...) > A map function in this case, to me at least, is a black box that takes an= Integer input and outputs an Integer. Doesn't a memory array (contiguous m= emory, not Ada array, possibly using a binary search) do this very quickly = and a function or some other data structure a bit slower? Ada's arrays ARE contiguous memory; so I'm not sure what you're trying to d= istinguish here. >It seems the compiler could create this for the programmer if necessary. I= was only trying to suggest that when a new syntax feature is added, that i= t is very surprising that it would break seemingly simple things like attri= butes and arrays. I'm interested in language design and IMO syntax is the worst place to star= t with language-features, I find it far more productive to think semantics-= first then "hammer out" the syntax. > If using Static_Predicate induces a run-time cost in some instances then = so be it -- the programmer can decide if the cost is unreasonable. That is = the nature of all programming -- finding the ideal solution to a problem gi= ven the constraints of the system in which it operates be it speed, memory = footprint, etc. I would not argue that speed is always of utmost importance= . Static_Predicate should, IMO, be a compile-time thing; the problems though,= were about how these features should be handled at compile-time; arguably = the dissalowance of 'succ, 'pred and such [to possibly include arrays] was = a punt on the issue. > It seems like the Ada community is always chasing higher adoption and bet= ter recognition of the Ada language. If the community truly wants this, the= n Ada needs to be accessible as a general purpose language with very few su= rprises. Ada does have very few surprises; this is why it disallows the non-contiguo= us subtype indexing of the array. > I evangelize for Ada when I can but I am of the opinion that language rul= es like these only frustrate people when create seemingly inconsistent usab= ility. There may be a good technical reason to break the behavior, but in t= his example and in my opinion, the technical excuse is not good enough when= there is a very simple solution that the programmer should not have to imp= lement. My 2 cents.=20 I think that in order to really fix the issue, we'd have to revisit the ide= a of multi-dimensional slices, as shown above, and *THAT* is a big can of w= orms. It *is* doable, I think, but at far more time or energy at both the standar= ds-level (the ARG's members) and at the implementation-level (the compiler = writers).