From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,74fbf0c5ce05c298 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1993-03-24 18:57:33 PST Newsgroups: comp.lang.ada Path: sparky!uunet!telesoft!kst From: kst@telesoft.com (Keith Thompson @pulsar) Subject: Re: Ada Decimal Arithmetic & Representations (ADAR) V1.0 available Message-ID: <1993Mar25.012215.26844@telesoft.com> Organization: Alsys Group, San Diego, CA, USA References: <1993Mar22.095301.806@enpc.fr> <1993Mar22.223336.23771@telesoft.com> Date: Thu, 25 Mar 1993 01:22:15 GMT Date: 1993-03-25T01:22:15+00:00 List-Id: In article 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!"