From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!v102.xanadu-bbs.net!xanadu-bbs.net!nntp.club.cc.cmu.edu!micro-heart-of-gold.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!.POSTED!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Text_IO, was: Re: Something I don't understand Date: Sun, 16 Feb 2014 11:17:16 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <4a3e55f6-9f54-4084-9f37-96efd4b0d349@googlegroups.com> <0b358700-871b-4603-addd-65e07c7d59e5@googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls7.std.com 1392567440 15191 192.74.137.71 (16 Feb 2014 16:17:20 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sun, 16 Feb 2014 16:17:20 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:V76Fx7yJw5tiya7F1tdU89qz2jo= Xref: news.eternal-september.org comp.lang.ada:18618 Date: 2014-02-16T11:17:16-05:00 List-Id: Simon Clubley writes: > On 2014-02-15, Robert A Duff 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