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,c9ae958322362a4d X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Ada Common Environment (ACE) Date: 1996/07/18 Message-ID: #1/1 X-Deja-AN: 169692741 references: <2.2.32.19960718155145.00ef64a8@mail.cts.com> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-07-18T00:00:00+00:00 List-Id: Robert Leif said "This sounds very good. I believe that ACE will be very useful. However, it still would make sense to be able to formally include ACE, ASIS, and other standards in Ada as Annexes in less than 11 or so years before the next language revision." Appropriate items can perfectly well be standardized independent of the RM, as for example the numerics were for Ada 83. By the way, you misunderstand ACE completely if you think of it as being anything *like* a standard that could be standardized at the ISO level. It is much more informal than this, and the whole idea is to agree on a level of commonality that will be useful without going through the standardization process. For example, it would take years to standardize a binding to X, and for sure the existing Intermetrics binding would require extensive changes before it could be accepted as an ISO standard, especially when X itself is not standardized. On the other hand, placing this binding in ACE is immediately useful, and can be done without the long wait or the long term instability. What ACE achieves in this case is the gauarantee that conforming compilers can compile and execute the binding, but ACE (unlike a standards organization) does not need to ensure that the design of this binding is absolutely correct and appropriate. Robert Dewar Ada Core Technologies