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,ea4f04ec8d41f5b7 X-Google-Attributes: gid103376,public From: Joe Gwinn Subject: Re: Ada83 equivalents for Ada95 Date: 1996/05/24 Message-ID: <31A66DAA.7418@sud.ed.ray.com>#1/1 X-Deja-AN: 156629621 x-disclaimer: This is the author's opinion and not that of Raytheon Company. references: <31927190.35AA@csehp3.mdc.com> x-authentication-warning: The author was not authenticated. content-type: text/plain; charset=us-ascii organization: Raytheon Electronic Systems mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.0 (Macintosh; I; PPC) Date: 1996-05-24T00:00:00+00:00 List-Id: We have the Ada83 versus Ada95 problem as well. In short, we plan to use the Ada83 subset of Ada95, so that in some future, we will be able to transition to Ada95, should the customer so desire. This will happen, if at all, long after the present project is complete. We are avoiding Ada95 for now, because we couldn't find sufficiently mature compilers, tools, runtimes, for our targets, and Ada83 is sufficient. If Ada83 is any guide, it will be three years before Ada95 reaches anything like Ada83's present level of maturity. Ada83 took more like six years, but started from scratch. The Ada95 standard defines this Ada83 subset, by what it doesn't mention as having been broken by Ada95. Joe Gwinn