Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation)

[heatwole@his.com (Kevin D. Heatwole)]

In article <dewar.845091423@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>"Gee, I thought the Annexes were OPTIONAL components of validated
compilers, not
>that compilers without the
>annexes were SUBSET(!!!) (implied "NOT REALLY FULL Ada 95") compilers."
>
>  Of course it is definitely the case that the annexes are optional, in the
>  same sense that the optional modules of COBOL, e.g. the Report Generator,
>  are optional. So a compiler that does not implement all the features
>  of the language is still meeting the conformance requirements, just as
>  would be the case with COBOL. No one is saying that such an implementation
>  is not a valid Ada 95 implementation.
>
>  By subset, I simply meant a subset of the full language capabilities in the
>  RM. There is nothing wrong with subsetting the language by leaving out the
>  annexes if the application does not need the full language! I would 
>  certainly think that most people would think that "full language" meant
>  everything in the RM, but you can use any term any way you want! Certainly
>  for us, full language *does* mean all the capabilities in the RM.
>

Well, I have used all the Ada95 compilers (or have talked to people who have)
and I got to say that this whole discussion is a bit irrelevant at this point.
There simply is no Ada95 compiler that implements all the core requirements
of the language, let alone worrying about whether the optional annexes are
optional.  GNAT certainly fails to compile many legal Ada95 programs and 
allows many other illegal programs (I run into this just about every day now 
since people are porting code written with GNAT to our PowerAda compiler).  
I don't mean to pick on GNAT here since all of the compilers are in the same 
boat here.

I would expect this situation to continue for a year or so until the current
compilers mature and get the bugs shaken out.  The question for end users
to decide now is not whether they require the "full language" (because if
this is the requirement, they are left with no options), but whether the
compiler is mature enough and implements enough of the language to meet
their needs.

During this period of transition to Ada95 from Ada83, I would expect that
it is, by far, more important to have a close working relationship with your
vendor than whether the vendor claims to have implemented the "full language".

By the way, for those not familar with the current validation process, the
US government requires that compiler vendors demonstrate compliance to
a set of minimum requirements for compilers sold to the government.  This
compliance is demonstrated for Ada95 by running a suite of tests called the
ACVC tests.  Just like the Ada compilers it tests, this test suite is currently
in the process of evolving/maturing.  The first version of this test suite for 
Ada95 compilers was called ACVC 2.0 and compiler vendors
started validating their compilers under this test suite late last year 
(OC Systems validated our PowerAda compiler in December).  This test
suite did not require a compiler to pass all the tests in the suite.  In
fact, any validate-able Ada83 compiler could be validated with ACVC 2.0
without having to implement a single Ada95 feature.  Most vendors chose
to validate by passing all the applicable core language tests, but one vendor
chose not to run any of the tests that use Ada95 features.  Also, the ACVC 2.0 
test suite isn't a very complete test suite for testing Ada95 features.

Early this year, an incremental version of ACVC 2.0 went into place for 
vendors validating new Ada95 compilers on new platforms.  This version is 
called ACVC 2.0.1.  ACVC 2.0.1 didn't add any new tests to the test suite but 
did fix the bugs in the existing ACVC 2.0 test suite for tests that had been 
withdrawn from ACVC 2.0.  One important policy change for this test suite
is that Ada95 compilers validating under this test suite now have to pass 
a few Ada95 tests to be validated (an Ada95 compiler must now pass either
the OOP tests or the Real-Time tests).

The "real" Ada95 validation suite will go into place for the 2nd quarter of 
1997 with the arrival of ACVC 2.1.  This test suite is still being developed, 
but it should contain tests for almost all testable features of Ada95 (of 
any consequence).  Vendors will have to demonstrate compliance to all core
requirements of the Ada95 language in order to get a validation certificate.
Compliance to the optional Ada95 annexes will also be optionally tested.
Passing this test suite will be a real accomplishment for Ada95 compilers.
Users can be assured that Ada95 compilers that have been validated under
ACVC 2.1 are reasonably complete.

So, during this transition period, I would be very careful about relying on
claims of "validated Ada95" or "full language support".  These claims are
largely "marketing hype".  Users will have to do their own research or
evaluation testing to determine whether a particular compiler is mature 
enough and implements enough of the Ada95 language for their own 
particular needs.   Fortunately, many of the current Ada95 compilers are
quite useable now, even if they don't support the "full language".

Speaking for myself,

Kevin Heatwole
OC Systems, Inc.