home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / ada / 3727 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  5.5 KB

  1. Path: sparky!uunet!olivea!spool.mu.edu!agate!linus!linus.mitre.org!linus!mbunix!eachus
  2. From: eachus@oddjob.mitre.org (Robert I. Eachus)
  3. Newsgroups: comp.lang.ada
  4. Subject: Extending Ada
  5. Message-ID: <EACHUS.92Dec16210643@oddjob.mitre.org>
  6. Date: 17 Dec 92 02:06:43 GMT
  7. Sender: news@linus.mitre.org (News Service)
  8. Organization: The Mitre Corp., Bedford, MA.
  9. Lines: 98
  10. Nntp-Posting-Host: oddjob.mitre.org
  11.  
  12.  
  13.     Mike Feldman send me some questions via e-mail, and I asked his
  14. permission to post the answers here, because this is a common area of
  15. misunderstanding.  There are lots of active projects to extend Ada in
  16. various directions, and one intent of the validation process is to
  17. control but not impede Ada extensions.  In particular, if an extension
  18. can be accomplished by a package, that is better than an
  19. implementation defined pragma, etc.
  20.  
  21.    Mike asked:
  22.  
  23.   > Can a compiler that does XYZ, where XYZ is NOT an Ada9X feature, and
  24.   > where XYZ adds syntax (new keywords, whatever) get validated? If so,
  25.   > that's a rather large change that should be better understood. I
  26.   > keep thinking back to the early ACVC's that looked hard for all the
  27.   > keywords from other languages to make sure that an Ada compiler was
  28.   > not a JOVIAL Trojan Horse.
  29.  
  30.    The ACVC tests still look for all those keywords, and there is a
  31. significant recent change in the interpretation of the rules, but
  32. neither has anything to do with what I am saying.  It has always been
  33. the case that only unauthorized extensions are prohibited, and some
  34. classes of extensions (such as built-in preprocessors) are explicitly
  35. permitted.  For example some of the SQL bindings add new keywords and
  36. syntax.  The two OO Ada products out there add new keywords and syntax
  37. and they've been around for a while.  (Why are they acceptable as
  38. "Ada" in greater or lesser degree?  Because there is a well defined
  39. mapping from the extended language to Ada, whether or not they are
  40. implemented as preprocessors, compiler switches or what have you.)
  41. All the battle about SQL bindings has been about how much violence a
  42. binding does to the Ada style, not about which adds more keywords.
  43.  
  44.   > Hmmm. Are we turning 1815-B into a permissive standard in the nature of
  45.   > the Fortran or Pascal standards, which lead to unending feature wars?
  46.   > Sheesh - I hope not! If not, then I'm really having trouble catching
  47.   > your meaning in the above paragraph.
  48.  
  49.    No, non, nein, nyet!  If vendor Y provides package Z with an Ada
  50. interface, users can judge for themselves how much lock-in they are
  51. buying into.  If you use STARLAN heavily, lots of luck porting off a
  52. VAX.  The same applies for many other vendor supplied OS interfaces.
  53. The fact that implementation of the bodies of these packages may or
  54. may not be possible in Ada is totally irrelevant.  This is the
  55. preferred method of extending Ada compilers, every vendor does it, and
  56. no one complains.  Similar things can be said about vendor supplied
  57. pragmas.  But since the culture is very much to only use
  58. implementation defined pragmas when forced to, the vendors do not
  59. compete in adding new and better pragmas.
  60.  
  61.    It is possible to go much further as described above, but most
  62. vendors will only do such things at a customer's special request,
  63. because they otherwise gain little or no market advantage.  The
  64. exceptions so far have been SQL interfaces, OO extensions, tailorable
  65. run-times and priority inheritance for hard real time scheduling.
  66. (Oh, and some vendors provide a C-style preprocessor.) So to say
  67. extensions are verbotten totally misrepresents the reality.
  68.  
  69.    Another better example is the issue of foreign language keywords
  70. (and comments).  There has always been a recognition that an Ada
  71. compiler with a mode which accepted Sanskrit keywords would be
  72. perfectly acceptable and validatable, but vendors have found no
  73. requirements for such products.  (Other localization requirements,
  74. such as local character sets in comments are a different story.)
  75.  
  76.    If you look at what is in Ada 9X, the need for most of those
  77. extensions outside the standard (and many of the vendor supplied
  78. packages) will be replaced by support of Ada 9X annexes, so I would
  79. say that we do have a fairly nice model to point to.  But if someone
  80. tried to sell an Ada compiler that accepted "B = A++;" they would get
  81. slapped around pretty hard by the validation people and the customer
  82. base as well.  (This probably comes under the Supreme Court position
  83. on obscenity, was it Justice Frankfurter that wrote it?  "I can't
  84. define obscenity, but I know it when I see it.")
  85.  
  86.   > This was certainly true of the guy in question. But if "extensions"
  87.   > are allowed, how will we prevent the dialect problem? (Note: I am NOT
  88.   > referring to annexes here.) What kind of extensions? Who rules on
  89.   > "legitimacy"?
  90.  
  91.    The dialect problem will exist in Ada 9X and the annexes are an
  92. attempt to limit it to a few dialects, but no one thinks it can be
  93. prevented altogether.  The information systems projects and signal
  94. processing projects I work with use vastly different styles of Ada,
  95. different compilers, different operating systems, and different
  96. processor architectures.  However they are all written Ada, and I can
  97. move back and forth without culture shock (and in some cases use the
  98. same tools).  We want to preserve that easy migration of people and
  99. tools, while recognizing that there may never be a compiler with all
  100. the bells and whistles for all markets.
  101.  
  102.  
  103. --
  104.  
  105.                     Robert I. Eachus
  106.  
  107. with Standard_Disclaimer;
  108. use  Standard_Disclaimer;
  109. function Message (Text: in Clever_Ideas) return Better_Ideas is...
  110.