Re: Get_Immediate warning, (was: How to get a character?)

[bglbv@my-dejanews.com]

Robert Dewar <robert_dewar@my-dejanews.com> 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.