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 07:49:28 PST
Path: archiver1.google.com!postnews1.google.com!not-for-mail
From: dewar@gnat.com (Robert Dewar)
Newsgroups: comp.lang.ada
Subject: Re: Attributes 'Version and 'Body_Version
Date: 28 Nov 2001 07:49:27 -0800
Organization: http://groups.google.com/
Message-ID: <5ee5b646.0111280749.77fabe6c@posting.google.com>
References: <9s9iti$g$1@nh.pace.co.uk> <yec3d3nij4r.fsf@king.cts.com>
 <5ee5b646.0111121351.27897bc4@posting.google.com>
 <yecsnbjdrh0.fsf@king.cts.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>
 <YsaTZ19cOfHh@eisner.encompasserve.org>
NNTP-Posting-Host: 205.232.38.14
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1006962568 6768 127.0.0.1 (28 Nov 2001 15:49:28
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: 28 Nov 2001 15:49:28 GMT
Xref: archiver1.google.com comp.lang.ada:17108
Date: 2001-11-28T15:49:28+00:00
List-Id: <comp.lang.ada>

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<YsaTZ19cOfHh@eisner.encompasserve.org>...
> But when followed it does not do a whole lot to prevent 
> current implementation-defined pragmas from conflicting 
> with the names of future language-define pragmas. 

Sure, there is always a problem in using any vendor defined
attributes or pragmas that might be redefined by the 
standard later. But in practice this has been a negligible
problem in the past, and I see no reason to think the
future will be different.

> 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.

I see no practical issue here, only a theoretical issue
that in practice is of minimal concern.

> 
> > 14   An implementation may provide implementation-defined pragmas; the
> > name of an implementation-defined pragma shall differ from those of
> > the language-defined pragmas.