Re: Ranges and (non)static constraints

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"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