Re: Ada Decimal Arithmetic & Representations (ADAR) V1.0 available

[kst@telesoft.com (Keith Thompson @pulsar)]

In article <EACHUS.93Mar23203327@dr_no.mitre.org> eachus@dr_no.mitre.org (Robert I. Eachus) writes:
> [...]
> In article <1993Mar22.223336.23771@telesoft.com> kst@telesoft.com (Keith Thompson @pulsar) writes:
> 
> > Ahem.  Actually, it's a shortcoming of the package that it depends
> > on Long_Integer....
> 
> > If you want the longest possible integer type (whatever its name
> > happens to be in Standard), use something like this:
> 
> >    type Longest_Integer is range System.Min_Int .. System.Max_Int;
> 
>   FLAME ON!!!!
> 
>     This sort of abstract pontificating has its place, but in this
> case you do a significant disservice in posting something like this
> without looking at the actual packages.
> 
>     First, most of the use of system dependant types occurs either in
> a configuration package or in examples.
> 
>     Second, every such case is commented with WHY the decision to
> declare things that way was made.
> 
>     Third, there are cases where declarations like Longest_Integer
> above will simply not work, because you must use Standard.Integer.
> Two examples are the rules in 3.6.1(2) and the exponentiation
> operators defined in 4.5.6(4).
> 
>     Forth, well you get the picture...
> 
>   FLAME OFF.
> [...]

I admit that I was a little quick to attack the package without being
sufficiently familiar with it.  Inappropriate use of predefined integer
types happens to be one of my hot buttons.  I apologize to the authors
of the ADAR packages for any perceived flame; it was unintentional.

HOWEVER...

The article I was responding to (not written by Robert Eachus) described
the Alsys SPARC compiler's lack of a Long_Integer type as a shortcoming.
This is unfair (IMHO).  For the SPARC hardware, it's perfectly appropriate
to define type Integer as 32 bits (it's a 32-bit processor, after all),
and not to define a type Long_Integer (the SPARC doesn't directly support
64-bit arithmetic operations).

Even if one is using only a single compiler/host/target combination, it's
still a good idea to avoid predefined integer types other than Integer.
The choice of how and whether to define types such as Short_Integer and
Long_Integer is an arbitrary one made by the compiler implementers.
It's unlikely that these names really correspond to concepts in
the problem domain; that's what user-defined integer types are for.
(They also keep you from comparing apples and oranges.)  Using Integer
is sometimes necessary, as you pointed out; it can also be perfectly
appropriate if all you need is an integer type of "reasonable" size,
range, and efficiency.

I've found that, even if portability isn't a concern (in those extremely
rare cases where you're sure that it will *never* be a concern),
writing software in as portable a fashion as practical tends to make
it cleaner and more easily maintainable.  If I'm maintaining a piece of
software that is never intended to run on anything other than a JCN 9000
computer with a FooCorp version 6.9 Ada compiler, I'd still rather deal
with a user-defined integer type than have to remember how the compiler
implementers chose to define Long_Integer.  (A brownie point to anyone
who recognizes "JCN 9000").

I offer this as general advice to Ada programmers, not as a criticism of
the ADAR packages.  Configuration packages and examples are probably
among the rare cases where direct use of predefined integer types other
than Integer can be appropriate.  I do understand the need to get down
close to the hardware and/or compiler when you're writing low-level
numeric software.

Besides, isn't a large part of the purpose of Ada, and of computer
science in general, to bring "abstract pontificating" down into useful
real-life domains?

> Where they can, we did, but for example, find the largest power of ten
> smaller than Integer'LAST in static Ada...)

This isn't pretty, but it should work for anything up to 64-bit
integers.  Thanks to Gary Dismukes for the idea.

with Text_IO;
procedure Power is
   B01: constant := Boolean'Pos(Integer'Last > 10 ** 1);
   B02: constant := Boolean'Pos(Integer'Last > 10 ** 2);
   B03: constant := Boolean'Pos(Integer'Last > 10 ** 3);
   B04: constant := Boolean'Pos(Integer'Last > 10 ** 4);
   B05: constant := Boolean'Pos(Integer'Last > 10 ** 5);
   B06: constant := Boolean'Pos(Integer'Last > 10 ** 6);
   B07: constant := Boolean'Pos(Integer'Last > 10 ** 7);
   B08: constant := Boolean'Pos(Integer'Last > 10 ** 8);
   B09: constant := Boolean'Pos(Integer'Last > 10 ** 9);
   B10: constant := Boolean'Pos(Integer'Last > 10 ** 10);
   B11: constant := Boolean'Pos(Integer'Last > 10 ** 11);
   B12: constant := Boolean'Pos(Integer'Last > 10 ** 12);
   B13: constant := Boolean'Pos(Integer'Last > 10 ** 13);
   B14: constant := Boolean'Pos(Integer'Last > 10 ** 14);
   B15: constant := Boolean'Pos(Integer'Last > 10 ** 15);
   B16: constant := Boolean'Pos(Integer'Last > 10 ** 16);
   B17: constant := Boolean'Pos(Integer'Last > 10 ** 17);
   B18: constant := Boolean'Pos(Integer'Last > 10 ** 18);
   B19: constant := Boolean'Pos(Integer'Last > 10 ** 19);
   B20: constant := Boolean'Pos(Integer'Last > 10 ** 20);
   Exponent: constant
      := B01 + B02 + B03 + B04 + B05 + B06 + B07 + B08 + B09 + B10 +
	 B11 + B12 + B13 + B14 + B15 + B16 + B17 + B18 + B19 + B20;
   Largest_Power_Of_Ten: constant := 10 ** Exponent;
begin
   Text_IO.Put_Line("Largest_Power_Of_Ten = " &
		    Integer'Image(Largest_Power_Of_Ten));
   Text_IO.Put_Line("Integer'Last         = " &
		    Integer'Image(Integer'Last));
end Power;
-- 
Keith Thompson (The_Other_Keith)  kst@telesoft.com
TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
5959 Cornerstone Court West, San Diego, CA, USA, 92121-9891
"Listen to me, people!  We must stick them with quills -- it's the only way!"