Programmer's ROM - The Computer Language Library/programmersrom.iso/ada/menu/mmgrtr.doc

Text File | 1988-05-03 | 7.6 KB | 217 lines

                          FINAL REPORT

                VIDEO MENU-MANAGER SOFTWARE SYSTEM
                    CONVERSION TO Ada LANGUAGE
                ISSUES OF CONVERSION AND REHOSTING


                  Contract No. N66001-85-C-0049









                    May 17, 1985


                    Submitted to

                Naval Ocean Systems Center
                   San Diego, CA 92152












                    AdaSoft, Inc.
                     9300 Annapolis Road
                      Lanham, MD  20706
INTRODUCTION

  The following is a summation of the problems encountered in converting the
original Fortran code to Ada code, using the Telesoft-Ada compiler V 1.5, and
rehosting the software from the IBM-PC/XT version to the VAX/VMS version. These
problems have been previously reported in the monthly status reports filed in
accordance with the requirements of the contract (CDRL item A004 ).

CONVERTING FORTRAN CODE TO Ada

There were no problems encountered in conversion of the sortware from existing
Fortran code to Ada code. This is primarily due to the fact that conceptual
coversion was performed rather than a line-by-line conversion. It is our
conclusion that conceptual conversion will result in better Ada code which is
more in keeping with the design philosophies associated with the Ada language.

USING THE TELESOFT-Ada COMPILER V 1.5

Unimplemented features of the Ada language were the least significant problem
in the development process. The features we could have used were:

  Enumeration_IO: Since we wished to define and use several enumeration types,
we were forced to accept character input from the user, matching this against a
look-up table. The table was defined as an array of strings, indexed by the
enumeration type we used, and     containing the character representation of the
enumeration type scalar values.

Delay Statement: There were several occasions when a delay statement would have
been useful, particularly when several messages were to be output to the same
line.

Record/Array Initialization: This was perhaps the most inconvenient
unimplemented feature. It is a particularly useful feature of Ada to be able to
declare a variable of some packed array type, and initialize this with a
statement such as, 1..20=> '*'. The alternative for us was to make all strings
of equal size and use strings of blanks to initialize. Named association for
initializing parts of records was also unimplemented, and required us to
initialize all parts of a record when only certain parts were required to have
an initial value.

Undocumented Problems: The Telsoft-Ada compiler V 1.5 has a particular problem
with visibility in library units. This seems to be particularly apparent when
renaming type     declarations defined in another package. For example,

        package A is
            type ENUM_TYPE is ( Q, R, S );
            type POINT_REC is
                record
                    X : NATURAL;
                    Y : NATURAL;
                end record;
        end A;

        with A;
        package B is
            subtype ENUM_TYPE is A.ENUM_TYPE;
            subtype POINT_REC is A.POINT_REC;
        end B;

        with B;
        package C is
            subtype ENUM_TYPE is B.ENUM_TYPE;
            subtype POINT_REC is B.POINT_REC;
        end C;

While tests for membership placed in C will work, any attempt to use a literal
enumeration value in C will be flagged as undeclared. For example, you may not
pass the value Q in place of a parameter, nor can you use Q in an assignment to
a variable of type ENUM_TYPE. In fact, for the values to be available in C, you
must include a "with A, B; use     A, B;" in package C. The use statement "use A;"
must also be included in package B if     references to values of that type are
made in package B.

Furthermore, even though POINT_REC is a legitimate subtype of A.POINT_REC, you
may not declare a variable of that type with an initial value without include a
use statement of the package containing the overall type in the package you are
working on. For example,

        POINT : POINT_REC := ( 0,0 );

would be unusable in package C unless package A was visible.

Qualifying an enumeration literal with it's underlying (base) type will still
be flagged as an error, i.e.,

        VAL : ENUM_TYPE := A.ENUM_TYPE'(Q);

would be uncompilable, as would any attempt to assign the literal value to the
appropriate type without first using a use statement of the original package,
A. What becomes interesting is that:

        TEXT_IO.PUT ( ENUM_TYPE'image(ENUM_TYPE'first));

used in package C, without the with statement for A, will compile and will
output the appropriate value.

Another problem is that assignment to strings is not correctly implemented. For
example, given the assignments:

        S : STRING(1..20);
        T : STRING(1..5);
        U : STRING(1..4);

the following statement raises a constraint error:

        S := T & U;

however, "S(1..T'last + U'last) := T & U;" does work.

An additional problem is an apparant inability to resolve overloaded
enumeration values. Given the following code:

        package TEST is
            type A is ( BOOT, ROOT, TREE);
            type B is ( BOOT, MENU, PROG);
        end TEST;

        with TEST; use TEST;
        package TEST_TOO is
            procedure ZIP ( I : in A );
        end TEST_TOO;
        package body TEST_TOO is
            procedure ZIP ( I : in A ) is
            begin
                    ***
            end ZIP;

            procedure ZIPPO is
            begin
                ZIP ( BOOT );
            end ZIPPO;
        end TEST_TOO;

The compiler could not resolve the overload in the call to ZIP, even though the
parameter list for that routine makes the type clear.

When you are using a variant record, the compiler does not check to see if you
are using the correct parts for the discriminant in the code. It will allow you
to declare a variable of the record type, making it have the structure
associated with one case of the discriminant,     and then later assign values to
parts of the record that exist only for another case of the discriminant. This
is not caught until run time. Secondly, if you rename the standard exceptions
and then try to handle them in another package, then unless the package
IO_EXCEPTIONS is visible, you must raise and handle the renamed exceptions,
especially if the rename uses the same name as the original exception.

REHOSTING THE VIDEO PACKAGES

Several problems were encountered in this area, one of which may be specific to
the NOSC computer.

A problem with forking (calling) a program from inside VIDEO could not be
resolved on the IBM-PC. Apparently the IBM-PC does not have enough stack space
to allow this. The program will run, but never returns to the calling program.
This has not been a problem with the VAX version, however, at this time, the
forking procedure does not allow the forking of a non-Ada program.

The IBM-PC version runs under the ROS operating system. No good
telecommunications programs were found that would allow transfer of files over
the network, nor were attempts at conversion of ROS format text files to DOS
format acceptable. Therefore, we direct-connected to a local VAX, and were then
able to port these files to the VAX, and create a tape in VAX format. We then
loaded the files onto a VAX that had access to the net, and used FTP to pull
the files to the NOSC system.

We had anticipated most of the code-related rehosting problems, and were able
to modify these with little difficulty. We did run into a problem with the
version of Terminal_Control (a proprietary package provide by Telesoft with the
compiler) on the NOSC computer. This  problem had not appeared when we had
previously tested the VIDEO code on a local VAX, and we must assume that the
problem is with the version of this package on the NOSC machine. We were able
to resolve the problem by writing our own set of procedures to handle the
terminal control we needed.