Re: Text_IO, was: Re: Something I don't understand

[Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>]

On 2014-02-16, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>> On 2014-02-15, Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>>>
>>> FWIW, Text_IO is a poor design, and I don't blame you for having
>>> trouble with it!
>>
>> I'm always interested in learning how people would do things differently
>> if they were given a second chance.
>>
>> So, what do you dislike about Text_IO and what design changes would you
>> make if given a second chance ?
>
> I/O should be separated from processing.  In this case, the "processing"
> I'm talking about is formatting and parsing of data (e.g. turning
> an integer into a human-readable sequence of characters).  See how
> it's done in Java.
>
> Formatting for type T belongs with type T, not in Text_IO.
>

Agreed, but it should be a two-way thing.

There should be both External_To_Internal and Internal_To_External
support to convert between the external (human readable) format and
the internal format. You would also need to specify a format when
going from internal to external format so the output would fit in
the requested field width and obey the requested attributes (for
example, number of decimal places).

> Input should be separate from output.  Put(Stream, X), where X is an
> integer makes sense, because we know X is an integer.  Get(X)
> makes no sense, because we have no idea what the user is going
> to type.  For text input, you need "read the next token, and tell
> me what it is", not "read an integer token, and blow up if the
> user typed something else".
>

While the current input routines need replacing, I don't agree with the
Ada RTL trying to work out what the input format is and pass a token
type back to the program. The problem is that unless you are careful,
you can end up with a Excel type solution in which it works most of
the time but fails when it thinks it knows better than you do what
you entered.

For example, consider the input "123,456".

Is the user entering a array of two numbers ?

Is the user entering one number but with a thousands seperator ?

Is the user in mainland Europe and hence is really entering "123.456" ?

Should this input be treated as a string (because it has a comma in it)
or should the Ada RTL impose it's idea of a number and convert the
input into some standard format even though that may not look anything
like what the user meant ?

What happens when the final destination is a range limited data type ?
You either have to still do the checking manually or take a exception
if the input value is outside of the range of the data type.

> A simplified and type-safe version of C's printf style
> (template-based) formatting would be more readable than
> concatenating a bunch of strings together to print messages,
> and MUCH better than using a series of Put calls to print
> a single message.
>

_Totally_ agree with this. It would also be nice if one could write
something like this (pseudo Fortran style to get the idea across):
"5(I4,2X,F10.4,2X)" so you could specify the layout for 5 columns worth
(in this example) of data cleanly.

>
> There should be a convenient way to read an entire file into
> a String.  Similar for writing.
>

Yes, but you may need two methods. One for binary (unchanged) input and
one for text input with end of line conversions.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world