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!news.glorb.com!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!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: Wed, 19 Feb 2014 16:15:10 -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 1392844514 870 192.74.137.71 (19 Feb 2014 21:15:14 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Wed, 19 Feb 2014 21:15:14 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:LV+xAC3enS5hIUVjpN92syM9pZs= X-Received-Bytes: 4325 X-Received-Body-CRC: 2733082995 Xref: news.eternal-september.org comp.lang.ada:18676 Date: 2014-02-19T16:15:10-05:00 List-Id: Simon Clubley writes: > On 2014-02-16, Robert A Duff wrote: >> 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. Right, it's not at all clear that this should be part of the language. But my "read the next token, and tell me what it is" method is how it should normally be done, and if the language doesn't support it, then the programmer will do that, which is fine. But the "read an integer token, and blow up if the user typed something else" method is rarely useful. I'd stick with "read a character", "read a line", and "read the whole file". > 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 ? All good questions, that are perhaps best left up to the programmer. > What happens when the final destination is a range limited data type ? All integer types in Ada are range-limited. I'd prefer to allow unbounded integers. > 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. That's not really what I meant by "simplified". ;-) >> 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. Maybe. Should the binary one return a String, or an array of bytes, or something else? - Bob