home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!spool.mu.edu!agate!linus!linus.mitre.org!linus!mbunix!eachus
- From: eachus@oddjob.mitre.org (Robert I. Eachus)
- Newsgroups: comp.lang.ada
- Subject: Extending Ada
- Message-ID: <EACHUS.92Dec16210643@oddjob.mitre.org>
- Date: 17 Dec 92 02:06:43 GMT
- Sender: news@linus.mitre.org (News Service)
- Organization: The Mitre Corp., Bedford, MA.
- Lines: 98
- Nntp-Posting-Host: oddjob.mitre.org
-
-
- 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...
-