From: mfeldman@seas.gwu.edu (Michael Feldman)
Subject: Re: Ada questions:  ungetting input, and cmd-line args
Organization: George Washington University
Date: Mon, 27 Jul 1992 03:50:32 GMT

In article <1992Jul26.033349.22498@coe.montana.edu> fortran@giac1.oscs.montana.edu (Lou Glassy) writes:
>
>[1]   How would you go about un-getting a character of input
>      (basically, backing up the input stream by one character, 
>      like C's ungetc() routine does) ?

The easiest way to do this portably is to read line-by-line into a
string, using Text_IO.Get_Line, then move the line pointer any way you
wish. Since you have the LRM before you, look this up and note both
the Get_Line procedure and also the fact that all the token-levl
Get's (integer, float, etc.) have versions that Get from a string
(like sscanf in C).
>
>I have before me a copy of ANSI/MIL-STD-1815A.  In 14.2.4 (Direct
>Input-Output), a procedure called SET_INDEX is described, that could do
>what I think I'd need to do, in a pinch.  The cheap-and-dirty solution
>I've got in mind (save the current INDEX, do the GET, then SET_INDEX to
>current INDEX minus one, to back up) is unpleasant at best.

This won't work - Direct_IO is really designed for binary input from
a random-access file.
>
>I'm building pieces of a compiler for a small language.  The ability to
>unget input would be very handy for the lexical analyzer. 
Understood. I think the Get_Line strategy will work best for you. It also
gives you complete control of your input buffer, so you can do other
kinds of backup besides just un-getting a single character.
>
>What is the portable, standard way to do this?
You got it.
>
>[2]   None of the Ada books I've seen in the school library (nor -1815A)
>      mention the environment in which an Ada program is expected to run
>      (except minimally).  Hence, there are no routines mentioned in the
>      standard trio of IO packages (SEQUENTIAL_IO, DIRECT_IO, TEXT_IO) 
>      that retrieve "command-line arguments."  Is there a portable, 
>      standard-conforming way to do this?  or is the idea of "command-line
>      arguments" outside of the scope of the Ada definition, or outside
>      of the ability of standard Ada?  (...I hope not, but it's non-fatal
>      if it is.  I'll just have to adjust the compiler's user interface
>      to suit...)
It was, in 1979-83, considered outside the scope of the standard. Remember
that there was a plethora of operating systems for which Ada was intended
to work. Unix was mostly a gleam in people's eyes, and DOS hardly
existed at all. There wasn't really a feasible way to specify stuff
like command-line args portably.

A common workaround, used by authors like Rick Conn in all the stuff he
submitted to the Ada Software Repository, is simply to supply an Ada
package to do command arguments, whose body interfaces to the
appropriate stuff in the OS. He provides bodies for common compilers.

Many if not most compilers supply a command-line package, but it's not 
portable. I assume the POSIX/Ada standard, which will eventually be adopted 
by every Ada vendor, will provide this portably for all POSIX-compliant 
OS'es. Meanwhile, you'll need to homebrew something or get Rick's stuff
from the Repository.

>One last small question:  (maybe a silly one.)  Will programs written 
>in Ada-83 (or whatever the specific name is of the language defined in
>-1815A) continue to compile and run without modification in the next
>version of Ada (Ada-9X)?  In other words, is it anticipated that Ada-9X
>will break some standard-conforming Ada-83 programs?  or will -9X be a
>strict superset of -83?  (Specifically, for 'Sequential-Ada', i.e., the
>subset of Ada without tasking, will -9X break anything?  If so, what?)
>
The Ada-9X project should really speak for itself on this. The upshot of 
it is that _portable_ Ada-83 programs (even tasking programs) are intended
to compile under Ada-9X and behave the same at execution. Ada-9X is
pretty well committed not to _gratuitously_ break any Ada-83 programs.
Ada-83 programs that would be considered erroneous (i.e. whose behavior
is implementation-dependent) might be expected to be equally unpredictable
in Ada-9X. 

Ada-9X gurus: can you give us the official wording of this again?

The bottom line: write as portably as you can, and work hard to encapsulate
machine dependencies neatly inside packag bodies. That's your best strategy
in Ada-83 and gives you the best shot at an easy transition to Ada-9X.

Mike Feldman
-----------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Aplied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)
Newsgroups: comp.lang.ada