Attributes 'Version and 'Body_Version

Attributes 'Version and 'Body_Version

[Marin David Condic]

On my way to playing around with something else, I started looking at the
results of the attributes 'Version and 'Body_Version with Gnat 3.13p on
WinNT. They appear to be intended for distributed systems, but could
potentially be useful within any system that uses someone's library of
stuff - a means of verifying that any assumed behavior from a given version
is still valid. Or, for example, a means of recording the version of a
package that produced some particular output so that on input, version
differences can be accommodated.

Looking at the strings from a particular package (a generic instantiatiation
at that) I see a pair of strings that look like: "2daafe2a" (spec)
"21adf138" (body) I didn't encounter anything in the ARM indicating what the
format of the string should be nor did I see anything in the GNAT documents
that explained how to interpret the string. Obviously, this is going to be
system dependent, but if you want to do anything more than say "This version
isn't the one I remember" you need to know how to interpret the string. Has
anybody used this before and possibly have some insight? Thanks.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Attributes 'Version and 'Body_Version

[Robert Dewar]

"Marin David Condic" 


 want to do anything more than say "This version
> isn't the one I remember" you need to know how to interpret the string.

What in the RM gives you the slightest idea that you
can expect to do anything more than compare two version
numbers?

Re: Attributes 'Version and 'Body_Version

[Marin David Condic]

I don't recall ever saying that the RM gave me the idea that I could do
anything but compare the two version numbers for equality. I think what I
said was that having discovered these strings, I might conceivably find some
use for them in identifying software versions in a manner that would be
dependent on the particular implementation - assuming one knew how those
numbers got built.

For example: Suppose you wrote a class that wants to store/load its data
to/from a file. Suppose that part of what it wrote to that file was the
version string. On reading the version string back in, it is possible for
the class to detect if it is consistent with the content of the file.
However, it might be more useful if it can detect some sequence to those
version strings so that it might be able to say "This file was created two
versions ago" or "This file was created by one version later than I am..."
and make intelligent decisions about what content to read in. I could
imagine how an implementation might have information coded in the strings
that might make it possible to determine lots of things about compatibility.
I could also imagine how some implementation defined pragmas might just be
able to add additional information to the string that might let the user
provide some compatibility information. So knowing how the strings change
and what can be detected from their content might just be useful
information - implementation dependent, but useful.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0111061939.595b61be@posting.google.com...
>
> What in the RM gives you the slightest idea that you
> can expect to do anything more than compare two version
> numbers?

Re: Attributes 'Version and 'Body_Version

[Marin David Condic]

Well, its useful enough for an application to be able to say: "I know I am
dependent on version 'LMNOP' and if the version is anything but 'LMNOP' then
I'd better take evasive action because something may not work." But if there
is some ability to determine order for the version strings, you get even
more usefulness out of it. You can then write code that can say things like
"I know that version '12345' and greater support feature X so it is O.K. for
me to use feature X." or "Versions prior to '54321' only support data items
A, B, and C, while versions between '54321' and '54323' support D, ane E,
and so now I know what I can read in and display..."

Like I said, it won't be "standard" but it still might be useful.

It might not hurt for Ada0x to insist that Something'Version and
Something'Body_Version yield a string that is increasing in sort order with
each change. That at least would let you do "<" and ">" comparisons and know
you are still portable.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Tony Gair" <tonygair@donot.spam.btinternet.com> wrote in message
news:9sbb1f$2bm$1@plutonium.btinternet.com...
> On a hopefully slightly more helpful note :-
>
> I think it is used in the Glade distrib. annex (Godinspired Labour, Design
> and Engineering)
> examples to compare versions, my interest would be in checking a client
from
> a server to
> check the version of the client.
>
> On the subject of the RM though has anyone read this ...
> The glade user guide, RM and a certain book written by John Barnes
> is far less likely to send you asleep.

Re: Attributes 'Version and 'Body_Version

[Vincent Marciante]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9sboee$42f$1@nh.pace.co.uk...
> Well, its useful enough for an application to be able to say: "I know I am
> dependent on version 'LMNOP' and if the version is anything but 'LMNOP'
then
> I'd better take evasive action because something may not work." But if
there
> is some ability to determine order for the version strings, you get even
> more usefulness out of it.

But you do know the order order of earlier versions and can store that list
in each new version othe code.  You also know that any version that was
not a past version (not in the stored list) must be a new version and can
then
deside what to do in that case (this case will only come up when a past
version of the code is attempting to work with a newer version )

Vincent Marciante

(please remove underbar remove from my email address to reply directly)

Re: Attributes 'Version and 'Body_Version

[Marin David Condic]

O.K. You can get there from here. Sort of. If you dutifully record every
version string of a released component you at least know the valid history
and you can check against it. But I still think this is not as useful.

Example:

package Somepackage is    --  Version 1.0 (my number)
    A, B, C : Integer ;
end Somepackage ;

package Somepackage is    --  Version 2.0 (my number)
    A, B, C : Integer ;
    D, E, F : Integer ;
end Somepackage ;

So assuming I know something about when features are introduced and that my
project (attempts to) maintain upward compatibility and all that, what, if
anything, might I know about Version 1.5? If I know that D, E and F were
introduced in 2.0 and my calling module detects 2.0 *or greater* then it is
O.K. to use D, E and F. If it sees a module that is *less than* 2.0, it
knows not to use D, E and F. If, for some reason, a 1.5 version were to
exist out there, I'd know by the order that it wasn't compatible.

Granted, this is a contrived example and the compiler would catch any
invalid use of D E and F (thank you, Ada.) But one can easily imagine cases
that are more complex in which an ordered version string would help.

It isn't a perfect thing and it isn't a substitute for good configuration
management and knowing what is going on with one's software, but I could
imagine situations where this might be helpful if it were ordered. You can
always Roll Your Own and this may, in some circumstances, be a better idea.
(What causes the 'Version or 'Body_Version to be incremented? Every time you
edit the file? Every time you compile it? Every time there is some semantic
difference? What if you revert to a prior version of the file? What if you
need to be compiler-independent? Etc?) The weaknesses of 'Version &
'Body_Version may make it impractical for some uses - but making it Ordinal
would probably have been a good thing. (Any reason *not* to make it
Ordinal?)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Vincent Marciante" <marciant_remove@li.net> wrote in message
news:W4fG7.11237$ym4.493547@iad-read.news.verio.net...
>
> But you do know the order order of earlier versions and can store that
list
> in each new version othe code.  You also know that any version that was
> not a past version (not in the stored list) must be a new version and can
> then
> deside what to do in that case (this case will only come up when a past
> version of the code is attempting to work with a newer version )
>

Re: Attributes 'Version and 'Body_Version

[Larry Kilgallen]

In article <9sboee$42f$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> It might not hurt for Ada0x to insist that Something'Version and
> Something'Body_Version yield a string that is increasing in sort order with
> each change. That at least would let you do "<" and ">" comparisons and know
> you are still portable.

At first glance this sounds like VMS shareable image matching
controls that are done manually, where numeric comparisons are
possible.  But the Ada feature seems to require something like
VMS shareable image matching controls that are done automatically,
and necessarily allows only equality comparisons.  I will not be
available to code the fully automatic relationship-comparing
version until I finish the required preliminary work on the
DWIM subprogram :-).

=======

Consider:

Something'*Version is required by the standard to change anytime
there is a change in a compilation unit referred to by Something.

So presume one changes both SubOne and SubTwo and then recompiles
Something.  Say the compiler takes the next logical sort ordered
value.

Then what happens if one rolls back SubTwo to what it used to be,
but retains the changed version of SubOne ?  The result we have is
_logically_ between the original and the first modification, but that might
be hard to achieve in the sort order.  Or what if we make _another_
version that has the original version of SubOne but retains the
change to SubTwo ?  How does the value of _that_ string relate
to the value of the one whose context is vice versa ?

Re: Attributes 'Version and 'Body_Version

[Tony Gair]

On a hopefully slightly more helpful note :-

I think it is used in the Glade distrib. annex (Godinspired Labour, Design
and Engineering)
examples to compare versions, my interest would be in checking a client from
a server to
check the version of the client.

On the subject of the RM though has anyone read this ...
The glade user guide, RM and a certain book written by John Barnes
is far less likely to send you asleep.
"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0111061939.595b61be@posting.google.com...
> "Marin David Condic"
>
>
>  want to do anything more than say "This version
> > isn't the one I remember" you need to know how to interpret the string.
>
> What in the RM gives you the slightest idea that you
> can expect to do anything more than compare two version
> numbers?

Re: Attributes 'Version and 'Body_Version

[Marin David Condic]

Well, as I said elsewhere, there's no substitute for formal CM and
understanding your own software. I understand the case you are describing
and I don't think I'd expect the compiler to be able to figure out that I
reverted to some prior version of a subprogram. That's a bit much to expect
from a poor, dumb compiler!

If you need that kind of version control, it seems to me you're going to
have to apply some human intelligence and Roll Your Own version numbering
scheme. I don't see the '*Version as something to take advantage of in rapid
iterations of the EditCompileLinkRun Development Methodology - but as
something you might use in conjunction with formal CM in environments where
you have possible multiple versions of a subsystem or you are using it to
control the artifacts of what a subsystem creates. (Recording version
numbers in the output from a subsystem.)

But is it a) impossible and/or b) undesirable to have the Something'*Version
increment with every compile? It might be nice to know that a unit you are
calling is a later compile or earlier compile than the one you know about
rather than the only information you have is that it is *not* the one you
know about. You still need to be able to answer the question "What can I do
about it?". You can't do much unless you know something about what changes
happened between versions. When you *do* know what the differences are, you
*might* be able to make some use of the ordering of the versions. Just an
idea that might be useful....

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:bgYJjEmY5R3$@eisner.encompasserve.org...
>
> Then what happens if one rolls back SubTwo to what it used to be,
> but retains the changed version of SubOne ?  The result we have is
> _logically_ between the original and the first modification, but that
might
> be hard to achieve in the sort order.  Or what if we make _another_
> version that has the original version of SubOne but retains the
> change to SubTwo ?  How does the value of _that_ string relate
> to the value of the one whose context is vice versa ?

Re: Attributes 'Version and 'Body_Version

[Keith Thompson]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> On my way to playing around with something else, I started looking at the
> results of the attributes 'Version and 'Body_Version with Gnat 3.13p on
> WinNT. They appear to be intended for distributed systems, but could
> potentially be useful within any system that uses someone's library of
> stuff - a means of verifying that any assumed behavior from a given version
> is still valid. Or, for example, a means of recording the version of a
> package that produced some particular output so that on input, version
> differences can be accommodated.
> 
> Looking at the strings from a particular package (a generic instantiatiation
> at that) I see a pair of strings that look like: "2daafe2a" (spec)
> "21adf138" (body) I didn't encounter anything in the ARM indicating what the
> format of the string should be nor did I see anything in the GNAT documents
> that explained how to interpret the string. Obviously, this is going to be
> system dependent, but if you want to do anything more than say "This version
> isn't the one I remember" you need to know how to interpret the string. Has
> anybody used this before and possibly have some insight? Thanks.

If you want to know which version is "older" or "newer", I can't think
of any good way to define the concepts (other than perhaps the source
file timestamp, but that can be changed by copying the file).  Knowing
whether a version is older or newer than the one you expected might be
useful if you can assume upward compatibility, but that can't be
enforced by the language; compatibility can be upward, downward, both,
or neither, and may apply only to some features of a package.

If you're looking for a configuration management system, I suggest
using a configuration management system.  If you want a version
indication in your package that gives you more information than
equality/inequality, it should be easy enough to add one yourself.
(For example, if you use RCS or CVS, you can have a version string
that's automatically updated whenever the source file is checked in.)

The version strings used by GNAT look like they might be 32-bit
checksums of the source, in hexadecimal, but that's just a guess.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Cxiuj via bazo apartenas ni.

Re: Attributes 'Version and 'Body_Version

[Robert Dewar]

"Tony Gair" <tonygair@donot.spam.btinternet.com> wrote in message news:<9sbb1f$2bm$1@plutonium.btinternet.com>...
> On a hopefully slightly more helpful note :-
> 
> I think it is used in the Glade distrib. annex > examples 
> to compare versions,

Exactly! All you can do is to do an equality comparison to
check for identical versions.

Re: Attributes 'Version and 'Body_Version

[Robert Dewar]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<9sc0cf$76a$1@nh.pace.co.uk>...
> But I still think this is not as useful.

I think you are quite confused about the semantics of
version, this string identifies a unit and all the units
on which it depends. It is nothing like a numerical version
number of the source for a particular unit. I would suggest
you review the RM, you have got a completely wrong idea
here. Perhaps if 'Version had been called 'Octupus you
would not have read this irrelevant semantics into the
attribute :-)

Re: Attributes 'Version and 'Body_Version

[Frank]

Hi!

In another development tool I worked on, we made a array of strings
containing all files and their versions that were
built into the executable. This array could be dumped into a file by a
pushbutton in the "about" box.
The array were populated by code in each source code file, this code was a
part of the coding standard, and after it was
initially there PVCS(configuration tool) was the only "one" worrying about
it.
I belive something similar can be done in Ada also. If you create a package
that has logic administrating the array, and a function
to set the array element this function could be called by all other
packages' main block. One constraint I see is that purity pragmas can
break this approach.

Frank

> If you're looking for a configuration management system, I suggest
> using a configuration management system.  If you want a version
> indication in your package that gives you more information than
> equality/inequality, it should be easy enough to add one yourself.
> (For example, if you use RCS or CVS, you can have a version string
> that's automatically updated whenever the source file is checked in.)

Re: Attributes 'Version and 'Body_Version

[Stephen Leake]

dewar@gnat.com (Robert Dewar) writes:

> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<9sc0cf$76a$1@nh.pace.co.uk>...
> > But I still think this is not as useful.
> 
> I think you are quite confused about the semantics of
> version, this string identifies a unit and all the units
> on which it depends. It is nothing like a numerical version
> number of the source for a particular unit. I would suggest
> you review the RM, you have got a completely wrong idea
> here. Perhaps if 'Version had been called 'Octupus you
> would not have read this irrelevant semantics into the
> attribute :-)

Actually, I think Marin has been quite up front in acknowledging how
the RM defines 'Version. He is simply wishing it was defined
differently.

Think of this as a feature request, for a new attribute, that does
what Marin wants it to.

Marin; if you want Robert and other language lawyers to hear a
feature request, you need to state it as a new attribute; they simply
will not consider redefining an existing one! :)

-- 
-- Stephe

Re: Attributes 'Version and 'Body_Version

[Larry Kilgallen]

In article <ubsidqiif.fsf@gsfc.nasa.gov>, Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> Actually, I think Marin has been quite up front in acknowledging how
> the RM defines 'Version. He is simply wishing it was defined
> differently.
> 
> Think of this as a feature request, for a new attribute, that does
> what Marin wants it to.

I think what Marin wants is not possible.

Otherwise I would want it also.

Re: Attributes 'Version and 'Body_Version

[Marin David Condic]

I'm sorry. I don't recall that I was trying to discuss what it *is*. I
thought I was trying to discuss what it *might be*. I was under the
impression that I was sort of off in the Blue Sky world of saying "Gee...
This feature would be more useful if it was more like this...." rather than
saying "My understanding of the feature is that it *is* this...."

But I could be wrong about what it was I was talking about and I'm willing
to stand corrected if someone out there knows more about what I was talking
about than I do.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0111071511.6fe3f067@posting.google.com...
>
> I think you are quite confused about the semantics of
> version, this string identifies a unit and all the units
> on which it depends. It is nothing like a numerical version
> number of the source for a particular unit. I would suggest
> you review the RM, you have got a completely wrong idea
> here. Perhaps if 'Version had been called 'Octupus you
> would not have read this irrelevant semantics into the
> attribute :-)

Re: Attributes 'Version and 'Body_Version

[Marin David Condic]

This may not be news: I often want what is, in fact, impossible. :-)

But so far, I don't think what I want has been shown to *be* impossible. If
the compiler is somehow or other capable of determining that the string for
'*Version needs to be *different* then how is it impossible to be sure that
the next string chosen satisfies the semantics: New_String > Old_String ???

If the relationship only has the meaning: "This version was compiled at a
later time than the previous version" and you make no other use of it beyond
that, then I don't think doing so is impossible or undesirable. It enables
you to use the version string in manners perhaps not originally contemplated
by its original designers. That's not necessarily A Bad Thing.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:hrQGkj0SsFUJ@eisner.encompasserve.org...
>
> I think what Marin wants is not possible.
>
> Otherwise I would want it also.

Re: Attributes 'Version and 'Body_Version

[Larry Kilgallen]

In article <9seku6$hes$1@nh.pace.co.uk>, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:
> This may not be news: I often want what is, in fact, impossible. :-)
> 
> But so far, I don't think what I want has been shown to *be* impossible. If
> the compiler is somehow or other capable of determining that the string for
> '*Version needs to be *different* then how is it impossible to be sure that
> the next string chosen satisfies the semantics: New_String > Old_String ???
> 
> If the relationship only has the meaning: "This version was compiled at a
> later time than the previous version" and you make no other use of it beyond
> that, then I don't think doing so is impossible or undesirable.

Yes, that much would be possible.  I just don't think it would be
much use, for instance in the case where I back out the change to
a compilation unit upon which the subject compilation unit depends.

A more recent compilation could mean an _earlier_ version of the code.

Re: Attributes 'Version and 'Body_Version

[Robert Dewar]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<9seku6$hes$1@nh.pace.co.uk>...
> But so far, I don't think what I want has been shown to *be* impossible. If
> the compiler is somehow or other capable of determining that the string for
> '*Version needs to be *different* then how is it impossible to be sure that
> the next string chosen satisfies the semantics: New_String > Old_String ???


Well, so much for the theory that Marin understands
'Version but wants different behavior :-)

Marin, you persist in thinking that unit'Version is about
the version of the unit in question. Perhaps we should have
called the attribute something else, since the name sure is
confusing you. Version here does NOT mean the source
version of the unit in question, it means the *object*
version of the unit, which includes contributions from
all the units on which the unit depends.

So the notion of newer or older is simply and fundamentally
inapplicable, given that this version represents the state
of a *set* of files.

I trust this makes things clear, if not I give up :-)

Re: Attributes 'Version and 'Body_Version

[Robert Dewar]

Keith Thompson <kst@cts.com> wrote in message news:<yecbsiekzkl.fsf@king.cts.com>...
> The version strings used by GNAT look like they might be > 32-bit checksums of the source
                                ^
                          sources!!!!!

It's really important to realize that 'Version is nothing
like the version number of the source file, it is the
version of the OBJECT, not the source, and hence depends
on a whole set of sources.

Re: Attributes 'Version and 'Body_Version

[Robert Dewar]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<9seku6$hes$1@nh.pace.co.uk>...
> This may not be news: I often want what is, in fact, impossible. :-)

It is perfectly reasonable to propose a new attribute
say 'Source_Version that returns a string with the kind
of attributes you suggest (e.g. it could return a version
number from the CM, or the time stamp, or some such).

But this has nothing whatsoever to do with the 'Version
attribute, and you merely confuse the discussion by
thinking otherwise.

Try reading the definition in the RM *forgetting* that
the name of the attribute is "version" :-)

Re: Attributes 'Version and 'Body_Version

[Keith Thompson]

dewar@gnat.com (Robert Dewar) writes:
> Keith Thompson <kst@cts.com> wrote in message
> news:<yecbsiekzkl.fsf@king.cts.com>...
> > The version strings used by GNAT look like they might be
> > 32-bit checksums of the source
>                                 ^
>                           sources!!!!!
> 
> It's really important to realize that 'Version is nothing
> like the version number of the source file, it is the
> version of the OBJECT, not the source, and hence depends
> on a whole set of sources.

Here's the RM definition of the 'Version attribute, from E.3(3):

    P'Version     Yields a value of the predefined type String that
                  identifies the version of the compilation unit that
                  contains the declaration of the program unit.

And here's what 10.1(2) has to say about compilation units:

    The text of a program can be submitted to the compiler in one or
    more compilations.  Each compilation is a succession of
    compilation_units.  A compilation_unit contains either the
    declaration, the body, or a renaming of a program unit.  The
    representation for a compilation is implementation-defined.

It certainly looks to me as if 'Version applies to a compilation unit,
and a compilation unit is a part of the text of a program.  The
version of a compilation unit changes whenever the compilation unit
changes in a "semantically significant" way; the phrase "semantically
significant" is explicitly left undefined.

If unit A depends on unit B, a change in B can affect the object
generated for A even if the source of A is unchanged.  I don't see a
requirement for A'Version or A'Body_Version to change when this
happens, though I can see that such a requirement would be useful.

It's likely that I'm missing something obvious, but I don't know what
it is.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Cxiuj via bazo apartenas ni.

Re: Attributes 'Version and 'Body_Version

[Larry Kilgallen]

In article <yec3d3nij4r.fsf@king.cts.com>, Keith Thompson <kst@cts.com> writes:

> If unit A depends on unit B, a change in B can affect the object
> generated for A even if the source of A is unchanged.  I don't see a
> requirement for A'Version or A'Body_Version to change when this
> happens, though I can see that such a requirement would be useful.

E.3 (5) says:

The version of a compilation unit changes whenever the version
changes for any compilation unit on which it depends semantically.
The version also changes whenever the compilation unit itself
changes in a semantically significant way. It is implementation
defined whether there are other events (such as recompilation)
that result in the version of a compilation unit changing.

Re: Attributes 'Version and 'Body_Version

[Marin David Condic]

The important thing about it is that at runtime, a subsystem can detect if
there has been a change in something (either within itself or within
something it is using) from some known point. That doesn't have to be
because the source file was edited and it would be hard to imagine how the
object file could know anything abut that without some kind of recompilation
going on. So its clear to me that the meaning is "This module has been
recompiled/relinked at a different time than the one you know about..." or
"This is the identical compiled/linked image you know about..." The file may
be edited a hundred times, but if it never got waved past the
compiler/linker how is the object file going to know that?

I just thought that the feature would be more useful if the strings were
ordered such that you could detect at runtime "This is a *later*/*earlier*
issue than the one I know about" rather than just detecting that it is
different.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:L9pmQ$PSskWd@eisner.encompasserve.org...
>
> E.3 (5) says:
>
> The version of a compilation unit changes whenever the version
> changes for any compilation unit on which it depends semantically.
> The version also changes whenever the compilation unit itself
> changes in a semantically significant way. It is implementation
> defined whether there are other events (such as recompilation)
> that result in the version of a compilation unit changing.

Re: Attributes 'Version and 'Body_Version

[Robert Dewar]

Keith Thompson <kst@cts.com> wrote in message news:<yec3d3nij4r.fsf@king.cts.com>...

>  I don't see a
> requirement for A'Version or A'Body_Version to change 
> when this happens, 

Yes, you are missing something obvious, keep reading (all
the way to para 5 :-)

Once again, the idea of 'Version is that it identifies
the *object* executable code of a unit, to see if it is
compatible, it has nothing to do with source versions.

Re: Attributes 'Version and 'Body_Version

[Tony Gair]

This would be very useful from a security point of view for downloadable
distributed programs from a open source point of view, and I would use it if
I could get the hang of the distrib annex (aaaaarrrrgggggghhhh)


"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9sm4se$35v$1@nh.pace.co.uk...
> The important thing about it is that at runtime, a subsystem can detect if
> there has been a change in something (either within itself or within
> something it is using) from some known point. That doesn't have to be
> because the source file was edited and it would be hard to imagine how the
> object file could know anything abut that without some kind of
recompilation
> going on. So its clear to me that the meaning is "This module has been
> recompiled/relinked at a different time than the one you know about..." or
> "This is the identical compiled/linked image you know about..." The file
may
> be edited a hundred times, but if it never got waved past the
> compiler/linker how is the object file going to know that?
>
> I just thought that the feature would be more useful if the strings were
> ordered such that you could detect at runtime "This is a *later*/*earlier*
> issue than the one I know about" rather than just detecting that it is
> different.
>
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
>
>
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
> news:L9pmQ$PSskWd@eisner.encompasserve.org...
> >
> > E.3 (5) says:
> >
> > The version of a compilation unit changes whenever the version
> > changes for any compilation unit on which it depends semantically.
> > The version also changes whenever the compilation unit itself
> > changes in a semantically significant way. It is implementation
> > defined whether there are other events (such as recompilation)
> > that result in the version of a compilation unit changing.
>
>

Re: Attributes 'Version and 'Body_Version

[Keith Thompson]

dewar@gnat.com (Robert Dewar) writes:
> Keith Thompson <kst@cts.com> wrote in message
> news:<yec3d3nij4r.fsf@king.cts.com>...
> >  I don't see a
> > requirement for A'Version or A'Body_Version to change 
> > when this happens, 
> 
> Yes, you are missing something obvious, keep reading (all
> the way to para 5 :-)
> 
> Once again, the idea of 'Version is that it identifies
> the *object* executable code of a unit, to see if it is
> compatible, it has nothing to do with source versions.

Aha!

In RM95, E.3(5) says:

    The version of a compilation unit changes whenever the version changes
    for any compilation unit on which it depends semantically.  The
    version also changes whenever the compilation unit itself changes in a
    semantically significant way.  It is implementation defined whether
    there are other events (such as recompilation) that result in the
    version of a compilation unit changing.

However, the RM I was using is a version with Technical
Corrigendum 1 merged into it.  In that version, E.3(5) has been
modified and expanded to two paragraphs:

    The *version* of a compilation unit changes whenever the
    compilation unit changes in a semantically significant way.  This
    International Standard does not define the exact meaning of
    "semantically significant".  It is unspecified whether there are
    other events (such as recompilation) that result in the version of
    a compilation unit changing.
    
    If P is not a library unit, and P has no completion, then
    P'Body_Version returns the Body_Version of the innermost program
    unit enclosing the declaration of P.  If P is a library unit, and
    P has no completion, then P'Body_Version returns a value that is
    different from Body_Version of any version of P that has a
    completion.

I still don't see anything that precludes implementing 'Version as,
say, a checksum of the source, or perhaps a checksum of a canonically
formatted version of the source (so semantically insignificant changes
don't affect the version).

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Cxiuj via bazo apartenas ni.

Re: Attributes 'Version and 'Body_Version

[Nick Roberts]

I think there's some mileage in the idea that it might be useful for
'Version and 'Body_Version to (be able to) return something more than just a
checksum (or the like). I think Tony Gair's comment hints at why.

Supposing an Internet web page is offering a download of a partition
(program) called Whizzo (which solves all your marital problems by
psychology).

Different potential users of Whizzo may well have different versions of the
partitions (which contain units) that Whizzo depends on. Suppose those units
are: Psychospeak; Technobabble; and Generally.Dodgy.Stuff. Each is in a
separate partition.

To support as many users as possible (before they jump off a bridge), Whizzo
has been built in multiple versions supporting the various versions of
Psychospeak, Technobabble, and Generally.Dodgy.Stuff, and a table is shown
on the web page allowing the user to select the correct version of Whizzo to
download. E.g.:

Psychospeak   Technobabble   Generally.Dodgy.Stuff     Whizzo
2f10e401      5ea109d0       4ea23310                  > 5a1b207a <
7bc195a2      d4216eee       40abba31                  > 8a90001b <
f9fa51ef      5201ac48       216b6d48                  > 21a68c5c <
6d33a902      5201ac48       39b278b7                  > d409b12b <
etc

Which is okay, but it would be nicer if the versions were in a slightly more
human-readable form. E.g.:

Psychospeak      Technobabble      Generally.Dodgy.Stuff     Whizzo
V:2 R:7 (472)    V:3 R:11 (1027)   V:Pub:1 R:2 (29)          > V:1 R:1
(10052) <
V:2 R:7 (479)    V:3 R:11 (1028)   V:Pub:1 R:2 (30)          > V:1 R:1
(10051) <
V:2 R:7 (480)    V:4 R:1 (2475)    V:Pub:1 R:2 (32)          > V:1 R:1
(10050) <
V:2 R:8 (20)     V:4 R:1 (2475)    V:Pub:1 R:2 (39)          > V:1 R:1
(10049) <
etc

The idea behind the versions shown here is that the build tool (source
controller, version manager, whatever) maintains a version and revision
number (which the user changes, and can enter prefixes for), and
automatically maintains an 'iteration' number (build number), and generates
the version string from all of these. But this is just an idea.

Recalling back to some of the comments made in this thread, there was the
suggestion that a unit could support multiple versions of a service unit,
which offered different levels of service.

I would suggest that this is best done (in Ada 95) by the technique of the
service unit exporting objects of a class (hierarchy) to its clients (via a
remote access-to-classwide type and a repository/directory/agency unit or
object).

This has to be a classic Ada 95 'pattern': the clients are versionistically
decoupled* from the servers; servers which add functionality can do it in a
totally forwards-compatible way (by deriving from the originally published
type, and exporting objects of the derived type); old clients are 'fooled'
into getting the old type (and service) they expect; new clients can take
advantage of the added functionality; an 'intelligent' client can test the
type of the object it gets, and perhaps adapt to the functionality the
object provides.

--
Best wishes,
Nick Roberts



*term obtained from the Technobabble unit (C) 2001 Technobabble Inc. All
rights reserved.

;-)

Re: Attributes 'Version and 'Body_Version

[Robert Dewar]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message news:<9trpj1$4e6v2$1@ID-25716.news.dfncis.de>...
> I think there's some mileage in the idea that it might be useful for
> 'Version and 'Body_Version to (be able to) return something more than just a
> checksum (or the like).

<<rest of peculiar ideas deleted :-)>>

I am not sure I understand what on earth Nick was talking
about here, but for sure it has nothing to do with the
existing attributes (*)

I think what happens here is that people see the word
Version, and it triggers all kinds of entirely irrelevant
baggage.

The idea is that if two partitions share a package, and
communicate in a way that uses this package, they need a
way to make sure that they are using the same *compiled*
version of the package. How this is guaranteed will depend
on the system. For example, in a conventional Ada 83 style
library system, it will be good enough to store a precise
enough time stamp of the time of compilation, since two
packages can only have the same time of compilation in
such a system if they are indeed the same (and depend on
all the same packages).

This is the *very limited* intention of these attributes,
they are not in any sense relevant for the purposes of
general version control, let alone the more extensive
ideas that Nick presents.

If any of these extended ideas have merit, I would suggest
completely disentangling them from the existing attributes,
starting by using entirely different names, otherwise you
will perpetuate the confusion.

(*) by the way, MD-5 hash codes are indeed used to guarantee getting
the right version of things on the
internet (have a look at the Farber True Names patent
for details of the idea).

Re: Attributes 'Version and 'Body_Version

[Nick Roberts]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0111251830.61aaa6be@posting.google.com...
> "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
news:<9trpj1$4e6v2$1@ID-25716.news.dfncis.de>...
> > I think there's some mileage in the idea that it might be useful for
> > 'Version and 'Body_Version to (be able to) return something more than
just a
> > checksum (or the like).
>
> <<rest of peculiar ideas deleted :-)>>
>
> I am not sure I understand what on earth Nick was talking
> about here,

It's tempting to agree :-)

> but for sure it has nothing to do with the
> existing attributes (*)

What am I supposed to say? [pantomime chorus] "Oh, yes it does!"

> I think what happens here is that people see the word
> Version, and it triggers all kinds of entirely irrelevant
> baggage.
>
> The idea is that if two partitions share a package,
> ...

I know what the original idea was for the attributes.

> This is the *very limited* intention of these attributes,
> they are not in any sense relevant for the purposes of
> general version control, let alone the more extensive
> ideas that Nick presents.

But just because they were originally intended for a certain purpose,
doesn't mean they cannot be used for another purpose (in addition), does it?

> If any of these extended ideas have merit, I would suggest
> completely disentangling them from the existing attributes,
> starting by using entirely different names, otherwise you
> will perpetuate the confusion.

Far be it from me to wish to perpetuate any confusion, but often confusion
is a problem cured by good documentation, and doesn't necessarily require
new attributes.

> (*) by the way, MD-5 hash codes are indeed used to guarantee getting
> the right version of things on the
> internet (have a look at the Farber True Names patent
> for details of the idea).

I can guess the general idea, and I'm sure it could be very handy sometimes.
Sadly, the fact that the process is patented is probably not so handy.

In fact, the more important part of my post was the bit at the bottom, about
exporting service objects. I presume Robert wasn't commenting on that bit,
and I hope nobody loses sight of the importance of that technique.

--
Best wishes,
Nick Roberts

Re: Attributes 'Version and 'Body_Version

[Robert Dewar]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message news:<9tsd63$4jjng$1@ID-25716.news.dfncis.de>...
> "Robert Dewar" <dewar@gnat.com> wrote in message
> news:5ee5b646.0111251830.61aaa6be@posting.google.com...
> I know what the original idea was for the attributes.

OK, one would not have guessed this from some earlier
messages. Certainly others in this thread have been
very confused (indeed the entire thread was started
by such a confusion).

> But just because they were originally intended for a 
> certain purpose,
> doesn't mean they cannot be used for another purpose (in 
> addition), does it?

It should if you are following good language design
principles. There is no point in using the same attribute
name for two different purposes.

Also, extending the meaning of 'Version would be a language
extension that would create a non-conforming variant of
Ada. That means no one is going to do it without very
general consensus, which you simply won't get going in
this direction.

If you choose a different attribute name, then you are no
longer talking about a language extension, and it is much
easier to get someone to implement it if they agree it has
some merit.

> Far be it from me to wish to perpetuate any confusion, 
> but often confusion is a problem cured by good 
> documentation, and doesn't necessarily require
> new attributes.

You can cure someones confusion with documentation if the
confusion arises from misunderstanding. If the confusion
stems from confused language design, such as in this case
suggesting the use of 'Version to mean two rather unrelated
things, then documentation won't be enough.

Re: Attributes 'Version and 'Body_Version

[Nick Roberts]

> > But just because they were originally intended for a
> > certain purpose,
> > doesn't mean they cannot be used for another purpose (in
> > addition), does it?
>
> It should if you are following good language design
> principles. There is no point in using the same attribute
> name for two different purposes.

Yes there is: simplicity.

> Also, extending the meaning of 'Version would be a language
> extension that would create a non-conforming variant of
> Ada.

No it wouldn't. Changing the meaning would, but extending it specifically
does not. My suggestion was purely to do with extending the ways in which
the attributes (Version and Body_Version) are used; at no point was my
suggestion to prevent them from doing what the RM95 requires.

> > Far be it from me to wish to perpetuate any confusion,
> > but often confusion is a problem cured by good
> > documentation, and doesn't necessarily require
> > new attributes.

> You can cure someones confusion with documentation if the
> confusion arises from misunderstanding. If the confusion
> stems from confused language design, such as in this case
> suggesting the use of 'Version to mean two rather unrelated
> things, then documentation won't be enough.

I'm sorry, but the confusion in this case is all yours, Robert!

--
Best wishes,
Nick Roberts

Re: Attributes 'Version and 'Body_Version

[Robert Dewar]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message news:<9tu7nj$4v9lc$1@ID-25716.news.dfncis.de>...

>> There is no point in using the same attribute
>> name for two different purposes.
> 
> Yes there is: simplicity.

That's a really peculiar view, confusing two separate
concepts by using the same name certainly does not make
things simpler, quite the contrary.

> > Also, extending the meaning of 'Version would be a 
> > language
> > extension that would create a non-conforming variant of
> > Ada.
> 
> No it wouldn't.

Nick, you really don't know the RM well enough. You are
completely and 100% wrong on this. Please don't make such
statements without carefully checking. There is far too
much misinformation on this newsgroup.

Section 2.8 of the RM is perfectly clear. The only
implementation permission is to add implementation
dependent pragmas, and the name is required to be
different from any other pragma. This is really not
a hard rule to find!

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

Changing the meaning of an existing pragma, by extension
or otherwise is DEFINITELY a non-conforming language
change. That's perfectly clear from the RM.

> I'm sorry, but the confusion in this case is all yours, 
> Robert!

Really Nick, you must spend more time reading the
RM *carefully* and avoid spreading misinformation!

Re: Attributes 'Version and 'Body_Version

[Georg Bauhaus]

Nick Roberts (:) and Robert Dewar debate:

:> There is no point in using the same attribute
:> name for two different purposes.
: 
: Yes there is: simplicity.
 
:> > Far be it from me to wish to perpetuate any confusion,
 
:> You can cure someones confusion with documentation [iff...]
 
I find the level of confusion in the thread unsatisfying,
in that it is at most at O(1). So let me add some loosely
related 2c. Or make that 2 centimes belgique :-)


package Versions is
   -- provide versions at run time, for a change, or maybe not

   type Version is
     -- to be attached to objects
      record
	 Version: Natural;
	 --  XXX provide a decent Version type instead of a Natural
	 -- type for versions
      end record;

   type Versioned_Versions is (Versi_On, Versi_Off);
   --  for toggling versioned versions of Version objects
   -- See Version below.

   procedure Which_Version(Want_Versioned_Version: Versioned_Versions);
   --  toggle versioning feature

   generic
      Max_Version: in Natural;
      --  no more than this number of Versions

   package Versioning is

      function Version (V: Version) return Version;
      --  versions V such that Version V has a Versions.Version iff this feature
      -- has been turned on with Version (See Version above above).

   end Versioning;

end Versions;


package body Versions is

   VV: Versioned_Versions:= Versi_Off;
   --  modus operandi

   -- ----------------
   -- Which_Version
   -- ----------------
   --  adjust the state variable VV to have the same value as
   -- Want_Versioned_Version

   procedure Which_Version(Want_Versioned_Version: Versioned_Versions) is
   begin
      VV:= Want_Versioned_Version;
   end Which_Version;



   package body Versioning is

      protected Versigen is
         --  new version numbers are assigned here up
         --  to a limit XXX remove the limit

         entry Next;
         -- can't proceed when no more versioning could
         -- possibly be done  XXX Add Free(Ver: Natural)
         -- (No, neither free the storage, nor Free the storage)

         function Current return Natural;

      private
         Ver: Natural:= 0;
      end Versigen;


      protected body Versigen is

         entry Next when Ver < Max_Version is
         begin
            Ver:= Natural'Succ(Ver);
         end Next;

         function Current return Natural is
         begin
            return Ver;
         end Current;

      end Versigen;



      -------------
      -- Version --
      -------------

      function Version (V: Versions.Version) return Versions.Version is
         Result: Versions.Version;

      begin
         if VV = Versi_On then

        Want_Versioning:
            declare
               Wanted_Version: Natural;
            begin
               Versigen.Next;
               Wanted_Version:= Versigen.Current;

               Result:= (Version => Wanted_Version);
            end Want_Versioning;

         else  --  Versi_off

            Result:= V;
         end if;

         return Result;
      end Version;

   end Versioning;

end Versions;

Re: Attributes 'Version and 'Body_Version

[Nick Roberts]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0111261956.3df9b8e3@posting.google.com...

> Changing the meaning of an existing pragma, by extension
> or otherwise is DEFINITELY a non-conforming language
> change. That's perfectly clear from the RM.

Robert, your reply is about pragmas. All of my posts in this thread have
been about attributes, and none has mentioned any pragma.

You don't even seem to have read my posts, to which you are replying.

If your replies are simply for a 'vexatious' purpose, I'll simply have to
k-line you, and perhaps others may also choose to do so.

If not, could I ask you, please, to re-read my posts, and then make a proper
reply.

--
Nick

Re: Attributes 'Version and 'Body_Version

[Larry Kilgallen]

In article <5ee5b646.0111261956.3df9b8e3@posting.google.com>, dewar@gnat.com (Robert Dewar) writes:

> Section 2.8 of the RM is perfectly clear. The only
> implementation permission is to add implementation
> dependent pragmas, and the name is required to be
> different from any other pragma. This is really not
> a hard rule to find!

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.  Was the thought that the
set of Ada compiler vendors will always be so small that such
issues can be worked out informally ?

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

Re: Attributes 'Version and 'Body_Version

[Robert Dewar]

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.

Re: Attributes 'Version and 'Body_Version

[Larry Kilgallen]

In article <5ee5b646.0111280749.77fabe6c@posting.google.com>, dewar@gnat.com (Robert Dewar) writes:
> Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<YsaTZ19cOfHh@eisner.encompasserve.org>...

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

Re: Attributes 'Version and 'Body_Version

[Robert Dewar]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<PFcoNrf74AeG@eisner.encompasserve.org>...
> 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.

If they expect this for going from a vendors compiler for
one Ada standard to its successor, they are fooling themselves. Easy
yes, effortless no. I remember the project
manager for the old ATC system saying that she expected
to be able to move from Ada 83 to Ada 95 without changing
a single character of source and I shook my head ...
 

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

Why?
This has not been a problem in practice.
Why solve problems that do not exist, when the result would
be to degrade readability. 

It is really useful that the assert pragma in GNAT has this
name and not something like Implementation_Assert or somesuch junk. 

If there is an Ada 0x, and if it includes Assert, and if
it (surprisingly) is not upwards compatible with the GNAT
pragma, then it is annoying but not disastrous to have to
run a trivial script to change the name of pragma Asserts.

Re: Attributes 'Version and 'Body_Version

[Larry Kilgallen]

In article <5ee5b646.0111281949.7032e04b@posting.google.com>, dewar@gnat.com (Robert Dewar) writes:
> Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<PFcoNrf74AeG@eisner.encompasserve.org>...

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

To automate the detection of errors wherever possible.

Re: Attributes 'Version and 'Body_Version

[Robert Dewar]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<Kg7U2sTGDFyI@eisner.encompasserve.org>...
> To automate the detection of errors wherever possible.

Note by the way that GNAT implements the pragma

pragma Restrictions (No_Implementation_Pragmas);
pragma Restrictions (No_Implementation_Attributes);

to help control the use of implementation attributes and
pragmas.

Re: Attributes 'Version and 'Body_Version

[Larry Kilgallen]

In article <5ee5b646.0111291826.276bc16c@posting.google.com>, dewar@gnat.com (Robert Dewar) writes:
> Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<Kg7U2sTGDFyI@eisner.encompasserve.org>...
>> To automate the detection of errors wherever possible.
> 
> Note by the way that GNAT implements the pragma
> 
> pragma Restrictions (No_Implementation_Pragmas);
> pragma Restrictions (No_Implementation_Attributes);
> 
> to help control the use of implementation attributes and
> pragmas.

That sounds good.