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,5894fe67040038b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-28 08:53:51 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!out.nntp.be!propagator-SanJose!in.nntp.be!news-in-sanjose!newsfeed.onecall.net!chcgil2-snf1.gtei.net!news.gtei.net!news.binc.net!kilgallen From: Kilgallen@SpamCop.net (Larry Kilgallen) Newsgroups: comp.lang.ada Subject: Re: Attributes 'Version and 'Body_Version Date: 28 Nov 2001 10:53:45 -0600 Organization: Berbee Information Networks Corporation Message-ID: References: <9s9iti$g$1@nh.pace.co.uk> <5ee5b646.0111121351.27897bc4@posting.google.com> <9trpj1$4e6v2$1@ID-25716.news.dfncis.de> <5ee5b646.0111251830.61aaa6be@posting.google.com> <9tsd63$4jjng$1@ID-25716.news.dfncis.de> <5ee5b646.0111260742.2a0d9357@posting.google.com> <9tu7nj$4v9lc$1@ID-25716.news.dfncis.de> <5ee5b646.0111261956.3df9b8e3@posting.google.com> <5ee5b646.0111280749.77fabe6c@posting.google.coOrganization: LJK Software NNTP-Posting-Host: eisner.encompasserve.org X-Trace: grandcanyon.binc.net 1006966426 17947 192.135.80.34 (28 Nov 2001 16:53:46 GMT) X-Complaints-To: abuse@binc.net NNTP-Posting-Date: Wed, 28 Nov 2001 16:53:46 +0000 (UTC) Xref: archiver1.google.com comp.lang.ada:17112 Date: 2001-11-28T10:53:45-06:00 List-Id: In article <5ee5b646.0111280749.77fabe6c@posting.google.com>, dewar@gnat.com (Robert Dewar) writes: > Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:... >> Was the thought that the set of Ada compiler vendors >> will always be so small that such issues can be worked >> out informally ? > > Not particularly, though this is in practice true. The real > point is that if you use implementation defined attributes > and pragmas, you are making your code incompatible with > other compilers, and that might include compilers for some > new version of Ada, but in any case that means no more than > that going to a new version of Ada might be as difficult as > moving to another vendors compiler for the current version > of Ada, and we have always used this distance comparison > as a measure of acceptable levels of incompatibility with > new versions. But going to a newer version of the same vendor's compiler is something programmers expect to be effortless. If that vendor implements a new language-defined attribute rather than its former implementation-defined attribute which had the same name, the expectation might not be realized. > I see no practical issue here, only a theoretical issue > that in practice is of minimal concern. The sort of approach I would have expected would be a division of the namespace. VMS linker (and other) namespace segregation is done with a dollar sign. Not that a dollar sign is appropriate for Ada, but I would expect some area set aside into which the language-defined attributes will not trespass in the future.