Re: Ranges and (non)static constraints

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 17 Nov 2006 11:37:14 +0100, Jean-Pierre Rosen wrote:

> 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).

Actually it is not the machine which cannot, but the compiler. Why should I
care if an integer would fit a machine word?

>> 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. 

3) I don't want to mention any constraint now, but delegate it to the user.
Generics is the only option for this now.

> 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.

Yes, I definitely agree with this rule.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de