From: eachus@oddjob.mitre.org (Robert I. Eachus)
Newsgroups: comp.lang.ada
Subject: Extending Ada
Date: 17 Dec 92 02:06:43 GMT
Organization: The Mitre Corp., Bedford, MA.


    Mike Feldman send me some questions via e-mail, and I asked his
permission to post the answers here, because this is a common area of
misunderstanding.  There are lots of active projects to extend Ada in
various directions, and one intent of the validation process is to
control but not impede Ada extensions.  In particular, if an extension
can be accomplished by a package, that is better than an
implementation defined pragma, etc.

   Mike asked:

  > Can a compiler that does XYZ, where XYZ is NOT an Ada9X feature, and
  > where XYZ adds syntax (new keywords, whatever) get validated? If so,
  > that's a rather large change that should be better understood. I
  > keep thinking back to the early ACVC's that looked hard for all the
  > keywords from other languages to make sure that an Ada compiler was
  > not a JOVIAL Trojan Horse.

   The ACVC tests still look for all those keywords, and there is a
significant recent change in the interpretation of the rules, but
neither has anything to do with what I am saying.  It has always been
the case that only unauthorized extensions are prohibited, and some
classes of extensions (such as built-in preprocessors) are explicitly
permitted.  For example some of the SQL bindings add new keywords and
syntax.  The two OO Ada products out there add new keywords and syntax
and they've been around for a while.  (Why are they acceptable as
"Ada" in greater or lesser degree?  Because there is a well defined
mapping from the extended language to Ada, whether or not they are
implemented as preprocessors, compiler switches or what have you.)
All the battle about SQL bindings has been about how much violence a
binding does to the Ada style, not about which adds more keywords.

  > Hmmm. Are we turning 1815-B into a permissive standard in the nature of
  > the Fortran or Pascal standards, which lead to unending feature wars?
  > Sheesh - I hope not! If not, then I'm really having trouble catching
  > your meaning in the above paragraph.

   No, non, nein, nyet!  If vendor Y provides package Z with an Ada
interface, users can judge for themselves how much lock-in they are
buying into.  If you use STARLAN heavily, lots of luck porting off a
VAX.  The same applies for many other vendor supplied OS interfaces.
The fact that implementation of the bodies of these packages may or
may not be possible in Ada is totally irrelevant.  This is the
preferred method of extending Ada compilers, every vendor does it, and
no one complains.  Similar things can be said about vendor supplied
pragmas.  But since the culture is very much to only use
implementation defined pragmas when forced to, the vendors do not
compete in adding new and better pragmas.

   It is possible to go much further as described above, but most
vendors will only do such things at a customer's special request,
because they otherwise gain little or no market advantage.  The
exceptions so far have been SQL interfaces, OO extensions, tailorable
run-times and priority inheritance for hard real time scheduling.
(Oh, and some vendors provide a C-style preprocessor.) So to say
extensions are verbotten totally misrepresents the reality.

   Another better example is the issue of foreign language keywords
(and comments).  There has always been a recognition that an Ada
compiler with a mode which accepted Sanskrit keywords would be
perfectly acceptable and validatable, but vendors have found no
requirements for such products.  (Other localization requirements,
such as local character sets in comments are a different story.)

   If you look at what is in Ada 9X, the need for most of those
extensions outside the standard (and many of the vendor supplied
packages) will be replaced by support of Ada 9X annexes, so I would
say that we do have a fairly nice model to point to.  But if someone
tried to sell an Ada compiler that accepted "B = A++;" they would get
slapped around pretty hard by the validation people and the customer
base as well.  (This probably comes under the Supreme Court position
on obscenity, was it Justice Frankfurter that wrote it?  "I can't
define obscenity, but I know it when I see it.")

  > This was certainly true of the guy in question. But if "extensions"
  > are allowed, how will we prevent the dialect problem? (Note: I am NOT
  > referring to annexes here.) What kind of extensions? Who rules on
  > "legitimacy"?

   The dialect problem will exist in Ada 9X and the annexes are an
attempt to limit it to a few dialects, but no one thinks it can be
prevented altogether.  The information systems projects and signal
processing projects I work with use vastly different styles of Ada,
different compilers, different operating systems, and different
processor architectures.  However they are all written Ada, and I can
move back and forth without culture shock (and in some cases use the
same tools).  We want to preserve that easy migration of people and
tools, while recognizing that there may never be a compiler with all
the bells and whistles for all markets.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...