From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,42b8b2c27439b7d0 X-Google-Attributes: gid103376,public From: Tucker Taft Subject: Re: obsolete ascii? (for language lawyers) Date: 1999/07/08 Message-ID: <3784CD8A.E180D772@averstar.com>#1/1 X-Deja-AN: 498703020 Content-Transfer-Encoding: 7bit Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.burl.averstar.com References: <7las7v$5p0$1@infosun2.rus.uni-stuttgart.de> <7lhqs9$9c$1@infosun2.rus.uni-stuttgart.de> <7ljde7$o4j$1@nnrp1.deja.com> <7llqr8$cre$1@nnrp1.deja.com> Content-Type: text/plain; charset=us-ascii Organization: AverStar (formerly Intermetrics) Burlington, MA USA Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-07-08T00:00:00+00:00 List-Id: Keith Thompson wrote: > > Robert Dewar writes: > > In article , > > Keith Thompson wrote: > > > > > more important reason, however, is to let people know that > > > there's a newer, better way to do the same thing. These are > > > features that are in the language *only* to support legacy > > > code; if the language were being designed from scratch today, > > > they wouldn't be there. > > > > No, you cannot conclude any of the above. All you can conclude > > is that certain people and in particular the design team, > > thought that some of the above were true. > > > > Those of us who disagreed in some cases did not argue strongly, > > because, at least speaking for myself, I did not care if > > features ended up in annex J or not. > > Ok, I was making some (possibly invalid) assumptions. I wasn't > closely involved in the design process, so everything I say here is > merely my opinion. In fact, feel free to assume that anything I say > anywhere is merely my opinion. > > Note that I tend to be prejudiced in favor of clean, coherent design > over backwards compatibility. I recognize the need for backwards > compatibility, but I tend to grit my teeth a bit when I see features > that seem to exist only for that reason. I don't expect everyone to > share this prejudice. For what it is worth, I tend to agree with Keith's view more than Robert's here. The point of Annex J was to remove from the main part of the manual the constructs of Ada 83 which were *perceived by the design team* as being marginal or redundant in the context of Ada 95. The goal was to present a (slightly ;-) simpler language, by moving these marginal/redundant features out of the main stream of the discussion. Of course, the manual is still daunting, and Robert will be happy to point out that the Ada 83 manual was significantly more readable (warts and all ;-). But if you want to know the design team's intent, it was along the lines of what Keith has said -- avoid talking about things that are only there for supporting legacy code, so that a new user of Ada encountering the Ada 95 manual has a few less things to worry about. Clearly, not all the Ada 9X reviewers had the same perception of Annex J. > -- > Keith Thompson (The_Other_Keith) kst@cts.com > San Diego Supercomputer Center <*> > One of the great tragedies of ancient history is that Helen of Troy > lived before the invention of the champagne bottle. -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA