Re: Ada 9X Mapping

Re: Ada 9X Mapping

[James THIELE]

In article <jls.671848656@rutabaga| jls@rutabaga.Rational.COM (Jim Showalter) writes:
In article <???| ??? writes:
|>     I have not seen any discussion on the Ada 9X draft Mapping Document in
|>this group.
|
|>Or does everyone thinks it perfect? 8-)
|
|Well, personally I think it's overkill. The current documents are in 
|a very sketchy state, and they are already large. By the time they
|are transmuted into real modifications to the LRM, the LRM will be
|twice as large as it already is.

Just what the world needs, an LRM twice as large!

Probably trying to stay more convoluted than C++. :-)

I like any number of features in Ada and C++, but the languages have
gotten too complex.  I'm somewhat relieved to be back to C.

James Thiele
Disclaimer:
Nobody on this group thinks that a C program written by a great C programmer
could be better than an Ada programm written by a lousy Ada programmer.
I do, I know you don't, so don't bother flaming me.

Re: Ada 9X Mapping

[Jim Showalter]

>James Thiele
>Disclaimer:
>Nobody on this group thinks that a C program written by a great C programmer
>could be better than an Ada programm written by a lousy Ada programmer.
>I do, I know you don't, so don't bother flaming me.

Now now--let's not jump to conclusions. I've seen good C and wretched Ada,
no doubt about it: nobody ever claimed otherwise. What IS claimed is that
if you pull a listing at random from a pile of C programs and a listing
at random from a pile of Ada programs and compare them, the smart money
bet is that the Ada program is better engineered.

Re: Ada 9X Mapping

[Larry M. Jordan]

Jim Showalter says:
>...What IS claimed is that if you pull a listing at random from a
>pile of C programs and listing at random from a pile of Ada programs
>programs and compare them, the smart money bet is that the Ada program
>is better engineered.

In theory I agree with this.  In practice, gained from two large
DoD funded efforts, this is not yet the case.  I've seen many
thousands of lines of poorly engineered Ada.  It is refreshing to
find that textbook example of a generic, but it is rare.

Re: Ada 9X Mapping

[Ted Grzesik]

In article <1991May9.055530.1516@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
>Now now--let's not jump to conclusions. I've seen good C and wretched Ada,
>no doubt about it: nobody ever claimed otherwise. What IS claimed is that
>if you pull a listing at random from a pile of C programs and a listing
>at random from a pile of Ada programs and compare them, the smart money
>bet is that the Ada program is better engineered.

About the worst Ada code I've seen is by someone that was obviously a prior
C programmer.  In general, I have observed code that was written in the
syntax of one language, but used the style of another language.

I worked on a large Ada program (an Ada compiler, to be precise) that used 
lots of UNCHECKED_CONVERSION and UNCHECKED_DEALLOCATION.  Once you've 
introduced these two routines into your program, you're just writing fancy 
C code.  Using these routines indicates either a flaw in your design or a
limitation of the Ada language.  Usually, it's a flaw in the design.

              My $0.02


Ted Grzesik       Massachusetts Language Lab             Hewlett-Packard Company
tedg@apollo.hp.com                          Chelmsford, MA  (508) 256-6600 x5959
"Civilization is the limitless multiplication of unnecessary necessities."
                                       -- Mark Twain (Samuel Clemens)

Re: Ada 9X Mapping

[Robert I. Eachus]

In article <5176c098.20b6d@apollo.HP.COM> tedg@apollo.HP.COM (Ted Grzesik) writes:

   I worked on a large Ada program (an Ada compiler, to be precise) that used 
   lots of UNCHECKED_CONVERSION and UNCHECKED_DEALLOCATION.  Once you've 
   introduced these two routines into your program, you're just writing fancy 
   C code.  Using these routines indicates either a flaw in your design or a
   limitation of the Ada language.  Usually, it's a flaw in the design.

   Not really.  What indicates a problem is when UNCHECKED_CONVERSION
or UNCHECKED_DEALLOCATION appears in a package specification, rather
than hidden in a body, hopefully a procedure body.  For years, I have
called UNCHECKED_CONVERSION in a library package specification
UNCHECKED_PERVERSION, since it usually destroys the data independence
of both input and output types.  The cost of putting the instantiation
in the body of a procedure is small (and on a good compiler it will
just be the cost of writing additional code, not executing it), but
the difference in portability can be night and day.

--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

Ada 9X Mapping

[byrne]

-Message-Text-Follows-

     I have not seen any discussion on the Ada 9X draft Mapping Document in
this group.  Is there another group dedicated to informal 9X rapping as opposed
to the formal comments to the AJPO?

Or does everyone thinks it perfect? 8-)

Dan J. Byrne 

Re: Ada 9X Mapping

[Jim Showalter]

>     I have not seen any discussion on the Ada 9X draft Mapping Document in
>this group.  Is there another group dedicated to informal 9X rapping as opposed
>to the formal comments to the AJPO?

>Or does everyone thinks it perfect? 8-)

Well, personally I think it's overkill. The current documents are in 
a very sketchy state, and they are already large. By the time they
are transmuted into real modifications to the LRM, the LRM will be
twice as large as it already is.

I'm personally a big fan
of subprogram and package types. I also favor getting rid of the
idiot special-cases (e.g. latter declarative items, etc) that make
learning the language more difficult than it needs to be. And I'd
like a few notational conveniences like "return...when" and "raise...
when".

The problem is, MY list isn't necessarily the same as YOUR list: and
our aggregate lists may not include some other person's wish list.
The aggregation of EVERYBODY'S lists results in a huge shaggy baggy
monster of a language revision. What should have been a very quick,
very restricted effort to triage the top 20 complaints has mushroomed
into accomodating just about everybody.

The question we ought to ask ourselves at this point is: what problem
are we really trying to solve? Are we trying to fix some defects in
the original language definition? Fine--by all mean let's do so. Or
are we actually trying to permute Ada into some radically new language,
like, say, C++ or Eiffel? If so, WHY? The putative merits of such
languages for large complex systems are not well-established. I think
they're largely a fad. Do we run off in eleventy-seven different directions
trying to make Ada be all things to all people (something it was never
EVER intended to do), or do we stick with the knitting? Focusing on
finding out WHY many compiler vendors have crappy tasking applications
is probably a far better way to deal with performance issues than is
dragging in a whole new, untried mechanism. If we're going to make the
language be all things to all people, shouldn't we throw in inferencing
for the AI folks, multiple inheritance for the inheritance weenies,
dynamic typing for the terminally confused, etc etc etc?

Hrmph.
--
* The opinions expressed herein are my own, except in the realm of software *
* engineering, in which case I borrowed them from incredibly smart people.  *
*                                                                           *
* Rational: cutting-edge software engineering technology and services.      *

Ada9X Report to the Public

[Michele L. Kee]

                               Ada9X UPDATE
                                 MAY 1991

                      Draft Mapping Document Released

The draft Mapping Document was distributed in March for public review and
comment.  It specifies the preliminary mappings of Ada 9X Requirements into
language solutions, and key features include enhancements to support
tasking (protected records), separate compilation (hierarchical libraries),
and object-oriented programming (single inheritance and polymorphism).

This first public discussion took place at the Ada 9X Mapping Workshop in
Orlando, Fla., 11-14 March -- which was a big success in obtaining valuable
feedback.  Comments have been quite favorable, though much work still
remains to be done to simplify proposed mappings in order to facilitate use
and lessen the implementation burden.  Expect the next version of the
Mapping Document in June to be streamlined while retaining important
functionality.

                      Requirements Rationale Document

The Ada 9X Requirements Document was released in December, and its
rationale document is now complete.  The rationale features discussion
supporting the selection of Ada 9X requirements and an index tracing
revision requests submitted by the public to specific requirements.  This
document is available electronically on the AJPO host and on the Ada 9X
Bulletin Board -- 1-800-Ada9X25 or 301/459-8939.  Or contact the Ada 9X
Project Office at the address below to receive a hard copy.

                   Keeping Compiler Vendors in the Loop

In an attempt to keep validated Ada compiler vendors up to date on Ada 9X,
the Project Office is routinely sending Ada 9X documents to all vendors.
Furthermore, to solicit feedback, the Project Office issued a vendor survey
in February.

Several vendor workshops are also planned, including a workshop in
conjunction with TRI-Ada in San Jose, Cal., on 21 October.  All vendors
will receive an invitation.

                              Ada in Academia

In order to provide researchers, instructors, and students with necessary
resources to study, teach, and use Ada, the Ada 9X Project Office is
exploring several options.  The first is to provide free compilers on
widely used platforms based on existing Ada products.  (No development from
scratch here!)  Important issues concerning licensing, documentation,
maintenance, etc. still need to be worked out.

The second approach is to provide source code of government-owned tools for
computer-science researchers to use so they can extend the state-of-the-art
in tool technology, bindings to associated standards, distributed/parallel
processing, etc.

Expect more news on these topics in the near term.  If you have suggestions
on these ideas or others to facilitate the use of Ada in academia, please
contact the Project Office.

                    Coordination with the International
                       Standards Organization (ISO)

In order to ensure that Ada retains its American National Standards
Institute (ANSI) and ISO status, a lot of international coordination is
taking place.  The chairs of non-US delegations to ISO Working Group 9
(Ada) were invited by the Ada 9X Project Office to participate in the ANSI
Ada 9X canvass.  Furthermore, a special ISO WG9 meeting featuring Ada 9X is
planned for September.

At the last ISO WG9 meeting, the Ada 9X Project Manager, and the Ada 9X
Mapping/Revision Team technical lead, Tucker Taft, were nominated for ISO
Ada 9X Standard editor and co-editor respectively.  Every attempt is being
made to bring the two standardization processes closer together.  This, of
course, assists users world-wide in ensuring Ada uniformity .

                Coordination with the National Institute of
                      Standards and Technology (NIST)

Ada is also a NIST standard, FIPS PUB 119.  A Memorandum of Understanding
is being established between the Ada 9X Project Office and NIST to
facilitate the NIST adoption process for Ada 9X.  NIST is the primary
maintainer of standards used by the U.S. Government.

                      Coordination with the Military

Ada is also a military standard.  Coordination with DoD agencies and other
U.S. Government agencies interested in Ada is also taking place to
facilitate the final publication of Ada 9X in 1993 as a military standard.
The Ada 9X Project Manager meets regularly with the Ada 9X Government
Advisory Group to coordinate key aspects of the project.

Because recent DoD policy favors adoption of non-military standards in lieu
of the administrative overhead of maintaining military standards, it has
been agreed that when Ada 9X receives ISO standardization approval, the
military designation will be dropped.

The DoD-sponsored Ada Joint Program Office will still be the lead ANSI and
ISO agent for the standard however.

                             Open Door Policy

As always, please free to contact me if you have any concerns or comments
regarding the Ada 9X Project.  I appreciate your support and interest.

To obtain Ada 9X documents or discuss the project, please contact me at the
Ada 9X Project Office:

Chris Anderson
Ada 9X Project Manager
WL/MNAG
Eglin AFB, FL 32542-5434
904/882-8264
e-mail: anderson@uv4.eglin.af.mil
FAX: 904/882-2095

Air Force's Interpretation of Ada "Cost Effective Policy"

[Michele L. Kee]

The following information came from MAJ Thomas J. Croak, AF/SCXS,
(703) 695-9931, croak@sc4.hq.af.mil.

***************************************************************************
The Air Force has published a policy letter stating our 
interpretation of the words "where cost effective" in Public Law
101-511, Section 8092, which requires the use of the Ada 
programming language.  The following is a transcript of the entire
policy letter.

-------------------------Referenced Policy Letter---------------------

                                             05 Apr 1991

MEMORANDUM FOR THE VICE CHIEF OF STAFF
               MAJOR COMMAND AND FIELD OPERATING AGENCY COMMANDERS
               PROGRAM EXECUTIVE OFFICERS

SUBJECT:  INTERPRETATION OF FY 1991 DOD Appropriations Act-
          INFORMATION MEMORANDUM

   The Congressional language of Public Law 101-511, Section 8092
(Atch 1), requires the use of the Ada programming language "where
cost effective."  This memo provides interim Air Force guidance on 
the interpretation of this language, pending issuance of 
consolidated DOD direction.

   Since the Public Law mandates Ada, the determination of
"cost-effectiveness" is interpreted to be the exception and not the
norm.  As such, a full lifecycle cost analysis is required only when
a software system is to be developed and the proposed solution is 
one which requires a waiver in accordance with my August 7, 1990
memo (which remains fully in effect).  Solutions which use COTS
software or other software for which waivers are not required by the
August, 1990 memo are deemed cost-effective for the purpose of
compliance with this law.  When computing the lifecycle cost of an 
Ada solution, any initial investment in Ada support environments,
tools, training, etc., must be amortized over all future anticipated
Ada projects.  In such cases the amortized amount of the total
investment should not exceed 50%, since the investment would be used
for future projects.

   Questions on this matter may be referred to Col Hassebrock,
HQ USAF/SCXS, DSN 223-2699.
                                       (SIGNED)

                               LLOYD K. MOSEMANN, II
                               Deputy Assistant Secretary
                               (Communications, Computers &
                                Logistics)

- -----------------------End Referenced Policy Letter--------------------