Re: array from static predicate on enumerated type

[Shark8 <onewingedshark@gmail.com>]

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_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-dimensional array. I will have to do tests on the performance of a map of a map of a map of a... 

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 are 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 leaving out the non-primes of 3..7. HOWEVER, you could have a type (Steve, James, Dave) with the representation of  (Steve => 3, James => 5, Dave => 7), and functionally achieve the same thing. This is because the static-predicate is *NOT* a new type, but the addition of constraints upon the base. -- 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 having some slicing like (2..3,2..3,2..3) would involve some tedious math/mapping and also result in something that has non-contiguous memory. -- This was either overlooked in Ada83 or considered too complex to do correctly and efficiently, overly burdening compiler creators.

So, in Ada, there's no good choice for how to actually DO an array with gaps 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 missing indices would have gone, completely destroying what indexing on an Ada83..Ada2005 RANGE-constrained subtype would be expected to do? (The same "no 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 switched, so too is the relationship between Array and Map. (And also Function 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 memory, 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 distinguish 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 it is very surprising that it would break seemingly simple things like attributes and arrays.

I'm interested in language design and IMO syntax is the worst place to start 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 given 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 better 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 surprises.

Ada does have very few surprises; this is why it disallows the non-contiguous subtype indexing of the array.

> I evangelize for Ada when I can but I am of the opinion that language rules like these only frustrate people when create seemingly inconsistent 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 enough when there is a very simple solution that the programmer should not have to implement. My 2 cents. 

I think that in order to really fix the issue, we'd have to revisit the idea of multi-dimensional slices, as shown above, and *THAT* is a big can of worms.
It *is* doable, I think, but at far more time or energy at both the standards-level (the ARG's members) and at the implementation-level (the compiler writers).