Re: Ranges and (non)static constraints

[Jean-Pierre Rosen <rosen@adalog.fr>]

Dmitry A. Kazakov a �crit :
> [;;;]
> I almost agree with this. However, unfortunately Ada does not require
> legality of
> 
>    type T range 1..N;
> 
> for any N, as it IMO should [*]. So the argument about portability becomes
> a bit shaky. In fact it is only more portable than the second. However, the
> second is definitely tasteless.
This is legal for any N less than System.Max_Int (and illegal 
otherwise). It is therefore portable on any machine which is capable of 
supporting it - and illegal otherwise. If your machine cannot support 
what you ask for, you'd better discover it at compile time! (I'm sure 
you agree with this).

> Well, this is nice in theory, which I strongly support. But this theory
> applies only to application software, where Absolute_Max_Expectable_Value
> is determinable from the problem space.
> 
> When developing portable libraries, and Ada is one of the best choices
> there, isn't it? Then the upper bound often becomes indeterminable. So
> people are forced to use [new] Integer. ARM does this as well by defining
> the type String based on Integer. Only in generics we have a choice to say:
> 
>    type T is range <>;
> 
> This shouldn't be so. It is IMO a language defect. 
> 
Actually, you have two (three) choices for libraries:
1) You want the maximum possible range. Declare a new type based on 
System.Max_Int.

2) You want a "reasonable" type, given the capabilities of the machine. 
Either derive from Integer, or use Integer directly (not a bad choice 
for vector or matrix indices for example). That's what String did. But 
in that case, there is no reason to put an additional range constraint. 
What I was objecting to is putting a range on a derivation from Integer.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr