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

[Robert A Duff <bobduff@shell01.TheWorld.com>]

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.

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

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.

I/O should be task safe, at least for standard output and friends.

There are various ways operating systems have chosen to represent text
files: lines separated by a single character, lines separated by two
characters (CR/LF), record oriented.  Obviously, the language design
needs to pick one of those models, and the implementation needs to map
that model onto whatever the OS does.  Any model will work, but Ada
chose the least convenient one.

Path names (file names with directory names and so on) should be
represented using an appropriate type, with structure, properly
interoperating with Ada.Directories.  String is the wrong type for that.
See how it's done in Common Lisp, quite portably.

The Get_Line procedure invites people to write broken programs
with arbitrary annoying line-length limitations.  However long
you make that String, it will be either too short or too long,
and most likely both.  The Get_Line function is better.

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

String should be a private data type with appropriate operations,
representing full Unicode, probably represented in UTF-8.
But we can't blame the designers of Ada 83 for choosing 7-bit
ASCII.  Even that was a bold move, at a time when most languages
didn't even define a standard character set, leaving it up to
the operating system.

There should be a standard way to represent multi-line text
in a String.

There is no convenient way to open a file in append mode,
creating it (empty) if it doesn't exist, atomically.

Calling Create followed by Close, with no intervening output,
does not create an empty file.  That's broken.

The line-counting business is largely useless, and somewhat confusing.

The page-handling is largely pointless, and gets in the way even
when you don't care about pages.

Finalization (which didn't exist in Ada 83) should be used to
automatically close files.

Open should be a build-in-place function (which didn't exist in Ada 83),
instead of a procedure.

> In a modified Ada, do you still see a role for Text_IO as it stands
> (with additional I/O package(s) implementing your desired changes) or do
> you think Text_IO should be outright replaced ?

You mean if compatibility were not a concern?  Yeah, the only reason
to keep Text_IO as it is is for compatibility.  In a from-scratch
language design, I'd do it rather differently.

- Bob