ISO/IEC JTC 1/SC 22/WG 9 N 459 Disposition of Informal Comments Received on Editor's Draft of Amendment Prepared by Convener, 23 March 2006 Document N458, the minutes of meeting #49, provide that: "The text of the draft amendment is currently the property of AXE Consultants. It was prepared under a contract initiated by The MITRE Corporation at the direction of the US Department of Defense. AXE Consultants has been coordinating with WG9's Ada Rapporteur Group (ARG) to ensure that the draft meets the requirements of the ARG as specified in their disposition of Ada Issues. The document will also be informally circulated to WG9 for comment. After dealing with the comments, a draft will be produced that carries the copyright of AXE Consultants. ... When the time is appropriate to make the contribution, AXE Consultants will provide the document ..." In accordance with that plan, the convener requested AXE Consultants to circulate a draft of its proposed contribution to participants in WG9 for informal comment. The convener also requested AXE Consultants to prepare an informal disposition of the comments that were received. Below, you will find the text of those comments and the dispositions taken by AXE. The convener instructed AXE that the disposition should accept helpful comments to the greatest possible extent but should remain strictly within the scope that was previously approved by WG9 (Resolution 46-8 and N437) for the amendment. The informal comments received by AXE included four issues that AXE Consultants judged to be outside of the scope of the Amendment as approved by WG 9 in June 2004. Some of these issues are considered very important by the representatives submitting the comments. Accordingly, AXE set aside these four comments as falling outside the scope of the amendment, but recommended that WG 9 take up the question of whether they should be considered as candidates for future work. Here is a brief summary of each issue (the full comment can be seen in the disposition document that is attached). 1) [Comment 16] In addition to class inheritance implemented by parent-child packages, the standard should provide for class associations implemented by a flat package structure that allow limited visibility control of operations between peer packages. "limited access with" of "limited subprograms" is proposed to meet this need. 2) [Comment 17] Provide more detail on the nature of a file-related exception, by specifying that an implementation must include a descriptive message to the exception. 3) [Comment 12] Include bounded and protected or synchronized versions of the Container packages in the Ada standard. 4) [Comment 19] File names in some operating systems are case sensitive, while others are case insensitive. Ada.Directories should provide a mechanism to determine which is the case for the target system. The convener will table an agenda item for the June 2006 meeting to discuss the manner in which WG9 should pursue future work addressing those four comments. AXE has implemented the dispositions described below and has contributed the resulting document to WG 9 via the US National Body. The convener will initiate a 30-day letter ballot authorizing the convener to forward the draft to SC22 for balloting. = = = = = = Disposition of informal comments Prepared by AXE Consulting, 23 March 2006 This document lists (information) comments received by AXE consultants from Representatives of National Bodies of WG 9, and their dispositions. When there are multiple comments on the same issue, they are all presented first, then the disposition is given. Throughout this document, references to the "Amendment" should be understood to mean "the draft of the Amendment under preparation by AXE Consultants for eventual contribution to ISO/IEC JTC 1/SC 22/WG 9". -------- Comment 1.1 [UK]: We propose that the Amendment be changed in accordance with the attached AI-445 concerning Dynamic Ceilings and interrupt handlers. This entails adding a new paragraph to the dynamic semantics of D.5.2. This comment is supported nem con by the UK group IST/5/-/9 of the BSI commonly known as the Ada Panel. [The AI can be found on the ARG web site (www.ada-auth.org). - Ed.] -- Disposition: See disposition to next comment. -- Comment 1.2 [Germany]: D.5.2. (dynamic ceilings for protected objects) Alan Burns already described the problem and its solution as follows... please note that I changed the !wording a bit vs his originally proposed wording. (some of these changes are editorially necessary) [AI-445 is included with the following edited wording: If the locking policy Ceiling_Locking (see D.3) is in effect, then for a protected object P with either an Attach_Handler or Interrupt_Handler pragma applying to one of its procedures, a check is made that the value to be assigned to 'Priority is in the range System.Interrupt_Priority. If the check fails, Program_Error is raised.] [The AI can be found on the ARG web site (www.ada-auth.org). - Ed.] --- Disposition: The wording provided by Germany was used, with the correction that the cross-reference was moved to the preceding paragraph (which first mentions Ceiling_Locking in this subclause). -------- Comment 2 [Germany]: 3.10.2(10/2) "evaluated" should be "evaluates" Reason: the entire RM section is written in present tense; this one bullet should not use past tense, potentially implying a temporal relationship. --- Disposition: The change was made to the Amendment. ------- Comment 3 [Germany]: 7.3(20) "the parent type can be anything ..." should read "the parent type can be any type ..." Reason: "anything" is uncharacteristically informal. Taken literally, it isn't true, since the parent type cannot be an exception, label, etc. --- Disposition: The change was made to the Amendment. ------- Comment 4.1 [Switzerland]: The only comment the Swiss Delegation have is to agree with Matthew Heaney that the Position parameter of the Splice procedure described in a.18.3 (The Package Containers.Doubly_Linked_Lists) paragraph 115 should be mode "in" rather than "in out" as dpecified in the draft. --- Disposition: See disposition to next comment. -- Comment 4.2 [US]: There is an issue with the latest AI-302 draft, concerning the signature of the Splice operation for the list container. The operation is declared as follows: procedure Splice (Container: in out List; Before : in Cursor; Position : in out Cursor); The purpose of this operation is to move elements within the same list. Position specifies the element to move, and Before specifies to where it moves. The issue is that the Position parameter is mode in out, not mode in. But this is wrong, since the value of the Position cursor does not change its value. The problem with the signature as it exists now is that it's impossible to directly pass the result of a function as the value of the Position parameter. For example, to "rotate" elements in a list, you would like to be able to say: L.Splice (Before => L.First, Position => L.Last); This moves the last element to head of the list. You could go the other way, too: L.Splice (Before => No_Element, Position => L.First); This moves the head of the list to the foot. To do this with the current signature, you have to declare a temporary variable: declare C : Cursor := L.Last; begin L.Splice (Before => L.First, Position => C); end; But this is much worse, because Position must be a variable, which means that its value can change in between its declaration and the call to Splice. The only reason Splice is declared this way is because its semantics are described as follows: Equivalent to Splice (Target => Container, Before => Before, Source => Container, Position => Position); The Splice operation to which the description refers is declared this way: procedure Splice (Target : in out List; Before : in Cursor; Source : in out List; Position : in out Cursor); The fact that Position has mode in out makes sense in this case, since this two-list version of Splice potentially moves the element designated by Position from one list to another. (The representation of type Cursor includes a reference to the container itself, so if the element moves to a different container, then the cursor value must change.) But in the one-list version of Splice, the element stays within the same container, so Position does not change its value. In fact, if an implementation of Splice were to change the value of the Position parameter then the implementation would be broken! Yet the parameter is still declared as in out. The only reason Splice is declared this way is because of the *description* of the semantics, not because of the semantics per se. The description, and the signature of the Splice operation, need to change. --- Disposition: See disposition to next comment. -- Comment 4.3 [Belgium]: Clause: "A.18.3 The Package Containers.Doubly_Linked_Lists" (both on pages 201 and 205) Correction of signature of 3rd version of "procedure Splice". The specification of that procedure now is: procedure Splice (Container: in out List; Before : in Cursor; Position : in out Cursor); It should be: procedure Splice (Container: in out List; Before : in Cursor; Position : in Cursor); In other words: the formal parameter Position should have mode "in" instead of "in out". Rationale: On page 205, the description states that the 3rd version of Splice is equivalent to the 2nd version when the same container object is given for both the Target and Source formal parameters. From the description of the 2nd version of Splice, it follows that the Position parameter is only updated if Source and Target denote a different container object and hence the element is moved to another container. If Source and Target denote the same container object, the element is not moved to another container and Position does not (should not) change. Therefore, in the 3rd version of Splice, Position does not change and mode "in" better reflects the actual use of the parameter. Meta-rationale: The "Ada95 Quality and Style Guide", section "5.2.4 Mode Indication", gives as guideline: "[...] Use the most restrictive parameter mode applicable to your application.", with as rationale "[...] Use the mode that reflects the actual use of the parameter." Cf. . --- Disposition: The specification of Splice was changed as requested. The description of the four parameter version of Splice was changed to make it clear that the Position is unchanged when the Source and Target are the same container. (This was necessary because the value of Position on return was unspecified in that case.) The description of the three parameter version of Splice was changed to use wording rather than an equivalence: If Position is No_Element then Constraint_Error is propagated. If Before does not equal No_Element, and does not designate an element in Container, then Program_Error is propagated. If Position does not equal No_Element, and does not designate a node in Container, then Program_Error is propagated. If Position equals Before there is no effect. Otherwise, the element designated by Position is moved immediately prior to Before, or, if Before equals No_Element, after the last element. The length of Container is unchanged. This is essentially the same wording as the four parameter version with the unnecessary parts dropped. Note that the equivalence still doesn't work, as such a call would be illegal; even though the meaning would be clear, we don't want to write illegal things in the wording of the Standard. ------- Comment 5 [US]: There are a number of problems with the stream wording. AI-444 outlines the problems and fixes. [The AI can be found on the ARG web site (www.ada-auth.org). - Ed.] --- Disposition: The changes requested by the AI were made to the Amendment. ------- Comment 6 [France]: The note in 4.5.2(33) says: "No exception is ever raised by a membership test, by a predefined ordering operator, or by a predefined equality operator for an elementary type, but an exception can be raised by the evaluation of the operands. A predefined equality operator for a composite type can only raise an exception if the type has a tagged part whose primitive equals operator propagates an exception." This note is certainly misleading, and probably incorrect. Formally it doesn't matter because it's non-normative text, but we try to avoid lying in notes, so it seems that the best course of action is to remove the note entirely. Trying to fix it would amount to paraphrasing other normative text, which would not be helpful. The problems with this note include: 1 - For floating-point types, comparisons involving a signaling NaN are sure to raise some exception. We don't want implementers to believe that they have to go through hoops to detect sNaNs. Formally an sNaN is an invalid value and its evaluation may raise an exception as explained in 13.9.1(9). However on some (most?) architecture it is the comparison, not the evaluation, that raises an exception. The user may not be able to tell the difference, but the note is still confusing and unhelpful. 2 - For abnormal values, evaluation of the operands is erroneous and anything can happen, including an exception. 3 - For type Ada.Tags.Tag, equality can be erroneous if the tag identifies a type that does not exist in the partition. Again, anything can happen, including an exception. Rather than describing all these cases in the note, it seems better to just drop it. --- Disposition: The note was removed from the Standard (that is, an instruction to delete it was added to the Amendment). ------- Comment 7 [Canada]: RM 3.9 (25.2/2) Missing reference to master. Reason: First use in document. --- Disposition: A cross-reference "(see 7.6.1)" was added to the paragraph. ------- Comment 8 [Canada]: Prefix Dereference Problem: There appears to be a lack of clarity in the proposed amendment for Ada 2005. Under section 3.10.1; In paragraph 8 we have; If such a name denotes a tagged incomplete view, it may also be used: - as the subtype_mark defining the subtype of a parameter in a formal_part; - as the prefix of an attribute_reference whose attribute_designator is Class; such an attribute_- reference is restricted to the uses allowed here; it denotes a tagged incomplete view. And for paragraph 10 we have; Replace paragraph 10: [AI95-00217-06; AI95-00326-01] A dereference (whether implicit or explicit - see 4.1) shall not be of an incomplete type. by: A prefix shall not be of an incomplete view. The highlighted proposed wording for paragraph 10 seems to conflict with the highlighted proposed wording for paragraph 8. Paragraph 10 needs to be reworded to provide better clarity. For example, should this read? A prefix shall not be used to dereference an incomplete view. --- Disposition: AXE agrees that this wording is confusing. The wording is technically correct, as a subtype name used as a prefix is not "OF an incomplete view". But depending of the use of "of" rather than "is" seems unnecessarily tricky. The suggested fix isn't correct, however, as the sentence is intended to cover more than just dereferences. Consider the following, for instance: package Something is type T is tagged record ...; end Something; limited with Something; package Interesting is procedure Size_It (Param : in Something.T); end Interesting; package body Interesting is procedure Size_It (Param : in Something.T) is begin ... Param'Size ...; end Size_It; end Interesting; The rule needs to prevent taking 'Size here, as representation information is not available for the incomplete view T. OTOH, there is no reason for the rule to cover types and subtypes at all; paragraph 8 and the others already cover those cases. Therefore paragraph 10 was replaced by: A prefix that denotes an object shall not be of an incomplete view. ------- Comment 9 [US]: Attached is an AI [AI-443 - Ed.] that addresses the current inconsistency in the rules relating to how "synchronized-ness" is inherited, where for interfaces it is *not* inherited from other interfaces, but for private extensions, it *is* inherited from any interface ancestor, and in fact can't be specified explicitly. By contrast, "limited-ness" is not inherited by private extensions from their interface ancestors, and *must* be specified explicitly if it is desired. There are two implications of this inconsistency which this AI explains, and ultimately the AI comes to the conclusion that we should eliminate this inheritance of "synchronized" and instead allow/require it to be respecified as with "limited" for private extensions, hence: type Synch_T is synchronized new Lim_Intf with private; would be the syntax when defining a private extension representing a partial view of a synchronized tagged type. Unfortunately this is not something that can easily be delayed to a future revision of the standard, as these inheritance rules will be very difficult to change later without incurring significant upward incompatibility. [The AI can be found on the ARG web site (www.ada-auth.org). - Ed.] --- Disposition: The syntax and wording changes made by this AI were applied to the Amendment. ------- Comment 10 [US]: The portion of AI-329 that changes the behavior of Raise_Exception should be a Binding Interpretation rather than an Amendment. (That is, it should apply to Ada 95 implementations as well as Ada 2005 implementations.) There are a number of reasons for this position: 1. The inconsistency was judged to be insignificant during the original deliberations on the AI. Moreover, many programs encountering the inconsistency actually have a bug (they meant to raise an exception, but will not). The change actually will help them discover their error (or mitigate it). As such, there is no important reason to delay making the change, and it will eliminate bugs from some programs. 2. There are two inconsistent changes made to Ada.Exceptions in paragraph 11.4.1(14/2). One of them (from AI-241) is classified as a Binding Interpretation, the other (from AI-329) is classified as an Amendment. The two changes are of a similar degree (if anything, AI-241 is a more serious inconsistency; we know that some programs depend on the old behavior); it is very bizarre to treat them differently. The categorization of AI-241 was carefully considered (and changed) at an ARG meeting; so it seems that the categorization of (part of) AI-329 is what is inconsistent. 3. There is a non-zero implementation cost in supporting both implementations in a compiler that supports both Ada 95 and Ada 2005. The behavior could be confusing in a mixed-mode program that contains both Ada 95 and Ada 2005 units; that complicates maintenance for no good reason. Thus, we conclude that the Raise_Exception portion of AI-329 should be classified as a Binding Interpretation. --- Disposition: This comment doesn't directly change the contents of the Amendment, although it does impact the related documents. In order to make the related documents correct, AI-329 was split into two parts; the Raise_Exception change was assigned AI-446. As the original status was approved by the ARG and WG 9, it will be necessary for those groups to approve the change. AXE recommends that the ARG Rapporteur schedule a vote on the classification as soon as possible. ------- Comment 11 [US]: In the containers library, A.18.3(71/2), the wording for the semantics of "=" seems over-specified. It seems to require that "=" are called in a particular order, and doesn't make clear that "short-cutting" the evaluations of "=" once a False result is found is allowed. We suggest replacing the wording of this paragraph after "otherwise" with: ... Otherwise, it compares, in an arbitrary order, the elements in Left to the corresponding elements in Right using the generic formal equality operator. If any such comparison returns False, the function returns False; otherwise it returns True. It is unspecified whether all comparisons are performed if at least one returns False. Any exception raised during evaluation of element equality is propagated. Similar changes should be made in A.18.2(99/2), A.18.4(21-24/2), and A.18.7(20/2). --- Disposition: This comment is based on a mistaken premise. These paragraphs, which give the canonical semantics, need to be read in the context of the complete Standard. Looking at A.18.2(99/2): The number of times and with which arguments that formal "=" is called is unspecified by A.18.2(83/2). Thus, the "=" operation can be short-circuited, or fully evaluated, or anything in between. And the order of the calls is also unspecified. That goes for *every* routine that uses "=", not just this one. This wording is supposed to define the canonical semantics. The suggested change is not helpful because it duplicates (slightly differently) existing "unspecified" wording. We don't want to make it appear that more things are unspecified than really are. Thus, the only changes that should be made here are the simplified wording that was originally suggested and to add an AARM implementation note so that such misunderstandings don't happen again. The paragraph now reads: If Left and Right denote the same vector object, then the function returns True. If Left and Right have different lengths, then the function returns False. Otherwise, it compares each element in Left to the corresponding element in Right using the generic formal equality operator. If any such comparison returns False, the function returns False; otherwise it returns True. Any exception raised during evaluation of element equality is propagated. The new AARM note reads: Implementation Note: This wording describes the canonical semantics. However, the order and number of calls on the formal equality function is unspecified for all of the operations that use it in this package, so an implementation can call it as many or as few times as it needs to get the correct answer. Specifically, there is no requirement to call the formal equality additional times once the answer has been determined. The same applies to A.18.3(71/2) (A.18.3(55/2) covers it). For A.18.4(21-4/2), A.18.4(3/2) covers the "unspecified" part; I don't see how to "simplify" the wording, so I only will add the AARM note. Similarly, for A.18.7(20/2), A.18.7(3/2) covers the "unspecified" part; I don't see how to "simplify" the wording, so I only will add the AARM note. -------- Comment 12 [Canada]: Ada.Containers is a useful set of packages for sequential programs in a system where dynamic storage or concurrency is not an issue. This, however, does not correspond to many of the interesting areas which Ada programs address. It is imperative that bounded and protected or synchronized versions of these packages be included in the Ada standard. It is our position that a delay in the release of the standard is acceptable to incorporate this work. When this happens, a corresponding set of unbounded packages should be included. However, since Ada has new capabilities, such as interfaces, which might permit a preferrable way of adding synchronization and user-defined storage pools to containers to achieve the bounded or synchronized behaviour, we would consider a JTC1 TR to provide these capabilities, provided this is made a priority item. --- Disposition: The issue identified was discussed several times at various levels of the process; certainly on Ada Comment. The conclusion was always the same; alternative forms of the containers should be left for future work. The containers were designed to meet 90% of the needs, and clearly that will leave some needs out. Moreover, they were designed to provide a foundation and template for future extensions to the library of containers. The AI that introduces the containers specifically mentions bounded forms as an area for future work. Therefore this suggestion would seem to be beyond the approved scope of the amendment project. We note that the final paragraph of the comment suggests that this addition could be the subject of future work rather than the current amendment. Obviously, AXE Consultants is in no position to promise a TR or any other WG 9 work. Therefore, AXE has made no change in the current Amendment but has forwarded the issue to the convenor of WG 9 so that the question of future work may be considered. -------- Comment 13 [Canada]: RM 3.2 (8/2) Suggested wording: "... its constraint with the exclusion of the null value ..." Reason: Reads clearer. --- Disposition: The suggested change may read clearer, but it would have the wrong meaning. The original sentence is: "The set of values of a subtype consists of the values of its type that satisfy its constraint and any exclusion of the null value. " "satisfy" is a technical term in this context. "with" is a modifier, while "and" is a connector. "Constraints" and "exclusions" are separate, unrelated, properties. An "exclusion" does not modify a constraint; it is in addition to it. I tried a number of options to improve the sentence, but they just made it longer, not clearer. For instance, "The set of values of a subtype consists of the values of its type that satisfy its constraint and that also satisfy any exclusion of the null value." Moreover, this sentence was wordsmithed by the ARG; the current wording was discussed and approved at the York meeting by an 8-0-0 vote. Thus, there was no change made. -------- Comment 14 [Canada]: RM 3.2 (11/2) Suggested wording: "These language-defined categories and classes are organized liked these: ..." Reason: Some entities in the list are classes. --- Disposition: All classes are also categories (but the reverse is not true). Including "classes" here would add unnecessary words and might induce some confusion regarding the existing clear relationship - "classes" are only relevant to derived types and not other kinds of types. In particular, they're not relevant when discussing types in general, as we're doing here. Moreover, "categories and classes" could be read to mean that all of these things are classes, which is clearly not true. That would confuse the distinction between "classes" and "categories" further. So no change was made here. -------- Comment 15 [Canada]: RM 3.9.2 (11/2) default_expresssion for a formal controlling parameter. We question the meaningfullness of this capability and thing that controlling parameters should not allow default expressions. --- Disposition: Ada 95 allows default expressions on controlling parameters. It would be incompatible to ban them now, and there would need to be a strong justification for such an incompatibility. "questioning the meaningfullness of this capability" doesn't seem to be a justification for introducing an incompatibility. Given that there was no reason to change the existing rule for regular controlling parameters (nor did anyone suggest it, so far as I know), the ARG decided to remove the restriction on access parameters, as it was there only because there were not tag indeterminate access functions -- but those have been added in Ada 2005. As a counterexample, Claw uses default parameters for controlling parameters in a couple of instances. It usually happens when there are multiple controlling parameters for an operation, and the secondary ones are optional in some sense. Remember that Ada is different from most other OOP languages in not having exactly one controlling parameter; Ada allows multiple controlling parameters and even controlling results. So I think banning such parameters would in fact be a *real* incompatibility; real existing programs would break. Thus, I'm not taking any action on this comment. -------- Comment 16 [Canada]: Proposal: Limited Subprograms (a.k.a. Friend Operations) Problem: In framework architecture, some class operations are available to client classes (APIs), some are internal to classes in the framework. Using (private) child packages to control class visibility is not flexible, it forces one to organize the classes in a hierarchical package structure. The class structure and the package structure do not necessary correspond. What is really needed, in addition to class inheritance implemented by parent-child packages, is class associations implemented by a flat package structure, yet allowing limited visibility control of operations between peer packages => need something similar to friend operations in C++. Friend types are not allowed because it breaks encapsulation. Friend operations do not break encapsulation. Proposed Solution: limited access with Frame; limited access with Frame_Manager; package Widget is type Widget_Class is private; ... limited procedure Draw (This : in out Widget_Class) with Frame; limited function Is_Enable (This : in Widget_Class) return Boolean with Frame, Frame_Manager; private type Widget_Class is ...; end Widget; a. The limited access with allows circular type dependency between Frame, Frame_Manager and Widget, in addition, these packages can also appear in the limited subprogram with clause. with_clause ::= limited_with_clause | nonlimited_with_clause limited_with_clause ::= limited [access | private] with library_unit_name {, library_unit_name}; nonlimited_with_clause ::= [private] with library_unit_name {, library_unit_name}; b. We disallow access private with, otherwise it defeats the purpose of using a flat package structure. c. The limited subprogram specifies Draw() can be called from Frame, Is_Enable() can be called from Frame and Frame_Manager. d. A limited subprogram can only be defined in the public part. e. The packages specified in the limited subprogram with clause must be the limited access with packages. f. The limited subprogram with clause says the subprogram is only visible to the limited access with packages. g. Visibility checks are determined at compile time. This proposal involves language construct changes. If it is too short a time to review its impact on the rest of the language for the current amendment, we would consider a JTC1 TR to implement this proposal, and add this capability to the language in 2 to 3 years. --- Disposition: This is a new idea with no obvious relationship to any of the new facilities of Ada 2005, and thus is outside of the scope approved by WG 9. We've not taken new ideas, even from WG 9 NBs, since January 2005. We note that the final paragraph of the comment suggests that this addition could be the subject of future work rather than the current amendment. Obviously, AXE Consultants is in no position to promise a TR or any other WG 9 work. Therefore, AXE has made no change in the current Amendment but has forwarded the issue to the convenor of WG 9 so that the question of future work may be considered. -------- Comment 17 [Canada]: A.16 The Package Directories - Exceptions Problem : The exceptions raised when manipulating files or directories are not always sufficient for determining the source of the error. For example, when a file is created by one user and another user attempts to modify the file, a Naming Error exception may occur due to the restrictive file permissions that exist. In this example, one may assume incorrectly that the file does not exist, when in fact it does. Solution : Provide more detail on the nature of a file-related exception, specify that an implementation must include a descriptive message to the exception. --- Disposition: The meanings of the IO_Exceptions was defined by Ada 83, and has changed little since. An implementation that raised Name_Error as explained above would be wrong (Use_Error is the appropriate exception). Requiring a descriptive message on raises of IO_Exceptions is a new idea outside of the scope approved by WG 9. (It makes little sense to restrict this to exceptions raised by Ada.Directories; argubly, it shouldn't even be restricted to IO_Exceptions, but rather apply to all exceptions raised by checks or by language-defined package.) Thus it is clearly too late for this process. Most compilers already do this anyway, and it seems as if there may be some embedded targets for which the space overhead would be inappropriate. Thus, this idea would need careful consideration. Moreover, it would not cause any compatibility issues if it was added in the future, so there no compelling reason to consider it now. Thus, this idea would be better considered at some an appropriate point in the future. This would allow WG 9 to consider all contexts in which this idea should be implemented. Obviously, AXE Consultants is in no position to promise future WG 9 work. Therefore, AXE has made no change in the current Amendment but has forwarded the issue to the convenor of WG 9 so that the question of future work may be considered. -------- Comment 18 [Canada]: Section 4.1.3 Prefix Naming There is no reference to the section on Prefix Naming in the index. An entry should be added so a user may easily locate the section. --- Disposition: There is no such thing as "prefix naming" or "prefix name". The concept is called a "prefixed view" of a subprogram; that term is in the index. Given that it is in exactly the place that "prefix naming" would occur if that term was in fact indexed, it doesn't seem likely that anyone would fail to look up "prefixed view" if they were looking for this term. In any case, it's not helpful to index things that don't occur in the text. No change was made. -------- Comment 19 [Canada]: Case sensitivity in Directories, Environment_Variables Case sensitivity is an implementation issue, but these packages currently ignore the issue. This has the unfortunate effect that programs written to be portable cannot account for operating system differences. This is a serious issue, because the 2 most common OS's differ in the issue of case sensitivity. A new enumeration type and two subprograms are required type Case_Sensitivity is (Upper, Lower, Mixed); -- mixed means case sensitive, Upper and Lower are case -- insensitive but the interpretation is upper or lower. function Is_Case_Sensitive return Case_Sensitivity; -- returns current behaviour, or default behaviour if -- Set_Case_Sensitive has not been called. procedure Set_Case_Sensitive( Sensitivity : in Case_Sensitivity ); -- Sets case sensitivity Since the type Case_sensitivity is common to Directories, Sequential_IO, Text_IO, etc so we recommend putting them in Environment_Variables or Directories. --- Disposition: AXE submitted this comment to the ARG for suggestions. The proposed solution was regarded as too general, but there was no agreement on an alternative solution. There seemed to be a consensus that alternative facilities could easily be added as a child package in the future, so it is not necessary to address this at this point. The complete ARG e-mail thread is filed in AI-248. Obviously, AXE Consultants is in no position to promise future work by WG 9. Therefore, AXE has made no change in the current Amendment but has forwarded the issue to the convenor of WG 9 so that the question of future work may be considered. -------- Comment 20 [Canada]: Problem: There is an imbalance in the proposed new syntax for Ada 2005 with regard to null exclusion. Specifically, the new syntax allows the programmer to explicitly specify whether an access type excludes the null value, but there currently are no means for a programmer to explicitly specify whether an access type includes null. To exclude null, the programmer can add the clause "not null" to an access type definition in Ada 2005. In order to allow the programmer to specify that an access type can be assigned null values, the clause "accept null" seems like it would fit naturally into the syntax to convey that meaning. Conceptually, an accept statement in Ada defines which operations can be performed on a particular task. Here we are defining an operation that can be performed on a particular access type. Therefore, the following could all be valid; type my_access_type is access foo; --- Defaults to either not null or accept null depending on context as per Ada 2005 type my_access_type is not null access foo; -- Cannot be assigned null values type my_access_type is accept null access foo; -- Can be assigned null values The first form would be considered a short hand for either the second or the third form depending on whether the usage was for a controlling access type or not. Having a means to explicitly specify whether or not a type can accept null values helps to reduce the inconsistency in the treatment of the first form for controlling vs non-controlling access types. There is no inconsistency when the second or third form is used. Having the third form means that there would always be a way to eliminate this inconsistency. This new proposed syntax means that the programmer will have a way to express exactly how the access type can be used with respect to null values. If the programmer specifies either "not null" or "accept null" then it is clear that the programmer has considered null usage, and further it allows the compiler to flag errors when the programmer is intending to use an access type in a manner that is not permitted. For example, if a programmer specifies "accept null" for a controlling access type, the compiler would generate an error at compile time. This also improves software maintainability and improves safety. For example if code is written where an access type can accept null, and later that code is modified so that the access type is made to be a controlling access type, the compiler can flag the need for changing the null exclusion whereever it is needed. If the first form is used, then there is an implicit change in how null values can be assigned which might introduce run time failures into the code. Note also that this feature can be added to the language without adding any new reserved words. The overriding and not overriding clause was added to Ada 2005 for very similar reasons, and apparently the reasons were considered strong enough to warrant adding a new reserved word to the language. Finally, note that it seems likely this feature would be relatively easy to implement for compiler vendors. Proposed revisions to AMENDMENT 1 (Draft 15) to support null_inclusion specification ------------------------------------------------------------------------- Section 3.10 Replace paragraph 2: [AI95-00231-01] access_type_definition ::= access_to_object_definition | access_to_subprogram_definition by: access_type_definition ::= [null_exclusion_indicator] access_to_object_definition | [null_exclusion_indicator] access_to_subprogram_definition Replace paragraph 6: [AI95-00231-01; AI95-00254-01; AI95-00404-01] access_definition ::= access subtype_mark by: null_exclusion_indicator ::= [null_inclusion | null_exclusion] null_inclusion ::= accept null null_exclusion ::= not null access_definition ::= [null_exclusion_indicator] access [constant] subtype_mark | [null_exclusion_indicator] access [protected] procedure parameter_profile | [null_exclusion_indicator] access [protected] function parameter_and_result_profile Replace paragraph 13: [AI95-00230-01; AI95-00231-01] For each (named) access type, there is a literal null which has a null access value designating no entity at all. The null value of a named access type is the default initial value of the type. Other values of an access type are obtained by evaluating an attribute_reference for the Access or Unchecked_Access attribute of an aliased view of an object or non-intrinsic subprogram, or, in the case of a named access-to-object type, an allocator, which returns an access value designating a newly created object (see 3.10.2). by: For each access type, there is a null access value designating no entity at all, which can be obtained by (implicitly) converting the literal null to the access type. The null value of an access type is the default initial value of the type. Non-null values of an access-to-object type are obtained by evaluating an allocator, which returns an access value designating a newly created object (see 3.10.2), or in the case of a general access-to-object type, evaluating an attribute_reference for the Access or Unchecked_Access attribute of an aliased view of an object. Non-null values of an access-to-subprogram type are obtained by evaluating an attribute_reference for the Access attribute of a non-intrinsic subprogram. A null_inclusion in a construct specifies that the null value does belong to the access subtype defined by the construct, that is, the access subtype includes null. A null_exclusion in a construct specifies that the null value does not belong to the access subtype defined by the construct, that is, the access subtype excludes null. In addition, the anonymous access subtype defined by the access_definition for a controlling access parameter (see 3.9.2) excludes null. Finally, for a subtype_indication without a null_exclusion_indicator, the subtype denoted by the subtype_indication excludes null if and only if the subtype denoted by the subtype_mark in the subtype_indication excludes null, otherwise the subtype denoted by the subtype_mark in the subtype_indication includes null. Replace paragraph 22: [AI95-00433-01] type Peripheral_Ref is access Peripheral; -- see 3.8.1 type Binop_Ptr is access all Binary_Operation'Class; -- general access-to-class-wide, see 3.9.1 by: type Peripheral_Ref is not null access Peripheral; -- see 3.8.1 type Binop_Ptr is accept null access all Binary_Operation'Class; -- general access-to-class-wide, see 3.9.1 Section 3.10.1 Replace paragraph 7: [AI95-00326-01; AI95-00412-01]  as the subtype_mark defining the subtype of a parameter or result of an access_to_subprogram_definition; by:  as the subtype_mark in the subtype_indication of a subtype_declaration; the subtype_indication shall not have a null_exclusion_indicator or a constraint; --- Disposition: AXE submitted this comment to the ARG for suggestions. A number of objections were raised to this comment: * Too large a change at this late point in the process; * This would be "optional" syntax; the ARG has been very opposed to such syntax, ruthlessly eliminating it from proposals wherever possible; * Little compile-time checking would be added, because subtype constraints are generally checked only at runtime; * The proposed feature would introduce subtypes that allow more than their parent subtype, which is a new concept in the language; * Stylistic issues (such as coding rules) are outside of the scope of the standard, and in any case we don't have enough experience with this feature to be able to formulation appropriate rules. There was some concern that there is no way to get a null-including subtype from a null-excluding first subtype, but there was no agreement that this was an important problem. The suggested solutions could be added at a later date without any compatibility concerns, so there is no need to act now. There was some interest in various solutions to this problem, so a letter ballot was taken to try to determine the depth of interest and to bound the technical solutions to the issue. The proposal from this comment was clearly thought to be not worth it at this time. Thus, no change was made to the Amendmnent. There was interest in reducing the compatibility issues; an AI (AI-447) to allow Ada 95 compilers to implement "not null" in access parameters and discriminants has been prepared and placed on the agenda of the next ARG meeting. Note that this doesn't require any change to the Amendment. The complete ARG e-mail thread is filed in AI-447. -------- Comment 21 [Canada]: Although moving a file or directory may be accomplished by calling a copy followed by a delete operation, to the user, the action should be atomic. Therefore, separate Move procedures should be made available in the Directories package. procedure Move_Directory (Source_Directory : in String; Target_Directory : in String); procedure Move_File (Source_Name : in String; Target_Name : in String); --- Disposition: "Move" is essentially the same as "Rename", which is already present in Ada.Directories. That is, the proper way to do this operation atomically is to rename the source to the target. If that doesn't work, it's probably not possible to atomically do the operation on the target system - implementers don't intentionally cripple operations. Indeed, on Windows, "Rename" would be implemented with Move_File (even for directories). The ARG was asked whether either a renames of "Rename" to "Move", or a user note to explain the similarity was appropriate. The ARG was mostly in favor of the note and against the rename. Thus a user note was added to the end of the notes in A.16: To move a file or directory to a different location, use Rename. Most target systems will allow renaming of files from one directory to another. If the target file or directory might already exist, it should be deleted first. The complete ARG e-mail thread is filed in AI-248. -------- Comment 22 [Belgium]: Clause: "Introduction" [of the Amendment] (middle of page 3) Correction of the reference to containers in the 7th bullet of the 2nd bullet list. The text now reads: Additional standard packages, including time management (see 9.6), file directory and name management (see clause A.16), containers (see clause A.17), execution-time clocks (see clause D.14), timing events (see clause D.15), and vector and matrix operations (see clause G.3); It should be: Additional standard packages, including time management (see 9.6), file directory and name management (see clause A.16), containers (see clause A.18), execution-time clocks (see clause D.14), timing events (see clause D.15), and vector and matrix operations (see clause G.3); In other words: the reference to containers should be "clause A.18" instead of "clause A.17". --- Disposition: The section reference was corrected. --------