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=-0.3 required=5.0 tests=BAYES_00,HK_RANDOM_FROM, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,463c997594f91391 X-Google-Attributes: gid103376,public From: bglbv@my-dejanews.com Subject: Re: Get_Immediate warning, (was: How to get a character?) Date: 1999/04/14 Message-ID: <87zp4aud4a.fsf@bglbv.my-dejanews.com>#1/1 X-Deja-AN: 466459761 References: <370EE07D.67C71458@dave-world.net> <87k8vkag6f.fsf@bglbv.my-dejanews.com> <923936702.835.91@news.remarQ.com> <371304D4.81D40292@ddre.dk> <7eva5j$npf$1@nnrp1.dejanews.com> <87hfqkgnrm.fsf@bglbv.my-dejanews.com> <7f2biq$bqu$1@nnrp1.dejanews.com> X-Complaints-To: abuse@freeuk.net X-Trace: mors.clara.net 924126356 212.126.148.21 (Wed, 14 Apr 1999 22:45:56 BST) NNTP-Posting-Date: Wed, 14 Apr 1999 22:45:56 BST Newsgroups: comp.lang.ada Date: 1999-04-14T00:00:00+00:00 List-Id: Robert Dewar writes: > In article <87hfqkgnrm.fsf@bglbv.my-dejanews.com>, > bglbv@my-dejanews.com wrote: > > > The standard is clearly written under the assumption that > > interactive input isn't normally buffered more than one > > line at a time, but this doesn't seem to be even an > > Implementation Advice, much less a requirement. > > That's quite wrong. Sorry, I should have been more specific: the description of Text_IO in the standard is written under the assumption... I'll support my claim by pointing you to the last sentence in A.10(2) which talks of "an end-of-line to signal availability". It does so in such a casual way that I would not construe that remark as normative; but as an indication of what the authors had in mind I find it excellent. > The standard is written under the assumption that Text_IO > is reading and writing files. On this we agree, and we've been saying essentially the same thing: that certain aspects of the mapping between Text_IO files and the user interface provided by the operating system are left unspecified by the standard, and that this applies to Get_Line as well as Get_Immediate. > Ada 83 standard is written that way, and the Ada 95 > standard copies the definitions, adding only Flush and > Get_Immediate, both of which are pretty much completely > implementation dependent. "Pretty much completely" isn't a technical term either, is it? What I think you mean is that those two functions spoil the abstraction of the original Text_IO in that their only role is one of synchronisation with the external environment. Close also has such a role, but in addition it changes the state of its first argument, and that has a non-trivial meaning even if one stays purely within the abstraction. > The entire issue of applying Text_IO to "interactive I/O" > (whatever that may be, this is not a technical term), is > in fact implementation dependent. Ultimately, all I/O is environment-dependent by its very nature. > The assumption (even > more true in these windowed days) is that any serious I/O > will be done with packages at a completely different level > in any case. I'm not sure about that. Serious text I/O can very well be layered on top of Ada.Text_IO. The point seems rather to be that user interfaces tend to have requirements that fall outside the scope of Text_IO.