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

[ok@goanna.cs.rmit.edu.au (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.