Re: OS Bindings (was: Where is the elusive jump command?)

[Robert A Duff <bobduff@world.std.com>]

Robert Dewar <robert_dewar@my-deja.com> writes:

> In article <wccg0srbbc4.fsf@world.std.com>,
>   Robert A Duff <bobduff@world.std.com> wrote:
> > If I made the rules, there would be no Max_Int.
> 
> That may be OK, multiple precision integers can be useful,
> so long as you do not go berserk and require that I be
> able to use them for case indexes, subscripts, entryu
> family indexes, loop variables, etc.
> 
> It is this kind of silly requirement that caused many Ada
> compilers not to even support 64-bit integers when they
> could have done so easily.

I agree about subscripts and entry families, but I don't see the problem
with case statements.  Loops?  I dunno.

I make the distinction because arrays are limited by address space;
there's not much point in an array (2**99..2**99+1).  But there could
well be a point in calculating numbers like 2**99 or 2**999.  And
there's nothing wrong with a case statement on such a type.

> The Ada 83 attitude was
> 
> "if you implement 64-bit integer arithmetic, you MUST allow
> all the above silly things, but it is absolutely FINE to not
> implement 64-bit integer arithmetic at all."
> 
> I am not sure whether we fixed this properly in Ada 95.

Well, the RM allows some sort of non-standard integer types,
which the implementation can arbitrarily restrict.
Eg, you could have a 128-bit integer type that allows "+"
and "-" but not "*" and "/".  You can't pass these weird types,
if they exist, as generic parameters.

> In the case of GNAT, we allow 64-bit integer arithmetic
> everywhere, and it would be very easy to allow larger
> arithmetic, provided it is clear we do not have to allow
> it in silly contexts.

I think that is clear.  I'm too lazy to look up the RM reference.  I do
remember that William Whitaker griped about this allowance rather
strongly, which surprised me, because it seemed to me silly to say (to a
compiler writer) you don't have to support X, but if you do support X,
you have to *fully* support it.  That's a bit different than saying, "if
you support X, you have to support it in a standard way", which is
something I have sometimes argued *for*.  I admit that I can't formally
define the difference between "incomplete support" and "different
support" -- but I know it when I see it ;-).

- Bob