NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/lang/ada/3663

Text File | 1992-12-14 | 5.6 KB | 118 lines

Newsgroups: comp.lang.ada
Path: sparky!uunet!walter!att-out!pacbell.com!sgiblab!zaphod.mps.ohio-state.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!mccall
From: [e-mail] (fred j mccall 575-3539)
Subject: Re: Open Systems closed to Ada?
Message-ID: <[e-mail]>
Organization: Texas Instruments Inc
References: <[e-mail]> <[e-mail]>     <[e-mail]>     <[e-mail]>     <[e-mail]> <[e-mail]>
Date: Mon, 14 Dec 1992 17:21:00 GMT
Lines: 107

In <[e-mail]> [e-mail] (Robert I. Eachus) writes:


>    I'm not going to quote any of Fred McCall's broken record,
>especially since most of it just ain't so.

Disproof by assertion.  Lovely.

>The DoD mandate says use
>a validated Ada compiler.  The validation rules go on to say what
>validation of an Ada compiler means.  It has never meant, and never
>will mean strict conformance to a particular standard.  (Godel proved
>that impossible quite a while ago.)  Validation sets a standard of
>quality, and provides a process for determining whether a particular
>deviation from the ACVC tests can be justified.

No, what it means is that you have to pass the validation suite.  This
means, in essence, no significant extensions to the language.

>    In particular if a compiler vendor has an Ada compiler which
>includes some Ada 9X features, or adds support for rate-monotonic
>scheduling or what have you, it is not automatically rejected.
>Instead, any deviations are evaluated to determine if the vendor's
>justification is in fact acceptable.

Then it's rejected. ;-)

Seriously, do you honestly believe that if someone had come up with an
Ada compiler that allowed multiple inheritance, etc., in 1986, that it
would have been validate?  *I* don't.

>    In practice the ARG acts as a court of last resort in such cases.
>If the fast reaction team (FRT) or the ARG feels that an issue needs
>further discussion, the validation certificate in question is issued,
>and the test in question is withdrawn if necessary until the issue is
>resolved.  Starting with ACVC 2.0, this process will be further
>streamlined to encourage vendors to offer such (legitimate)
>extensions, and also to allow vendors to release new technology
>sooner.

And just what constitutes an 'illegitimate' extension and how do you
decide?  What about a compiler whose default behaviour matches the
standard (and passes the validation suite) but which has switches that
turn on and off various features.  Would you validate it or not?

>    There have been cases where some members felt this was used by one
>vendor or another as a sort of sneaky loophole, but others didn't.  In
>this case the rule is effectively innocent unless unanimously found
>guilty.  In other cases--even though the test was correct and the
>compiler was wrong--a test was withdrawn because the ARG felt it was
>counterproductive.  We even have a class of AI called pathology,
>informally defined as "we'll tell the vendors what they should do, but
>no user, and especially no ACVC test, should expect it to work that
>way."

>     So validation and the Ada mandate are NOT intended to stiffle
>innovation or limit creativity.

Of course they're not INTENDED to do that.  Hell, nobody sets out to
DELIBERATELY prevent progress.

>They are intended to insure that long
>lived source code is still useable ten years from now, without a lot
>of support costs.

It is one thing to say what the language should do and test for that
insofar as comiling working code.  The problem is that in a lot of
cases extensions to the compiler that permit it to accept certain
constructs that are 'not Ada' is enough to prevent validation (unless
they've changed the rules considerably).  That's hardly necessary to
keep working code working, now is it?  After all, if the code wasn't
'broken' originally, it won't be broken in the future.  Of course,
USING one of those extensions can lead to code that breaks on a
compiler that doesn't support them (presumably the reason why getting
compilers with extensions through validation is tough), but what about
pragmas?  One compiler could offer a pragma that another doesn't
support, and when you change compilers code is going to break.  So
just what have you accomplished, other than discouraging innovation?

>You don't like that, play in another sandbox.

I don't like it.  I think it's a bad idea.  I will continue to say
that I think it's a bad idea.  If you don't like that, go to a country
where the government is allowed to prevent people from saying what
they think.

>I
>can find you companies which mandate FORTRAN, C, C++, COBOL, and LISP,
>but you probably wouldn't be happy with any of them.

Well, goody goody for you.  I certainly hope those companies are
working in a field for which that mandated language is well suited;
otherwise they're doing the same silly thing that the govenrment does.

>The company
>policy is there for the same reason as the DoD policy, and your
>difficulty seems to involve having rules to enforce software
>engineering standards.

Well, I don't feel particularly responsible for how things "SEEM" to
you.  The problem would appear to be with your perceptions.

--
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
[e-mail] - I don't speak for others and they don't speak for me.