MINUTES FOR THE MEETING OF THE ADA RAPPORTEUR GROUP FEBRUARY 27-28, 1989 LA CELLE ST. CLOUD, FRANCE MONDAY, FEBRUARY 27, 1989 Ada Rapporteur Group members present were: Barnes, Dewar, Fisher, Goodenough, Hilfinger, Ichbiah, Lester, Mitchell, Pedersen, and Woodger. Apologies were received from Bardin, Eachus, and Wichmann. The following observers were also present during the meeting: Norman Cohen IBM Jean-Marc Chebat Alsys Jean-Pierre Rosen ENST The chair announced, with regret, the resignation of Peter Belmont from the ARG. He is no longer certain of financial support to attend meetings, but he has agreed to continue to comment on issues as he is able. Approval of Minutes After correcting observer Anthony Gargaro's name, the minutes were accepted. Future Meetings Next, the ARG considered future meeting dates. The following dates were agreed: June 14-15, 1989, Madrid, Spain. Jean Ichbiah volunteered to find a suitable hotel in Madrid. October 25-26, 1989, Software Engineering Institute, Pittsburgh, PA. February 15-16, 1990, in New York City. Robert Dewar will host the meeting. Letter Ballot Results 1 Letter ballot results were announced (Y+P-N-A). 9 positive votes are needed for a commentary to be passed. Any negative or provisional approval votes require discussion. _______________ 1 Y: yes; P: yes, with editorial suggestions; N: no; A: no vote received. DRAFT-1 1 1989-03-13 Ada Rapporteur Group Minutes La Celle St. Cloud, France, 1989-02-27, 28 AI-00270/05 The properties of an object declared to have a private type *********** Approved (9-3-1) (Ichbiah, Lester, and Woodger voted no; Wichmann abstained.) AI-00341/14 Extra precision or range for fixed point representations *********** Not passed (7-6-0) (Barnes, Dewar, Goodenough, Lester, Mitchell, and Woodger voted no.) AI-00459/05 Precision and range of predefined numeric types *********** Approved (13-0-0). Discussion then turned to commentary AI-00270, since negative votes were received. AI-00270/05 The properties of an object declared to have a private type *********** Those voting against AI-00270 explained that AI-00270 was improperly presented as a letter ballot. On 88-06-05, this commentary was discussed while in editorial review state. Since the discussion resulted in considerable changes to the commentary, its previous approval should have been considered revoked. The chair agreed to return the commentary to work-item status, subjecting the commentary to further action at this meeting. Discussion then continued on the substance of the commentary. It was requested that compiler version numbers be added to the test results reported in Engle's comment, and furthermore, that the test results reference the version of the commentary being tested. Finally, the ARG asked that tests be run to check the treatment of the constant given in the example. Further discussion was then postponed until the afternoon. AI-00341/14 Extra precision or range for fixed point representations *********** Since AI-00341 was not approved, it was placed on the agenda for discussion. No one appeared to disagree with the substance of the commentary, namely, that an explicit specification of SMALL determines the value of SMALL for a fixed point base type, and hence, the accuracy of operations for that type. But several members were concerned about the effect of this recommendation on AI-00099, an approved commentary. The concern was expressed using the following example: DRAFT-1 2 1989-03-13 Ada Rapporteur Group Minutes La Celle St. Cloud, France, 1989-02-27, 28 type F1 is delta 0.5 range 0.0 .. 1.0; -- 1 type DF1 is new F1; -- 2 for DF1'SMALL use 0.125; -- 3 XDF1 : DF1; -- 4 Analysis of this example: - After line 1, F1'BASE'SMALL has not been determined. - The derivation at line 2 does not determine F1'BASE'SMALL. - According to AI-00341, the length clause at line 3 determines DF1'BASE'SMALL. However, 3.4(4) says that the set of values of the derived (base) type is a copy of the set of values of the parent (base) type. The set of values for a base type depends on the base type's value of SMALL, so F1'BASE'SMALL apparently must equal DF1'BASE'SMALL. Therefore, it would appear that the specification of SMALL for DF1, if accepted, implicitly specifies the value of SMALL for F1's base type, contradicting the discussion of AI-00099. More important, such an implicit "retroactive" specification of SMALL for a parent type is unexpected and potentially awkward for an implementation. - The object declaration at line 4 is a forcing occurrence for DF1, but is not considered to be a forcing occurrence for the parent type, F1. A straw vote was taken on whether it was considered useful (i.e., desirable) to have two fixed point types related by derivation whose base types had different values of SMALL. The vote was (7-2-4) in favor, although the reasoning for the above example apparently does not allow such a result. In trying to find a viewpoint that allowed the desired capability, it was suggested that perhaps one could consider that every fixed point type's values are the values of type UNIVERSAL_FIXED, but the accuracy of operations on these values would be dictated by the value of SMALL for the base type. This would allow types related by derivation to have the same set of values but would allow different values of SMALL for the base types. One objection to this possibility was the potential complexity of conversions between values having different SMALL values. For example, consider: package P is type F2 is delta 1.0/13 range 0.0 .. 1.0; for F2'SMALL use 1.0/13; procedure P (X : in out F2); end P; with P; package Q is type DF2 is new F2 delta 1.0/12; -- subprogram P is derived. for DF2'SMALL use 1.0/12; end; DRAFT-1 3 1989-03-13 Ada Rapporteur Group Minutes La Celle St. Cloud, France, 1989-02-27, 28 Calls to P must convert between values with a SMALL of 1/12 and values with a SMALL of 1/13. Such a conversion in general requires a division, a more time-consuming implicit change of representation than is generally considered consistent with the intent of implicit conversions applied when calling a derived subprogram. Moreover, such implicit conversions are dangerous because accuracy could be lost implicitly. For example: X : Q.DF2 := 1.0/12; ... P (X); Suppose P does not actually assign a new value to X. Because of the implicit conversion to type F2, the value of X after the call will not necessarily be equal to X's value before the call -- an unexpected and potentially dangerous result. This result occurs only because the model numbers of the derived type, DF2, are not a subset of the model numbers of its parent type, F2. It was then suggested that a specification of SMALL not be allowed for a parent type after a type derivation. This would allow an implementation to choose the parent type's SMALL at the place of the type derivation. Robert Dewar was asked to consider the issue for further discussion at the next day's meeting. 2 Discussion then turned to other commentaries. AI-00309/03 Aggregates with choices outside the aggregate's subtype *********** This commentary considers the legality of an aggregate: SS'(10 => 'A', others => D) when SS is a STRING(11..13) subtype. Given that no implementation tested rejects an aggregate that has a choice outside its applicable index constraint and that the standard is unclear about whether such aggregates should be considered legal, it was decided (10-0-0) that such aggregates should be considered legal and that their evaluation must raise CONSTRAINT_ERROR. AI-00318/04 [LB] Conformance rules and derived subprograms *********** It was noted that several implementations appear to disallow explicit subtype conversions in calls of derived subprograms. Despite this result, it was considered sufficiently important to allow such explicit conversions that commentary was nonetheless approved (6-0-4), subject to some editorial _______________ 2 An index to the commentaries that were discussed appears at the end of these Minutes. DRAFT-1 4 1989-03-13 Ada Rapporteur Group Minutes La Celle St. Cloud, France, 1989-02-27, 28 corrections. The following example was suggested as motivation for the importance of allowing such conversions: package P is type T is digits 5; procedure PROC (X : in out T); end P; with P; package Q is type NT is new T; -- derives PROC (X : in out NT) function ADDITIONAL (Y : NT); end Q; with Q; function R return FLOAT is X : Q.NT; Y : FLOAT; begin Q.PROC (Q.NT(Y)); -- 1 end R; Package Q is used to declare a new type that has the same subprograms as parent type P.T plus some new subprograms. The intention is to use the subprograms declared by Q as though they had all been declared explicitly. If the call of Q.PROC at (1) is illegal, such a use of derived types would not be allowed. A letter ballot was requested by Mike Woodger. AI-00473/02 Named associations for default array aggregates *********** It was agreed (9-0-1) that this commentary should be rewritten as a commentary to be considered during the revision of Ada, i.e., as a commentary in the "Study" class. In particular, the current rule specifying when named associations are allowed together with an OTHERS choice should be broadened to reflect the intent of the rule, namely, that such associations are allowed when no "sliding" of the index values is allowed. These are the contexts in which no implicit subtype conversion is applied to the aggregate. Such a rule would reflect the intent of the design. AI-00558/00 Specifying a collection size (Mitchell) *********** After discussion, the following points were approved (9-0-1): - If the specified storage size is zero or negative, no storage is reserved for the collection. DRAFT-1 5 1989-03-13 Ada Rapporteur Group Minutes La Celle St. Cloud, France, 1989-02-27, 28 - If a positive storage size is specified, an implementation must allocate at least the specified amount of space; reasonable "rounding up" of the specified amount is allowed, where reasonable is to be understood in terms of the implementation's usual algorithm for allocating space. The rounding algorithm must be specified in Appendix F. - No space beyond the initial allocation can be provided by an implementation, i.e., automatic extension of the amount of space is inconsistent with the intent of specifying a collection size. Mitchell agreed to provide a revision reflecting these points. AI-00608/01 The value of 'STORAGE_SIZE *********** After discussion, it was decided (9-0-0) that if a collection size has been specified for T's collection, T'STORAGE_SIZE returns the amount of space actually reserved for the collection. If no collection size has been specified, the effect of evaluating T'STORAGE_SIZE is either to return an implementation-defined value or to raise an exception such as PROGRAM_ERROR. AI-00270/05 The properties of an object declared to have a private type *********** After brief discussion, the commentary was approved (9-1-0). AI-00613/01 Invalid pragmas are not illegal *********** It was agreed that if a pragma does not appear at one of the places specified in 2.8(3-5), a program should be considered illegal. Further discussion of the conditions under which a pragma could be rejected was deferred until resolution of AI-00009, AI-00010, and AI-00509. In considering these commentaries, it was suggested that the following pragma be discussed: pragma UNK ('a''b); This pragma has the "form" of a name, since 'a' is syntactically a name, and a name can appear as the prefix of an attribute, i.e., the above argument is syntactically identical to NAME'B. No vote was taken on AI-00613. AI-00624/01 No operations are declared for a subtype declaration *********** Approved (10-0-0). DRAFT-1 6 1989-03-13 Ada Rapporteur Group Minutes La Celle St. Cloud, France, 1989-02-27, 28 AI-00640/01 Ensuring the effect of specifying SMALL *********** Approved (10-0-0). AI-00654/01 A discriminant part is not allowed for a derived type *********** Reclassified as a presentation commentary (9-0-1). AI-00738/01 Renaming a subcomponent of a constant *********** Approved (10-0-0). It was requested that an example be added illustrating the problem being discussed by the commentary. AI-00754/01 TIME is a type, and has no value *********** Reclassified as a presentation commentary (10-0-0). AI-00772/01 Elaboration order of secondary units *********** Reclassified as a presentation commentary (9-0-1). AI-00798/01 Static expressions in enumeration representation clauses *********** Reclassified as a presentation commentary (8-0-2). AI-00301/03 Representation clauses and nonstatic constraints *********** It was noted that the commentary was incorrect in suggesting that a record component clause can ever be given for a record component whose index or discriminant constraint depends on a discriminant. No vote was taken, however. TUESDAY, FEBRUARY 28, 1989 Ada Rapporteur Group members present were: Barnes, Dewar, Fisher, Goodenough, Hilfinger, Ichbiah, Lester, Mitchell, Pedersen, and Woodger. Apologies were received from Bardin, Eachus, and Wichmann. The following observers were also present during the meeting: DRAFT-1 7 1989-03-13 Ada Rapporteur Group Minutes La Celle St. Cloud, France, 1989-02-27, 28 Norman Cohen IBM Jean-Marc Chebat Alsys Jean-Pierre Rosen ENST AI-00341/14 Extra precision or range for fixed point representations *********** Discussion of AI-00341 was continued from the previous day. Robert Dewar proposed that derivation of a fixed point type be considered to determine the size and SMALL of the parent (base) type (if not already determined). The effect of determining these aspects of the type's representation is to determine the base type's set of values. The reason for suggesting that derivation be considered to determine the base type's size was illustrated by the following example: type F3 is delta 0.5 range 0.0 .. 1.0; type NF3 is new F3; for F3'SIZE use 32; If F3 and NF3 are to have the same set of values, then the size of NF3's base type must be determined by the size specification for its parent type, even though the size specification occurs after the type derivation. Paul Hilfinger suggested that it should be possible to change the size of a derived type without implying a change in the set of values: type F4 is delta ...; for F4'SIZE use 32; type NF4 is new F4; for NF4'SIZE use 16; A straw vote was taken to see how many people thought it would be acceptable to forbid a specification of both the size and the value of SMALL for a parent type after the parent type is used in a type derivation. Although there was general sentiment that it was probably desirable to forbid a specification of SMALL for a parent type after its use in a derivation, there was no agreement on whether the specification of 'SIZE should also be restricted. Robert Dewar agreed to prepare a further discussion of the issues. AI-00594/01 Sensible preemption by high priority tasks *********** After discussion, it was agreed (10-0-0) that the Standard intended task preemption to be supported in a "sensible" manner. In particular, the criteria for deciding when two tasks with different priorities can "sensibly" be executed using the same physical resources will differ depending on application requirements. In particular, multiprocessor execution can be simulated using a single processor, as described in comment 83-00945 and priority inversion can be minimized by allowing a low priority task to execute when necessary to unblock a high priority task. An implementation DRAFT-1 8 1989-03-13 Ada Rapporteur Group Minutes La Celle St. Cloud, France, 1989-02-27, 28 might also disallow preemption of a rendezvous because in some applications, it is not sensible to allow preemption in this case. In short, "sensibly" in 9.8(4) is to be interpreted sensibly. It was noted that AI-00594 should give a proper interpretation of AI-00032's discussion, which may be worded too strongly. AI-00536/04 [LB] The meaning of 'SIZE applied to a type or object *********** After considerable discussion, it was proposed that when a size specification has been given for a type T, the following invariants must hold, assuming that the specified size is V: - T'SIZE = V. - S'SIZE = T'SIZE for all subtypes, S, of T. - For any object, OBJ, of type T: - If OBJ is not a subcomponent, OBJ'SIZE >= T'SIZE. (OBJ'SIZE can be greater than T'SIZE if an implementation considers padding bits to be part of the object's size.) - If OBJ is a subcomponent, OBJ'SIZE may be larger or smaller than T'SIZE. The following example illustrates the implications of these rules: type SIZE_TYPE is (SMALL, LARGE); for SIZE_TYPE'SIZE use 1; type R (D : SIZE_TYPE := SMALL) is record case D is when SMALL => C1 : INTEGER; when LARGE => D1, D2, D3 : INTEGER; end case; end record; V : constant := 3*INTEGER'SIZE + SIZE_TYPE'SIZE; for R'SIZE use V; type W is array (1..10) of R(SMALL); pragma PACK (W); The value of R'SIZE is V. Each component of array W occupies at least V bits. A derived type could be used to get a more compact representation for an array with components of subtype R(SMALL), e.g., DRAFT-1 9 1989-03-13 Ada Rapporteur Group Minutes La Celle St. Cloud, France, 1989-02-27, 28 type SMALL_R is new R(SMALL); for SMALL_R'SIZE use INTEGER'SIZE + 1; type W1 is array (1..10) of SMALL_R; pragma PACK (W1); OBJ : W1; Although SMALL_R'SIZE has the value INTEGER'SIZE + 1, OBJ(1)'SIZE might have the value INTEGER'SIZE + 8, since pragma PACK allows reasonable use of padding bits. When no size has been specified for type T, the following invariants must hold (where S is any subtype of T): - T'SIZE >= S'SIZE. - For any object of type T, OBJ: - if OBJ is not a subcomponent, OBJ'SIZE >= S'SIZE, for all S. - if OBJ is a subcomponent, OBJ'SIZE can be less than T'SIZE or S'SIZE, where S is the subtype of the object. It was noted that when no size has been specified for a type, it can be difficult to compute a non-pessimistic upper bound for the size. For example, consider: type R (D1, D2, D3, D4, D5 : NON_STAT_INTEGER_TYPE := 0) is record C1 : T1 (D1 .. -5); C2 : T2 (D1 .. D2, D2 .. D1); C3 : T3 (D4, D5); end record; In particular, note that component C2 is either a null array or an array with one component, but few algorithms for computing R'SIZE would take this into account. Although it is difficult to compute the maximum size occupied by any object of type R, it is not hard to compute the size for any subtype of R. Hence, it is to be expected that R'SIZE will be greater than S'SIZE for any subtype of R. It should be noted that the recommended relationships between 'SIZE applied to a type, a subtype, and an object do not require that OBJ'SIZE bear any particular relation to T'SIZE when no size has been specified for T. In particular, OBJ'SIZE could be larger than T'SIZE if a record component clause has specified a particularly large amount of space to hold a component of type T. DRAFT-1 10 1989-03-13 Ada Rapporteur Group Minutes La Celle St. Cloud, France, 1989-02-27, 28 Ada Commentary Integration Document *********** Discussion then turned to the Ada Commentary Integration effort. The group first discussed and resolved several issues raised by Brian Wichmann: - If a commentary is relevant to several Chapters, the editors of each Chapter should communicate with each other to decide how the commentary will be treated. - Editors should be economical in deciding when to add notes or examples. In general, notes should only be added to forestall confusion on important issues. It should be kept in mind that in the attempt to make a note understandable, it might be worded less precisely than the rest of the Standard, and this imprecision can foster confusion rather than clarity. This is another reason for being restrained in adding notes and examples. - Issues raised in "presentation" commentaries should be addressed at the discretion of an editor. If the addition is accepted by the ARG in its review of a Chapter, this will constitute approval of the commentary. Approved presentation commentaries will not be presented individually to WG9 for consideration; instead, WG9's review of ACID will constitute acceptance of presentation commentaries that have been incorporated. It was requested that when a referenced commentary is a presentation commentary, the ACID footnote indicate this by adding the word "presentation" after the commentary number. Attention was then given to the drafts of Chapters 1 and 2 that had been prepared by Bryce Bardin. Several changes were made. Norman Cohen was asked to prepare one chapter draft in which references to syntax productions were given in a different font. It was noted that probably not all uses of a syntax term need be placed in such a font. For example, section 2.8 frequently uses the term "pragma" or "pragmas". It is not clear that all of these uses should be in the special font. In addition, the Standard uses plurals of syntax terms, e.g., "library unit bodies", and it is not clear how these should be treated if a special font is used. In discussing section 2.8, it was noted that the term "formal part" referred just to the declaration of subprogram formal parameters rather than to the declaration of the formal parameters of a generic unit (for which the term is "generic formal part"). Editors were asked to consider whether it would be feasible to use the term "subprogram formal part" instead in order to reduce a reader's potential confusion. AI-00556/03 Giving a size specification for an array type *********** Although no vote was taken, it was generally agreed that a size specification for an array type was limited to removing or adding leading bits from the DRAFT-1 11 1989-03-13 Ada Rapporteur Group Minutes La Celle St. Cloud, France, 1989-02-27, 28 entire array value. In particular, an array size specification is not allowed to change gaps between components or remove unneeded bits from components. The reason for this restriction is to disallow potentially expensive implicit conversions when a size specification is given for a derived array type that has derivable subprograms. It was not the intent to allow such conversions. Pragma PACK provides the only way to specify a more compact representation for an array type. Adjournment The meeting was adjourned after thanking Alsys for its efforts as host for the meeting. The following commentaries were on the agenda, but not discussed, for lack of time: AI-00009/05 Implementation-defined names cannot be reserved words AI-00010/07 The meaning of operations and identifiers in pragma arguments AI-00021/13 MACHINE_OVERFLOWS for correct extended safe results AI-00119/02 The prefix of an expanded name AI-00509/02 The legality of pragma arguments AI-00561/02 Size specifications for scalar types AI-00599/01 The representation of a derived type DRAFT-1 12 1989-03-13 Ada Rapporteur Group Minutes La Celle St. Cloud, France, 1989-02-27, 28 Index to Commentaries Ada Commentary Integration Document . . . . . . . . . . . . . . . . . . 11 AI-00270/05 The properties of an object declared to have a private type 2, 6 AI-00301/03 Representation clauses and nonstatic constraints . . . . . 7 AI-00309/03 Aggregates with choices outside the aggregate's subtype . . 4 AI-00318/04 [LB] Conformance rules and derived subprograms . . . . . . 4 AI-00341/14 Extra precision or range for fixed point representations . 2, 8 AI-00459/05 Precision and range of predefined numeric types . . . . . . 2 AI-00473/02 Named associations for default array aggregates . . . . . . 5 AI-00536/04 [LB] The meaning of 'SIZE applied to a type or object . . . 9 AI-00556/03 Giving a size specification for an array type . . . . . . . 11 AI-00558/00 Specifying a collection size (Mitchell) . . . . . . . . . . 5 AI-00594/01 Sensible preemption by high priority tasks . . . . . . . . 8 AI-00608/01 The value of 'STORAGE_SIZE . . . . . . . . . . . . . . . . 6 AI-00613/01 Invalid pragmas are not illegal . . . . . . . . . . . . . . 6 AI-00624/01 No operations are declared for a subtype declaration . . . 6 AI-00640/01 Ensuring the effect of specifying SMALL . . . . . . . . . . 7 AI-00654/01 A discriminant part is not allowed for a derived type . . . 7 AI-00738/01 Renaming a subcomponent of a constant . . . . . . . . . . . 7 AI-00754/01 TIME is a type, and has no value . . . . . . . . . . . . . 7 AI-00772/01 Elaboration order of secondary units . . . . . . . . . . . 7 AI-00798/01 Static expressions in enumeration representation clauses . 7 DRAFT-1 i 1989-03-13