MINUTES FOR THE MEETING OF THE ADA RAPPORTEUR GROUP JANUARY 18-19, 1988 NEW YORK CITY, NY, U.S.A MONDAY, JANUARY 18, 1988 Ada Rapporteur Group members present were: Bardin, Barnes, Belmont, Brender, Dewar, Eachus, Fisher, Goodenough, Hilfinger, Ichbiah, Lester, Pedersen, and Woodger. Apologies were received from Engle, Ferguson, Wichmann, and Hummel. The following observers were also present: Charles Mitchell Digital Equipment Corp. Norman Cohen IBM It was announced that people intending to attend the June ARG meeting in Munich would have to confirm their intention by April 1 to ensure that sufficient room space would be available. The Chair will send out a reminder notice at the beginning of March. There was some discussion of ARG procedures. It was informally agreed that in the future, if there were any negative votes on a letter ballot, the commentary would be discussed at the next ARG meeting. If the decision at that meeting is to affirm the commentary, no further letter ballot will be taken. If the decision is reversed or substantially extended (in the opinion of the Chair), a letter ballot can be requested. The Chair will prepare revised procedures for consideration at the next meeting. The Chair was asked to review with WG9 the procedures by which someone who is not a member of WG9 could become a member of the ARG. In particular, are such members appointed by the Chair? by the Group? by the Chair of WG9? Minutes of the September 1987 meeting were reviewed and accepted. It was agreed that the ARG would meet in the future as follows: June 6-7, in Munich, Germany Oct 31-Nov 1, Pittsburgh, PA (at the SEI) Feb 27-28, 1989, La Celle St. Cloud, France (Alsys) June 1989, Madrid, Spain AI-00005/05 'CONSTRAINED for a formal parameter that is a type conversion The commentary was approved (13-0-0) after recommending that 6.4.1(3) be quoted to show why conversion to a constrained type does not present any problem. FINAL 1 1988-11-14 Ada Rapporteur Group Minutes New York City, NY, U.S.A January 18-19, 1988 AI-00021/09 The value of MACHINE_OVERFLOWS The title should be changed to ``MACHINE_OVERFLOWS for correct extended safe results'' (13-0-0). AI-00333/05 Evaluation order when assigning an aggregate It was agreed that the left-hand side of the assignment statement must be evaluated first when the right-hand side is a positional aggregate or an aggregate with an others choice, since the aggregate cannot be evaluated until its bounds are known (13-0-0). AI-00361/12 Support for representation clauses The following positions concerning size specifications for integer types were discussed and approved, subject to final approval of the entire commentary: - The maximum size that must be supported is the size of the largest predefined integer type, excluding type universal_integer (11-0-2). - Signed and unsigned (unbiased) representations must be supported (12-0-1). - Support for biased representations is optional (11-0-2). - Support for a size specification of zero is optional (11-1-1). In considering the need for biased representations, it was argued that good support for biased representation pervades code generation, since one must always be concerned with the need to adjust a value for its bias. Sometimes the adjustment is not needed. The complexity of compiler support is such that it would be inappropriate to require every implementation to support biased representation. There was considerable discussion concerning whether record component clause specifications could reduce or expand the size allocated for an integer type even if a size specification has been given for that type. The following points were made: - JDI: If a suitable range constraint is given for a record component, a record component clause can be used to allocate just enough space to hold the specified range of values, even if this is less space than that specified by a size specification for the component's type. This is one of the reasons the Standard says a size specification gives an upper bound on the number of bits occupied by stored values of the type, i.e., a size specification says: "This is the size you get unless less space is required by another representation clause." - Another reason for giving a size specification is to ensure that unchecked conversion will work correctly. FINAL 2 1988-11-14 Ada Rapporteur Group Minutes New York City, NY, U.S.A January 18-19, 1988 - RB suggested that a record component clause could give a larger size for a component than that specified by a size specification for the type itself, i.e., such a size specification might not even be an upper bound. (Such additional space might be reserved for expansion purposes.) - JDI: It makes sense to consider a size specification as an upper bound because a subtype specification can only reduce the set of storable values, and hence, only reduce the amount of space needed. - RB: Suppose a base type occupies 16 bits, the longest integer type occupies 32 bits, and no size specification is given for the base type. Shouldn't it be possible to have a record component for that base type that occupies 32 bits? After all, an explicit 32-bit size specification could have been given. - It was argued that it is necessary to allow a size specification for records since that is the only way to get rid of extra components. - RBKD suggested that there should not be any hidden components when all constraints on subcomponents are static, whether or not an explicit representation clause is given. - There was considerable discussion of the need to have some components cross storage unit boundaries. It was not thought that this capability was needed for large component sizes, but there was no agreement on how to characterize the minimal size for which arbitrary bit alignment must be supported. Some of the criteria suggested were: * can you pick up the bits in one or two instructions? * is there a difference in criteria for a word-addressable machine vs. a byte addressable machine? * if the component could fit within a storage unit, then arbitrary alignment must be supported. * every implementation should be able to support commonly encountered data structures, e.g., structures used by the operating system or hardware associated with the machine, even when these structures require a component to cross one or more storage unit boundaries. - It was argued that crude support can always be provided for arbitrary alignment of any size component, e.g., by making a system call to extract or store values. Hence, for easy cases, the compiler should emit the code, but otherwise, it need only make a system call. - JDI: the issue is one of usability, not portability. There should be a standard set of representation clauses for each target. FINAL 3 1988-11-14 Ada Rapporteur Group Minutes New York City, NY, U.S.A January 18-19, 1988 - Since our goal is to specify the capabilities that must be supported by all implementations, we should be careful to require only capabilities that are essential, not merely desirable. Discussion closed on AI-361 without reaching agreement on the extent to which the alignment of record component clauses should be implementation dependent. AI-00301/01 Representation clauses and nonstatic constraints on access types The discussion was extended to cover the possibility of nonstatic constraints on scalar types. Are the restrictions in 13.2(6) and 13.4(7) only intended to apply to constraints for array types and types with discriminants? Does a constraint given for an access type affect the set of storable access values? Should the AI be extended to cover constraints on scalar types as well as access types? AI-00495/01 Specifying SIZE when a component depends on a discriminant It was argued that a binding interpretation should be issued stating that REC(10) has a static subcomponent constraint. There was concern about the use of implicit pointers for large record components, e.g., subtype SMALL is INTEGER range 0..1000; type R(D: INTEGER := 0) is record C1 : STRING (1..D); C2 : STRING (1..D); end record; If each string is represented by pointers to actual strings on the heap, what kind of size specification is allowable? Are records of scalar types and arrays of scalar types the only ones for which a size specification can be given? It was argued that the clause specified in the commentary was legal, but should never be accepted. The commentary will be redrafted to reflect a better definition of when a component constraint is static, using for inspiration, similar cases of entities that are nonstatic in generic templates but static in the instance. The meeting was adjourned for the day. Tuesday, January 19, 1988 Ada Rapporteur Group members present were: Bardin, Barnes, Belmont, Brender, Dewar, Eachus, Fisher, Goodenough, Hilfinger, Ichbiah, Lester, Pedersen, and Woodger. Apologies were received from Engle, Ferguson, Wichmann, and Hummel. The following observers were also present: FINAL 4 1988-11-14 Ada Rapporteur Group Minutes New York City, NY, U.S.A January 18-19, 1988 Charles Mitchell Digital Equipment Corp. Norman Cohen IBM AI-00304/02 Universal_integer includes more values than MIN_INT .. MAX_INT The commentary was approved (10-1-1). AI-00399/11 Status of library tasks when main program terminates There was some discussion about whether this draft of the commentary was intended to imply anything about when the result of the main program could be communicated to the programmer (e.g., could it be communicated before completion of the library tasks? could the operating system return control to the user before execution of the main program, or all library tasks, was complete?). It was decided to delete the paragraph that attempted to address these issues, since many options were possible and the paragraph only raised issues that need not be dealt with. After making a few other editorial changes, the commentary was approved (12-0-0). AI-00222/08 Executing a program Concern was expressed that the specific program model might be over-interpreted, i.e., it might be used to infer conclusions that could not really be justified based on the Standard. The wording of the commentary should therefore emphasize more strongly that the specific program is only intended to capture the specific findings stated in the commentary, and that it should not be used to make further inferences about the behavior of an Ada program. For example, the time at which the main program's result is communicated to the environment is implementation dependent, and might occur prior to termination of all the library tasks. Since the commentary was not intended to present any new conclusions, it was recommended that the paragraph dealing with the effect of a pragma PRIORITY on library unit elaboration be extracted into a separate commentary, as a binding interpretation. The commentary was then approved to be of class "no action", but was to be submitted to WG9 for consideration (8-0-5). AI-00548/00 Effect of pragma PRIORITY on library unit elaboration AI-00222/08 stated that "If a pragma PRIORITY appears at the outermost declarative part of the main program, this priority applies to the execution of the environment task (and thereby to the elaboration of library units as well as to the execution of the main program)." This conclusion was approved as a separate commentary (11-0-0). FINAL 5 1988-11-14 Ada Rapporteur Group Minutes New York City, NY, U.S.A January 18-19, 1988 AI-00341/11 [LB] A fixed point type can be represented with extra precision It was noted that the word "include" is used in 3.5.9(10) to cover the case when no length clause is supplied. It was further argued that if small is defined explicitly, then it determines the values of the type, i.e., any conversion to such a type must yield a model number, i.e., T'BASE'SMALL must equal T'SMALL when a small specification has been given for T. It was also argued that such a specification meant no extra accuracy could be provided in intermediate calculations involving type T. This position was approved (11-0-2). A letter ballot was requested. AI-00344/05 Model and safe numbers for real subtypes with no accuracy definition It was argued that since 4.6(7) mentioned "the accuracy of of the specified subtype" when discussing conversions involving real types, it was important to know what the model numbers of a subtype were. Others argued that since the conversion operation was an operation of the base type, 4.6(7) was misleading, but did not imply the need to define model numbers for a subtype. Nonetheless, the current conclusion of the commentary was considered harmless, and potentially helpful to an understanding of the Standard, and so it was approved, 9-2-2. AI-00547/00 Type conversion conformance for generic subprograms It was argued that the example might be more convincing if X were of type FLOAT. It was pointed out that renaming GET is not a solution, since conformance with the denoted subprogram is required for a type conversion. Finally, it was agreed that the type conversion in a call to a generic subprogram instance should be allowed if the name given in the conversion conforms to the name given in the instantiation (11-1-0). AI-00241/04 Conformance between a subprogram declaration and its subunit Considering that the proposed rule changed the legality of certain programs, it was voted to return to the recommendation of the previous version of this commentary. In the previous version, it was not required that names conform in a transitive manner; instead, pairwise conformance is sufficient and does not imply transitivity (13-0-0). AI-00309/01 Aggregates with choices outside the aggregate's subtype Before issuing an interpretation, it was requested that the Chair survey compilers to see how they treat examples like those given in the question. FINAL 6 1988-11-14 Ada Rapporteur Group Minutes New York City, NY, U.S.A January 18-19, 1988 AI-00473/01 Named associations for default array aggregates Before issuing an interpretation, it was requested that the Chair survey compilers to see how they treat examples like those given in the question. AI-00136/02 Implicit conversion rules It was noted that there were other cases where adding something to a package changes the meaning of programs without making them illegal. Given this finding, the commentary was approved, 13-0-0. AI-00536/00 [LB] Sizes of types with very large objects Approved 8-3-2. A letter ballot was requested. AI-00178/02 Semantics of parameter passing by reference The real issue here is under what circumstances certain subprogram calls are erroneous, since if certain forms of actual parameter imply that the parameters must be passed by copy, then any change to the actual parameter during the call would not make the call erroneous. In particular, the following forms of actual in parameters were considered. In each case, the question is whether a change to A during the call makes the call erroneous: - A + 0 - (A) - A(1..2) & A(3) It was suggested that perhaps only actual parameters having the form of a name can be passed by reference (although this rule would not necessarily be appropriate for a type conversion of a derived type). It was noted that pass-by-copy is always allowed. The key questions is when is pass-by-reference not allowed. No resolution was reached. AI-00183/03 Conformance rules are not used for overload resolution Approved, 9-0-1. The ARG unanimously passed a resolution of thanks to Robert Dewar for hosting the meeting. The ARG meeting was then adjourned. FINAL 7 1988-11-14 Ada Rapporteur Group Minutes New York City, NY, U.S.A January 18-19, 1988 Index to Commentaries AI-00005/05 'CONSTRAINED for a formal parameter that is a type conversion . 1 AI-00021/09 The value of MACHINE_OVERFLOWS . . . . . . . . . . . . . . . . 1 AI-00136/02 Implicit conversion rules . . . . . . . . . . . . . . . . . . . 7 AI-00178/02 Semantics of parameter passing by reference . . . . . . . . . . 7 AI-00183/03 Conformance rules are not used for overload resolution . . . . 7 AI-00222/08 Executing a program . . . . . . . . . . . . . . . . . . . . . . 5 AI-00241/04 Conformance between a subprogram declaration and its subunit . 6 AI-00301/01 Representation clauses and nonstatic constraints on access types 4 AI-00304/02 Universal_integer includes more values than MIN_INT .. MAX_INT 5 AI-00309/01 Aggregates with choices outside the aggregate's subtype . . . . 6 AI-00333/05 Evaluation order when assigning an aggregate . . . . . . . . . 2 AI-00341/11 [LB] A fixed point type can be represented with extra precision 5 AI-00344/05 Model and safe numbers for real subtypes with no accuracy definition . . . . . . . . . . . . . . . . . . . . . . . . . . 6 AI-00361/12 Support for representation clauses . . . . . . . . . . . . . . 2 AI-00399/11 Status of library tasks when main program terminates . . . . . 5 AI-00473/01 Named associations for default array aggregates . . . . . . . . 6 AI-00495/01 Specifying SIZE when a component depends on a discriminant . . 4 AI-00536/00 [LB] Sizes of types with very large objects . . . . . . . . . . 7 AI-00547/00 Type conversion conformance for generic subprograms . . . . . . 6 AI-00548/00 Effect of pragma PRIORITY on library unit elaboration . . . . . 5 FINAL 8 1988-11-14