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,794a4cb8f6cfe39b X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Clear Screen Date: 1997/03/01 Message-ID: #1/1 X-Deja-AN: 222450361 References: <330FE569.29FA@bix.com> <5erk3a$a29@news.cict.fr> <5f15dg$an@fozzie.sun3.iaf.nl> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-03-01T00:00:00+00:00 List-Id: Robert Eachus said <<(And I lost on one in the formal vote--pragma Elaborate--but won later when the Development Team actually checked out the issue. My guess is that in about 30% of the cases where pragma Elaborate actually needed, it can't be replaced by Elaborate_Body or Elaborate_All. But I suspect the real reason it was left in Chapter 10 was that it only requires a few words there. ;-) >> Rober notes The history here is that we found it was impossible to build the GNAT runtime without the use of pragma Elaborate. I investigated carefully, and sent the exact examples into the vr list, and when we looked into them they were indeed reasonable. Nevertheless the estimate of 30% is *way* too high. This is not a guess it is based on actual observations of the number of times that pragma Elaborate is used, and could be replaced by Elaborate_All in the GNAT test suite. Robert Eachus said <> That's exactly what people said about ALTER in the context of the COBOL 74 standard (they were sure it would be removed next time around). People who make such statements greatly underestimate the force of compatibility arguments from legacy code. I will bet anyone who cares to take the bet that none of the Annex J features will disappear from the next version of Ada. I note in advance that of course I will argue against their removal regardless of whether anyone takes up this bet. We are talking about a couple of minor features here that are trivial to implement. It is inconceivable to me that the designers of the next version of Ada would introduce gratuitious non-upwards compatibilities by trying to remove them!