Version 1.2 of acs/ac-00006.txt

Unformatted version of acs/ac-00006.txt version 1.2
Other versions for file acs/ac-00006.txt

!standard 13.09.02 (02)          01-02-12 AC95-00006/01
!class amendment 01-02-12
!status received no action 01-02-12
!subject The Valid attribute should be defined for composite types
!summary
!appendix

From: Robert Dewar
Sent: Monday, December 25, 2000 6:41 AM

A customer of ours just noted that it would be extremely useful
to be able to write x'valid where x was a composite (record or
array) type with the meaning that 'valid should be applied to all
subcomponents.

That seems really useful and very easy to do, so we will go ahead
at some point and add this facility to GNAT.

But it is annoying that we will have to call it 'All_Valid or
something, because it would be illegal to add a meaning to
the existing attribute.

We already ran into this for 'Small which we fixed (if I remember
right).

I wonder whether we might not ease up on this rule generally.
The trouble is that if we implement All_Valid now, we will have
to keep it for ever, and it would really be much cleaner to
allow 'Valid.

I suppose we could put it under our language extension flag,
that's the other possibility.

Well .. just musing on the best way to do extensions like this ...

****************************************************************

From: Jean-Pierre Rosen
Sent: Monday, December 25, 2000 11:00 AM

I reread 1.1.3, and did not find any explicit phrase that would disallow
extending a language defined attributes to more types than specified by the
standard.

Sure, you can play lawyers forever on issues like this...

****************************************************************

From: Robert Dewar
Sent: Monday, December 25, 2000 5:35 PM

Well 1.1.3 says that variations are allowed only if they are
explicitly permitted, so on its own 1.1.3 certainly does not
permit anything!

The only permission to extend the language in the area of
attributes is provided by 4.1.4(12)

12   An implementation may provide implementation-defined attributes; the
identifier for an implementation-defined attribute shall differ from those of
the language-defined attributes.

I don't see how even the most ardent and devious language lawyer can
conclude that extensions to language defined attributes are allowed.

(unless you consider that the recent decision by the supreme court of the
US legitimizes an approach where you start with the conclusion you want, and
then bend the law to fit, even if it breaks in the bending :-)

****************************************************************

From: Robert A Duff
Sent: Tuesday, December 26, 2000 7:30 AM

> We already ran into this for 'Small which we fixed (if I remember
> right).

'Small is special, because it existed in Ada 83.

> I wonder whether we might not ease up on this rule generally.

I think there is some value in the rule: you can tell whether your
program uses impl-def attributes (and pragmas) by searching for strings
and/or reading the code.  If the rule were relaxed generally, then when
I see "Foo'Valid", I wouldn't know whether it's portable or not without
rummaging around looking at various declarations.  (In fact, the average
programmer would probably assume that it's portable until trying to port
-- many programmers assume that their current compiler's behavior is the
definition of the language, unfortunately.)

There are other cases of non-portability in Ada that are not obvious
from the source code.  (Too many, IMHO.)  But I don't think we should
add one more.

> The trouble is that if we implement All_Valid now, we will have
> to keep it for ever, and it would really be much cleaner to
> allow 'Valid.
>
> I suppose we could put it under our language extension flag,
> that's the other possibility.

In this kind of case, I recommend either: (1) the language extension
flag, as you suggest above, or (2) push for this to be added as a
standard feature of the language, so all compilers (eventually) support
it.  I agree that calling it Mumble_Valid is an annoyance.

Now, as to the feature itself: we left it out on purpose, and the AARM
explains why (13.9.2(12.b-12.c)).  Are those issues taken into account?
Are there restrictions on what types are allowed?

What is the meaning of X'Valid if X is abnormal (eg, an abort happened
in the middle of "X := Y;", so X's discriminants have been damaged)?
I suppose 13.9.1(8) says that's erroneous.  Is that a good idea (would
the programmer think maybe X'Valid determines whether X itself is in a
good state)?

There is some talk in 13.9.1(8.a-8.c) about "static constraints all the
way down", but I think that's wrong -- I don't see any such thing in
the RM proper.  We must have changed the RM and forgotten to change the
AARM at some point.

By the way, 13.9.2(3) says that X'Valid checks that X is not abnormal.
But how can this be, given that 13.9.1(8) makes the prefix erroneous?

****************************************************************

From: Robert Dewar [dewar@GNAT.COM]
Sent: Tuesday, December 26, 2000 11:18 AM

<<I think there is some value in the rule: you can tell whether your
program uses impl-def attributes (and pragmas) by searching for strings
and/or reading the code.  If the rule were relaxed generally, then when
I see "Foo'Valid", I wouldn't know whether it's portable or not without
rummaging around looking at various declarations.  (In fact, the average
programmer would probably assume that it's portable until trying to port
-- many programmers assume that their current compiler's behavior is the
definition of the language, unfortunately.)>>

Well a very important feature in GNAT that definitely should be
semi-standardized is

pragma Restrictions (No_Implementation_Attributes);

which would of course also disallow extensions to existing attributes

We also have

pragma Restrictions (No_Implementation_Pragmas);
pragma Restrictions (No_Implementation_REstrictions)

yes yues, I know the latter has to exclude itself :-)

[Editor's note: This discussion continues in AI-00257.]

<<By the way, 13.9.2(3) says that X'Valid checks that X is not abnormal.
But how can this be, given that 13.9.1(8) makes the prefix erroneous?>>

This is of course a (to me well known) bug in the RM, I thought it
had been addressed by the ARG, but that's not really important, since
any implentation is going to do the right thing here one would hope
(certainly GNAT does).

****************************************************************

From: Pascal Leroy
Sent: Wednesday, December 27, 2000 4:53 AM

> <<By the way, 13.9.2(3) says that X'Valid checks that X is not abnormal.
> But how can this be, given that 13.9.1(8) makes the prefix erroneous?>>

This is (at least partially) addressed by AI95-00167, which says that in the
case of scalars Unchecked_Conversion or imported subprograms do not create
an abnormal object.  This makes Valid usable (and it's probably not a big
implementation headache).

> This is of course a (to me well known) bug in the RM, I thought it
> had been addressed by the ARG, but that's not really important, since
> any implentation is going to do the right thing here one would hope
> (certainly GNAT does).

For scalar objects, I agree, any reasonable implementation is going to do
the right thing.

For composite objects, I don't see how the above statement can be true.  If
you have a discriminated record with plenty of implicit components and an
imported subprogram overwrites it with random junk, the object is surely
becoming abnormal, and I don't understand how an implementation would be
expected to detect that it has been corrupted.  That's why I don't think
'Valid is a good idea for composites.

Of course, a particular implementation may be able to detect the corruption
and do the right thing, but this is not true in general, so this argues in
favor of making it clear that the attribute is implementation-defined, i.e.
using a name other than Valid.

****************************************************************

From: Ted Baker
Sent: Wednesday, December 27, 2000 8:13 AM

| I don't see how even the most ardent and devious language lawyer can
| conclude that extensions to language defined attributes are allowed.

Right.  On the other hand, this seems like the kind of thing for
which ARG and/or WG9 should provide a fast track to authorization.

--Ted

PS:

| (unless you consider that the recent decision by the supreme court of the
| US legitimizes an approach where you start with the conclusion you want, and
| then bend the law to fit, even if it breaks in the bending :-)

At the risk of a potentially endless discussion, I can't let that
jibe pass uncountered. :-)

The Florida Supreme Court did even better.  They started by
finding a contradiction in the law where there was none, then
created new law to resolve their putative contradiction, and in so
doing managed to end up with a conclusion I guess they did NOT
want, i.e., extending the protest phase too little to allow a
proper recount in that phase, but enough to reduce the contest
time period below what was needed to resolve the court cases and
then do a recount.

****************************************************************

From: Robert Dewar
Sent: Wednesday, December 27, 2000 7:48 AM

<<For composite objects, I don't see how the above statement can be true.  If
you have a discriminated record with plenty of implicit components and an
imported subprogram overwrites it with random junk, the object is surely
becoming abnormal, and I don't understand how an implementation would be
expected to detect that it has been corrupted.  That's why I don't think
'Valid is a good idea for composites.>>

Regarding 'Valid for composites.

The useful applications are when the components are all scalars, or
recursively OK composites. There is no difficulty here.

In fact in GNAT we are not in the implicit component business, and there
is no difficulty in dealing with the discriminated record case, we would
first check the discriminants and then go from there, and everything
would be fine. Howver, this would make implementation considerably more
complex for no gain, so we will just stick with the simple case.

****************************************************************

From: Randy Brukardt
Sent: Wednesday, December 27, 2000 12:12 PM

> This is (at least partially) addressed by AI95-00167, which says that in the
> case of scalars Unchecked_Conversion or imported subprograms do not create
> an abnormal object.  This makes Valid usable (and it's probably not a big
> implementation headache).

Umm, keep in mind that AI-167 is a work item that hasn't progressed in a
long time. (It was assigned to Norm Cohen.) Moreover, we assigned it "very
low priority" at the recent meeting, so there is very little chance that it
will progress at any time in the near future. So, I think it is best to
forget that it exists for the purposes of this discussion.

****************************************************************

From: Robert Dewar
Sent: Wednesday, December 27, 2000 10:20 PM

<<Umm, keep in mind that AI-167 is a work item that hasn't progressed in a
long time. (It was assigned to Norm Cohen.) Moreover, we assigned it "very
low priority" at the recent meeting, so there is very little chance that it
will progress at any time in the near future. So, I think it is best to
forget that it exists for the purposes of this discussion.>>

Yes, but that's just formalism. The substance:

> This is (at least partially) addressed by AI95-00167, which says that in the
> case of scalars Unchecked_Conversion or imported subprograms do not create
> an abnormal object.  This makes Valid usable (and it's probably not a big
> implementation headache).

is of course implemented on all compilers how could it not be?)

****************************************************************


Questions? Ask the ACAA Technical Agent