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

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

[Michele L. Kee (AdaIC)]

The source code for Ada Decimal Arithmetic and Representations (ADAR),
Version 1.0, January 1993, which was developed under the Ada Joint
Program Office's Ada Technology Insertion Program (ATIP), is now
available for anonymous FTP on the AJPO host computer,
ajpo.sei.cmu.edu.  The source code has been UNIX TAR'd and compressed
into one file, "ADAR-1.0.tar.Z".

The ADAR packages were developed to provide a common approach for
decimal arithmetic and Ada 83.  The ADAR package set consists of two
related facilities for decimal arithmetic, one based on discriminant
records, and the other on generics, to provide decimal computation and
interoperable representations of decimal quantities.

The ADAR packages include support for decimal data with up to 18
digits of precision, arithmetic operations with programmer control
over rounding versus truncation, conversions to and from common
external representations, and formatted output of decimal values based
on COBOL's "picture" clauses.

Anonymous FTP:

Host: ajpo.sei.cmu.edu
IP address: 128.237.2.253
Location: /public/atip/adar/ADAR-1.0.tar.Z


For those of you without FTP access, the AJPO host provides mail-server
capabilities.  Use the "file-request" service to receive an uuencoded copy
of the file, ADAR-1.0.tar.Z.  Address your message as such --

	To: ftpmail@ajpo.sei.cmu.edu
	Subject: file-request atip/adar/ADAR-1.0.tar.Z

There is no need for any text in the body of your message.
-- 
Ada Information Clearinghouse (AdaIC)		|  IIT Research Institute
703/685-1477, 800/AdaIC-11, FAX 703/685-7019	|  operates the AdaIC for
Internet:  adainfo@ajpo.sei.cmu.edu		|  the Ada Joint Program
CompuServe:  70312,3303				|  Office (AJPO).

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

[Michael Feldman]

In article <1993Mar19.161646.26563@sei.cmu.edu> adainfo@ajpo.sei.cmu.edu (Michele L. Kee (AdaIC)) writes:
>
>The ADAR packages were developed to provide a common approach for
>decimal arithmetic and Ada 83.  The ADAR package set consists of two
>related facilities for decimal arithmetic, one based on discriminant
>records, and the other on generics, to provide decimal computation and
>interoperable representations of decimal quantities.
>
>The ADAR packages include support for decimal data with up to 18
>digits of precision, arithmetic operations with programmer control
>over rounding versus truncation, conversions to and from common
>external representations, and formatted output of decimal values based
>on COBOL's "picture" clauses.
>
I have been working with ADAR off and on for a month or so, and find it
an extraordinarily interesting artifact for educational purposes because
there is some very good Ada in it. I believe that it is also useful in
its own right as a facility for adding IS features to Ada83. You can view it
as a preview of some of the IS facilities in Ada9X.

Ben Brosgol, Dave Emery, and Bob Eachus have done a great job of producing
this software and deserve our commendation. That said, I wish to express
some disappointment at the limited number of compilers for which ADAR
has been tested. The Meridian family is the most common family of compilers
in education, and ADAR dos not (yet) work under Meridian; preliminary
tests indicate that at least some compilation-order problems will need to
be resolved. 

To operate under Ada/Ed, ADAR will need a good bit more work; there are
(I think) some capacity problems as well as the Ada/Ed requirement (which
used to be common in Ada compilers) that a generic body appear in the
same file as the associated generic spec.

Perhaps we at GW will find the time to re-work ADAR for these two
important education-oriented Ada systems; perhaps someone in net-land
will. Whatever, I commend ADAR to you as a neat bunch of stuff.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"The most important thing is to be sincere, 
and once you've learned how to fake that, you've got it made." 
-- old show-business adage
------------------------------------------------------------------------

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

[Rolf EBERT]

In article <1993Mar21.231233.2934@seas.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes:
|> In article <1993Mar19.161646.26563@sei.cmu.edu> adainfo@ajpo.sei.cmu.edu (Michele L. Kee (AdaIC)) writes:
|> >
|> >The ADAR packages were developed to provide a common approach for
|> >decimal arithmetic and Ada 83.  The ADAR package set consists of two
|> >related facilities for decimal arithmetic, one based on discriminant
|> >records, and the other on generics, to provide decimal computation and
|> >interoperable representations of decimal quantities.
|> >
|> >The ADAR packages include support for decimal data with up to 18
|> >digits of precision, arithmetic operations with programmer control
|> >over rounding versus truncation, conversions to and from common
|> >external representations, and formatted output of decimal values based
|> >on COBOL's "picture" clauses.
|> >
|> I have been working with ADAR off and on for a month or so, and find it
|> an extraordinarily interesting artifact for educational purposes because
|> there is some very good Ada in it. I believe that it is also useful in
|> its own right as a facility for adding IS features to Ada83. You can view it
|> as a preview of some of the IS facilities in Ada9X.
|> 
|> Ben Brosgol, Dave Emery, and Bob Eachus have done a great job of producing
|> this software and deserve our commendation. That said, I wish to express
|> some disappointment at the limited number of compilers for which ADAR
|> has been tested. The Meridian family is the most common family of compilers
|> in education, and ADAR dos not (yet) work under Meridian; preliminary
|> tests indicate that at least some compilation-order problems will need to
|> be resolved. 
|> 
|> To operate under Ada/Ed, ADAR will need a good bit more work; there are
|> (I think) some capacity problems as well as the Ada/Ed requirement (which
|> used to be common in Ada compilers) that a generic body appear in the
|> same file as the associated generic spec.
|> 
|> Perhaps we at GW will find the time to re-work ADAR for these two
|> important education-oriented Ada systems; perhaps someone in net-land
|> will. Whatever, I commend ADAR to you as a neat bunch of stuff.
|> 
|> Mike Feldman
|> ------------------------------------------------------------------------
|> Michael B. Feldman
|> co-chair, SIGAda Education Committee
|> 
|> Professor, Dept. of Electrical Engineering and Computer Science
|> School of Engineering and Applied Science
|> The George Washington University
|> Washington, DC 20052 USA
|> (202) 994-5253 (voice)
|> (202) 994-5296 (fax)
|> mfeldman@seas.gwu.edu (Internet)
|> 
|> "The most important thing is to be sincere, 
|> and once you've learned how to fake that, you've got it made." 
|> -- old show-business adage
|> ------------------------------------------------------------------------

I tried the package with the Alsys compiler (V5.5.1) on a SPARC station and had
no difficulties to compile it. The only problem was a shortcoming of the Alsys
compiler that defines no Long_Integer. Context-fiffs are applied at the end.


diff -c3 -r ADAR/examples/generic/exercise/decpck.ada ADAR.new/examples/generic/exercise/decpck.ada
*** ADAR/examples/generic/exercise/decpck.ada	Mon Mar 15 20:03:23 1993
--- ADAR.new/examples/generic/exercise/decpck.ada	Sat Mar 20 15:04:39 1993
***************
*** 1,2 ****
  with ADAR_Generic_Decimal;
! package Decimal_Pckg is new ADAR_Generic_Decimal (Long_Integer, Long_Float);
--- 1,2 ----
  with ADAR_Generic_Decimal;
! package Decimal_Pckg is new ADAR_Generic_Decimal (Integer, Long_Float);
diff -c3 -r ADAR/examples/generic/exercise/example1.ada ADAR.new/examples/generic/exercise/example1.ada
*** ADAR/examples/generic/exercise/example1.ada	Mon Mar 15 20:03:43 1993
--- ADAR.new/examples/generic/exercise/example1.ada	Sat Mar 20 15:43:55 1993
***************
*** 20,26 ****
     subtype Fraction is Fraction_Type.Decimal;
     use Fraction_Type;
  
!    subtype Years is Long_Integer;
  
     Input_File, Output_File : Text_IO.File_Type;
  
--- 20,26 ----
     subtype Fraction is Fraction_Type.Decimal;
     use Fraction_Type;
  
!    subtype Years is Integer;
  
     Input_File, Output_File : Text_IO.File_Type;
  
***************
*** 38,44 ****
         (Fraction, Fraction_Type.Default_Format);
  
     function "**" (L : Fraction;
!                   R : Long_Integer) return Fraction is
        use Fraction_Log;
     begin
        return Exp (R * Log (L));
--- 38,44 ----
         (Fraction, Fraction_Type.Default_Format);
  
     function "**" (L : Fraction;
!                   R : Integer) return Fraction is
        use Fraction_Log;
     begin
        return Exp (R * Log (L));
***************
*** 84,90 ****
        use Text_IO;
     begin
        Put (File, '$');
!       Long_Int_IO.Put (File, Long_Integer (Dollars_Type.Float (P)), 4);
        Long_Int_IO.Put (File, T, 9); -- six spaces plus two digits.
        Fraction_IO.Put (File, Item => R * 100);
        -- The multiplication by 100 is to convert to a percentage.
--- 84,90 ----
        use Text_IO;
     begin
        Put (File, '$');
!       Long_Int_IO.Put (File, Integer (Dollars_Type.Float (P)), 4);
        Long_Int_IO.Put (File, T, 9); -- six spaces plus two digits.
        Fraction_IO.Put (File, Item => R * 100);
        -- The multiplication by 100 is to convert to a percentage.
diff -c3 -r ADAR/examples/generic/exercise/example2.ada ADAR.new/examples/generic/exercise/example2.ada
*** ADAR/examples/generic/exercise/example2.ada	Mon Mar 15 20:04:10 1993
--- ADAR.new/examples/generic/exercise/example2.ada	Sat Mar 20 15:06:57 1993
***************
*** 1,3 ****
--- 1,4 ----
+ 
  with Adar_Formats;
  with Text_IO;
  with Long_Int_IO;
***************
*** 24,30 ****
     subtype Fraction is Fraction_Type.Decimal;
     use Fraction_Type;
  
!    subtype Shares is Long_Integer;
  
     package Price_Type is new Decimal_Pckg.Short_Decimal
         (Decimal_Places => 2,
--- 25,31 ----
     subtype Fraction is Fraction_Type.Decimal;
     use Fraction_Type;
  
!    subtype Shares is Integer;
  
     package Price_Type is new Decimal_Pckg.Short_Decimal
         (Decimal_Places => 2,
diff -c3 -r ADAR/examples/generic/exercise/example3.ada ADAR.new/examples/generic/exercise/example3.ada
*** ADAR/examples/generic/exercise/example3.ada	Mon Mar 15 20:04:32 1993
--- ADAR.new/examples/generic/exercise/example3.ada	Mon Mar 22 09:51:36 1993
***************
*** 68,74 ****
     begin
   --             0--------1---------2---------3---------4---------5---------6---
   --             123456789012345678901234567890123456789012345678901234567890123
!       Put ("     WEST GERMAN AUTOMOBILE IMPORT COSTS (U.S.$1 = DM ");
        Fraction_IO.Put (Deutschmarks_Per_Dollar, Conversion_Format);
        Put_Line (")");
        New_Line;
--- 68,74 ----
     begin
   --             0--------1---------2---------3---------4---------5---------6---
   --             123456789012345678901234567890123456789012345678901234567890123
!       Put ("       GERMAN AUTOMOBILE IMPORT COSTS (U.S.$1 = DM ");
        Fraction_IO.Put (Deutschmarks_Per_Dollar, Conversion_Format);
        Put_Line (")");
        New_Line;
diff -c3 -r ADAR/examples/generic/exercise/lint_io.ada ADAR.new/examples/generic/exercise/lint_io.ada
*** ADAR/examples/generic/exercise/lint_io.ada	Mon Mar 15 20:04:36 1993
--- ADAR.new/examples/generic/exercise/lint_io.ada	Sat Mar 20 15:05:17 1993
***************
*** 1,2 ****
  with Text_IO;
! package Long_Int_IO is new Text_IO.Integer_IO(Long_Integer);
--- 1,2 ----
  with Text_IO;
! package Long_Int_IO is new Text_IO.Integer_IO(Integer);
diff -c3 -r ADAR/intrface/except.ada ADAR.new/intrface/except.ada
*** ADAR/intrface/except.ada	Mon Mar 15 18:15:08 1993
--- ADAR.new/intrface/except.ada	Sat Mar 20 15:50:40 1993
***************
*** 20,22 ****
--- 20,25 ----
     --  of an unchecked conversion by the programmer
  
  end ADAR_Exceptions;
+ 
+ package body ADAR_Exceptions is
+ end ADAR_Exceptions;


Rolf

-----------------------------------------------------------------------------
Rolf Ebert     Groupe Informatique et Systemes Energetiques     GISE EMP-ENPC
Tel: +33 1 43044098 app 3475 FAX: +33 1 43046364            La Courtine Cedex
Internet: ebert@enpc.fr                                F-93167 Noisy le Grand
-----------------------------------------------------------------------------

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

[Keith Thompson @pulsar]

In article <1993Mar22.095301.806@enpc.fr> re@hades.NoSubdomain.NoDomain (Rolf EBERT) writes:
> I tried the package with the Alsys compiler (V5.5.1) on a SPARC station
> and had no difficulties to compile it. The only problem was a
> shortcoming of the Alsys compiler that defines no Long_Integer.
> Context-fiffs are applied at the end.

Ahem.  Actually, it's a shortcoming of the package that it depends
on Long_Integer.  The language definition allows but does not require
Long_Integer and/or Short_Integer to be defined in Standard, and does
not define their sizes or ranges.  Portable software should not use
these types directly; instead, it should define its own integer types
with whatever ranges are appropriate.  For that matter, portable software
should be very careful about using type Integer; it's guaranteed to exist,
but its range will vary from one host/target/implementation to another.

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;
-- 
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!"

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

[Robert I. Eachus]

    Summary:

    The ADAR packages are a portable langauge extension in an area
where Ada just isn't very portable.  We came up with a LOT of magic to
make this code possible, since when we started it was expected that
any Ada 83 decimal extension would require support by compiler
vendors.  The ADAR packages as produced have portable, but in some
cases slow, bodies which can be customized to a particular compiler to
get a very efficent facility.  But don't expect to do such
customization without knowing the compiler internals and the hardware
arithmetic model a lot better than you would like to.


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.

    We went to a lot of work to push Ada to the edges of the Reference
Manual definition in the ADAR packages.  Unfortunately you can only
carry portability so far.  In general, the (package) specifications
are perfectly portable.  However, it is simply not possible to write,
for example, an efficient portable double precision multiply that will
work on 24-bit and 32-bit hardware.  Plan to change a couple of
constants.  (And don't flame me about the fact that you need static
values in some places that can't be calculated from static attributes.
Where they can, we did, but for example, find the largest power of ten
smaller than Integer'LAST in static Ada...)  We tried to produce
software which could be easily ported without modifying compilers.
But to expect the kind of magic which has to go on in the bodies of
these packages to port with zero effort, give me a BREAK.

    As a "simple" example, one of the implementations uses floating
point to provide a type with exact fixed-point semantics.  It works,
it's neat, but the number of digits for which you get exact decimal
arithmetic will be a complex function of the hardware floating point
model.  (It's usually 15 or 16.)  The code as written will get the
bounds right on most hardware I know of, but it does take some
attention to make sure.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

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

[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!"

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

[Robert I. Eachus]

In article <1993Mar25.012215.26844@telesoft.com> kst@telesoft.com (Keith Thompson @pulsar) writes:

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

  Better IMHO is to have Long_Integer in STANDARD as the longest
supported Integer type, even if it is the same length as Integer.  I
"overreacted" in this case because the examples mentioned have
Long_Integer with a comment to use the longest integer type
available... the intent was that anyone getting an error message could
figure it out, but if we put in Integer, it would compile with no
warnings then fail at run-time.  (And it is a case where, as I said,
you do want to use Integer if possible.)

  (A brownie point to anyone who recognizes "JCN 9000").

-- I'm afraid I can't do that, Dave...

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

-- Nice try, but not necessarily static!  An expression which raises
-- an exception is not-static.  It is legal for a compiler not to
-- raise an exception when evaluating B20, but it is also legitimate
-- to raise one.  So, if it works on your compiler, a tip o' the hat,
-- but it is not really portable.  (And boy is it ugly! :-)  By the
-- way, I gave a presentation at a SIGAda conference on a different
-- case of implementation dependant static expressions which caused a
-- program to be illegal.


					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

But it is possible....

[Robert I. Eachus]

    I realized just as I sent the preceding message that it is
possible to modifiy Keith's code to make it portably static.  Just
replace Integer'LAST with Integer'POS(Integer'LAST).  This makes both
arguments to ">" of type universal_integer instead of STANDARD.Integer.
(About six AI references omitted to avoid terminal language-lawyeritis.)

    Unfortunately, that makes the code even more ugly.  Maybe if you
write it as a single (big!) expression:

   Largest_Power_Of_Ten: constant := 10 ** (
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 1) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 2) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 3) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 4) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 5) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 6) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 7) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 8) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 9) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 10) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 11) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 12) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 13) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 14) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 15) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 16) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 17) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 18) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 19) +
      Boolean'POS(Integer'POS(Integer'LAST) > 10 ** 20));

    At least this way it doesn't pollute the name space. But I still
don't think I'll put it in the next version of ADAR.


					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...