!standard 13.09.02 (02) 01-02-12 AC95-00006/01 !class uninteresting 01-02-12 !status received 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 <> 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.] <> 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 > < 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 <> 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 <> 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?) ****************************************************************