From stt@dsd.camb.inmet.com Mon Oct 2 11:01:51 1995 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA27918; Mon, 2 Oct 95 11:01:51 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA16911; Mon, 2 Oct 95 11:01:52 EDT Received: from dsd.camb.inmet.com by sw-eng.falls-church.va.us (8.6.11/) id PAA01215; Mon, 2 Oct 1995 15:02:19 GMT Received: from houdini.i2ada (houdini.camb.inmet.com) by dsd.camb.inmet.com (4.1/SMI-4.1) id AA27908; Mon, 2 Oct 95 11:00:53 EDT Received: by houdini.i2ada (5.x/SMI-SVR4) id AA01533; Mon, 2 Oct 1995 10:59:59 -0400 Date: Mon, 2 Oct 1995 10:59:59 -0400 From: stt@dsd.camb.inmet.com (Tucker Taft) Message-Id: <9510021459.AA01533@houdini.i2ada> To: ada-comment@sw-eng.falls-church.va.us, gary@ixi.saic.com, rbrukardt@BIX.com Subject: Re: Unknown_Discriminant parts on generic formal types. !topic Unknown_Discriminant parts on generic formal types. !reference RM95-12.5(8) !reference RM95-3.3(23) !reference RM95-3.7(1) !reference RM95-3.7(8) !reference 95-5307.a rbrukardt@BIX.com 95-9-29 !reference 95-5309.a Gary Dismukes 95-09-30 !from Tucker Taft 95-10-02 <> !discussion > > 12.5(8) (a note) says that "A discriminant_part is allowed only for certain > > kinds of types, and therefore only for certain kinds of generic formal types. > > See 3.7." > > > > Unfortunately, the rule in 3.7(8) only applies to known_discriminant_parts. > > 3.7 does not contain any rule restricting the usage of > > unknown_discriminant_parts. > > Coincidentally, I came across this definitional gap myself just a few > days ago. There doesn't seem to be a rule disallowing an unknown_ > discriminant_part for arbitrary kinds of formal types. I agree there is a gap. > However... > > > Various syntax rules usually do the job, but for generic formal types, > > the syntax allows unknown_discriminant_parts. Therefore, are the following > > legal? If not, why not? > > > > Generic > > Type Disc (<>) Is (<>); > > Type Flt (<>) Is Digits (<>); > > Type Str (<>) Is New String; > > Procedure .... > > I don't believe an unknown_discriminant_part should be permitted for > these, at least in the first two of the above examples. There is > strong evidence that the intent is that elementary types cannot have > unknown discriminants. That is for sure. I agree the first two should be illegal. There also seems no compelling reason to allow the third either. I believe our intent was to only allow (<>) on formal private types, and on formal derived types where the ancestor type has discriminants, or is tagged (so discriminants could be added). > ... In 3.3(23) we have a definition of indefinite > subtype followed by "otherwise the subtype is a definite subtype > (all elementary subtypes are definite subtypes)." Since types Disc > and Flt are elementary subtypes but also are indefinite subtypes > (since they have unknown discriminants), that's in contradiction to > the parenthetical assertion. There also wouldn't seem to be much > practical use for such types, even if they were allowed. > > In the case of a type such as Str it's somewhat less clear to me whether > this should be disallowed. I don't see any big problem with allowing > it and it might conceivably be of some use (well probably marginal > use if any), but it doesn't seem worth any special rules. Incidentally, > it turns out there's an ACVC test (bc50001) that gives (<>) on a formal > derived access type and a formal derived string type. This test is of > course invalid if either of these uses of unknown_discriminant_part is > deemed illegal. I believe they should be. > So I would suggest there should be a rule that states that an > unknown_discriminant_part is only allowed for (at most) a formal > type that is a composite type. Actually, it seems simpler to me and > more sensible to only allow an unknown_discriminant_part for formal > private types. I'm not sure whether that disallows any useful cases, > but at the moment I can't see any real benefit to allowing (<>) for > the other cases of composite formal types. In fact, since 3.7(1) > discusses unknown_discriminant_parts specifically in the context > of partial views, this suggests that the intent is that they > can only be given for partial views. That's what makes the most > sense to me. As mentioned above, I think we should allow (<>) for formal derived types where the ancestor has discriminants, or is tagged. > Perhaps a restriction against giving (<>) for nonprivate formal types > is somehow a consequence of other rules, but since we're both missing > it, that suggests that at least a clarification is in order. More than a clarification, I am afraid. Definitely a gap. > -- Gary -Tuck From dismukes@nile.gnat.com Mon Oct 2 15:05:07 1995 Return-Path: Received: from inmet.camb.inmet.com by dsd.camb.inmet.com (4.1/SMI-4.1) id AA06596; Mon, 2 Oct 95 15:05:07 EDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by inmet.camb.inmet.com (4.1/SMI-4.1) id AA20192; Mon, 2 Oct 95 15:05:07 EDT Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.6.11/) id TAA11311; Mon, 2 Oct 1995 19:05:33 GMT Received: by nile.gnat.com (5.61/1.34) id AA02127; Mon, 2 Oct 95 15:05:19 -0400 Date: Mon, 2 Oct 95 15:05:19 -0400 From: dismukes@nile.gnat.com (Gary Dismukes) Message-Id: <9510021905.AA02127@nile.gnat.com> To: ada-comment@sw-eng.falls-church.va.us Subject: Draft of AI95-00033/00: delayed declaration of inherited primitive subprograms !topic Draft of AI95-00033/00: delayed declaration of inherited primitive subprograms <> !standard 07.03.01 (03) 95-06-25 AI95-00033/00 !standard 07.03.01 (04) !standard 07.03.01 (05) !standard 07.03.01 (06) !class binding interpretation 95-06-25 !status received 95-06-25 !subject delayed declaration of inherited primitive subprograms !summary 95-06-25 A primitive subprogram that is inherited but not yet declared at the point of a derived type's declaration will not be declared at a later place within the type's immediate scope where the parent subprogram is visible unless the derived type is declared within the same declarative region in which its parent type is declared. Similarly, additional characteristics of a composite type or derived type will not become available for the type unless the type is declared within the same declarative region as a component type or parent type that would make those characteristics available. !question 95-06-25 Is the rule given in 7.3.1(6) intended to apply to cases where a derived type is declared outside the declarative region in which its parent type is immediately declared? (No.) Consider the following example: package body R is package P is type Pt is ...; private procedure Op (X : Pt); end P; type T is new P.Pt; -- procedure Op (X : T); is inherited here but not yet declared package body p is -- procedure Op (X : T) is declared here, according to -- 7.3.1(6), because the corresponding declaration for Pt -- is visible at this point and the body of P is still within -- the immediate scope of T. It is somewhat strange, however, -- that the subprogram does not get declared immediately -- within the same declarative region as T. end p; end R; Also, are the rules of 7.3.1(3) and 7.3.1(4) regarding the availability of additional characteristics for composite types and derived types intended to apply when such types are declared outside the declarative region in which a component type or parent type is immediately declared? (No.) !recommendation 95-06-25 (See summary.) !wording 95-06-25 In paragraphs 7.3.1(3,4,5,6) replace wording of the form "within the immediate scope of the type" with "immediately within the declarative region in which the type is declared". Alternatively, provide a prefatory paragraph that specifies that the rules apply only when the composite or derived type is declared within the same declarative region as the type from which it inherits additional operations and characteristics. !discussion 95-06-25 The wording of RM95-7.3.1 was inherited from RM83-7.4.2, but by stating the rules in terms of the immediate scope of the type this inadvertently included all nested scopes, which was not intended. It was the intent that implicit declarations of operations (or other characteristics) of a type could occur only immediately within the same declarative region as the type declaration. The wording inherited from Ada 83 was meant to apply only to points immediately within the declarative region in which the composite or derived type was immediately declared. RM83 prefaced paragraph 7.4.2(6) by saying "If the composite type is itself declared within the package that declares the private type", which avoided the problems introduced by RM95-7.3.1(3,4,6). In attempting to be more general and include derived types as well as composite types, plus handle the case of child units (which are not "within" their parent package but are "within the declarative region of" their parent), the restriction imposed by the RM83 preface was unintentionally lost. Note that the AARM does not list this as a "Change from Ada 83", which is further evidence that this change was not intended. Also, paragraph 7.3.1(7.b) of the AARM makes it clear that these rules were only meant to pertain to types declared within the same declarative region as the component type or parent type providing the additional operations. If the existing wording in 7.3.1(6) were retained this could have negative effects on existing Ada 83 compilers being transitioned to Ada 95 since in Ada 83 implementations could rely on the operations of a type always being declared immediately within the declarative region where the type is declared. Such compilers also already implement RM83-7.4.2(7) (which is checked by several ACVC tests) and would be impacted by the change implied by the new wording given in 7.3.1(3) and 7.3.1(4). !appendix 95-06-25 !section 7.3.1(7) !section 7.3.1(7) !subject delayed declaration of inherited primitive subprograms !reference AARM-7.3.1(7);6.0 !reference AARM-7.3.1(7b);6.0 !from Jesper Joergensen 95-03-29 !keywords !reference as: 95-5108.a Jesper Joergensen 95-3-31>> !discussion As I understand the rules in 7.3.1(6) they need not necessarily apply to the case where the derived type is declared within the declarative region of the package that declares the parent type (as 7.3.1(7b) claims they do). Consider: package body R is package P is type Pt is .. private procedure Op( X : Pt ); end P; type T is new P.Pt; -- We are NOT in the declarative region of P package body p is -- procedure Op( X : T ) is declared implicitly here because now -- the corresponding declaration for Pt is visible and we are -- still in the immediate scope of T. -- It is somewhat strange, however, that the subprogram does not -- get declared in the same declarative region as T. end p; end R; Is 7.3.1(7b) wrong or am I misunderstanding 7.3.1(6)? /Jesper **************************************************************** !section 7.3.1(7) !section 7.3.1(7) !subject delayed declaration of inherited primitive subprograms !reference AARM-7.3.1(7);6.0 !reference AARM-7.3.1(7b);6.0 !reference RM83-7.4.2(7) !reference 95-5108.a Jesper Joergensen 95-03-29 !from Tucker Taft 95-03-31 !reference as: 95-5110.a Tucker Taft 95-3-31>> !discussion > As I understand the rules in 7.3.1(6) they need not necessarily apply > to the case where the derived type is declared within the declarative region > of the package that declares the parent type (as 7.3.1(7b) claims they do). The wording of 7.3.1 was inherited from RM83 7.4.2, but as you point out, the term "within the immediate scope of the type" actually includes all nested scopes as well. The correct wording would be "immediately within the declarative region in which the type was declared." The "meta rule" is that no user of a type should have more operations available on it than those available somewhere immediately within the package in which the type was immediately declared. > Consider: > > package body R is > > package P is > type Pt is .. > private > procedure Op( X : Pt ); > end P; > > type T is new P.Pt; -- We are NOT in the declarative region of P > > package body p is > -- procedure Op( X : T ) is declared implicitly here because now > -- the corresponding declaration for Pt is visible and we are > -- still in the immediate scope of T. > -- It is somewhat strange, however, that the subprogram does not > -- get declared in the same declarative region as T. This was not the intent, but you are correct that the wording implies this. The wording (inherited from Ada 83) was meant to apply only to points immediately within the declarative region in which the composite/derived type was immediately declared. It was always the intent that implicit declarations of operations (or other "characteristics") of a type could occur only immediately within the same declarative region as the type declaration. RM83 prefaced paragraph 7.4.2(6) by "If the composite type is itself declared within the package that declares the private type" so using the phrase "within the immediate scope" would not suffer from the above problem. Unfortunately, in our attempt to be more general and include derived types as well as composite types, and handle the case of child units (which are not "within" their parent package but are "within the declarative region of" their parent), we simply left out the critical preface. We should have prefaced 7.3.1(3-7) by saying that we are only talking about cases where the composite/derived type is declared within the declarative region of the package where some private component/parent type is declared (or use the longer-winded "immediately within the declarative region in which the composite/derived type was immediately declared"). > end p; > > end R; > > Is 7.3.1(7b) wrong or am I misunderstanding 7.3.1(6)? You are wrong, but you are not misunderstanding the words, only the intent of 7.3.1(6) ;-). It should only apply within the declarative region of the package in which some component/parent private type was declared. > /Jesper -Tucker Taft stt@inmet.com Intermetrics, Inc. P.S. So much for "partial reuse" of RM83 wording... -T ****************************************************************