Ranges and (non)static constraints

Ranges and (non)static constraints

[Maciej Sobczak]

Hi,

type T is range 1 .. N;
type U is new Integer range 1 .. M;

N must be static, but M does not have to.
Why and what is the real difference between T and U?

(Please feel free to use formal terminology if that helps to explain the 
above, I just got confused and need to put the pieces together again.)

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Ranges and (non)static constraints

[Martin Krischik]

On 16 Nov., 12:02, Maciej Sobczak <no.s...@no.spam.com> wrote:
> Hi,
>
> type T is range 1 .. N;
> type U is new Integer range 1 .. M;
>
> N must be static, but M does not have to.
> Why and what is the real difference between T and U?

Let me answer with a question: What value has T'Size?

Martin

Re: Ranges and (non)static constraints

[Maciej Sobczak]

Martin Krischik wrote:
> 
> On 16 Nov., 12:02, Maciej Sobczak <no.s...@no.spam.com> wrote:
>> Hi,
>>
>> type T is range 1 .. N;
>> type U is new Integer range 1 .. M;
>>
>> N must be static, but M does not have to.
>> Why and what is the real difference between T and U?
> 
> Let me answer with a question: What value has T'Size?

Whatever the compiler picks to fit the given range? :-)

OK, now I see - but is there any preference I should give to one of 
these two forms apart from that? I understand that the second form is 
the only I can use if the range is not statically known and (what 
surprised me) when the constraints come from formal generic parameters.
But even if the range is known statically, I might choose to always use 
the second form for notational consistency. Is this recommended?

Assuming that T'Size = U'Size, can I expect any run-time observable 
(including performance) differences between T and U?

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Ranges and (non)static constraints

[Jeffrey R. Carter]

Maciej Sobczak wrote:
> 
> OK, now I see - but is there any preference I should give to one of 
> these two forms apart from that? I understand that the second form is 
> the only I can use if the range is not statically known and (what 
> surprised me) when the constraints come from formal generic parameters.
> But even if the range is known statically, I might choose to always use 
> the second form for notational consistency. Is this recommended?

No. You're relying on Integer, which is only required to be 16 bits. In 
addition, Integer is the only required predefined integer type. So using 
Long_Integer and its friends is not portable. So it's best to use the 
1st form whenever possible. When you must have a non-static range, you 
should define your own parent type using application limits on the 
possible range to derive from. If there are no such limits, then use a 
type based on System.Min_Int and System.Max_Int to derive from.

> Assuming that T'Size = U'Size, can I expect any run-time observable 
> (including performance) differences between T and U?

There should be none. In your example, U'Size = Integer'Size.

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail
08

Re: Ranges and (non)static constraints

[Robert A Duff]

"Martin Krischik" <krischik@users.sourceforge.net> writes:

> On 16 Nov., 12:02, Maciej Sobczak <no.s...@no.spam.com> wrote:
>> Hi,
>>
>> type T is range 1 .. N;
>> type U is new Integer range 1 .. M;
>>
>> N must be static, but M does not have to.
>> Why and what is the real difference between T and U?
>
> Let me answer with a question: What value has T'Size?

Good question.  But perhaps a better question is: What is the range of
T'Base?  That's what determines overflows in intermediate expression
results.

- Bob

Re: Ranges and (non)static constraints

[Dmitry A. Kazakov]

On Thu, 16 Nov 2006 12:02:15 +0100, Maciej Sobczak wrote:

> type T is range 1 .. N;
> type U is new Integer range 1 .. M;
> 
> N must be static, but M does not have to.
> Why and what is the real difference between T and U?

Informally, the second is an abbreviation for:

   type <anonymous> is new Integer;
   subtype U is <anonymous> range 1..M;

so "range" refers to a subtype. On the contrary, in the first, "range"
refers a type. So the difference.

Is it real? I don't think so. I would eliminate this difference between
types and subtypes by allowing the latter to have a different
representation than the base. So the first should be also an abbreviation
for

   type <anonymous> is new Universal_Integer;
   subtype T is <anonymous> range 1..N;

That would make both legal (or, maybe, illegal (:-)).

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

Re: Ranges and (non)static constraints

[Jean-Pierre Rosen]

Dmitry A. Kazakov a �crit :
> On Thu, 16 Nov 2006 12:02:15 +0100, Maciej Sobczak wrote:
> 
>> type T is range 1 .. N;
>> type U is new Integer range 1 .. M;
>>
>> N must be static, but M does not have to.
>> Why and what is the real difference between T and U?
> 
> Informally, the second is an abbreviation for:
> 
>    type <anonymous> is new Integer;
>    subtype U is <anonymous> range 1..M;
> 
> so "range" refers to a subtype. On the contrary, in the first, "range"
> refers a type. So the difference.
> 
> Is it real? I don't think so. 

Sorry, but there is a huge difference. With U, the range cannot be 
outside the range of Integer, under penalty of Constraint_Error. T is 
valid as long as the compiler offers a big enough integer type, and if 
it doesn't, it won't compile.

Actually, the second form should never be used: you are relying on 
Integer, a non-portable type that plays absolutely (or almost) no 
special role in Ada. Why derive from Integer, rather than from 
Long_Integer, or anything else?

If you want dynamic bounds, remember that anything "dynamic" has to have 
an upper limit at some point. It is thus better to write:

type Biggest_T is range 1 .. Absolute_Max_Expectable_Value;
subtype T is Biggest_T range 1 .. N;
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ranges and (non)static constraints

[Dmitry A. Kazakov]

On Thu, 16 Nov 2006 18:18:47 +0100, Jean-Pierre Rosen wrote:

> Dmitry A. Kazakov a �crit :
>> On Thu, 16 Nov 2006 12:02:15 +0100, Maciej Sobczak wrote:
>> 
>>> type T is range 1 .. N;
>>> type U is new Integer range 1 .. M;
>>>
>>> N must be static, but M does not have to.
>>> Why and what is the real difference between T and U?
>> 
>> Informally, the second is an abbreviation for:
>> 
>>    type <anonymous> is new Integer;
>>    subtype U is <anonymous> range 1..M;
>> 
>> so "range" refers to a subtype. On the contrary, in the first, "range"
>> refers a type. So the difference.
>> 
>> Is it real? I don't think so. 
> 
> Sorry, but there is a huge difference. With U, the range cannot be 
> outside the range of Integer, under penalty of Constraint_Error. T is 
> valid as long as the compiler offers a big enough integer type, and if 
> it doesn't, it won't compile.
> 
> Actually, the second form should never be used: you are relying on 
> Integer, a non-portable type that plays absolutely (or almost) no 
> special role in Ada. Why derive from Integer, rather than from 
> Long_Integer, or anything else?

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.

But is this difference "real"?

> If you want dynamic bounds, remember that anything "dynamic" has to have 
> an upper limit at some point. It is thus better to write:
> 
> type Biggest_T is range 1 .. Absolute_Max_Expectable_Value;
> subtype T is Biggest_T range 1 .. N;

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. 

-------------
* OK, there still remains a limitation on the biggest universal integer a
compiler can swallow, but it is a different dimension.

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

Re: Ranges and (non)static constraints

[Stuart]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:g2go52hf14qn.16tb2xiy7ilrf.dlg@40tude.net...

> On Thu, 16 Nov 2006 18:18:47 +0100, Jean-Pierre Rosen wrote:
>> Dmitry A. Kazakov a �crit :
>>> On Thu, 16 Nov 2006 12:02:15 +0100, Maciej Sobczak wrote:
>>>
>>>> type T is range 1 .. N;
>>>> type U is new Integer range 1 .. M;
>>>>
>>>> N must be static, but M does not have to.
>>>> Why and what is the real difference between T and U?
...
>> Actually, the second form should never be used: you are relying on
>> Integer, a non-portable type that plays absolutely (or almost) no
>> special role in Ada. Why derive from Integer, rather than from
>> Long_Integer, or anything else?
...
>> If you want dynamic bounds, remember that anything "dynamic" has to have
>> an upper limit at some point. It is thus better to write:
>>
>> type Biggest_T is range 1 .. Absolute_Max_Expectable_Value;
>> subtype T is Biggest_T range 1 .. N;

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

Surely there is System.Max_Int!
   [ARM 13.7 (23)] The largest (most positive) value allowed for the 
expression
  of a signed_integer_type_definition.

So you would have:
   type Biggest_T is range 1..System.Max_Int;
  subtype T is Biggest_T range 1..N;

-- 
Stuart 

Re: Ranges and (non)static constraints

[Jean-Pierre Rosen]

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

Re: Ranges and (non)static constraints

[Dmitry A. Kazakov]

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

Re: Ranges and (non)static constraints

[Jean-Pierre Rosen]

Dmitry A. Kazakov a �crit :
> Actually it is not the machine which cannot, but the compiler. Why should I
> care if an integer would fit a machine word?
In theory you are right, but in practic you may assume that compiler 
writers are not crazy and want to provide a product that's useful to 
their clients. Although nothing really requires it in the RM, it is
safe to assume that System.Max_Int is the biggest integer value that can 
be handled by the machine, and that Standard.Integer is the usual, 
efficient integer type.

> 3) I don't want to mention any constraint now, but delegate it to the user.
> Generics is the only option for this now.
OK, that's another option. What's the problem?

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

Re: Ranges and (non)static constraints

[Dmitry A. Kazakov]

On Fri, 17 Nov 2006 17:04:00 +0100, Jean-Pierre Rosen wrote:

> Dmitry A. Kazakov a �crit :

>> 3) I don't want to mention any constraint now, but delegate it to the user.
>> Generics is the only option for this now.
> OK, that's another option. What's the problem?

Generics are too limiting in too many aspects.

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

Re: Ranges and (non)static constraints

[Stephen Leake]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Dmitry A. Kazakov a �crit :
>> Actually it is not the machine which cannot, but the compiler. Why should I
>> care if an integer would fit a machine word?
> In theory you are right, but in practic you may assume that compiler
> writers are not crazy and want to provide a product that's useful to
> their clients. Although nothing really requires it in the RM, it is
> safe to assume that System.Max_Int is the biggest integer value that
> can be handled by the machine, and that Standard.Integer is the usual,
> efficient integer type.

This is specifically not true for GNAT; all GNAT compilers handle 64
bit integers, regardless of target.

I believe the philosophy is that portability is more important than
performance; if you need better performance, then either pick a better
target processor, or spend more time optimizing the code.


-- 
-- Stephe

Re: Ranges and (non)static constraints

[Jeffrey R. Carter]

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

I agree. GNAT has gone a little ways in this direction, providing 64-bit 
integers on 32-bit machines. If I ever get around to defining NINA, it 
will accept any range for integer types. Of course, if you make them too 
big, objects of the type may raise Memory_Exhausted. There would be ways 
to create integer types that correspond to those supported by the HW, 
where that's important. And there'd be type Unbounded_Integer, providing 
use of the unbounded-integer library used by the compiler.

-- 
Jeff Carter
"Beyond 100,000 lines of code you
should probably be coding in Ada."
P. J. Plauger
26

Re: Ranges and (non)static constraints

[Robert A Duff]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes:

> Dmitry A. Kazakov wrote:
>> Actually it is not the machine which cannot, but the compiler. Why
>> should I
>> care if an integer would fit a machine word?
>
> I agree. GNAT has gone a little ways in this direction, providing 64-bit
> integers on 32-bit machines. If I ever get around to defining NINA, it
> will accept any range for integer types. Of course, if you make them too
> big, objects of the type may raise Memory_Exhausted. There would be ways
> to create integer types that correspond to those supported by the HW,
> where that's important.

What's NINA?

I think you're on the right track, here.  The goal should be (1) the
program can use arbitrarily large integers (up to the memory limit), as
in Lisp et al, and (2) if you don't need that, you don't pay any
efficiency cost (no distributed overhead).  I don't know of any language
that achieves both.

If I say:

    type T is range 1..1_000_000;
    X : constant T := ...;
    Y : constant T := ...;
    Z : constant T := (X + Y) / 2;

it is implementation dependent whether or not the calculation of Z
overflows.  That's bad.  (But no implementations overflow in that case,
so nobody cares, and people write such things all the time.)

If I say:

    type T is range 1..1_000_000_000_000;

some implementations fail at compile time, and some do not.  That's bad,
too.  I ought to be allowed to say, portably:

    type T is range 1..10**100;

>... And there'd be type Unbounded_Integer, providing
> use of the unbounded-integer library used by the compiler.

Well, I'll quibble with your names, here.  When God created the
integers, He didn't say they stop at 2**31-1 or 2**64 or whatever!
The term "integer" (or the abbreviation "int") ought to mean the true
unbounded integers.  Names like Unbounded_Integer and _universal_integer
are an abomination.  ;-)

- Bob

Re: Ranges and (non)static constraints

[Dmitry A. Kazakov]

On Fri, 17 Nov 2006 18:58:00 -0500, Robert A Duff wrote:

> If I say:
> 
>     type T is range 1..1_000_000_000_000;
> 
> some implementations fail at compile time, and some do not.  That's bad,
> too.  I ought to be allowed to say, portably:
> 
>     type T is range 1..10**100;

Yes, that's my point. I would also add:

   type T is range <>;  -- A true bignum, like Unbounded_String

>>... And there'd be type Unbounded_Integer, providing
>> use of the unbounded-integer library used by the compiler.
> 
> Well, I'll quibble with your names, here.  When God created the
> integers, He didn't say they stop at 2**31-1 or 2**64 or whatever!
> The term "integer" (or the abbreviation "int") ought to mean the true
> unbounded integers.  Names like Unbounded_Integer and _universal_integer
> are an abomination.  ;-)

Yes, but there is a naming problem of different things:

1. An unconstrained set of integer numbers = mathematical Integer, bignum.
No bounds, whatsoever, similar to Unbounded_String.

2. A finite subset of, which bounds are unknown until run-time, similar to
String.

3. A finite subset with statically known bounds, similar to String (1..80).

Ideally, both 3 and 2 should be defined in terms of 1.

BTW, what about

   type M is mod <>;

This looks as a bit harder nut. Considering:

   X : M := 23; -- Hmm, which the modulo here? (:-))

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

Re: Ranges and (non)static constraints

[Jeffrey R. Carter]

Robert A Duff wrote:
> 
> What's NINA?

It's the name I've given to the language I've been thinking about for 
some time. NINA is an acronym; it stands for NINA Is Not Ada.

> Well, I'll quibble with your names, here.  When God created the
> integers, He didn't say they stop at 2**31-1 or 2**64 or whatever!
> The term "integer" (or the abbreviation "int") ought to mean the true
> unbounded integers.  Names like Unbounded_Integer and _universal_integer
> are an abomination.  ;-)

You may have a point, there. What do you think the Ada type Integer 
should be called, if Integer referred to Z? 
String_Index_And_Exponentiation_Value seems a bit excessive to me, but 
perhaps the concepts should be separated.

-- 
Jeff Carter
"Sheriff murdered, crops burned, stores looted,
people stampeded, and cattle raped."
Blazing Saddles
35

Re: Ranges and (non)static constraints

[Björn Persson]

Jeffrey R. Carter wrote:

>> Well, I'll quibble with your names, here. �When God created the
>> integers, He didn't say they stop at 2**31-1 or 2**64 or whatever!
>> The term "integer" (or the abbreviation "int") ought to mean the true
>> unbounded integers. �Names like Unbounded_Integer and _universal_integer
>> are an abomination. �;-)
> 
> You may have a point, there. What do you think the Ada type Integer
> should be called, if Integer referred to Z?

How about Hardware_Integer, Machine_Integer or Efficient_Integer?

-- 
Bj�rn Persson                              PGP key A88682FD
                   omb jor ers @sv ge.
                   r o.b n.p son eri nu

Re: Ranges and (non)static constraints

[Robert A Duff]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes:

> Robert A Duff wrote:
>> What's NINA?
>
> It's the name I've given to the language I've been thinking about for
> some time. NINA is an acronym; it stands for NINA Is Not Ada.

OK.  I'm sure I will enjoy reading the RM for it someday.

But are you sure you want to define it by what it is NOT,
rather than what it IS?  ;-)

>> Well, I'll quibble with your names, here.  When God created the
>> integers, He didn't say they stop at 2**31-1 or 2**64 or whatever!
>> The term "integer" (or the abbreviation "int") ought to mean the true
>> unbounded integers.  Names like Unbounded_Integer and _universal_integer
>> are an abomination.  ;-)
>
> You may have a point, there. What do you think the Ada type Integer
> should be called, if Integer referred to Z?
> String_Index_And_Exponentiation_Value seems a bit excessive to me, but
> perhaps the concepts should be separated.

String_Index seems reasonable for indexing strings.  Machine_Integer
seems reasonable for a type that matches the machine's register size
(but it should not be in Standard).  I think one wants a way to say
(e.g.) that a type ranges from 1 up to at least a million, but it's fine
to go beyond that, and please make it efficient (for example, perhaps
round it up to 2**31-1).

Instead of Machine_Integer, perhaps we want a way to define a type that
can count the number of Mumble objects, given that if we create more
than some number of Mumble objects, or an array of them, we can be sure
this count will not overflow.  That is, we would have run out of
(virtual) memory before that count overflows.

- Bob

Re: Ranges and (non)static constraints

[Jeffrey R. Carter]

Robert A Duff wrote:
> 
> OK.  I'm sure I will enjoy reading the RM for it someday.

As I will yours.

> But are you sure you want to define it by what it is NOT,
> rather than what it IS?  ;-)

I'll define it by what it is, and name it by what it isn't.

> String_Index seems reasonable for indexing strings.  Machine_Integer
> seems reasonable for a type that matches the machine's register size
> (but it should not be in Standard).  I think one wants a way to say
> (e.g.) that a type ranges from 1 up to at least a million, but it's fine
> to go beyond that, and please make it efficient (for example, perhaps
> round it up to 2**31-1).
> 
> Instead of Machine_Integer, perhaps we want a way to define a type that
> can count the number of Mumble objects, given that if we create more
> than some number of Mumble objects, or an array of them, we can be sure
> this count will not overflow.  That is, we would have run out of
> (virtual) memory before that count overflows.

That would have to be a dynamic type, as the actual upper bound could 
not generally be known at compile time.

-- 
Jeff Carter
"Ditto, you provincial putz?"
Blazing Saddles
86

Re: Ranges and (non)static constraints

[Robert A Duff]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes:

>> Instead of Machine_Integer, perhaps we want a way to define a type that
>> can count the number of Mumble objects, given that if we create more
>> than some number of Mumble objects, or an array of them, we can be sure
>> this count will not overflow.  That is, we would have run out of
>> (virtual) memory before that count overflows.
>
> That would have to be a dynamic type, as the actual upper bound could
> not generally be known at compile time.

I don't see why.  It's easy to come up with a static worst-case bound
based on the size of the address space.

- Bob

Re: Ranges and (non)static constraints

[Adam Beneschan]

Robert A Duff wrote:

> OK.  I'm sure I will enjoy reading the RM for it someday.
>
> But are you sure you want to define it by what it is NOT,
> rather than what it IS?  ;-)

That would indeed be interesting.  Instead of specifying the correct
syntax for anything, the RM would specify only what constructs are
illegal.  Then any program that doesn't violate one of the RM rules
would be legal by default, and Jeff's compiler would have to figure out
what the program is supposed to do and compile it correctly.  :)

                        -- Adam

Re: Ranges and (non)static constraints

[Maciej Sobczak]

Jean-Pierre Rosen wrote:

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

Then imagine that the following apply (both):
1. I want a "reasonable" type (matrix indices or even... strings), which 
will play nice with the underlying machine architecture.
2. I want a named subtype with dynamically determined constraints so 
that I can use this named subtype in subsequent array definitions, 
loops, etc.

With such assumptions, the following:

type T is new Integer range 1..N;

seems reasonable, right?

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Ranges and (non)static constraints

[Jean-Pierre Rosen]

Maciej Sobczak a �crit :
> Jean-Pierre Rosen wrote:
> 
>> 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.
> 
> Then imagine that the following apply (both):
> 1. I want a "reasonable" type (matrix indices or even... strings), which 
> will play nice with the underlying machine architecture.
> 2. I want a named subtype with dynamically determined constraints so 
> that I can use this named subtype in subsequent array definitions, 
> loops, etc.
> 
> With such assumptions, the following:
> 
> type T is new Integer range 1..N;
> 
> seems reasonable, right?
> 
Hmmm... What *I* would do is define:
type My_Index is new Integer;

and use unconstrained array definitions with that type.
I would let the subtype to the user.

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

AW: Ranges and (non)static constraints

[Grein, Christoph (Fa. ESG)]

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 [*]
...
> * OK, there still remains a limitation on the biggest universal integer a compiler
> can swallow, but it is a different dimension.

I cannot follow. This is legal exactly when the compiler can fulfil the requested range.
So what are you talking about?

Re: Ranges and (non)static constraints

[Dmitry A. Kazakov]

On Fri, 17 Nov 2006 11:39:55 +0100, Grein, Christoph (Fa. ESG) 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 [*]
> ...
>> * OK, there still remains a limitation on the biggest universal integer a compiler
>> can swallow, but it is a different dimension.
> 
> I cannot follow. This is legal exactly when the compiler can fulfil the requested range.
> So what are you talking about?

These are sufficiently different. Consider this example:

   N : constant := 2**64; -- Legal in GNAT
   type T is range 1..N;  -- Illegal in GNAT

(This is not a bug)

I would at least require the second be legal when the first is.

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

Re: Ranges and (non)static constraints

[Stuart]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1msd2xaahtsgv.f8io255x4f0n$.dlg@40tude.net...

> These are sufficiently different. Consider this example:
>
>   N : constant := 2**64; -- Legal in GNAT
>   type T is range 1..N;  -- Illegal in GNAT
>
> (This is not a bug)
>
> I would at least require the second be legal when the first is.

Why?  The first is a named value declaration (rather than a constant object 
declaration).  In the type declaration I think the semantics of Ada require 
that the base type be a signed type, which thus introduces issues of 
symmetry around zero.

Unfortunately I am in a bit of a rush at the moment so I don't have a chance 
to test an idea like:
   type T is mod N range 1..N-1;

Regards
-- 
Stuart 

Re: Ranges and (non)static constraints

[Dmitry A. Kazakov]

On Fri, 17 Nov 2006 13:30:34 -0000, Stuart wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1msd2xaahtsgv.f8io255x4f0n$.dlg@40tude.net...
> 
>> These are sufficiently different. Consider this example:
>>
>>   N : constant := 2**64; -- Legal in GNAT
>>   type T is range 1..N;  -- Illegal in GNAT
>>
>> (This is not a bug)
>>
>> I would at least require the second be legal when the first is.
> 
> Why?  The first is a named value declaration (rather than a constant object 
> declaration).  In the type declaration I think the semantics of Ada require 
> that the base type be a signed type, which thus introduces issues of 
> symmetry around zero.

So? Let it allocate two 64-bit words! It is not my business, Ada is a
higher-level language.

> Unfortunately I am in a bit of a rush at the moment so I don't have a chance 
> to test an idea like:
>    type T is mod N range 1..N-1;

You mean:

   type T is mod N;
   subtype S is T range 1..N;

No, that won't work.

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

Re: Ranges and (non)static constraints

[Jean-Pierre Rosen]

Dmitry A. Kazakov a �crit :
> 
> You mean:
> 
>    type T is mod N;
>    subtype S is T range 1..N;
> 
> No, that won't work.
> 
And with reason. How could you define what the automatic mod would do?

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

Re: Ranges and (non)static constraints

[Stuart]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
 news:pu08fww26xs9$.jctxs7a23inh.dlg@40tude.net...

> On Fri, 17 Nov 2006 13:30:34 -0000, Stuart wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1msd2xaahtsgv.f8io255x4f0n$.dlg@40tude.net...
>>
>>> These are sufficiently different. Consider this example:
>>>
>>>   N : constant := 2**64; -- Legal in GNAT
>>>   type T is range 1..N;  -- Illegal in GNAT
>>>
>>> (This is not a bug)
>>>
>>> I would at least require the second be legal when the first is.
>>
>> Why?  The first is a named value declaration (rather than a constant 
>> object
>> declaration).  In the type declaration I think the semantics of Ada 
>> require
>> that the base type be a signed type, which thus introduces issues of
>> symmetry around zero.
>
> So? Let it allocate two 64-bit words! It is not my business, Ada is a
> higher-level language.

There is nothing in Ada that stops this, however compiler's typically draw a 
line somewhere.

Ada is a higher-level language - but it also acknowledges the practicalities 
of compiler design, efficient implementation and the 'broad spectrum' of 
what users may want to achieve.  Compiler writers set out their product for 
the market place they want.  There is nothing in Ada that prevents what you 
seem to be wanting - but compiler writers don't seem to be operating in that 
area.  Adopting a 'no compromise' approach they might say - "It's not my 
business, choose a compiler that does support it".

>> Unfortunately I am in a bit of a rush at the moment so I don't have a 
>> chance
>> to test an idea like:
>>    type T is mod N range 1..N-1;

> You mean:
>   type T is mod N;
>   subtype S is T range 1..N;

Well, almost
    subtype S is T range 1..N-1;

(my apologies - in my haste to go home I repeated the semantics which have 
already been shown to be inappropriate for various reasons).

> No, that won't work.

Because N is not a value in the modular type, or for some other reason?

Earlier I had noted:

> Surely there is System.Max_Int!
>    [ARM 13.7 (23)] The largest (most positive) value allowed for the
>   expression of a signed_integer_type_definition.
>
>  So you would have:
>    type Biggest_T is range 1..System.Max_Int;
>    subtype T is Biggest_T range 1..N;

There is also System.Max_Binary_Modulus, which (on the system I have checked 
with) is larger than System.Max_Int (2**32 vs 2**31 - 1).  But that then 
starts getting into other areas where Ada is treading a fine line between 
language concepts and practical implementations (note 
System.Max_Nonbinary_Modulus).

[So upon reflection the whole 'mod' thing is possibly a bad idea unless you 
consider the likely practical implementation issues - which DK seems to be 
trying to avoid].

However, from my point of view, Ada seems to be giving me - through these 
constants - the means to write practical routines, without 'undue' 
artificial constraints.  I can even set minimum levels of support by doing 
something like:

    type Biggest_T is range 1..System.Max_Int;
    subtype Minimum is Biggest_T range 1..10_000;
    subtype T is Biggest_T range 1..N;

I accept that at the very fringes I might need to play carefully with 
Max_Int and Max_Binary_Modulus, but then I consider that playing close to 
the edge is always fraught with danger - so I accept the risks with 
portability.

-- 
Stuart 

Re: Ranges and (non)static constraints

[Stuart]

"Stuart" <stuart@0.0> wrote in message 
news:4561b3d2$1_1@glkas0286.greenlnk.net...

>> You mean:
>>   type T is mod N;
>>   subtype S is T range 1..N;
>
> Well, almost
>    subtype S is T range 1..N-1;

double Doh!

    type T is mod System.Max_Binary_Modulus;
    subtype S is T range 1..N-1;

(many apologies; again)

-- 
Stuart 

Re: Ranges and (non)static constraints

[Dmitry A. Kazakov]

On Mon, 20 Nov 2006 14:12:49 -0000, Stuart wrote:

> "Stuart" <stuart@0.0> wrote in message 
> news:4561b3d2$1_1@glkas0286.greenlnk.net...
> 
>>> You mean:
>>>   type T is mod N;
>>>   subtype S is T range 1..N;
>>
>> Well, almost
>>    subtype S is T range 1..N-1;
> 
> double Doh!
> 
>     type T is mod System.Max_Binary_Modulus;
>     subtype S is T range 1..N-1;

> (many apologies; again)

Unfortunately S is not a true integer type. For example, you will get no
overflow upon wrapping. For example, when System.Max_Binary_Modulus = N,
then S'Last+2 would result in 1. For the same reason, the subtype
declaration should be rather:

   subtype S is T range 1..T(N-1);

Otherwise it won't compile when N is not in T'Range, but N-1 is.

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

Re: Ranges and (non)static constraints

[Jeffrey R. Carter]

Dmitry A. Kazakov wrote:
> Informally, the second is an abbreviation for:
> 
>    type <anonymous> is new Integer;
>    subtype U is <anonymous> range 1..M;
> 
> so "range" refers to a subtype. On the contrary, in the first, "range"
> refers a type. So the difference.

Actually, the 1st is an abbreviation for:

    type <anonymous> is new
       <hardware-specific type with sufficient range>;
    subtype T is <anonymous> range 1 .. N;

It's allowing the compiler to decide which hardware-specific type to use 
that results in N needing to be static.

-- 
Jeff Carter
"Hello! Smelly English K...niggets."
Monty Python & the Holy Grail
08

Re: Ranges and (non)static constraints

[Adam Beneschan]

Maciej Sobczak wrote:
> Hi,
>
> type T is range 1 .. N;
> type U is new Integer range 1 .. M;
>
> N must be static, but M does not have to.
> Why and what is the real difference between T and U?

I believe U'Base'First will necessarily be equal to Integer'Base'First
(and similarly for 'Last), while T'Base'First and 'Last will be
whatever the compiler picks.

                       -- Adam