Re: Inferring array index type from array object

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

Warren wrote:
> Niklas Holsti expounded in news:88ec2vF3uqU1@mid.individual.net:
>> Dmitry A. Kazakov wrote:
>>> On Wed, 23 Jun 2010 00:30:23 -0700 (PDT), Maciej Sobczak wrote:
> ..
>>>> 2. Is it possible to declare the index variable without hardcoding
>>>> the index type (that is, to infer it from the array object)?
>>> No, without improving the type system. E.g. introducing abstract
>>> index types, and abstract range types (or more general sets of index
>>> types), and abstract composite types like arrays.
>> I don't think such large language changes would be necessary. The 
>> expression S'Range gives the compiler all the information about the
>> type and its constraints, so I see no reason why Ada could not be
>> extended simply to allow S'Range in a variable declaration, as in the
>> above quoted "I : S'Range". The declared variable "I" would have the
>> same (sub)type as the loop counter in "for I in S'Range loop ...".
> 
> I think most would agree that this is a "convenience" feature.

Yes, but in other contexts, when we advocate Ada, we often make a big 
point of the "convenience" of the 'Range attribute for arrays, such as 
"No need to pass extra parameters for array index bounds, just use 
'Range". The suggestion to let variables be declared by the "type" 
S'Range (or, if desired, a new attribute S'Index_Type) has a similar 
advantage (but a weaker one, I admit).

> I think the language (and its compiler) is probably complicated
> enough for these types of additions. Don't forget each new feature
> requires a "test suite" and validation, in addition to the 
> compiler itself.

Yes, of course. But as time goes on, and as long as the extensions are 
backwards compatible, I think the compiler writers and validators could 
live with a growing test and validation suite. But then I am not one of 
those guys...

On the other hand, I do worry about language and compiler complexity. If 
the creation and maintenance of Ada compilers is very costly and 
difficult, it creates a risk for the survival of Ada, as well as a brake 
on the evolution of Ada. When we talk about "the Ada way", it seems to 
me that we have in mind a simpler and more elegant and uniform thing 
than the current Ada language -- some "core of Ada" that perhaps could 
be defined and implemented in an easier way. I suspect that Dmitry has 
the same feeling, which is why he keeps suggesting (or dreaming about) 
such large and fundamental changes to Ada.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .