How to get a character?

How to get a character?

[Ben Barth]

I was wondering if there was a way to get a character in Ada from the
user such as the getchar() function that can be used in C.  I'm trying
to add a stop after displaying some information to the screen so the
user can press any key to continue with the program.  I used the
Text_IO.Get() function but that didn't seem to work very well.

I was also wondering if there was a way to format output to the screen
ala C which uses "\t" for a tab.

Thanks
-Ben

Re: How to get a character?

[Matthew Heaney]

Ben Barth <bebart@dave-world.net> writes:

> I was wondering if there was a way to get a character in Ada from the
> user such as the getchar() function that can be used in C.  

Try Get_Line.  


> I'm trying to add a stop after displaying some information to the
> screen so the user can press any key to continue with the program.

Yup.  Use Get_Line.

  <display info>

  Put_Line ("Hit any key to continue");

  declare
    Line : String (1 .. 20);  
    Last : Natural;
  begin
    Get_Line (Line, Last);
  end;

  <continue with program>



> I used the Text_IO.Get() function but that didn't seem to work very
> well.

That function only returns only readable characters, and keeps consuming
the line terminator until it finds one.  In this case, this is not the
behavior you want.

I made a post on this topic a week or two ago, with the title "weird
get_line".  You can look it up at DejaNews.

<http://www.dejanews.com/>

> I was also wondering if there was a way to format output to the screen
> ala C which uses "\t" for a tab.

Try ASCII.HT.  Set_Column (Set_Col?) might be better, though.

Re: How to get a character?

[bglbv]

Matthew Heaney <matthew_heaney@acm.org> writes:

> Ben Barth <bebart@dave-world.net> writes:
> 
> > I was wondering if there was a way to get a character in Ada from the
> > user such as the getchar() function that can be used in C.  
> 
> Try Get_Line.  

Don't you mean Get_Immediate?

> > I'm trying to add a stop after displaying some information to the
> > screen so the user can press any key to continue with the program.
> 
> Yup.  Use Get_Line.

Nope. With Get_Line the "any key" had better be labelled "return" or
"enter".

> > I used the Text_IO.Get() function but that didn't seem to work very
> > well.
> 
> That function only returns only readable characters, and keeps consuming
> the line terminator until it finds one.  In this case, this is not the
> behavior you want.

Correct.

Re: How to get a character?

[Matthew Heaney]

bglbv@my-dejanews.com writes:

> Don't you mean Get_Immediate?

Yes.
 
> > > I'm trying to add a stop after displaying some information to the
> > > screen so the user can press any key to continue with the program.
> > 
> > Yup.  Use Get_Line.
> 
> Nope. With Get_Line the "any key" had better be labelled "return" or
> "enter".

In my mind, I was thinking "return", even though he did say any key.

Thanks for pointing this out to me.

Matt

Re: How to get a character?

[Fraser Wilson]

paene lacrimavi postquam Matthew Heaney scribavit:

>In my mind, I was thinking "return", even though he did say any key.

>Thanks for pointing this out to me.

By the way, if I really want a return I usually use Skip_Line, so
that I don't have to worry about the input.  For some reason I
have an irrational fear of Get_Immediate, but it's probably just me.

Fraser.
(change i's to y's for my real email address)

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

[JS]

Fraser Wilson wrote:
> 
> paene lacrimavi postquam Matthew Heaney scribavit:
> 
> >In my mind, I was thinking "return", even though he did say any key.
> 
> >Thanks for pointing this out to me.
> 
> By the way, if I really want a return I usually use Skip_Line, so
> that I don't have to worry about the input.  For some reason I
> have an irrational fear of Get_Immediate, but it's probably just me.

Not Quite irrational.
Since Get_Immediate is much less used, 
You can never be sure if it really works as it is supposed to
until you have verified it yourself for the compiler at hand.

One recent example is Object-Ada version 7.1.1 where it did not !

> 
> Fraser.
> (change i's to y's for my real email address)

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

[Robert Dewar]

In article <371304D4.81D40292@ddre.dk>,
  JS <john.doe@ddre.dk> wrote:
> Since Get_Immediate is much less used,
> You can never be sure if it really works as it is
> supposed to until you have verified it yourself for the
> compiler at hand.
>
> One recent example is Object-Ada version 7.1.1 where it
> did not !

That's not the right point of view. The issue here is
one of implementation dependence, Remember the only formal
requirement for Get_Immediate is:

  10   Reads the next character, either control or
       graphic, from the specified File or the default
       input file.  Mode_Error is propagated
       if the mode of the file is not In_File.  End_Error
       is propagated if at the end of the file.  The
       current column, line and page numbers
       for the file are not affected.

Any implementation satisfying this is "working". Note that
the above definition has nothing to say about echoing or
line returns being needed or anything.

Most likely by "working", people are talking about
paragraph 23 in the same section, which talks about
keyboard devices, and not waiting for input, but that
whole section is Implementation Advice, not a requirement,
for the very good reason that it is hard to know what it
means in some environments.

Note that even para 23 does not make it clear whether or
not Get_Immediate echoes the input (some people want the
answer to be yes, some to be no, implementations differ,
probably the ARG should address that particular subissue).

Anyway the point is that when you use Get_Immediate you
are definitely in the implementation dependent arena and
you must consult annex M of your vendors documentation.

Presumably this documentation in Object Ada said that this
advice was not followed, so this is not a bug, merely an
implementation choice that you do not like.

The corresponding part of the GNAT Annex M documentation,
found in the GNAT reference manual, says that GNAT does
follow this advice, so at least you should not have to
wait for a line return.

As for having an irrational fear of Get_Immediate, you
should use this ONLY when you need this functionality,
if Skip_Line or Get_Line has the right semantics, this
is far preferable since it is non-implementation dependent.
If you really need Get_Immediate, then you need to use it
regardless of your fears, but carefully document your
expectations and requirements, and realize that this part
of your code may not be as portable as other parts.



-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

[bglbv]

Robert Dewar <robert_dewar@my-dejanews.com> writes:

>   JS <john.doe@ddre.dk> wrote:
> > Since Get_Immediate is much less used,
> > You can never be sure if it really works as it is
> > supposed to until you have verified it yourself for the
> > compiler at hand.

> That's not the right point of view. The issue here is
> one of implementation dependence, Remember the only formal
> requirement for Get_Immediate is:
> 
>   10   Reads the next character, either control or
>        graphic, from the specified File or the default
>        input file.  Mode_Error is propagated
>        if the mode of the file is not In_File.  End_Error
>        is propagated if at the end of the file.  The
>        current column, line and page numbers
>        for the file are not affected.
> 
> Any implementation satisfying this is "working". Note that
> the above definition has nothing to say about echoing or
> line returns being needed or anything.

Yes, but... is the situation any different with respect to Get_Line
or Skip_Line?

At least with Get_Immediate there is that piece of Implementation
Advice to the effect that input buffering should be turned off.
I can find no corresponding wording to say that entering a line
terminator at the keyboard *must* make the line immediately available
to Get_Line. 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. Maybe it is part of the operational
definition of "interactive input"; but note that input through a
CGI form, for example, could easily be page-buffered.

I certainly agree that *any* trick like "type RETURN to continue" or
"press any key to continue" makes certain assumptions about the
operating environment and will not be portable to contexts where
these assumptions fail. What I disagree with is your claim that the
presence of that Implementation Advice paragraph makes Get_Immediate less
portable than Get_Line. My reading is exactly the opposite: that
Implementation Advice is much better than the silence that surrounds
Get_Line's buffering behaviour.

In practice, it's all a quality of implementation issue: a decent
compiler should not ignore that Implementation Advice without a
very good reason (and the behaviour must be documented in Annex M),
and keyboard input shouldn't be buffered in multi-line units without
good reason either (but this doesn't need to be documented in Annex M
as far as I can tell).

> Anyway the point is that when you use Get_Immediate you
> are definitely in the implementation dependent arena and
> you must consult annex M of your vendors documentation.

Yes, and I see that definiteness as a good thing.

> As for having an irrational fear of Get_Immediate, you
> should use this ONLY when you need this functionality,
> if Skip_Line or Get_Line has the right semantics, this
> is far preferable since it is non-implementation dependent.

If Skip_Line or Get_Line have the right semantics, they are
preferable because they have the right semantics, not because
the implementation dependence (which still exists) happens to be
less clearly stated in the standard.

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

[Robert Dewar]

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.

The standard is written under the assumption that Text_IO
is reading and writing files. Well more accurately, the
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.

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.

If you try to do a VERY accurate implementation of Text_IO
on interactive terminals, you sometimes have to press
Line return twice, since you need to be sure there is no
page mark in the input before you know exactly what is
going on.

Most reasonable Ada compilers do something about this (e.g.
GNAT defines that there are no page marks for non regular
files), but this is definitely in the implementation
dependent area.

Basically the design approach was that Text_IO is to be
used for simple I/O with no fancy requirements (sort of
like DISPLAY and ACCEPT in COBOL). 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.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

[bglbv]

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.

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

[Robert Dewar]

In article <87zp4aud4a.fsf@bglbv.my-dejanews.com>,
  bglbv@my-dejanews.com wrote:
> 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...

Nope, the most you can say is that the addons (get
immediate and flush) are written with this assumption.
But these are addons to a largely unchanged spec that
was written with NO thought of interactive IO at all.

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

But that sentence *is* one of the glued on sentences.
Just compare this para with RM83 (14.3(2)).

> > 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?

I have defined this precisely by showing you EXACTLY what
the RM has to say that is normative about these functions.
We *do* know that Get_Immediate gets a character, so it
is not *completely* implementation dependent, but that's
EXACTLY the uninteresting part of Get_Immediate, what is
interesting is *how* it gets it, and this is left as ID.
That's *exactly* what I meant by PMCID :-)

THe problem of Text_IO in interactive environments is
well understood, and it was a quite deliberate decision
NOT to try to address it in the Ada 95 design. The general
feeling was that it was too broken to get exactly right,
and not broken enough to be worth a major kludging up.
At the last minute the Get_Immediate and Flush bandaids
were applied to stop the patient from bleeding to death :-)
But plastic surgery was beyond the budget!


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

[Matthew Heaney]

Robert Dewar <robert_dewar@my-dejanews.com> writes:

> THe problem of Text_IO in interactive environments is
> well understood, and it was a quite deliberate decision
> NOT to try to address it in the Ada 95 design. The general
> feeling was that it was too broken to get exactly right,
> and not broken enough to be worth a major kludging up.
> At the last minute the Get_Immediate and Flush bandaids
> were applied to stop the patient from bleeding to death :-)
> But plastic surgery was beyond the budget!

Can you elaborate on the "well understood problems" with interactive
Text_IO?

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

[Robert Dewar]

In article <m3pv55m887.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> Robert Dewar <robert_dewar@my-dejanews.com> writes:
>
> Can you elaborate on the "well understood problems" with
> interactive

There are many such problems, the two best known are
Line/Col values not being "correct", and page mark
semantics.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

[Jean-Pierre Rosen]

Robert Dewar a �crit dans le message
<7f8dm2$mp2$1@nnrp1.dejanews.com>...
>In article <m3pv55m887.fsf@mheaney.ni.net>,
>  Matthew Heaney <matthew_heaney@acm.org> wrote:
>> Robert Dewar <robert_dewar@my-dejanews.com> writes:
>>
>> Can you elaborate on the "well understood problems" with
>> interactive
>
>There are many such problems, the two best known are
>Line/Col values not being "correct", and page mark
>semantics.
>
I addressed these issues in a paper, back in 1983.
The paper described the solution used in the Ada/Ed compiler.
I don't have any electronic version any more, but I still have a paper
copy, and I can send it to people interested.
Just drop me a note at the address below.
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

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

[Robert A Duff]

Robert Dewar <robert_dewar@my-dejanews.com> writes:

> Nope, the most you can say is that the addons (get
> immediate and flush) are written with this assumption.
> But these are addons to a largely unchanged spec that
> was written with NO thought of interactive IO at all.

Not true.  Section 14.7 of the Ada 83 RM, "Example of Input-Output",
shows that the authors intended for interactive I/O to work.  Of course,
the example is wrong.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

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

[Larry Kilgallen]

In article <87hfqkgnrm.fsf@bglbv.my-dejanews.com>, bglbv@my-dejanews.com writes:

> to Get_Line. 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.

If that assumption were made, it would certainly indicate those
making the assumption lacked some degree of experience with real
operating systems.

> and keyboard input shouldn't be buffered in multi-line units without
> good reason either (but this doesn't need to be documented in Annex M
> as far as I can tell).

So what was the approach taken by the GNAT developers when
they encountered the VMS implementation of typeahead buffers?

Larry Kilgallen

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

[JS]

Robert Dewar wrote:
> 
> In article <371304D4.81D40292@ddre.dk>,
>   JS <john.doe@ddre.dk> wrote:
> > Since Get_Immediate is much less used,
> > You can never be sure if it really works as it is
> > supposed to until you have verified it yourself for the
> > compiler at hand.
> >
> > One recent example is Object-Ada version 7.1.1 where it
> > did not !
> 
> That's not the right point of view. The issue here is
> one of implementation dependence, 

.. <snip diverse interesting stuff>

Sorry for failing to say, that the error in OA 7.1.1 was with the
non-blocking get_immediate(ch,avail), and that the error has been
corrected in OA 7.1.2.

Get_immediate(ch,avail) is supposed to return immediately, whether a key
is pressed (Avail=FALSE) or not (Avail=TRUE).

However, using OA 7.1.1, this only happened some of the time, not every
time.
Some times, get_immediate(ch,avail) instead would wait for a keypress, 
just like the "normal" get_immediate(ch).  

I would not call this an implementation dependance, but a compiler bug.

And I maintain, that the prudent user must be more careful of running
into 
hitherto unknown compiler bugs when he is using the outskirts of the
language, than when staying with mainstream features. 

Greetings,

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

[Robert Dewar]

In article <3714398E.B7E4D499@ddre.dk>,
  JS <john.doe@ddre.dk> wrote:
> Robert Dewar wrote:
> >
> > In article <371304D4.81D40292@ddre.dk>,
> >   JS <john.doe@ddre.dk> wrote:

> I would not call this an implementation dependance, but a
> compiler bug.

(here "this" = waiting for line return before returning
for a Get_Immediate with Available set).

Well anyone can all anything by any label they want, but
the issue is not what John Doe calls something, but rather
what the RM says.

Since the requirement in the RM does not define what
available means, or what is required to compute the
predicate available, you cannot conclude there is a bug
here.

The "interesting stuff" you snipped from my message also
applies here. The issue is whether your compiler obeys the
implementation advice. You need to look this up in Annex
M. Whether this was a bug in the compiler or not depends
on whether they claimed to follow this advice. If you can't
find documentation on whether the compiler follows this
advice, then the compiler does not conform to the RM in
any case, because this documentation is required.

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

[Robert A Duff]

Robert Dewar <robert_dewar@my-dejanews.com> writes:

> Well anyone can all anything by any label they want, but
> the issue is not what John Doe calls something, but rather
> what the RM says.

Surely you're not trying to imply that the only way for an Ada compiler
to have a bug is for it to disobey the RM?!

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: How to get a character?

[David C. Hoos, Sr.]

Ben Barth wrote in message <370EE07D.67C71458@dave-world.net>...
>I was wondering if there was a way to get a character in Ada from the
>user such as the getchar() function that can be used in C.  I'm trying
>to add a stop after displaying some information to the screen so the
>user can press any key to continue with the program.  I used the
>Text_IO.Get() function but that didn't seem to work very well.
>
If you really want him to just press any key, and only one key,
then in Ada95, you can use text_io.Get_immediate -- the one with only
one parameter.  This procedure will not return until the user types
some (any) character.

If using Ada83, then, without resorting to some OS-specific or
compiler-specific code, you would use text_io.Get_Line.  However,
this will require a <return> character to return from the call.
You could, of course simply say "Press return to Continue."

>I was also wondering if there was a way to format output to the screen
>ala C which uses "\t" for a tab.
>
This one's the same in Ada83 and Ada95:

If I wanted to move to the next "tab stop" where the "stops" are at
intervals of N columns, I would do
Ada.Text_IO.Set_Col (((Ada.Text_IO.Col + N) mod N) + 1);

(of course leave off the Ada. prefix if using Ada83).

Re: How to get a character?

[Jeff Carter]

Again, I see people recommending Ada.Text_Io.Get_Line as the way to
perform the "Press Enter [or Return] to continue:" function. This is
incorrect. When, in response to this message, the user types enough
characters to fill the Item parameter to Get_Line, the program will
continue before the user presses Enter [or Return]. If the user
mistakenly types ahead, this can be a significant problem.

In Ada terms, the desired behavior is for the program to wait until the
user inputs a line terminator on standard input, and consume that line
terminator. The Enter [or Return] key is how the user inputs a line
terminator. The correct way to wait for and consume a line terminator on
standard input is

Ada.Text_Io.Skip_Line;
-- 
Jeff Carter
"You empty-headed animal-food-trough wiper."
Monty Python & the Holy Grail

Re: How to get a character?

[Larry Kilgallen]

In article <3711753C.A665E406@spam.innocon.com>, Jeff Carter <spam.carter.not@spam.innocon.com> writes:
> Again, I see people recommending Ada.Text_Io.Get_Line as the way to
> perform the "Press Enter [or Return] to continue:" function. This is
> incorrect. When, in response to this message, the user types enough
> characters to fill the Item parameter to Get_Line, the program will
> continue before the user presses Enter [or Return]. If the user
> mistakenly types ahead, this can be a significant problem.
> 
> In Ada terms, the desired behavior is for the program to wait until the
> user inputs a line terminator on standard input, and consume that line
> terminator. The Enter [or Return] key is how the user inputs a line
> terminator. The correct way to wait for and consume a line terminator on
> standard input is
> 
> Ada.Text_Io.Skip_Line;

In human interface terms, the desired behavior is to recognize that
the user who inputs many characters rather than a single carriage return
is probably not synchronized with what the program is asking and intended
those characters to go somewhere useful and may proceed to enter yet some
additional line which would also be used for the wrong purpose.

The program should flush the ambiguous input and signal to the user
that something is wrong through whatever mechanism (bell, reverse video,
speech synthesizer, etc.) is appropriate to the environment.

Larry Kilgallen

Re: How to get a character?

[Robert Dewar]

In article <3711753C.A665E406@spam.innocon.com>,
  Jeff Carter <spam.carter.not@spam.innocon.com> wrote:
> Again, I see people recommending Ada.Text_Io.Get_Line as
> the way to perform the "Press Enter [or Return] to
> continue:" function. This is
> incorrect.

I don't see that, providing you use a big buffer, e.g.
a few hundred K, which in typical commit on use systems
is not real space allocated, you cannot run into problems.


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own