Leading zeros with Int_IO.Put()? Or another package?

Leading zeros with Int_IO.Put()? Or another package?

[J.D. Baldwin]

A "how-to" question from an Ada dabbler:

I just got a copy of GNAT and 'make'-ed the examples.  The first one
I ran, cal.exe, gave me the following date and time:

                11/5/1996 10:4:3

. . . when what one *wants* of course is:

                11/05/1996 11:04:03

(Leading zero optional--but, by me, preferred--for the date; omitting
it is of course inexcusable for the minutes and seconds fields in the
time.)

In C, building a formatted string takes care of such silliness.
(Spare me a list of C's other, more-than-offsetting, shortcomings,
please.)  I seem to recall from the mists of the distant past that
Pascal provided a means of accomplishing this, too.

I searched the c.l.a archives at DejaNews, I web-searched for Int_IO,
I scanned the FAQ and I read the appropriate sections of RM95 (A.10.8
and adjacent). I found nothing about leading zeros except as pertains
to exponent portions of floating point numbers.  (Actually, I found
one snippet of example code that implemented the same kludge I did.)

So I added relevant lines of code to CAL.ADB:

                  if (MINUTE <= 9) then
                     Int_IO.Put(0, 0);
                  end if;
                  Int_IO.Put(MINUTE,0);

. . . and so forth, for each relevant value.

My question:  is there a better way to pad out integers with leading
zeros?  What if I wanted to pad to a width of three or four or sixteen,
all with zeros?  Is there a standard way to achieve this in Ada?
--
 From the catapult of J.D. Baldwin  |+| "If anyone disagrees with anything I
   _,_    Finger baldwin@netcom.com |+| say, I am quite prepared not only to
 _|70|___:::)=}-  for PGP public    |+| retract it, but also to deny under
 \      /         key information.  |+| oath that I ever said it." --T. Lehrer
***~~~~-----------------------------------------------------------------------

Re: Leading zeros with Int_IO.Put()? Or another package?

[Samuel Tardieu]

I've never tried it myself, but the Interfaces.Cobol package may be of
some help.

  Sam
-- 
  Samuel Tardieu -- sam@ada.eu.org

Re: Leading zeros with Int_IO.Put()? Or another package?

[David Shochat]

J.D. Baldwin wrote:
> 
[snip]
> My question:  is there a better way to pad out integers with leading
> zeros?  

Whenever I need leading zeros (in any radix), I use what we call here
the "Everage Maneuver" (named after fellow Logiconer Amy Everage, who
came up with this years ago). Lets say we want to put the nonnegative
integer n to a field of k characters with radix r using leading zeros if
necessary. So we assert n < r**k.
1. Convert n + r**k to a string. This uses k+1 characters, the 1st of
which is '1', representing r**k.
2. Use all but the 1st character from the result of (1).

If it makes anyone feel better, it looks like Java (API) doesn't know
how to do leading zeros either (but the Everage Maneuver works fine for
Java too). 
-- David

Re: Leading zeros with Int_IO.Put()? Or another package?

[robin]

	David Shochat <shochat@itg-sepg.logicon.com> writes:

	>J.D. Baldwin wrote:

	>> My question:  is there a better way to pad out integers with leading
	>> zeros?  

	>Whenever I need leading zeros (in any radix), I use what we call here
	>the "Everage Maneuver" (named after fellow Logiconer Amy Everage, who
	>came up with this years ago). Lets say we want to put the nonnegative
	>integer n to a field of k characters with radix r using leading zeros if
	>necessary. So we assert n < r**k.
	>1. Convert n + r**k to a string. This uses k+1 characters, the 1st of
	>which is '1', representing r**k.
	>2. Use all but the 1st character from the result of (1).

Interface to PL/I and you can use standard I/O:

put edit (n) (P'-99999999');

and you don't have to worry about whether the number is
negative either.  The nines in the picture format
force leading zeros to print.

And if you want, you can insert commas in the output
to make it more readable.  The picture specification becomes:

P'-999,999,999'

Re: Leading zeros with Int_IO.Put()? Or another package?

[Ken Garlington]

robin wrote:
> 
>         David Shochat <shochat@itg-sepg.logicon.com> writes:
> 
>         >J.D. Baldwin wrote:
> 
>         >> My question:  is there a better way to pad out integers with leading
>         >> zeros?
> 
>         >Whenever I need leading zeros (in any radix), I use what we call here
>         >the "Everage Maneuver" (named after fellow Logiconer Amy Everage, who
>         >came up with this years ago). Lets say we want to put the nonnegative
>         >integer n to a field of k characters with radix r using leading zeros if
>         >necessary. So we assert n < r**k.
>         >1. Convert n + r**k to a string. This uses k+1 characters, the 1st of
>         >which is '1', representing r**k.
>         >2. Use all but the 1st character from the result of (1).
> 
> Interface to PL/I and you can use standard I/O:
> 
> put edit (n) (P'-99999999');
> 
> and you don't have to worry about whether the number is
> negative either.  The nines in the picture format
> force leading zeros to print.
> 
> And if you want, you can insert commas in the output
> to make it more readable.  The picture specification becomes:
> 
> P'-999,999,999'

Or, if you use a decimal type, you can just use Ada:

  package Pic_IO is new Ada.Text_IO.Editing.Decimal_Output(<some decimal type>);
  ...
  Pic_IO.Put (n, Pic_IO.To_Picture("-99999999")); -- or "-999,999,999", etc.

See ISO/IEC 8652:1995 F.3 (Edited Output for Decimal Types).

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Leading zeros with Int_IO.Put()? Or another package?

[Robert Dewar]

robin says

"Interface to PL/I and you can use standard I/O:

put edit (n) (P'-99999999');

and you don't have to worry about whether the number is
negative either.  The nines in the picture format
force leading zeros to print.

And if you want, you can insert commas in the output
to make it more readable.  The picture specification becomes:

P'-999,999,999'"



I guess robin knows PL/1 and does not know Ada!

If you want to use picture editing to solve this kind of problem, then
use the picture editing in Ada, no need to wander off into PL/1, even in
the unlikely case that you have a PL/1 compiler at hand. Personally I 
dislike the picture stuff in PL/1, they tried to improve on COBOL and
made a mess of it.

Re: Leading zeros with Int_IO.Put()? Or another package?

[Verne Arase]

In article <dewar.847457421@merv>,
dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

 >Personally I dislike the picture stuff in PL/1, they tried to improve
 >on COBOL and made a mess of it.

How so?

---
The above are my own opinions, and not those of my employer.

Re: Leading zeros with Int_IO.Put()? Or another package?

[robin]

	dewar@merv.cs.nyu.edu (Robert Dewar) writes:

	>>robin says

	>>"Interface to PL/I and you can use standard I/O:

	>>put edit (n) (P'-99999999');

	>>and you don't have to worry about whether the number is
	>>negative either.  The nines in the picture format
	>>force leading zeros to print.

	>>And if you want, you can insert commas in the output
	>>to make it more readable.  The picture specification becomes:

	>>P'-999,999,999'"

	>If you want to use picture editing to solve this kind of problem, then
	>use the picture editing in Ada, no need to wander off into PL/1, even in
	>the unlikely case that you have a PL/1 compiler at hand. Personally I 
	>dislike the picture stuff in PL/1, they tried to improve on COBOL and
	>made a mess of it.

PL/I picture editing is a lot simpler than using Ada's,
which -- if implemented by the compiler -- applies to decimal types.

For *any* data type -- binary integer, decimal integer,
float, complex, etc, PL/I has full picture editing.

It's ony necessary to use a simple line such as:

put edit (n) (P'-99999999');

or, for the real mccoy,

put edit (d) (P'999.V999');	[d is decimal fixed with fraction,
				 or floating-point, PICTURE, etc]
				 

which is a lot less than the (up to) 82 lines of Ada code
suggested by various posters to force zeros to print.

---------------------------------------------------------------------------
-- Utility to print zero-filled strings of integer values.
---------------------------------------------------------------------------

package zero_fill is
.....[81 lines of Ada deleted]

Re: Leading zeros with Int_IO.Put()? Or another package?

[Ken Garlington]

robin wrote:
> 
> PL/I picture editing is a lot simpler than using Ada's,
> which -- if implemented by the compiler -- applies to decimal types.

Absolutely true. Ada implements strong type checking, which can make
writing Ada more complex. The advtantages of strong type checking tend
to outweigh this, however, particularly for large and/or critical systems.

From the Introduction section of ISO/IEC 8652:1995:

"The need for languages that promote reliability and simplify maintenance
is well established. Hence emphasis was placed on program readability over
ease of writing."

To read more, see:

  http://www.adahome.com/LRM/95/rm95html/rm9x-intro.html#goals

or, for even more information about Ada:

  http://info.acm.org/sigada/
  http://lglwww.epfl.ch/Ada/
  http://sw-eng.falls-church.va.us/AdaIC/

> For *any* data type -- binary integer, decimal integer,
> float, complex, etc, PL/I has full picture editing.
> 
> It's ony necessary to use a simple line such as:
> 
> put edit (n) (P'-99999999');
> 
> or, for the real mccoy,
> 
> put edit (d) (P'999.V999');     [d is decimal fixed with fraction,
>                                  or floating-point, PICTURE, etc]
> 
> 
> which is a lot less than the (up to) 82 lines of Ada code
> suggested by various posters to force zeros to print.

Of course, once you have the zero-fill package (or whatever
other abstraction you intend to reuse), the number of lines
you have to write drops quite a bit. With a well-designed
abstraction, you can also have your compiler detect when you
accidently did a put of one of those "etc."s when you meant to
put an Apple_Type (or whatever). I assume PL/I has an equivalent
capability?

"Furthermore, error-prone notations have been avoided, and the
syntax of the language avoids the use of encoded forms in favor
of more English-like constructs."

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Leading zeros with Int_IO.Put()? Or another package?

[robin]

Ken Garlington <garlingtonke@lmtas.lmco.com> writes:

	>robin wrote:
	>> 
	>> PL/I picture editing is a lot simpler than using Ada's,
	>> which -- if implemented by the compiler -- applies to decimal types.

	>Absolutely true. Ada implements strong type checking, which can make
	>writing Ada more complex. The advtantages of strong type checking tend
	>to outweigh this, however, particularly for large and/or critical systems.

	>From the Introduction section of ISO/IEC 8652:1995:

	>"The need for languages that promote reliability and simplify maintenance
	>is well established. Hence emphasis was placed on program readability over
	>ease of writing."

Ada clearly failed in this aspect.

	>> For *any* data type -- binary integer, decimal integer,
	>> float, complex, etc, PL/I has full picture editing.
	>> 
	>> It's ony necessary to use a simple line such as:
	>> 
	>> put edit (n) (P'-99999999');
	>> 
	>> or, for the real mccoy,
	>> 
	>> put edit (d) (P'999.V999');     [d is decimal fixed with fraction,
	>>                                  or floating-point, PICTURE, etc]
	>> 
	>> which is a lot less than the (up to) 82 lines of Ada code
	>> suggested by various posters to force zeros to print.

	>Of course, once you have the zero-fill package (or whatever
	>other abstraction you intend to reuse), the number of lines
	>you have to write drops quite a bit.

No excuse for having everyone who wants to use such a facility
to have to write it.

It is, after all, avalable ina number of languages including COBOL
and PL/I.

The simplicity and usefulness of PL/I in producing
zero suppression/insertion of characters/general editing/
in a variety of forms (integer, fixed-point, floating-point) and suitable
for business and science cannot be refuted.

As I indicated earlier, just one short line will suffice! :

put edit (d) (P'999.V999');

Re: Leading zeros with Int_IO.Put()? Or another package?

[Robert Dewar]

robin said

"No excuse for having everyone who wants to use such a facility
to have to write it."

Ah, yes, the design principle that PL1 made famous, or rather infamous.
If something is useful, pop it in, after all, you don't have to use it
if you don't want to. 

Part of the trouble with this philosophy, which is characteristic of
committee designed languages (unlike Ada, PL/1 was very much a committee
designed language, trying to meet the requirements of many dissimilar
constituencies), is that it is quite difficult to get implementations
to handle simple cases efficiently. PL/1 was, compared to IBM's expectations,
a dismal failure, and in particular, the very public abandonment of PL/1
by early adopters, notably Sears, was not so much a reaction to the language,
which is, as I have noted before, not as bad as people think, but rather
a reaction to the implementation quality.

Now it is true that part of the implementation problems were due to what
is now generally perceived as fundamental mistakes in the PL/1 design
(e.g. far too many implicit conversions permitted), but they were much
more due to simple size and complexity. Of course over time, the compilers
did improve, but too late to avoid the initial bad publicity.

Acceptance of languages is always based as much on initial implementations
as it is on the language itself. Algol-68 was quite successful in the
few environments in which decent compilers were available (notably the
Algol68-R compiler on ICL machines in the UK), but in most environments,
no decent compilers were available.

Certainly you can see a parallel in the Ada world, there is no question
that the acceptance of ada 83 was influenced by the quality and
availability of compilers early on, and even today you see people making
unfounded statements about Ada the *language*, based on their early
experience with Ada *compilers*.

Re: Leading zeros with Int_IO.Put()? Or another package?

[Richard A. O'Keefe]

rav@goanna.cs.rmit.edu.au (robin) writes:

>Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
>	>From the Introduction section of ISO/IEC 8652:1995:

>	>"The need for languages that promote reliability and simplify maintenance
>	>is well established. Hence emphasis was placed on program readability over
>	>ease of writing."

>Ada clearly failed in this aspect.

This is not clear at all.
I have used a great many programming languages,
and find Ada to be _dramatically_ more readable (in terms of
how well I can read other people's code) than most of them.
It beats C and C++ by a country mile,
and I find that it beats PL/I as well.
One of the reasons is that conversions are explicit.

>No excuse for having everyone who wants to use such a facility
>to have to write it.

*BUT THEY DON'T*.

It is a common rhetorical device of yours, rav, to take a
true statement "someone must write X", and use the _false_
statement "everyone must write X" as a stick to beat Ada with.

>It is, after all, avalable ina number of languages including COBOL
>and PL/I.

We are specifically talking about converting numbers to text.
If you want a list of languages with such features,
add Burroughs Extended Algol, and Algol 68.
Also add Ada 95.

Have you looked at Annex F in the Ada 95 LRM?
It's on-line here, and quite a few staff members have printed copies.
Have you _tried_ the Annex F stuff?
We have GNAT, and the current GNAT documentation says all
the annexes are supported.
I _have_ tried picture editing in GNAT; it works fine, and it
is no harder and no easier to write Ada pictures than COBOL
or PL/I pictures.

>The simplicity and usefulness of PL/I in producing
>zero suppression/insertion of characters/general editing/
>in a variety of forms (integer, fixed-point, floating-point) and suitable
>for business and science cannot be refuted.

Can I refute the usefulness of PL/I for this?
I cannot, and would not want to.
Can I refute the simplicity of PL/I for this?
Well, it depends on what you you mean.
As noted above, I don't find it any harder to write
Ada pictures than PL/I pictures, and I welcome the
level of detail in the ADA 95 LRM.
I've used pictures in Burroughs Algol, COBOL, and PL/I, and
the devil is in the details.
Concerning the actual _use_ of pictures, if you use named
pictures in PL/I, there is very little to chose.  If you
_don't_ use named pictures (by which I mean ones declared
in a PL/I DECLARE statement or an Ada object declaration)
then using "magic strings" is just as bad as using "magic
numbers".

>As I indicated earlier, just one short line will suffice! :

>put edit (d) (P'999.V999');

I note that Ada 95 pictures offer some features missing from COBOL-85
and that they're pretty useful.

I note that Ada 95 makes it pretty easy to read a picture from a file,
or compute on on the fly by some other method.  (In particular, from
the attributes of "d" in an example like this.)

I willingly concede that it is a nuisance that Ada 95 pictures apply to
decimal fixed point numbers, not integers or floating point numbers.
(In particular, Ada 95 pictures have no "exponent picture" support.)
I also willingly concede that waiting until run time to check pictures
whose strings are known at compile time is not what I would have chosen.

In the case of writing out integers with pictures,
I don't greatly mind having

	type Decimal_Integer is delta 1.0 digits 9;
	package Decimal_Integer_Editing is new
	   Ada.Text_IO.Editing.Decimal_Output(Decimal_Integer);
	use Decimal_Integer_Editing;

ONCE somewhere in a program (probably written by someone else) and
then doing

	Put(Decimal_Integer(X), To_Picture("-999_999_999"));

or whatever.  

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Leading zeros with Int_IO.Put()? Or another package?

[robin]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

	>rav@goanna.cs.rmit.edu.au (robin) writes:

	>>Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
	>>	>From the Introduction section of ISO/IEC 8652:1995:

	>>	>"The need for languages that promote reliability and simplify maintenance
	>>	>is well established. Hence emphasis was placed on program readability over
	>>	>ease of writing."

	>>Ada clearly failed in this aspect.

	>This is not clear at all.

---It is abundantly clear that it failed as to ease of writing.
Various postings suggested that the conversion could be done in up to
82 lines of Ada code, whereas PL/I requires one simple line.

	>I have used a great many programming languages,

Haven't we all!

	>and find Ada to be _dramatically_ more readable (in terms of
	>how well I can read other people's code) than most of them.
	>It beats C and C++ by a country mile,

On this we agree.

	>and I find that it beats PL/I as well.

On this we don't.

	>One of the reasons is that conversions are explicit.

	>>No excuse for having everyone who wants to use such a facility
	>>to have to write it.

	>*BUT THEY DON'T*.

But they do, and there were various postings all giving different
ways to accomplish it in Ada.

	>It is a common rhetorical device of yours, rav, to take a
	>true statement "someone must write X", and use the _false_
	>statement "everyone must write X" as a stick to beat Ada with.

	>>It is, after all, avalable in a number of languages including COBOL
	>>and PL/I.

	>We are specifically talking about converting numbers to text.
	>If you want a list of languages with such features,
	>add Burroughs Extended Algol, and Algol 68.

Those (COBOL and PL/I) were only examples.  Even BASIC has it.

	>Also add Ada 95.

Only if it's implemented.

	>We have GNAT, and the current GNAT documentation says all
	>the annexes are supported.
	>I _have_ tried picture editing in GNAT; it works fine, and it
	>is no harder and no easier to write Ada pictures than COBOL
	>or PL/I pictures.

Only where Ada supports a CoBOL or PL/I equivalent, as you
admit below.

	>>The simplicity and usefulness of PL/I in producing
	>>zero suppression/insertion of characters/general editing/
	>>in a variety of forms (integer, fixed-point, floating-point) and suitable
	>>for business and science cannot be refuted.

	>Can I refute the usefulness of PL/I for this?
	>I cannot, and would not want to.
	>Can I refute the simplicity of PL/I for this?
	>Well, it depends on what you you mean.
	>As noted above, I don't find it any harder to write
	>Ada pictures than PL/I pictures, and I welcome the
	>level of detail in the ADA 95 LRM.
	>I've used pictures in Burroughs Algol, COBOL, and PL/I, and
	>the devil is in the details.
	>Concerning the actual _use_ of pictures, if you use named
	>pictures in PL/I, there is very little to chose.

There is considerable difference -- in favor of PL/I -- between the
two.  After all, you have demonstrated it!

	>If you
	>_don't_ use named pictures (by which I mean ones declared
	>in a PL/I DECLARE statement or an Ada object declaration)
	>then using "magic strings" is just as bad as using "magic
	>numbers".

???????
Now why would you bury a picture specification in a remote place from 
the output statement that uses it?

	>>As I indicated earlier, just one short line will suffice! :

	>>put edit (d) (P'999.V999');

	>I note that Ada 95 pictures offer some features missing from COBOL-85
	>and that they're pretty useful.

	>I note that Ada 95 makes it pretty easy to read a picture from a file,
	>or compute on on the fly by some other method.

A facility that's available in IBM's PL/I for OS/2, Windows 95/NT and
AIX.

	>In particular, from
	>the attributes of "d" in an example like this.)

	>I willingly concede that it is a nuisance that Ada 95 pictures apply to
	>decimal fixed point numbers, not integers or floating point numbers.
	>(In particular, Ada 95 pictures have no "exponent picture" support.)
	>I also willingly concede that waiting until run time to check pictures
	>whose strings are known at compile time is not what I would have chosen.

	>In the case of writing out integers with pictures,
	>I don't greatly mind having

	>	type Decimal_Integer is delta 1.0 digits 9;
	>	package Decimal_Integer_Editing is new
	>	   Ada.Text_IO.Editing.Decimal_Output(Decimal_Integer);
	>	use Decimal_Integer_Editing;

	>ONCE somewhere in a program (probably written by someone else) and
	>then doing
	>	Put(Decimal_Integer(X), To_Picture("-999_999_999"));
	>or whatever.  

Thank you for proving the point!  PL/I's

   put edit (d) (P'-999,999,999');

is a lot simpler. What's more, you don't have to hunting for
Decimal_Integer to find out what it does.

P.S. Check out PL/I's drifting user-specifiable currency symbols etc
for picture editing.  Great fun!

	>Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Leading zeros with Int_IO.Put()? Or another package?

[Larry J. Elmore]

robin <rav@goanna.cs.rmit.edu.au> wrote in article
<56trsm$f5a$1@goanna.cs.rmit.edu.au>...
> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
>>>From the Introduction section of ISO/IEC 8652:1995: 
>>>"The need for languages that promote reliability and simplify
maintenance
>>>is well established. Hence emphasis was placed on program readability
over
>>>ease of writing."
>>> 
>>>Ada clearly failed in this aspect.
>>> 
>>This is not clear at all.
>> 
> ---It is abundantly clear that it failed as to ease of writing.

Wait a minute, Robin. First you quote ISO/IEC 8652:1995 where it justifies
the decision to favor program readability (to promote reliability and
maintainability) over ease of writing and then state that Ada clearly
failed in this respect. Then you immediately turn around and state that Ada
failed in ease of writing. As you had just pointed out, it was never
designed with ease of writing as a major priority (nor should it have been,
since all major software is read many, many more times than it is written,
mostly by programmers other than the original designer). My point being
that it *did not* fail in that respect as you mistakenly claim. It exactly
met its design goals! 

> Various postings suggested that the conversion could be done in up to
> 82 lines of Ada code, whereas PL/I requires one simple line.

"Up to 82 lines of Ada"? Really, Robin... I've no doubt I could replicate
some aspect of Ada 95 that PL/1 lacks in "up to" any number of lines of
PL/1 I care to bloat it up to...


-- 
Larry J. Elmore

"A man's worth is no greater than the worth of his ambitions."
-- Marcus Aurelius Antoninus, "Meditations," c. 170 A.D.

"The universe is change; our lives what our thoughts make of it."
-- Ibid.

Re: Leading zeros with Int_IO.Put()? Or another package?

[robin]

	"Larry J. Elmore" <ljelmore@montana.campus.mci.net> writes:

	>robin <rav@goanna.cs.rmit.edu.au> wrote in article
	><56trsm$f5a$1@goanna.cs.rmit.edu.au>...
	>> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
	>>>>From the Introduction section of ISO/IEC 8652:1995: 
	>>>>"The need for languages that promote reliability and simplify maintenance
	>>>>is well established. Hence emphasis was placed on program readability over
	>>>>ease of writing."
	>>>>Ada clearly failed in this aspect.
	>>>This is not clear at all.
	>> ---It is abundantly clear that it failed as to ease of writing.
	>Wait a minute, Robin. First you quote ISO/IEC 8652:1995

Larry, if you look back at the earlier posts, you'll find
that Ken Garlington quoted this, not me.

	>where it justifies
	>the decision to favor program readability (to promote reliability and
	>maintainability) over ease of writing and then state that Ada clearly
	>failed in this respect. Then you immediately turn around and state that Ada
	>failed in ease of writing.

That too.  If it's not easy to write, it's not going
to be easy to maintain either.

	>As you had just pointed out, it was never
	>designed with ease of writing as a major priority (nor should it have been,
	>since all major software is read many, many more times than it is written,
	>mostly by programmers other than the original designer). My point being
	>that it *did not* fail in that respect as you mistakenly claim. It exactly
	>met its design goals! 

	>> Various postings suggested that the conversion could be done in up to
	>> 82 lines of Ada code, whereas PL/I requires one simple line.

	>"Up to 82 lines of Ada"? Really, Robin... I've no doubt I could replicate
	>some aspect of Ada 95 that PL/1 lacks in "up to" any number of lines of
	>PL/1 I care to bloat it up to...

You've missed the point.  Those suggestions were from Ada
afficionados.  We assume that they are not going to "bloat
it up" to favor PL/I.  The posters were quite serious.

	>Larry J. Elmore

Re: Leading zeros with Int_IO.Put()? Or another package?

[Robert Dewar]

robin said

"That too.  If it's not easy to write, it's not going
to be easy to maintain either."

Surprising that anyone could actually believe this, it just goes to
show that even the most obvious and elementary principles of language
design are not universally understood.

It is of course NOT the case AT ALL that ease of writing and ease
of maintenance are the same thing, or even related. The most elementary
example relates to comments, extensive comments don't make writing easier,
but they certainly help maintenance, and when it comes to the language
itself, various elements of redundancy can help maintenance considerably,
at the clear expense of ease of writing.

Re: Leading zeros with Int_IO.Put()? Or another package?

[Larry J. Elmore]

robin <rav@goanna.cs.rmit.edu.au> wrote in article
<57bj2t$c6m$1@goanna.cs.rmit.edu.au>...
> 	"Larry J. Elmore" <ljelmore@montana.campus.mci.net> writes:
> 
> 	>robin <rav@goanna.cs.rmit.edu.au> wrote in article
> 	><56trsm$f5a$1@goanna.cs.rmit.edu.au>...
> 	>> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
> 	>>>>From the Introduction section of ISO/IEC 8652:1995: 
> 	>>>>"The need for languages that promote reliability and simplify
maintenance
> 	>>>>is well established. Hence emphasis was placed on program
readability over
> 	>>>>ease of writing."
> 	>>>>Ada clearly failed in this aspect.
> 	>>>This is not clear at all.
> 	>> ---It is abundantly clear that it failed as to ease of writing.
> 	>Wait a minute, Robin. First you quote ISO/IEC 8652:1995
> 
> Larry, if you look back at the earlier posts, you'll find
> that Ken Garlington quoted this, not me.

Oops... The original quote of ISO/IEC 8652:1995 ws indeed from Ken
Garlington. However, Robin, the totally spurious conclusion that "it [Ada]
failed as to ease of writing." is entirely yours. It couldn't have failed
as to ease of writing because that was subordinated to ease of reading.

> 	>where it justifies
> 	>the decision to favor program readability (to promote reliability and
> 	>maintainability) over ease of writing and then state that Ada clearly
> 	>failed in this respect. Then you immediately turn around and state that
Ada
> 	>failed in ease of writing.
> 
> That too.  If it's not easy to write, it's not going
> to be easy to maintain either.

I fail to understand how one can come to that conclusion. Ada is *far* more
maintainable than other languages that are "easier" to write, C being a
prime example. Besides, if you'd given the matter any thought, you'd have
realized that Ada is "not easy to write" in the sense that it is quite
verbose compared other languages (such as C), and it is precisely because
of that verbosity that it is eminently readable and therefore more easily
maintainable. The more you write on this subject, the more obvious it
becomes that you have little knowledge and even less experience with Ada
95.

> 	>As you had just pointed out, it was never
> 	>designed with ease of writing as a major priority (nor should it have
been,
> 	>since all major software is read many, many more times than it is
written,
> 	>mostly by programmers other than the original designer). My point being
> 	>that it *did not* fail in that respect as you mistakenly claim. It
exactly
> 	>met its design goals! 
> 
> 	>> Various postings suggested that the conversion could be done in up to
> 	>> 82 lines of Ada code, whereas PL/I requires one simple line.
> 
> 	>"Up to 82 lines of Ada"? Really, Robin... I've no doubt I could
replicate
> 	>some aspect of Ada 95 that PL/1 lacks in "up to" any number of lines of
> 	>PL/1 I care to bloat it up to...
> 
> You've missed the point.  Those suggestions were from Ada
> afficionados.  We assume that they are not going to "bloat
> it up" to favor PL/I.  The posters were quite serious.

I didn't miss the point. *You're* the one who quoted "up to 82 lines of Ada
code." That certainly reads as though you picked the worst example
presented, *not* the best one. The English language may sometimes be obtuse
and ambiguous, but your usage of it in this instance is quite clear. The
Ada posters didn't intentionally bloat their code if they were serious in
defending Ada, but you should know as well as anyone else in the field that
their are good examples of how to do something and hideous examples. Did
you cite the best possible example or the worst, Robin?


-- 
Larry J. Elmore

"A man's worth is no greater than the worth of his ambitions."
-- Marcus Aurelius Antoninus, "Meditations," c. 170 A.D.

"The universe is change; our lives what our thoughts make of it."
-- Ibid.

Re: Leading zeros with Int_IO.Put()? Or another package?

[Richard A. O'Keefe]

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.

"Magic numbers" do not appear in well written code.
"Magic strings" do not appear in well written code.
"Magic pictures" do not appear in well written code.


>	>I note that Ada 95 makes it pretty easy to read a picture from a file,
>	>or compute on on the fly by some other method.

>A facility that's available in IBM's PL/I for OS/2, Windows 95/NT and
>AIX.

To borrow the stick you beat Ada with,
"in short, where it's implemented".

>	>ONCE somewhere in a program (probably written by someone else) and
>	>then doing
>	>	Put(Decimal_Integer(X), To_Picture("-999_999_999"));
>	>or whatever.  

>Thank you for proving the point!  PL/I's

>   put edit (d) (P'-999,999,999');

>is a lot simpler.

NONONONO!  It's *SHORTER*, is all.
"Shorter" and "simpler" are very different things.

>What's more, you don't have to hunting for
>Decimal_Integer to find out what it does.

Well, you don't have to go *hunting* for Decimal_Integer in Ada,
either, because the name truthfully _says_ what it is, and any
decent Ada system (like GNAT) will give you the tools you need
to say "where's _that_ defined?".

>P.S. Check out PL/I's drifting user-specifiable currency symbols etc
>for picture editing.  Great fun!

Ada pictures also provide user-specifiable currency symbols,
and they can float.  Have _you_ checked out the on-line free
Ada 96 manual here?  (Is there a free complete current PL/I
reference manual you can be put on-line without paying royalties?)

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Leading zeros with Int_IO.Put()? Or another package?

[robin]

	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.

	>>Thank you for proving the point!  PL/I's

	>>   put edit (d) (P'-999,999,999');

	>>is a lot simpler.

	>NONONONO!  It's *SHORTER*, is all.
	>"Shorter" and "simpler" are very different things.

I said "simpler" because that's exactly what it is.
It's clear and simple.

	>Richard A. O'Keefe

Re: Leading zeros with Int_IO.Put()? Or another package?

[Richard A. O'Keefe]

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

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

In the same way, the PL/I thing is "clear and simple"
 - IF you already know PL/I pictures (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!

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Leading zeros with Int_IO.Put()? Or another package?

[robin]

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

Re: Leading zeros with Int_IO.Put()? Or another package?

[Robert Dewar]

robin says

"        >and I find that it beats PL/I as well.

On this we don't."


well of course Robin thinks PL/1 is more readable than Ada 95. It's
like asking a Russian who barely speaks English whether he finds
Russian easier to read than English. Robin has made it very clear
that he is not very familiar with Ada 95. It always puzzles me
when people spend so much time fulminating about programming languages
that they know very little about, but it's typical of the programming
language field.

So you can't pay too much attention to robin's opinions on Ada 95, and
equally it is probably the case that a lot of people contributing to
this thread do not know PL/1 very well either.

What is most missing from Robin's understanding of Ada 95 is the
concept of abstraction. This is pretty much missing of course in PL/1,
a rather old language, derived from Fortran, Algol and COBOL, so what
do you expect?

But it does mean that he does not appreciate that if an abstraction is
useful it would be written once, and what is important is the
readability, and usability of the interface specification, not
whether there are 10 lines in the body or 1000.

Let's go back to the original question, which was the issue of how
to print an integer with leading zeroes suppressed. The answer in
Ada 95 is that you use the Image_ZP function:

    function Image_ZP (X : Integer) return String;

Well that's easy enough, Ah ha! says Robin, but look at the body of that
function, its xxx lines long and voila! I can do this in one line in
PL/1. Maybe true, but the answer is so what? Robin is like the APL 
programmer who thinks it is wonderful that sorting is built into APL
as a primitive.

Ultimately the issue of how reusable interfaces are constructed is
FAR more important than what particular collectoin of primitives
have been built into the language. Note for example that the picture
editing in PL/1 is actually *built in* to the language, seems pretty
horrible to me. In Ada 95, the picture editing is simply an add-on
abstraction. Yes, it happens to be one of the predefined add-on
abstractions, but that's a relatively minor point.

Richard says that he concedes that it is too bad that the picture
editing does not work for integers, but only for decimal. I can't
see that as significant, it is trivial to extend the abstraction
to cover the integer case if this is useful.

Re: Leading zeros with Int_IO.Put()? Or another package?

[Richard A. O'Keefe]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Richard says that he concedes that it is too bad that the picture
>editing does not work for integers, but only for decimal. I can't
>see that as significant, it is trivial to extend the abstraction
>to cover the integer case if this is useful.

Did I say it was significant?  Did I say it was non-trivial?
Surely the point of my con version to Decimal_Integer was to *show*
that it is a trivial extension, and anyone even halfway familiar with
Ada would see how that idea could be used to build an appropriate
abstraction.

Let me state clearly:
    I do not see
	Put(Decimal_Integer(<<E>>), To_Picture("<<P>>"));
    as _significantly_ harder than
	PUT EDIT(<<E>>) (P'<<P>>');
    or whatever the PL/I code was.

    I regard the "magic string" in the first and the "magic picture" in
    the second as equally poor, and would prefer to use named pictures
    in either language.

    I am willing to concede that you then end up with an explicit conversion
    in the Ada version that is not needed in the PL/I version, but I note
    that roughly the same number of *tokens* is needed in the two languages,
    so even then a "PL/I is simpler" claim is harder to sustain.

-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Leading zeros with Int_IO.Put()? Or another package?

[shmuel]

In <dewar.848496377@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>well of course Robin thinks PL/1 is more readable than Ada 95. It's
>like asking a Russian who barely speaks English whether he finds
>Russian easier to read than English. Robin has made it very clear
>that he is not very familiar with Ada 95. It always puzzles me
>when people spend so much time fulminating about programming languages
>that they know very little about, but it's typical of the programming
>language field.

That sword cuts both ways; if you think that Ada 95 is perfect and that PL/I has
nothing to offer, I suspect that you either don't know Ada very well or don't know 
PL/I very well. In fact, I am suspicious of the qualifications of anyone who can't find
flaws in his preferred languages or who can't find good points in at least one 
language that he despises.

I find it interesting that you defended the charge that Ada lacks expressive power
by saying that you could always build an abstraction to encapsulate a subroutine,
instead of citing some of the areas where Ada has more expressive power than PL/I.
You accuse Mr. Dewar of being ignorant, but you have laid yourself open to the same
charge. If you tell me that your failure to mention certain features doesn't mean that
you are unaware of them, well, the same could be true for Mr. Dewar's failure to
mention things that he may not have considered relevant.




     Shmuel (Seymour J.) Metz
     Systems Programmer & JOAT
     Atid/2

Any unsolicited commercial junk E-mail will will be subject to
legal action.

I added an * to my E-mail address to foil automated spammers;
remove it to contact me.

Re: Leading zeros with Int_IO.Put()? Or another package?

[Jerry Coffin]

In article <56trsm$f5a$1@goanna.cs.rmit.edu.au>, 
rav@goanna.cs.rmit.edu.au says...

[ rav said ] 
> 	>>Ada clearly failed in this aspect.
> 

[ Richard O'keefe repiled ] 
> 	>This is not clear at all.

[ and rav replied to that: ]
> ---It is abundantly clear that it failed as to ease of writing.
> Various postings suggested that the conversion could be done in up
> to 82 lines of Ada code, whereas PL/I requires one simple line.

Given almost any two programming languages, it's trivial to find a 
construct that's far more difficult to create in one than the other.  
The fact that this particular construct happens to be built into PL/I 
but no Ada proves absolutely _nothing_ about the two languages 
overall.

If we take a single example as indicative of a language in general, 
it's trivial to show that, for instance, C is far more readable than 
BASIC.

Likewise, if you simply take program length as an indication of 
complexity, it's fairly trivial to show that PL/I is generally 
superior to Ada.  However, it's equally trivial to show that APL is 
_dramatically_ superior to either.  Having had to maintain some APL at 
one time, I have to question a premise that leads to that particular 
conclusion.  If you'd like, attempt to translate one simple line of 
APL: `b <- /+ a' (where <- is really a single character) into PL/I, 
and retain full generality.  Here I'm not even trying to pick 
something terribly difficult either - just some _really_ simple APL.

Oh, in case you don't know APL, that sums the members of an array 
named a, and puts the result into a variable named b.  a can be of any 
size and number of dimensions.

-- 
    Later,
    Jerry.

Re: Leading zeros with Int_IO.Put()? Or another package?

[Ken Garlington]

robin wrote:
> 
>>>Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
>>>      >From the Introduction section of ISO/IEC 8652:1995:
> 
>>>      >"The need for languages that promote reliability and simplify maintenance
>>>      >is well established. Hence emphasis was placed on program readability over
>>>      >ease of writing."
> 
> ---It is abundantly clear that it failed as to ease of writing.

Ah! I see the problem now. You are misreading the above statement. Ease of READING
is the design goal, not ease of WRITING.

> Various postings suggested that the conversion could be done in up to
> 82 lines of Ada code, whereas PL/I requires one simple line.

As you probably know, this argument is easily refuted by someone writing a (bad) PL/I
program that does the same function in 82 lines.

The correct comparison, if you want to talk about ease of writing (and why would you,
if you're a software engineer?) is the _smallest_ Ada implementation vs. the _smallest_ 
PL/I implementation, which is two Ada lines (or three shorter lines) vs. one PL/I line.

By your criteria, of course, APL is a much better language than either Ada or PL/I.

>         >>No excuse for having everyone who wants to use such a facility
>         >>to have to write it.
> 
>         >*BUT THEY DON'T*.
> 
> But they do, and there were various postings all giving different
> ways to accomplish it in Ada.

Whereas there was only one poster giving only one PL/I solution. Using the rhetoric
of this thread, the greater flexibility of Ada over PL/I "cannot be refuted." (Troll
language if there ever was any... :)

> Now why would you bury a picture specification in a remote place from
> the output statement that uses it?

Going back to my business COBOL days, one possibility would be to specify a standard
picture for:

   all currency values
   all tank quantity measurements
   etc.

even though values of these types might be reported in different columns, etc. This
would allow consistency between different output statements for the same type value.

>         >I note that Ada 95 makes it pretty easy to read a picture from a file,
>         >or compute on on the fly by some other method.
> 
> A facility that's available in IBM's PL/I for OS/2, Windows 95/NT and
> AIX.

Does this mean that this feature is not available in other implementation of PL/I?
I thought this was standard in all implementations of PL/I.

> Thank you for proving the point!  PL/I's
> 
>    put edit (d) (P'-999,999,999');
> 
> is a lot simpler.

Not as simple as RPG, though. Now _there_ was a language that emphasized
ease of writing!

> P.S. Check out PL/I's drifting user-specifiable currency symbols etc
> for picture editing.  Great fun!

Perhaps you could compare PL/I's version with Ada's and give us your
opinion. See paragraph 15 of

   http://www.adahome.com/rm95/rm9x-F-03.html

and paragraph 11 of

   http://www.adahome.com/rm95/rm9x-F-03-03.html

to understand how Ada does it.

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Leading zeros with Int_IO.Put()? Or another package?

[Robert Dewar]

Richard says

"I also willingly concede that waiting until run time to check pictures
whose strings are known at compile time is not what I would have chosen.""

No need to concede, willingly or otherwise, points that are plain false!

There is nothing that stops a compiler from checking pictures at compile
time and issuing warnings, and compiling the picture, if the picture
string is static. 

GNAT doesn't do that yet (it's a convenience feature, and an optimization,
not a requirement), but it's on the list of things to do. Whether and
when it gets done depends on how much use the picture editing gets.

The way you would do this is to make the picture editing routines
compiler intrinsics, which is, as I say, on the list of possible
enhancements.

Re: Leading zeros with Int_IO.Put()? Or another package?

[Norman H. Cohen]

Apparently the software for the Russian Mars 96 probe wasn't written in
PL/I either.

:-)

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Leading zeros with Int_IO.Put()? Or another package?

[Ken Garlington]

robin wrote:
> Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
> 
>         >"The need for languages that promote reliability and simplify maintenance
>         >is well established. Hence emphasis was placed on program readability over
>         >ease of writing."
> 
> Ada clearly failed in this aspect.

Hmmm. So you consider the syntax

  put edit (n) (P'-99999999');

more readable than the Ada equivalent

  use Ada.Text_IO.Editing;
  ...
  package Edited_IO is new Decimal_Output (type);
  ...
  Edited_IO.Put (n, To_Picture ("-99999999"));

Interesting. They look reasonably similar to me. If anything,
the Ada version makes it clear from the text that this
I/O is using the Picture feature of the language. However,
if you believe "P" is more readable in this regard, I
suppose we'll have to agree to disagree...

>         >Of course, once you have the zero-fill package (or whatever
>         >other abstraction you intend to reuse), the number of lines
>         >you have to write drops quite a bit.
> 
> No excuse for having everyone who wants to use such a facility
> to have to write it.

1. Why does everyone have to rewrite publicly-available code? I usually
just reuse it. (Perhaps this is an Ada-unique mindset.)

2. The equivalent of your code is directly available in Ada, if
desired (see above).

> It is, after all, avalable ina number of languages including COBOL
> and PL/I.
> 
> The simplicity and usefulness of PL/I in producing
> zero suppression/insertion of characters/general editing/
> in a variety of forms (integer, fixed-point, floating-point) and suitable
> for business and science cannot be refuted.
> 
> As I indicated earlier, just one short line will suffice! :
> 
> put edit (d) (P'999.V999');

What I don't understand is, given the statement above, how I can
restrict the use of the statement above so that "d" is always a
numeric value in the range 0.000 .. 999.999. Implicit strong
typing is available in a number of languages, including Ada, so
there's no excuse for having everyone who wants to use such a
facility to have to write it explicitly. Perhaps you could post
the PL/I solution so that I could compare it to the Ada version.

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Leading zeros with Int_IO.Put()? Or another package?

[Verne Arase]

In article <3295F2A9.1EF0@lmtas.lmco.com>,
Ken Garlington <garlingtonke@lmtas.lmco.com> wrote:

 >  use Ada.Text_IO.Editing;
 >  ...
 >  package Edited_IO is new Decimal_Output (type);
 >  ...
 >  Edited_IO.Put (n, To_Picture ("-99999999"));
 >
 >Interesting. They look reasonably similar to me. If anything,
 >the Ada version makes it clear from the text that this
 >I/O is using the Picture feature of the language. However,
 >if you believe "P" is more readable in this regard, I
 >suppose we'll have to agree to disagree...

Well, we are talking about a langugage primative rather than a subroutine
library.

Or are you saying that PayRoll is also built into the language (and
implemented in a single statement)?

---
The above are my own opinions, and not those of my employer.

Re: Leading zeros with Int_IO.Put()? Or another package?

[Ken Garlington]

Verne Arase wrote:
> 
> In article <3295F2A9.1EF0@lmtas.lmco.com>,
> Ken Garlington <garlingtonke@lmtas.lmco.com> wrote:
> 
>  >  use Ada.Text_IO.Editing;
>  >  ...
>  >  package Edited_IO is new Decimal_Output (type);
>  >  ...
>  >  Edited_IO.Put (n, To_Picture ("-99999999"));
>  >
>  >Interesting. They look reasonably similar to me. If anything,
>  >the Ada version makes it clear from the text that this
>  >I/O is using the Picture feature of the language. However,
>  >if you believe "P" is more readable in this regard, I
>  >suppose we'll have to agree to disagree...
> 
> Well, we are talking about a langugage primative rather than a subroutine
> library.

I'm not sure what a "language primitive" is, but any Ada compiler that implements
the Information Systems annex of the Ada standard (ISO/IEC 8652:1995) will support
the three lines written above (which can also be re-written as two slightly longer
lines, if desired). Specifically, the generic package
Ada.Text_IO.Editing.Decimal_Output is supplied by the compiler, just as the body of
SQRT would be provided (via a subroutine library, in many cases) by most FORTRAN
compilers.

The only definitions supplied by the user in this case, other than the lines
shown above, are "n" and "type", which refer to the value to be formatted and
its type, respectively.

Assuming that a generic package supplied by the compiler does not meet your
definition of a "language primitive," what's the relevance of this to the lines
you quoted? Is there a language design philosophy for PL/I that says "language 
primitives" should be very terse? Is this in the standard somewhere?

> Or are you saying that PayRoll is also built into the language (and
> implemented in a single statement)?

Since I don't know to what "PayRoll" you are referring, I certainly would
not claim it is part of the Ada language (or any other language :). I would
say something is "built into" the language if it is defined by the language
specification. For Ada.Text_IO.Editing.Decimal_Output, this is the case. See

  http://www.adahome.com/rm95/rm9x-F-03.html

"Edited Output for Decimal Types," in the on-line version of the Ada standard.

(By the way, is there an equivalent on-line version of the ISO PL/I standard?)

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Leading zeros with Int_IO.Put()? Or another package?

[Bert]

 If you'd like, attempt to translate one simple line of 
>APL: `b <- /+ a' (where <- is really a single character) into PL/I, 
>and retain full generality.

PLI:

	b = sum(a);


Point made.

Dave Bertollo

Re: Leading zeros with Int_IO.Put()? Or another package?

[robin]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

	>robin says

	>>"Interface to PL/I and you can use standard I/O:

	>>put edit (n) (P'-99999999');

	>>and you don't have to worry about whether the number is
	>>negative either.  The nines in the picture format
	>>force leading zeros to print.

	>>And if you want, you can insert commas in the output
	>>to make it more readable.  The picture specification becomes:

	>>P'-999,999,999'"

	>I guess robin knows PL/1 and does not know Ada!

	>If you want to use picture editing to solve this kind of problem, then
	>use the picture editing in Ada, no need to wander off into PL/1, even in
	>the unlikely case that you have a PL/1 compiler at hand. Personally I 
	>dislike the picture stuff in PL/1, they tried to improve on COBOL and
	>made a mess of it.

Isn't it amazing!  Robert Dewar [among others] already has
had an opportunity to reply in this vein to the original
posting and subsequent ones, but it didn't occur to him to
do so, more than likely because he didn't know that a limited
facility existed in Ada.  Instead, he suggested using
string facilities.

Below is Robert Dewar's previous posting:

>This is a place where CLEARLY there is a missing abstraction (Put with
>leading zeros), and it seems obvious that you fix this in the way that
>you always do abstraction extension, you create an appropriate abstraction
>and use it. If it is useful enough, hopefully it gets to be widely available.

>Note that if you do want to construct on the fly, a much clearer way is to
>use the string routines from the string packages, which have padding
>capabilities.

PL/I is not restricted to picture editing with decimal data,
(one poster suggested changing to Ada decimal data in order to use
Ada's limited editing).   PL/I requires *only* the single line:

put edit (n) (P'-99999999');

and not the (up to) page of Ada code to implement the
requirement of the original post.

Re: Leading zeros with Int_IO.Put()? Or another package?

[Ken Garlington]

robin wrote:
> 
> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> 
>         >robin says
> 
>         >>"Interface to PL/I and you can use standard I/O:
> 
>         >>put edit (n) (P'-99999999');
> 
>         >>and you don't have to worry about whether the number is
>         >>negative either.  The nines in the picture format
>         >>force leading zeros to print.
> 
>         >>And if you want, you can insert commas in the output
>         >>to make it more readable.  The picture specification becomes:
> 
>         >>P'-999,999,999'"
> 
>         >I guess robin knows PL/1 and does not know Ada!
> 
>         >If you want to use picture editing to solve this kind of problem, then
>         >use the picture editing in Ada, no need to wander off into PL/1, even in
>         >the unlikely case that you have a PL/1 compiler at hand. Personally I
>         >dislike the picture stuff in PL/1, they tried to improve on COBOL and
>         >made a mess of it.
> 
> Isn't it amazing!  Robert Dewar [among others] already has
> had an opportunity to reply in this vein to the original
> posting and subsequent ones, but it didn't occur to him to
> do so, more than likely because he didn't know that a limited
> facility existed in Ada.  Instead, he suggested using
> string facilities.

Actually, if you know Ada, it's not amazing at all. The Ada picture I/O is for
decimal types; the original request was for integer types. If you don't want to
convert your type, the suggestion by Dr. Dewar is more straight-forward. If you
do want to use picture I/O, you probably still want to use an abstraction of
this facility to hide the details of type conversion, instantiation of picture I/O,
etc.

Ada people have this perversity of suggesting the most straight-forward and
maintainable approach first. :)

> 
> Below is Robert Dewar's previous posting:
> 
> >This is a place where CLEARLY there is a missing abstraction (Put with
> >leading zeros), and it seems obvious that you fix this in the way that
> >you always do abstraction extension, you create an appropriate abstraction
> >and use it. If it is useful enough, hopefully it gets to be widely available.
> 
> >Note that if you do want to construct on the fly, a much clearer way is to
> >use the string routines from the string packages, which have padding
> >capabilities.
> 
> PL/I is not restricted to picture editing with decimal data,
> (one poster suggested changing to Ada decimal data in order to use
> Ada's limited editing).   PL/I requires *only* the single line:
> 
> put edit (n) (P'-99999999');
> 
> and not the (up to) page of Ada code to implement the
> requirement of the original post.

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Leading zeros with Int_IO.Put()? Or another package?

[robin]

Ken Garlington <garlingtonke@lmtas.lmco.com> writes:

	>robin wrote:
	>> 
	>> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
	>> 
	>>         >robin says
	>> 
	>>         >>"Interface to PL/I and you can use standard I/O:
	>> 
	>>         >>put edit (n) (P'-99999999');
	>> 
	>>         >>and you don't have to worry about whether the number is
	>>         >>negative either.  The nines in the picture format
	>>         >>force leading zeros to print.
	>> 
	>>         >>And if you want, you can insert commas in the output
	>>         >>to make it more readable.  The picture specification becomes:
	>> 
	>>         >I guess robin knows PL/1 and does not know Ada!
	>> 
	>>         >If you want to use picture editing to solve this kind of problem, then
	>>         >use the picture editing in Ada, no need to wander off into PL/1, even in
	>>         >the unlikely case that you have a PL/1 compiler at hand. Personally I
	>>         >dislike the picture stuff in PL/1, they tried to improve on COBOL and
	>>         >made a mess of it.
	>> 
	>> Isn't it amazing!  Robert Dewar [among others] already has
	>> had an opportunity to reply in this vein to the original
	>> posting and subsequent ones, but it didn't occur to him to
	>> do so, more than likely because he didn't know that a limited
	>> facility existed in Ada.  Instead, he suggested using
	>> string facilities.

	>Actually, if you know Ada, it's not amazing at all. The Ada picture I/O is for
	>decimal types; the original request was for integer types. If you don't want to
	>convert your type,

Really!  The task is to convert to string type.  You're saying
that that's not a type conversion.

	 the suggestion by Dr. Dewar is more straight-forward. If you
	>do want to use picture I/O, you probably still want to use an abstraction of
	>this facility to hide the details of type conversion, instantiation of picture I/O,
	>etc.

	>Ada people have this perversity of suggesting the most straight-forward and
	>maintainable approach first. :)

	>> 
	>> Below is Robert Dewar's previous posting:
	>> 
	>> >This is a place where CLEARLY there is a missing abstraction (Put with
	>> >leading zeros), and it seems obvious that you fix this in the way that
	>> >you always do abstraction extension, you create an appropriate abstraction
	>> >and use it. If it is useful enough, hopefully it gets to be widely available.
	>> 
	>> >Note that if you do want to construct on the fly, a much clearer way is to
	>> >use the string routines from the string packages, which have padding
	>> >capabilities.
	>> 
	>> PL/I is not restricted to picture editing with decimal data,
	>> (one poster suggested changing to Ada decimal data in order to use
	>> Ada's limited editing).   PL/I requires *only* the single line:
	>> 
	>> put edit (n) (P'-99999999');
	>> 
	>> and not the (up to) page of Ada code to implement the
	>> requirement of the original post.

Re: Leading zeros with Int_IO.Put()? Or another package?

[Ken Garlington]

robin wrote:
> 
> Really!  The task is to convert to string type.  You're saying
> that that's not a type conversion.

  I thought the request was to generate formatted output via Int_IO.Put. I don't
  usually consider that a type _conversion_, but I suppose you could call it that.

  In any case, starting with an integer type, there would be an _additional_ type
  conversion (if you prefer) if you wanted to use the picture mechanism:

       integer -> decimal -> string   vs.  integer -> string

  The extra conversion isn't necessarily a bad thing; it's just that there's some
  housekeeping involved (making sure the range of the decimal type is compatible
  with the integer type) that you might not want to fuss with. Of course, if
  you want to go to a string, there may be other housekeeping (determining the
  string length) that's involved.

  Getting back to the topic, there's several good ways (and some poor ways) of
  using Ada to get the desired effect. Good software practices indicate that the
  specific mechanism chosen should be properly hidden behind an appropriate
  abstraction, so that the mechanism can be changed as needed.

  (The preceding paragraph appears to read equally well if "PL/I" is substituted
  for "Ada".)

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com

Re: Leading zeros with Int_IO.Put()? Or another package?

[Robert Dewar]

robin says

"Really!  The task is to convert to string type.  You're saying
that that's not a type conversion."


Yes, well of course a PL/1 programmer would regard the routine that
takes an integer as input and generates some corresponding string
to be a "type conversion", but most other languages would not, and
indeed this kind of over-extensive notion of type conversion is one
of the clearly recognized errors in the PL/1 design, but clearly
recognized here, I mean recognized in the programming language
design community -- I don't think anyone would repeat that mistake.

Of course PL/1 programmers won't agree, but then any language has its
ardent advocates who think it is 100% right, so the existence of such
ardent advocates does not prove anything about a language :-)

Re: Leading zeros with Int_IO.Put()? Or another package?

[Robert Dewar]

Robin says

"Isn't it amazing!  Robert Dewar [among others] already has
had an opportunity to reply in this vein to the original
posting and subsequent ones, but it didn't occur to him to
do so, more than likely because he didn't know that a limited
facility existed in Ada."

Well nice to wake up to another entertaining post from Robin! I guess we
can't blame him too much, he clearly knows neither Ada nor the people
involved with it :-)

I do of course know quite well the Ada picture facility - I helped
design it, and in particular, probably as much as anyone I was responsible
for the decision to mirror COBOL very closely (as Robin may not know,
I am pretty familiar with COBOL, having written a big chunk of one of
the two COBOL compilers in wide spread use on PC's today -- namely the
Computer Associates Realia compiler).

What Robin is probably not aware of is that the picture facilities are
in the Information Systems annex, which means that they are not available
in all implementations, in particular, at the moment only GNAT implements
these facilities. So the solution using string operations is more portable.

As for PL/1 here, although generally I don't think it's nearly as terrible
a language as its reputation, I do think it got things wrong in the picture
area, and did not improve on COBOL. No, RObin, I don't care to elaborate, 
because I don't think enough people are interested enough in PL/1 to make
it worth the time.

Picture processing is something that COBOL got right. I see no reason
to do things much differently from COBOL in this area. 

By the way, I guess Robin should get a new printer, one with pages that
hold more than a few lines, since of course in practice the solution
with pictures is quite concise in Ada.

P.S. regarding the informatoin systems annex, it is not the case that you
can take GNAT libraries and use them with other Ada 95 compilers. The
reason has nothing to do with licenses, but rather is technical. The
library units from annex F supplied with GNAT assume very extensive
support from the compiler itself (18 digit decimal with proper decimal
fixed point semantics and handling of the intrinsic divide for example),
and at the moment only GNAT provides the necessary compiler support. I
mention this because several times now we have received questions from
people asking us if they could get annex F stuff working by (e.g.)
combining the TSP compiler and the GNAT library routines, and the answer
is unfortunately no so far!

Re: Leading zeros with Int_IO.Put()? Or another package?

[Robert I. Eachus]

   rav@goanna.cs.rmit.edu.au (robin) writes:

   >Thank you for proving the point!  PL/I's

   >   put edit (d) (P'-999,999,999');

   >is a lot simpler.

In article <56u4vf$r65$1@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

  > NONONONO!  It's *SHORTER*, is all.
  > "Shorter" and "simpler" are very different things.

   Not even that.  It is shorter once in PL/I but embarrassingly
longer when you have lots of puts to do.  In Ada I typically declare a
Put routine for any numeric type, and then just write Put(D); (If D
was a meaningful variable name. ;-)   There are occasions where you
want to use more than one format with a particular type, but this
almost always occurs in totalling situations.  I prefer even for that
case to use two renamings, one as Put one as Put_Total, etc.

--

					Robert I. Eachus

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

Re: Leading zeros with Int_IO.Put()? Or another package?

[robin]

	eachus@spectre.mitre.org (Robert I. Eachus) writes:

	>   rav@goanna.cs.rmit.edu.au (robin) writes:

	>   >Thank you for proving the point!  PL/I's

	>   >   put edit (d) (P'-999,999,999');

	>   >is a lot simpler.

	>In article <56u4vf$r65$1@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

	>  > NONONONO!  It's *SHORTER*, is all.
	>  > "Shorter" and "simpler" are very different things.

	>   Not even that.  It is shorter once in PL/I but embarrassingly
	>longer when you have lots of puts to do.

Rubbish!

If the same PL/I picture specification [ and for that matter
*any* format specification -- not only pictures ]
has to be re-used, it can be written once.  That facility has
been available in PL/I since 1966.  New (addiional) ways of
doing the same thing are available in IBM's PL/I for OS/2,
Windows 96 and Windows NT, and AIX.

 	>In Ada I typically declare a
	>Put routine for any numeric type, and then just write Put(D); (If D
	>was a meaningful variable name. ;-)   There are occasions where you
	>want to use more than one format with a particular type,

Happens more than just on "occasions".

	>but this
	>almost always occurs in totalling situations.  I prefer even for that
	>case to use two renamings, one as Put one as Put_Total, etc.

As a media personally used not to say regularly, "This I *don't*
believe".

	>					Robert I. Eachus

Re: Leading zeros with Int_IO.Put()? Or another package?

[Norman H. Cohen]

J.D. Baldwin wrote:
 

> So I added relevant lines of code to CAL.ADB:
> 
>                   if (MINUTE <= 9) then
>                      Int_IO.Put(0, 0);
>                   end if;
>                   Int_IO.Put(MINUTE,0);
> 
> . . . and so forth, for each relevant value.
> 
> My question:  is there a better way to pad out integers with leading
> zeros?  What if I wanted to pad to a width of three or four or sixteen,
> all with zeros?  Is there a standard way to achieve this in Ada?

Using the GNAT-specific 'Img attribute and the standard package
Ada.Strings.Fixed:

   Ada.Strings.Fixed.Move
      (Source  => Minute'Img,
       Target  => Buffer, 
       Justify => Right, 
       Pad     => '0');
   Ada.Text_IO.Put (Buffer);

(where Buffer is a string of the appropriate length, in this case 2). 
Using the standard 'Image attribute (which annoyingly places a space in
front of nonnegative numerals) instead of 'Img to retain portability to
other compilers:

   declare
      Image  : constant String := Minute'Image;
      Buffer : String (1 .. Field_Length);  -- 2 in the case of minutes
   begin
      Ada.Strings.Fixed.Move
         (Source  => Image (2 .. Image'Length),
          Target  => Buffer, 
          Justify => Right, 
          Pad     => '0');
      Ada.Text_IO.Put (Buffer);
   end;

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Leading zeros with Int_IO.Put()? Or another package?

[Pascal Obry]

Norman H. Cohen <ncohen@watson.ibm.com> a =E9crit dans l'article =
<3281088B.24F@watson.ibm.com>...
>=20
>    declare
>       Image  : constant String :=3D Minute'Image;
                                                 ^^^^^^^^^^^^^^^^
It should be :  Image : constant String :=3D Integer'Image (Minute);

Well I don't know the type of Minute, so I have assumed that it is an =
Integer.

>       Buffer : String (1 .. Field_Length);  -- 2 in the case of =
minutes
>    begin
>       Ada.Strings.Fixed.Move
>          (Source  =3D> Image (2 .. Image'Length),
>           Target  =3D> Buffer,=20
>           Justify =3D> Right,=20
>           Pad     =3D> '0');
>       Ada.Text_IO.Put (Buffer);
>    end;
>=20
> --=20
> Norman H. Cohen
> mailto:ncohen@watson.ibm.com
> http://www.research.ibm.com/people/n/ncohen
>=20

--=20

--|------------------------------------------------------------
--| Pascal Obry                               Team-Ada Member |
--|                                                           |
--| EDF-DER-IPN-SID- Ing=E9nierie des Syst=E8mes d'Informations   |
--|                                                           |
--| Bureau G1-010           e-mail: pascal.obry@der.edfgdf.fr |
--| 1 Av G=E9n=E9ral de Gaulle  voice : +33-1-47.65.50.91         |
--| 92141 Clamart CEDEX     fax   : +33-1-47.65.50.07         |
--| FRANCE                                                    |
--|------------------------------------------------------------
--|
--|   http://ourworld.compuserve.com/homepages/pascal_obry
--|
--|   "The best way to travel is by means of imagination"

Re: Leading zeros with Int_IO.Put()? Or another package?

[Norman H. Cohen]

Pascal Obry wrote:
> =

> Norman H. Cohen <ncohen@watson.ibm.com> a =E9crit dans l'article <32810=
88B.24F@watson.ibm.com>...
> >
> >    declare
> >       Image  : constant String :=3D Minute'Image;
>                                                  ^^^^^^^^^^^^^^^^
> It should be :  Image : constant String :=3D Integer'Image (Minute);
> =

> Well I don't know the type of Minute, so I have assumed that it is an I=
nteger.

Exactement.

-- =

Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Leading zeros with Int_IO.Put()? Or another package?

[Norman H. Cohen]

I wrote:

> Using the GNAT-specific 'Img attribute and the standard package
> Ada.Strings.Fixed:

[example presuming that X'Img = "99" when X=99 deleted]

> Using the standard 'Image attribute (which annoyingly places a space in
> front of nonnegative numerals) instead of 'Img to retain portability to
> other compilers:
> 
>    declare
        Image  : constant String := Integer'Image(Minute);  
                                       -- Pascal Obry's correction
>       Buffer : String (1 .. Field_Length);  -- 2 in the case of minutes
>    begin
>       Ada.Strings.Fixed.Move
>          (Source  => Image (2 .. Image'Length),
>           Target  => Buffer,
>           Justify => Right,
>           Pad     => '0');
>       Ada.Text_IO.Put (Buffer);
>    end;

Keith Thompson informed me in private correspondence that, like the
standard 'Image attribute, the GNAT-only 'Img attribute puts in that
annoying leading space, and upon trying it I find he's right.  That's
the risk of relying on vague recollections of descriptions of 'Img by
GNAT team members rather than testing its behavior.  (The ideal
approach, of course, is to consult the documentation, but no version of
gnatinfo.txt that I have mentions 'Img.)

Anyway, the bottom line is that you have to deal with the annoying space
anyway, so you might as well use the standard 'Image attribute.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Leading zeros with Int_IO.Put()? Or another package?

[Robert Dewar]

Norman Cohen says

"Keith Thompson informed me in private correspondence that, like the
standard 'Image attribute, the GNAT-only 'Img attribute puts in that
annoying leading space, and upon trying it I find he's right.  That's
the risk of relying on vague recollections of descriptions of 'Img by
GNAT team members rather than testing its behavior.  (The ideal
approach, of course, is to consult the documentation, but no version of
gnatinfo.txt that I have mentions 'Img.)"

Norman, you are missing a critical piece of documentation that is included
in all GNAT releases, and which has often been mentioned on CLA, namely
the features file.

This describes the language features implemented, and in particular has
full documentation on all GNAT defined attributes and pragmas (there are
quite a lot of them, you should definitely look at this file).

Here is the excerpt on 'Img

  Img 
   
    The 'Img function is defined for any prefix, P, that denotes an
    object of scalar type T. P'Img is equivalent to T'Image (P). This
    is convenient for debugging. For example:
   
       Put_Line ("X = " & X'Img);
   
    has the same meaning as the more verbose:
   
       Put_Line ("X = " & Temperature_Type'Image (X));
   
    where Temperature_Type is the subtype of the object X.

I think you will find reading this file better than relying on vague
recollections :-)

Re: Leading zeros with Int_IO.Put()? Or another package?

[Stephen Leake]

Check annex F and the package Text_IO.Editing (supported by gnat). I've
not used them, but they should solve your problem.
-- 
- Stephe

Re: Leading zeros with Int_IO.Put()? Or another package?

[Robert I. Eachus]

In article <baldwinE0Eq2n.KLB@netcom.com> baldwin@netcom.com (J.D. Baldwin) writes:

 >  I just got a copy of GNAT and 'make'-ed the examples.  The first one
 >  I ran, cal.exe, gave me the following date and time:

 >		   11/5/1996 10:4:3

 >  . . . when what one *wants* of course is:

 >		   11/05/1996 11:04:03

 >  (Leading zero optional--but, by me, preferred--for the date; omitting
 >  it is of course inexcusable for the minutes and seconds fields in the
 >  time.)...

 >  So I added relevant lines of code to CAL.ADB:

 >		     if (MINUTE <= 9) then
 >			Int_IO.Put(0, 0);
 >		     end if;
 >		     Int_IO.Put(MINUTE,0);

 >  . . . and so forth, for each relevant value.

 >  My question:  is there a better way to pad out integers with leading
 >  zeros?  What if I wanted to pad to a width of three or four or sixteen,
 >  all with zeros?  Is there a standard way to achieve this in Ada?

  Three answers.  1) Use the ADAR components which are designed
specifically to address things like this for Ada 83. 2) In Ada 95
look at Annex F.  3) Write your own Put function and use it instead of
the Text_IO.Integer_IO.Put operation.  There are several ways to do
this cleanly and still get a leading sign or blank if you want, but in
this case what you want is:

     with Int_IO;
     function Put_Leading(To: out String; Item: in Int_IO.Num) is
     begin
       Int_IO.Put(To,Item);
       for I in To'RANGE loop
         if To(I) = ' '
         then To(I) := '0';
         elsif To(I) = '-'  and I /= 1
         then To(1) := '-'; To(I) := '0';
         end if;
       end loop;
     end Put_Leading;

    This may be a little heavy for what you want.  (For your case,
negative numbers should not occur so moving the sign to the lead
position is overkill.)


--

					Robert I. Eachus

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

Re: Leading zeros with Int_IO.Put()? Or another package?

[Norman H. Cohen]

Robert I. Eachus wrote:


> ... 2) In Ada 95 look at Annex F.  

Good idea, this is certainly an appropriate application of
picture-directed output.  If your compiler supports the Information
Systems annex, you can write:

   with Ada.Text_IO.Editing; 
   use Ada.Text_IO, Ada.Text_IO.Editing;

   procedure Put_Time (Hours, Minutes, Seconds: in Integer) is
      type Time_Component_Type is
         delta 1.0 digits 2 range 0.0 .. 60.0;
      package Time_Component_Output is
         new Decimal_Output (Time_Component_Type);
      use Time_Component_Output;
      Leading_Zero  : constant Picture := To_Picture ("99");
      Leading_Space : constant Picture := To_Picture ("Z9");
   begin
      Put (Time_Component_Type(Hours), Leading_Space);
      Put (':');
      Put (Time_Component_Type(Minutes), Leading_Zero);
      Put (':');
      Put (Time_Component_Type(Seconds), Leading_Zero);
   end Put_Time;

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Leading zeros with Int_IO.Put()? Or another package?

[David Emery]

You can get edited output using the facilities of the I.S. Annex, or
by using the ADAR components (which work for Ada83, and for Ada95 compilers
that do not support the I.S. annex.).

				dave
-- 
<.sig is away on vacation>

Re: Leading zeros with Int_IO.Put()? Or another package?

[Fergus Henderson]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

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

Still, that's not going to look good if your 131-column printouts now
become 133 columns wide, forcing either wrap or truncation when you try
to print them on a standard 132-column printer.

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

"What am I writing" is important, but sometimes "where it is going"
matters too.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Leading zeros with Int_IO.Put()? Or another package?

[Robert Dewar]

Fregus refers to

"Still, that's not going to look good if your 131-column printouts now
become 133 columns wide, forcing either wrap or truncation when you try
to print them on a standard 132-column printer."


That's good for a laugh -- hands up all those programmers who interact
with "standard 132-column printers" any more. For those who do, I guess
you must still punch your programs on 80-column cards???

Yes, well I know there are mainframe environments which would not consider
this a joke :-)

Re: Leading zeros with Int_IO.Put()? Or another package?

[J. David Bryan]

On 24 Nov 1996 08:26:07 -0500 in article <dewar.848841884@merv>, 
dewar@merv.cs.nyu.edu wrote...
>
>That's good for a laugh -- hands up all those programmers who interact
>with "standard 132-column printers" any more. For those who do, I guess
>you must still punch your programs on 80-column cards???

Personally, I prefer paper tape; if you drop it, the program logic doesn't 
change!

BTW, that's also why I prefer APL over Ada.  It takes *much* less time to read 
in on my model 33 Teletype!

:-)  ;-)  :-)

-- 
                                        -- Dave Bryan
                                   dbryan@mail.bcpl.lib.md.us

Re: Leading zeros with Int_IO.Put()? Or another package?

[Larry Kilgallen]

In article <dewar.848841884@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Fregus refers to
> 
> "Still, that's not going to look good if your 131-column printouts now
> become 133 columns wide, forcing either wrap or truncation when you try
> to print them on a standard 132-column printer."
> 
> 
> That's good for a laugh -- hands up all those programmers who interact
> with "standard 132-column printers" any more. For those who do, I guess
> you must still punch your programs on 80-column cards???

While few have their source limited to emulation of 80-column cards,
even printers capable of arbitrary graphics (e.g., Postscript) are
often fed by spooling and queueing programs which emulate a certain
width (132 being one popular number).  The more expensive the printer,
the greater the likelihood that it is treated as a "production" device,
with spooling and queueing controlled by system administrators rather
than individual programmers.

Larry Kilgallen

Re: Leading zeros with Int_IO.Put()? Or another package?

[Verne Arase]

In article <dewar.848841884@merv>,
dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

 >That's good for a laugh -- hands up all those programmers who interact
 >with "standard 132-column printers" any more. For those who do, I guess
 >you must still punch your programs on 80-column cards???

Yes, we do.

We also have code still running unchanged which can be traced back to the
70s; how about you?

... and what does that say about your "reusability" ... :-)

---
The above are my own opinions, and not those of my employer.

Re: Leading zeros with Int_IO.Put()? Or another package?

[Richard A. O'Keefe]

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

>ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
[the point of putting picture declarations with data is so that they
 can be revised if the data scale/precision/&c is revised.]

>Still, that's not going to look good if your 131-column printouts now
>become 133 columns wide, forcing either wrap or truncation when you try
>to print them on a standard 132-column printer.

I haven't seen a "standard 132-column printer" in nearly 20 years.
I went to an accountant this morning to have him do our tax return.
Form filled in using a flashy Win3.1.1-for-workgroups spreadsheet of
some kind (with a bug; apparently something has been carried over
every year since 1990!) and will be printed on A4 paper.

A couple of years ago I got something from a lawyer that used
the ISO 646 minus sign (code point 2/13) instead of the decimal
point (code point 2/14); I tried to explain the problem but never
did get it across.   Standards?  Feh!

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

Of course wrap-around matters.  This is why the behaviour of the Put
procedures in Ada.Text_IO and its children is not *always* appropriate.
If a Fortran format isn't big enough for the data, you get stars instead.
If a C format isn't big enough for the data, the field expands until it
_is_ big enough, and presto chango! your record overflows.
Ada "Put" procedures are just like C in this respect.
The Ada designers were not blind to this, which is why
Ada.Text_IO.Set_Line_Length exists.  This would more adequately address
the problem of wrapping if only there were some way to ask Text_IO to
raise an exception if the record to be generated overflows, instead of
quietly wrapping.  At least the wrapping is done treating the current
output item as a single unit, so that line breaks only occur _between_
units.  Could an implementation co-opt the FORM parameter in the Open
or Create call for this purpose?

>"What am I writing" is important, but sometimes "where it is going"
>matters too.

Nobody is denying this.

However, this turns out to be an even _stronger_ argument in favour
of moving the pictures out of the PUTs and giving them names, because
then the program can check itself.

Suppose I want to write a record containing 
 - specified String variables and constants
 - data edited using named pictures.
Then I can *once* in my program, at startup, do

    if Line_Length(Current_Output)
     < S1'Length
     + ..
     + Sn'Length
     + Length(Pic1)
     + ...
     + Length(Picx)
    then
	raise Configuration_Error;
    end if;

It is much easier to get this right when the pictures have names.
-- 
Fear most of all to be in error.	-- Kierkegaard, quoting Socrates.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Collection of 2500+ links about Object-Orientation - interested ?

[Manfred Schneider]

Hello,

are you interested in a collection of more than 2500 links
about object-orientation? No ads, fast and free access!

Main topics of the collection are:

   o   General Information and Links
   o   Distributed Objects, Corba, OpenDoc, ActiveX / OLE,
       Object Request Brokers, Business Objects
   o   OOA/OOD Methods and Tools, Diagram Layout
   o   Languages, Ada, Delphi, Eiffel, Java, JavaScript, 
       Python, Smalltalk, VBScript, Visual Basic, Visual C++
   o   Databases, OO DBMS, OR DBMS
   o   Patterns, Libraries, Frameworks
   o   Metrics, Reuse, Testing, Numerics
   o   Services and Companies

The collection runs on a server in Heidelberg, Germany.
Mirrors are available for faster access from other contries.

URL of original site:

   o   http://www.rhein-neckar.de/~cetus/software.html

URLs of mirrors:

   o   Australia, Melbourne
       http://www.csse.swin.edu.au/manfred/software.html

   o   Brazil, RS, Porto Alegre
       http://www.intuitive.com.br/cetus/software.html

   o   USA, IL, Chicago
       http://www.objenv.com/cetus/software.html

   o   USA, UT, Provo
       http://mini.net/cetus/software.html

I am still looking for sites in ASIA, which would like to mirror 
Cetus. So visitors from the APA region have easier access 
to the link collection.

Moreover I am interested in further URLs about ... 
   o   diagram layout
   o   frameworks
   o   metrics
   o   reuse
   o   testing

If you are interested in mirroring or know some URLs 
please let me know.

Manfred

Re: Leading zeros with Int_IO.Put()? Or another package?

[John Herro]

baldwin@netcom.com (J.D. Baldwin) wrote:
> if (MINUTE <= 9) then
>    Int_IO.Put(0, 0);
> end if;
> Int_IO.Put(MINUTE,0);
> ... is there a better way to pad out integers
> with leading zeros?

I don't know if this way is "better," but here's how I force leading zeros
when I know the number is never too large for the desired width and the
number is never negative.  (In this example, Minute is never more than two
digits and never negative).  Let's call the desired width W.  Add the
constant 10**W, take the 'Image, which will always have exactly W+2
characters, and select the last W characters of the result.  For example,
if Minute = 4 and is of type Integer, then Integer'Image(104) is " 104"
and the last two characters are "04".  In your code, you COULD replace
four lines with

Ada.Text_IO.Put(Integer'Image(100 + Minute)(3 .. 4));

This technique works only when W is small enough that 10**W plus the
largest number you're going to handle doesn't overflow.  For example, if
the number you're outputting is an Integer and Integer'Last is
2_147_483_647 (ten digits), then W can be at most nine to avoid overflow. 
Within that limit, this technique can force multiple leading zeros to any
desired width.

Whether this way of forcing leading zeros is "better" is certainly
debatable.  All I can say for certain is that it's fewer lines.

- John Herro
Software Innovations Technology
http://members.aol.com/AdaTutor
ftp://members.aol.com/AdaTutor
-----
ANSWER: "Close cover before striking."
QUESTION: What did the labor union leader say to the sewer workers?

Re: Leading zeros with Int_IO.Put()? Or another package?

[Robert Dewar]

John Herro says

"Whether this way of forcing leading zeros is "better" is certainly
debatable.  All I can say for certain is that it's fewer lines."

That of course is NOT a criterion (and you don't say it is :-)

This is a place where CLEARLY there is a missing abstraction (Put with
leading zeros), and it seems obvious that you fix this in the way that
you always do abstraction extension, you create an appropriate abstraction
and use it. If it is useful enough, hopefully it gets to be widely available.

Note that if you do want to construct on the fly, a much clearer way is to
use the string routines from the string packages, which have padding
capabilities.

Re: Leading zeros with Int_IO.Put()? Or another package?

[James Rogers]

The following certainly does not qualify for the shortest solution,
but it does cover a multitude of cases.

---------------------------------------------------------------------------
-- Utility to print zero-filled strings of integer values.
---------------------------------------------------------------------------

package zero_fill is

   procedure zput (Item : in Integer; 
                   Width : in Natural := 2);

   function zput ( Item : in Integer; 
                   Width : in Natural := 2) return string;
end zero_fill;
---------------------------------------------------------------------------
-- Utility to print zero-filled strings of integer values.
---------------------------------------------------------------------------
with Ada.Text_IO;
with Ada.Numerics.Aux;

package body zero_fill is

   Package tio renames Ada.Text_IO;
   Package int_io is new tio.integer_io(integer);

   Package naux renames Ada.Numerics.Aux;

   procedure zput (Item : in Integer; 
                   Width : in Natural := 2) is
      num_digits : long_float;
      Length : Positive;
      calc_digits : Natural;
   
   begin

      num_digits := naux.log(long_float(Item)) / naux.log(10.0);
      begin
      calc_digits := natural(long_float'floor(num_digits)) + 1;
      exception
         when constraint_error =>
               tio.put_line("Conversion Error.");
               raise;
      end;
      if calc_digits  < Width then
         Length := Natural(Num_Digits) + 1;
      else
         Length := Width;
      end if;

      declare
         out_string : string(1..Length);
      begin
         int_io.put(out_string, Item);
         for Index in reverse out_string'Range loop
            if out_string(Index) not in '0'..'9' then
               out_string(Index) := '0';
            end if;
         end loop;
         tio.put(out_string);
      end;
   end zput;

   function zput ( Item : in Integer; 
                   Width : in Natural := 2) return string is
      num_digits : long_float;
      Length : Positive;
      
   begin

      num_digits := naux.log(long_float(Item)) / naux.log(10.0);
      if Natural(num_digits) + 1  < Width then
         Length := Natural(Num_Digits) + 1;
      else
         Length := Width;
      end if;

      declare
         out_string : string(1..Length);
      begin
         int_io.put(out_string, Item);
         for Index in reverse out_string'Range loop
            if out_string(Index) not in '0'..'9' then
               out_string(Index) := '0';
            end if;
         end loop;
         return out_string;
      end;
   end zput;
end zero_fill;

-- 
Jim Rogers
*************************************************************
Team Ada

Re: Leading zeros with Int_IO.Put()? Or another package?

[Robert Dewar]

"Yes, we do.
We also have code still running unchanged which can be traced back to the
70s; how about you?"

Well of course the answer is yes (my Xray crystallography codes developed
in the late 60's are still in use, and SPITBOL/370, originally developed
in the early 70's is still in wide use -- there are even some United Airlines
counters still using old Incoterm machines for which I wrote the software
around 1970 -- it's quite amazing how old code sticks around :-)

But I do not punch my code on 80-column cards any more. In fact last I knew
you cannot buy 80-column cards any more -- I know this because there was a
major panic at NYU some years ago. They used 80-column cards for
registration, and the last company announced they were being discontinued.
NYU bought up the remaining stock and managed to keep going for another
couple of years (using ancient unit record equipment :-)