Re: array from static predicate on enumerated type

[Matt Borchers <mattborchers@gmail.com>]

Dimitry,
I understand what you are saying.  But, we don't pass CURVED_LETTERS to Count, we pass a value of CURVED_LETTERS to Count.  In my mind, the value should then assumed to be of the type as declared in the parameter to Count -- which is LETTERS in your example.  Obviously any value of CURVED_LETTERS is actually a value of LETTERS.  This is how Ada treats this case now.

To your question, I would say that the compiler treat the argument for A : LETTERS as a member of LETTERS such that A'First = 0 and A'Last = 11 even if a value of CURVED_LETTERS was passed in (as it does now).

Runtime dispatching wouldn't work obviously.  It is also not legal to write two Count routines, one with A : LETTERS and the other with A : CURVED_LETTERS within the same scope.

If Count was written with a parameter A: CURVED_LETTERS then it can be assumed that A is a member of CURVED_LETTERS and A'First = 0 and A'Last = 4 and it would be up to the programmer to know that the sub-type Predicate has introduced additional constraints.  However, this would be different from all prior behavior of sub-types where the result of 'Pos (and the like) on both the enumerated type and the sub-type produce the same result.  In this sense, the introduction of the Predicate would alter the behavior and thus could, in some sense, be considered inconsistent.  I now see that implementing this could cause run-time errors in existing code that used 'Pos and the rest on a sub-type to which a Predicate was added.

This discussion is helpful as I am now understanding that what I'm thinking is perhaps also equally inconsistent.  My current thinking is that I preferred a value of a sub-type to continue to be comparable (with =) to a value of the parent type, but I also wanted it to behave like a full-fledged type when using its attributes.  Nevertheless, it still feels like an unfinished feature as it is now.

Regards,
Matt


On Wednesday, March 17, 2021 at 3:08:38 AM UTC-4, Dmitry A. Kazakov wrote:
> On 2021-03-17 05:05, Matt Borchers wrote: 
> 
> > It feels like an unfinished addition or incomplete feature to actively prevent 'First, 'Last, etc. from returning something reasonable about the sub-type in question. Return SOMETHING, even if it pertains to the parent type, and let the programmer decide how it can be useful to them. Using my LETTERS and CURVED_LETTERS example, I still don't see why the following would be problematic: 
> > 
> > A <= LETTERS'First 
> > K <= LETTERS'Last 
> > 11 <= LETTERS'Length 
> > 1 <= LETTERS'Pos(B) 
> > 10 <= LETTERS'Pos(J) 
> > 
> > B <= CURVED_LETTERS'First 
> > J <= CURVED_LETTERS'Last 
> > 5 <= CURVED_LETTERS'Length 
> > 0 <= CURVED_LETTERS'Pos(B) 
> > 4 <= CURVED_LETTERS'Pos(J) 
> > 
> > I didn't address 'Succ and 'Pred, but these also seem reasonable.
> Consider this: 
> 
> function Count (A : LETTERS) return Natural is 
> Count : Natural := 0; 
> begin 
> for I in A'First..A'Last loop 
> Count := Count + 1; 
> end loop; 
> end Count; 
> 
> How this supposed to be compiled? Note that CURVED_LETTERS is a subtype 
> of LETTERS. So you can pass CURVED_LETTERS to Count. 
> 
> Count cannot use LETTERS'First, 'Succ etc in its body, they might be 
> overridden they are like in CURVED_LETTERS. 
> 
> In short it must either dispatch on the actual argument or else the 
> argument must be converted to LETTERS in a way that LETTERS operations 
> would yield the correct result. 
> 
> Neither is possible.
> -- 
> Regards, 
> Dmitry A. Kazakov 
> http://www.dmitry-kazakov.de