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, LOTS_OF_MONEY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,22b2c05a8088bbb2 X-Google-Attributes: gid103376,public X-Google-Thread: 101deb,495b037244521cf3 X-Google-Attributes: gid101deb,public From: rav@goanna.cs.rmit.edu.au (robin) Subject: Re: Leading zeros with Int_IO.Put()? Or another package? Date: 1996/11/23 Message-ID: <575p0v$mkn$1@goanna.cs.rmit.edu.au>#1/1 X-Deja-AN: 198222592 expires: 20 February 1997 00:00:00 GMT references: <327FB8A3.745B@itg-sepg.logicon.com> <55ubsh$lh0$1@goanna.cs.rmit.edu.au> <56bi13$3pa$1@goanna.cs.rmit.edu.au> <328A0DDD.94B@lmtas.lmco.com> <56rgou$r4k$1@goanna.cs.rmit.edu.au> <56tjrh$4ak$1@goanna.cs.rmit.edu.au> <56trsm$f5a$1@goanna.cs.rmit.edu.au> <56u4vf$r65$1@goanna.cs.rmit.edu.au> <57381t$at8$1@goanna.cs.rmit.edu.au> <573mrl$3v2$1@goanna.cs.rmit.edu.au> organization: Comp Sci, RMIT, Melbourne, Australia newsgroups: comp.lang.ada,comp.lang.pl1 nntp-posting-user: rav Date: 1996-11-23T00:00:00+00:00 List-Id: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes: >rav@goanna.cs.rmit.edu.au (robin) writes: >> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes: >> >rav@goanna.cs.rmit.edu.au (robin) writes: >> >>Now why would you bury a picture specification in a remote place from >> >>the output statement that uses it? >> >In order to be close to the *variable declarations* it will be used with. >>That's back to front, isn't it! A layout isn't >>used with variable declarations, it's used with I/O >>operations. So it's logical that that's where it should >be. >Nope. A layout is used to write *DATA*. It's not "where is it going" >that determines what picture should be used, but "what am I writing". >COBOL got this right: the picture is a property of the variable and >is declared with it. Oh? And what happens when you want to write the value in one place with a particular layout (e.g. dollars and cents) and in another place (e.g. with just dollars)? And you really have got this wrong. The output layout is a property of the layout and how the user wants to display it. How the value's stored may be completely different. By way of another example, a variable may need to be declared with full precision available, so as to handle intermediate calculations without danger of overflowing. The final result may be relatively small. Yet to print intermediate results and final results? (Well, nearly right. But at least it's _better_.) >The point is that if I do > DECLARE D DECIMAL(6,2); /* +/- $9,999.99 */ >and 4000 lines later have > PUT (D) EDIT(P'$9999.99'); >then some day I am going to _change_ the declaration of D to > DECLARE D DECIMAL(8,2); > /* Money; limit has been raised to +/- $999.999.99 */ >but the picture is _not_ changed. >Better by far to have > DECLARE D DECIMAL(6,2); /* money */ > DECLARE D_PICTURE PICTURE ...whatever */ >so that when the declaration of D is revised, the declaration of >D_PICTURE gets revised to match. Sure does. But then the layout's stuffed, and then where are you? Why, you have to all the places where that variable is used in output statements anyway, and fix the layout. Of course, if this is the way you want to work, that's fine, because you can do it in PL/I. And -- as you already know -- you can also do PUT EDIT (d) (P'$9999.V99'); (note the corrections -- you multiplied the result by 100, and the EDIT is in the wrong place, and you might want to include a CR or DB to deal with negative values). And you can also declare D to be a picture variable, and then you don't have to worry about a format (but you still have to worry about the layout and so on). Having the picture format in the output statement gives you the greatest flexibility. >>I said "simpler" because that's exactly what it is. >>It's clear and simple. >I always thought the APL I wrote was clear and simple too. >_I_ knew what it meant. Unfortunately, the APL system I was using >was not an IBM one, and didn't conform _exactly_ to the ISO APL >standard, and so the code didn't port very well because some of the >boundary conditions were just _slightly_ different, and some of the >things I'd used had no equivalent at all. Completely irrelevant. >In the same way, the PL/I thing is "clear and simple" > - IF you already know PL/I pictures Don't need to. You can get a pretty good idea of what a picture does without knowing much about pictures; it's so easy, it's even in BASIC. >(I found knowing COBOL pictures > was the reverse of a help with PL/I pictures, because the details > were different), > - IF you were letter perfect about the boundary conditions and what > picture editing does in unusual case, and > - IF the code is never maintained. >In the same way, the formats in BASIC look really cute, but when you >try to port or revise your program, watch out! Again, not relevant. >Richard A. O'Keefe