array from static predicate on enumerated type

[Matt Borchers <mattborchers@gmail.com>]

Say, for example, I define a static predicate on a sub-type of an enumerated type, like:

type LETTERS is ( A, B, C, D, E, F, G, H, I , J, K );

subtype CURVED is LETTERS
    with Static_Predicate CURVED in B | C | D | G | J;

What I want is an array over CURVED (using CURVED as the index), but since attributes 'First and 'Last (and thus 'Range) is not allowed, this cannot be done.

Also, I am restricted in that the order of LETTERS cannot be rearranged.

Has anybody come up with a clever data structure to make sub-types with predicates easy and sensible for indexing (not iterating)?

I only need read access, so I defined an array over 1..5 and then created a function that takes a LETTERS type as input and outputs a POSITIVE.

type ARR(1..5) of BOOLEAN;

function ARR_IDX( u : CURVED ) return POSITIVE is
    (case u is when B => 1, when C => 2, when D => 3, when G => 4, when J => 5);

states : ARR := (others => FALSE);
b : BOOLEAN;

Then later,

b := states(arr_idx(G))

What I don't like about this solution is all of it.  If an element is added to CURVED then the range of ARR would have to be updated and the case expression for ARR_IDX also needs to be updated.  At least with a case statement or expression, the compiler can identify that part for me.

I assume that internally an enumerated type is represented by its position such that LETTERS.G'Pos = 6.  Perhaps CURVED.G'Pos could result in 3?  If programmers could define an array over CURVED'Range, then any mapping math could be done by the compiler that they would have to do manually anyway.  It seems reasonable that the compiler could take care of this for us effectively as I have done, but there would be the benefit of doing static checks at compilation.  Perhaps a language lawyer could explain why this can't be so when the sub-type mark is explicitly provided.

I guess what I'm saying is that it would be nice if LETTERS.G equaled CURVED.G semantically (because CURVED is a sub-type), but LETTERS.G'Pos would not necessarily equal to CURVED.G'Pos.  I'm sure this was discussed and that there is a rational reason why this can't be so but I haven't given it a lot of thought myself.  I'm not expecting the same kind of lookup speed from the index mapping that needs to be done.

Beyond this, as an alternate solution, I think some type of basic hash functionality built into the language syntax for enumerated types would be useful and would go a long way to make Ada more contemporary and adoptable.  Using the generic hash packages in Containers is overkill for my needs.

Matt