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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7e021fc0e7fc15a1 X-Google-Attributes: gid103376,public From: Richard D Riehle Subject: Re: Ada 95 LRM Error? Date: 1999/01/28 Message-ID: <78qsvv$pim@dfw-ixnews10.ix.netcom.com>#1/1 X-Deja-AN: 438124864 References: <36AF6C22.896FC5B8@easystreet.com> <78oaj9$d9g@sjx-ixn5.ix.netcom.com> <36AFC42A.57696F4D@easystreet.com> Organization: Netcom X-NETCOM-Date: Thu Jan 28 5:48:15 PM CST 1999 Newsgroups: comp.lang.ada Date: 1999-01-28T17:48:15-06:00 List-Id: In article <36AFC42A.57696F4D@easystreet.com>, Al Christians wrote: >Richard D Riehle wrote about Interfaces.Cobol: >> >> As it is, the package is defined so it conforms to the conventions of >> typical COBOL programming. >> > >But if I put non-numeric data into a Numeric, it will flunk the >Valid() test, right? > >Since you speak of 'typical COBOL programming', can you enlighten me a >little about why this interface looks the way it does? > "Well, now, then, there ..." COBOL is not a strongly-typed language. There are, of course, data types in the form of PICTURE characters, but a COBOL programmer has great latitude in performing operations that mix alphanumeric numbers and ordinary alphanumeric characters. 05 Some-Number PICTURE S99V99 USAGE DISPLAY. 05 Some-String PICTURE 9(6). We may freely MOVE (actually MOVE means "copy") the numeric data to the string data without regard to the typing. On the other hand, we will get a compile time error if we try to do arithmetic on the string. The rules for this kind of thing in COBOL are actually rather complex; what is truncated, what is left justified or right justified, all kinds of interesting permutations. If the data type corresponds to COBOL, USAGE DISPLAY, the example shown in the example will work. This does not mean it is good style. It isn't good Ada style, but this package is intended to assist in the interface between Ada and COBOL so a certain amount of flexibility is necessary. As for the function, Interfaces.Cobol.Decimal_Conversions.Valid, invocation depends on the decimal type used for instantiation as well as the actual implementation of type Display_Format. One reason why this is unusual is COBOL's flexibility in where the sign is located in USAGE DISPLAY format. It could be a trailing or leading sign. The people who worked on this package had their work cut out for them. They seem to have done it well, given the huge differences between the COBOL language and Ada. On the positive side, COBOL was designed quite well in the time it was conceived. Consider that it has been one of the most successful programming languages ever used. It would be wonderful if Ada could be even a tenth as successful as COBOL. Richard Riehle richard@adaworks.com http://www.adaworks.com