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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9ae4660d46953150,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2000-09-12 10:56:03 PST Path: supernews.google.com!sn-xit-02!sn-xit-03!supernews.com!dispose.news.demon.net!demon!news.demon.co.uk!demon!norvu.demon.co.uk!ntlworld.com!MPickett From: Michael Pickett Newsgroups: comp.lang.ada Subject: Enhancement needed (was strange record size ?) Date: Tue, 12 Sep 2000 13:51:22 +0100 Organization: Norvu Message-ID: <0$9CsHAKbiv5Ewg1@ntlworld.com> NNTP-Posting-Host: norvu.demon.co.uk X-NNTP-Posting-Host: norvu.demon.co.uk:158.152.205.227 X-Trace: news.demon.co.uk 968781301 nnrp-03:18230 NO-IDENT norvu.demon.co.uk:158.152.205.227 X-Complaints-To: abuse@demon.net MIME-Version: 1.0 X-Newsreader: Turnpike Integrated Version 4.02 U Xref: supernews.google.com comp.lang.ada:608 Date: 2000-09-12T13:51:22+01:00 List-Id: At Robert Dewar's request, this thread has been moved from chat@gnat.com to CLA on the grounds that it had ceased to be GNAT-specific. The thread originated when a poster noted that GNAT and another compiler adopted different record sizes, and that the other compiler's strategy served the poster's purposes better. Robert pointed out that GNAT followed the Implementation Advice in the RM in respect of the effects of trying to set the Size attribute, whereas the other compiler appeared not to. There was a protracted exchange involving many posters, and it seems that the original requirement can be met, albeit not in the non- portable way that had been assumed by the poster. If, through this summary, I have in any way misrepresented anyone or anything that transpired in this thread, I humbly apologise. Feeling that GNAT had been somewhat unfairly criticised in the discussion, and being ever ready to jump on to a bandwagon, I added a further comment to the thread, part of which Robert has included at the head of yet a further comment which I have reproduced below. My intention in commenting earlier was to encourage contributions to the further development and improvement of the language where a programmer had identified a deficiency. Robert may have misunderstood my intentions, for, although I can find no fault in what he writes, he does not appear to agree with what I wrote. :-( Therefore, let me set out a few bullet points which I hope will clarify what I have to say, and then we can pull those to bits also, in due course. :-) * Ada is not perfect. It is not yet at the end of its life as far as development is concerned. Although the current five year review of the ISO Standard is not going to give us an Ada 2000 (we are going to get a Technical Corrigendum to tidy up a few points) we are already looking towards a possible Ada 2005. If anyone has identified genuine (or even merely perceived) deficiencies in the language, please would they bring these to the attention of the language maintenance team rather than risk undermining Ada's reputation or perhaps the reputations of its implementors. * If there is some perfectly reasonable effect that cannot be achieved in a portable way, (subject to limitations imposed by context and environment,) that may well be considered to be a language deficiency. * Implementation Advice is a useful mechanism for persuading an implementor to adopt (or avoid) a particular approach where it would be inappropriate to introduce a normative clause. (Unfortunately, the Standard does not provide any background on what qualifies a clause to be a recommendation rather than a requirement.) * A programmer should not need to rely on the use of non-portable code. I have interspersed a few comments in Robert's text. Note that I believe the original poster's problem has been resolved satisfactorily from everyone's point of view. This posting does not address that issue, and hence the change in title. In message <20000911122532.7E0E734D80@nile.gnat.com>, Robert Dewar writes ><<<perfectly reasonable effect in Ada is to rely on Implementation Advice >being taken or not taken, or on some other permitted implementation >choice, then that is a weakness in the Ada Standard and should be >reported to the language maintenance team. It is not a reason in itself >for criticising the particular choice made by the compiler implementor, >although it may be one of the factors which determines whether or not >the compiler in question is suitable. >>> >>> > >THe IA in this case says that size clauses should not have a certain effect. >The issue is not one of relying on this, but rather the inversion, the >suggestion here was that (a) compilers should ignore this advice and >(b) it is reasonable for programs to *rely* on compilers NOT following >the implementatoin advice, and that (c) compilers that DO follow the >implementation advice are therefore somehow irritiating :-) > >So the above para is not really applicable in this case. But I did say "rely on Implementation Advice being taken or NOT taken," so I think it /is/ applicable. I do agree with your analysis of what was said, though. > >However, it is in fact, though very reasonable sounding, not correct. There >are many many situations in which a program must rely on things that are >NOT in the standard, and could NOT be in the standard. I'm sure you are right. I'm only interested in "things that are NOT in the standard" but OUGHT to be. I was not speaking against the use of Implementation Advice. Please don't think I want to over-specify the language; there are already people who think it is over-specified, (well, over-restricted, really) and I don't want to fuel too much of that sort of thing. > >For example, when you write > > a := A + B; > >you realy on the fact that the compiler will generate some kind of add >instruction, but a compiler that called a recursive routine that worked >something like > > function "+" (A,B : Integer) is > begin > if B = 0 then > return A; > elsif B > 0 then > return (Integer'Succ (A) + Integer'Pred (B)); > else > return (Integer'Pred (A) + Integer'Succ (B)); > end if; > end; > >would of course conform to the RM, and we have no way AT ALL to prohibit >this ludicrous code. If we thought there was a problem, we could add >implementatoin advice, but in this case, we don't bother, since we >don't think the above is realistic. I agree. But equally I would not like to see that it was only Implementation Advice that recommended that A + B should result in the sum of the two quantities. :-) > >IA is used in cases where we cannot make normative requirements because > >either > >a) the issue is target dependent I have no problem with that. > >or > >b) it involves issues which are not within reach of the semantic framework >of the RM. In other words, if some of the IA paragraphs were made normative >requirements, they would be semantically vacuous and there fore useless. Sorry, Robert. That's a bit grand for me. If you could quote some specific examples, I might understand, but from looking at a few, I conclude that they simply seem to be sensible (and useful) ways of doing things. Still, anyone who relies on a particular IA being followed or else not followed is treading in the area of non-portability. But that's a problem they should recognise. > >We allow ourselves much more freedom in specifying IA than requirements. > >Take the Size issue at hand, obviously the normative text cannot prohibit >the size clause from rearranging internal layouts, because it would be >quite valid to determine the internal layout by tossing a coin, or >consulting astrological charts. So this is only advice, but it is good >advice, and useful for a programmer. Unless, it would seem, that programmer wants portability, in which case the programmer should rely on something which is normative, and not on something which is just Implementation Advice. We agree that Implementation Advice is for things which cannot be normative. Relying on things which are not normative is taking a risk, even though it may be a calculated risk. > >(finally some GNAT relevance) > >THat's why in GNAT, with very rare exceptions, which we document along >with the reasons for the discrepancies, we consider IA to be as governing >as normative requirements, and other vendors generally take the same >attitude in the Ada 95 world. That should be good news for everyone. > >And now I think followups definitely SHOULD go to CLA :-) and it was so. -- Michael Pickett Ada@norvu.demon.co.uk