!standard 8.3 09-12-28 SI99-0057-1/02 !standard 8.7 !standard 13.10 !standard 13.12 !standard 13.13 !standard 13.14 !standard 13.16 !standard 13.17 !standard 13.18 !standard 13.25 !standard 13.47 !standard 13.50 !standard 15.11 !standard 15.30 !standard 15.47 !standard 15.48 !standard 16.18 !standard 16.40 !standard 20.25 !standard 23.2.1 !standard 23.2.2 !standard 23.3.1 !standard 23.4.1 !standard 23.5.1 !standard 23.9.1 !standard 23.11.1 !standard 23.11.8 !standard 23.12.1 !standard 23.13.1 !standard 23.14.1 !standard F.5.5 !class Binding Interpretation 09-11-03 !status ARG Approved 6-0-6 09-11-06 !status work item 09-11-03 !status received 09-11-03 !priority Medium !difficulty Medium !qualifier Omission !subject Various comments on the ASIS CD !summary Various changes are made. !question (See !discussion.) !recommendation (See summary.) !wording [1] Modify the second paragraph of 8.3: Procedure Associate is used to give name and parameter associations to a Context{ prior to opening}. The Has_Associations query is used to test whether or not a Context has been given name and parameter associations. The Name and Parameters queries are used to examine name and parameter associations. Modify the third paragraph of 8.3: A Context has at most one set of name/parameter values associated with it at any time. [If The_Context is not open then any previous Name and Parameters associations are replaced by this call]{A call on Associate will replace any prior name/parameter values with the given Name and Parameters}. [2] Modify the third paragraph of 8.7: Unless both Contexts are open, this operation is implemented as a pair of simple string comparisons between the Name and Parameter associations for the two Contexts. If both Contexts are open, this operation acts as a set comparison and returns True if both sets contain the same units [(all unit versions are included in the comparison)]{, where two compilation units are the same when Is_Equal on the corresponding Compilation_Units returns True}. [3] In the third paragraph of 13.10, replace A_Type_Declaration by An_Ordinary_Type_Declaration. In the fifth paragraph of 13.12, replace A_Type_Declaration by An_Ordinary_Type_Declaration. In the sixth paragraph of 13.12, delete An_Interface_Type_Definition. In the third paragraph of 13.13, replace A_Type_Declaration by A_Private_Extension_Declaration. In the fourth paragraph of 13.17, delete A_Tagged_Record_Type_Definition. [4] Replace the fourth paragraph of 13.14 with: Element expects an element that has the following Definition_Kinds: A_Protected_Definition or an element that has the following Type_Kinds: An_Interface_Type_Definition Replace the fourth paragraph of 13.16 with: Element expects an element that has the following Definition_Kinds: A_Private_Extension_Definition or an element that has the following Type_Kinds: An_Interface_Type_Definition Replace the fourth paragraph of 13.18 with: Element expects an element that has the following Definition_Kinds: A_Task_Definition or an element that has the following Type_Kinds: An_Interface_Type_Definition [5] Add at the end of 13.25: or an element that has the following Formal_Type_Kinds: A_Formal_Access_Type_Definition [6] Replace the second paragraph of 13.47 with: Returns True if the prefix of the call is a prefixed view of the subprogram (see Ada Standard 4.1.3(9.2/2)). Returns False for any other element including Nil_Element. Delete the last paragraph of 13.47. [7] Delete the second function definition from 13.50. Delete the second sentence from the first paragraph of 13.50. Delete the second usage note of 13.50 from the AASIS. Add a new clause F.5.5: F.5.5 function Enclosing_Element (with Expected_Parameter) The behavior of this function is not portable; use the one parameter version of Enclosing_Element (see 13.50) instead. Use of the two parameter version of function Enclosing_Element is not recommended in new programs. function Enclosing_Element (Element : in Asis.Element; Expected_Enclosing_Element : in Asis.Element) return Asis.Element; Element specifies the element to query. Expected_Enclosing_Element specifies an enclosing element expected to contain the element; the interpretation of this parameter is implementation-defined. Returns the Element that immediately encloses the given element. This query is intended to exactly reverse any single parent-to-child element traversal. For any structural query that returns a subcomponent of an element (or that returns a list of subcomponent elements), the original element can be determined by passing the subcomponent element to this query. Returns Nil_Element if: * the element is the declaration part of a compilation unit (Unit_Declaration). * the element is with clause or use clause of a context clause (Context_Clause_Elements). * the element is a pragma for a compilation unit (Compilation_Pragmas and Context_Clause_Elements). Use Enclosing_Compilation_Unit to get the enclosing compilation unit for any element value other than Nil_Element. Raises ASIS_Inappropriate_Element if the Element is Nil_Element. Usage Note: The original intent of the second parameter was described as follows (we do not try to normatively describe this intent): The Expected_Enclosing_Element parameter is used only to optimize this query. This speed up is only present for ASIS implementations where the underlying implementor's environment does not have "parent pointers". For these implementations, this query is implemented as a "search". The Enclosing_Compilation_Unit is searched for the argument Element. The Expected_Enclosing_Element parameter provides a means of shortening the search. Note: If the argument Element is not a sub-element of the Expected_Enclosing_Element parameter, or if the Expected_Enclosing_Element is Nil_Element, the result of the call is Nil_Element. Implementations that do not require the Expected_Enclosing_Element parameter may ignore it. They are encouraged, but not required, to test the Expected_Enclosing_Element parameter and to determine if it is an invalid Element value (its associated Environment Context may be closed) Portable applications should not use the Expected_Enclosing_Element parameter since it can lead to unexpected differences when porting an application between ASIS implementations where one implementation uses the parameter and the other implementation does not. Passing a "wrong" Expected_Enclosing_Element to an implementation that ignores it, is harmless. Passing a "wrong" Expected_Enclosing_Element to an implementation that may utilize it, can lead to an unexpected Nil_Element result. [8] Replace the last three paragraphs of 15.11 (these start with "Name expects an element...") with: Raises ASIS_Inappropriate_Element with a Status of Value_Error Value_Error if the element Name has an Element_Kind is not A_Defining_Name or if element Name does not designate a constant declaration. Returns an element that has one of the following Element_Kinds: Not_An_Element A_Declaration that has one of the following Declaration_Kinds: A_Constant_Declaration A_Deferred_Constant_Declaration A_Pragma [9] Remove the last paragraph of 15.30. [10] Change "Definition" to "Declaration" in the specification of function Progenitor_List (15.47). Add A_Private_Extension_Definition to the third paragraph of 16.40. [11] Delete A_Null_Procedure_Declaration from the list in 15.48. Move the entire clause to 13.20 (before Mode_Kind). [12] Replace the third paragraph of 16.18 with: Definition expects an element that has the following Definition_Kinds: An_Access_Definition that has one of the following Access_Definition_Kinds: An_Anonymous_Access_To_Variable An_Anonymous_Access_To_Constant or expects an element that has the following Type_Kinds: An_Access_Type_Definition that has one of the following Access_Type_Kinds: A_Pool_Specific_Access_To_Variable An_Access_To_Variable An_Access_To_Constant [13] Modify the last paragraph of 20.25: An implementation shall make text available for all explicit elements{ if text exists for the enclosing compilation (see the Ada Standard 10.1(2)}. [14] In 23.4.1, 23.5.1, 23.9.1, 23.11.1, 23.12.1, 23.13.1, and 23.14.1, change "and View" to "and Views.View". In 23.3.1, change "and View_Declaration" to "and Views.Declarative_Regions.View_Declaration". [15] In 23.2.1, declare the functions in the order Kind, Is_Exception, Is_Generic, Is_Package, Is_Callable, Is_Object_Or_Value, Is_Subtype, Is_Statement. [16] Modify the last paragraph of 23.2.2: If V is a view representing the use of Var in the exit statement at (2), the element returned by Element_Denoting_View is the one in the exit statement, and not the one in the declaration {at (1)}. In particular, if E is the element representing the exit statement, then Exit_Condition (E) = Element_Denoting_View (V). [17] Modify the second paragraph of 23.11.8 with: {Function }Visible_Part {returns}[yields] the appropriate (either limited or full) view of the visible part of the package. {Function }Private_Part {returns}[yields] the appropriate (either limited or full) view of the private part of the package. !discussion Following are all of the technical comments filed by Gary Barnes (via SIGAda) on the ASIS CD before November 1st. His comments came too late to include in the US position. They are marked with [GB:] (as we already have a "Gary" on the ARG). (He also noted a number of typos, which have been fixed without comment as the CD did not match the intent shown in the appropriate SI.) 8.3: [GB:] This paragraph was reworded going from ASIS'95 to ASIS'05. It is now less clear than it was before because it has become necessary to read all of the paragraphs before this one paragraph can be fully understood. It should be changed back to something closer to the previous form. [Randy:] Redundancy is extremely dangerous in a Standard. Repeating information in different ways leads to conflicting requirements. So it *is* necessary to read all of the paragraphs. One could imagine adding an "otherwise" to the second sentence and merging in the last paragraph, but that is even more churn on the text. [ARG (Meeting 39):] Adjust the wording. Add to the end of the first sentence of the second paragraph " prior to opening." Replace the second sentence of the third paragraph with "A call on Associate will replace any prior name/parameter values with the given Name and Parameters." Wording [1]. 8.7: [GB:] There is no mention of what affect unit state has on Is_Equal. Imagine a context that is opened after some unit has entered the context but before that unit has compiled successfully. And then another context that is opened after the successful compilation of that unit. Are those two contexts Is_Equal? Either (a) add words indicating that "set comparison" does not imply equality of the compilation state of the individual units or (b) add words indicating that not only are the two sets identical in membership but the individual units will have the same state (obsolete versus consistent). Note that option (b) can imply considerable overhead as an implementation would need to go out and dynamically check on every unit. I do not recommend (b). [Randy:] This text is original ASIS. One wonders if this is a more widespread problem than just here. [ARG (Meeting 39):] The existing text "all unit versions are included in the comparison" definitely implies that the compilation status matters. We should add some wording to clarify that. Add "where two compilation units are the same when Is_Equal on the corresponding Compilation_Units returns True." This change is consistent with the one we made to 9.9 in SI99-0053-1; these two Is_Equals ought to work the same. Wording [2]. 13.10, 13.12, 13.13: [GB:] These three interfaces, unique in the draft, use A_Type_Declaration (a subtype) instead of enumerating the actual kinds. Two things. (1) This is contrary to the rest of the draft. (2) One or more of the kinds subsumed in the subtype are also listed. Suggest replacing the three references to A_Type_Declaration with the list: An_Ordinary_Type_Declaration A_Task_Type_Declaration A_Protected_Type_Declaration An_Incomplete_Type_Declaration A_Private_Type_Declaration A_Private_Extension_Declaration and also remove any duplicates from the three lists. [Randy:] Looks like a mistake to me. Should fix. [ARG (Meeting 39):] We're not trying to cover all kinds of types here. Instead, this is supposed to be An_Ordinary_Type_Declaration. However, for 13.13, we only want things that can have "private" in them, so we just want A_Private_Extension_Declaration. Wording [3]. 13.12: [GB:] An_Interface_Type_Kind is a Type_Kinds and not a Definition_Kinds. It needs its own section. Suggest adding: or an element that has one of the following Type_Kinds: An_Interface_Type_Definition [Randy:] This seems to be the wrong fix, as all A_Type_Definition is already allowed. If that was actually intended (allowing querying of all types), An_Interface_Type_Definition should just be dropped from the list. Alternatively, (if we only want to query types that could have "limited"), this should be added as a subvalue of A_Type_Definition. I cannot tell from SI-22 which if these was the intent; if I had to guess it would be the latter. [ARG (Meeting 39):] Just drop An_Interface_Type_Definition, we don't need to be more detailed in what can return True. (Recall that a correct implementation could ignore this list of kinds and simply determine if "limited" occurs textually.) Wording [3]. 13.14, 13.18: [13.16 also has this mistake - ED] [GB:] An_Interface_Type_Kind is a Type_Kinds and not a Definition_Kinds. It needs its own section. Suggest adding: or an element that has one of the following Type_Kinds: An_Interface_Type_Definition [Randy:] Yes, of course removing the existing reference. [ARG (Meeting 39):] Make the change suggested (in all three clauses). Wording [4]. 13.17: [GB:] A_Tagged_Record_Type_Definition is a Type_Kinds and not a Definition_Kinds. It needs its own section. [Gary had misidentified this comment as applying to 13.18 - ED] Suggest adding: Add, or an element that has one of the following Type_Kinds: A_Tagged_Record_Type_Definition [Randy:] Actually, it already has its own section, but it is mistakenly given in the previous section as well. [ARG (Meeting 39):] Delete the extra item. Wording [3]. 13.25: [GB:] In ASIS'95 this function also had an expected Formal_Type_Kind of A_Formal_Access_Type_Definition. That should be added. [Bill:] Actually I don't see this in the old 13.17, but I agree we should have it: Add missing expected kind. [Randy:] I agree with Bill, ASIS '95 does *not* have this kind. But it seems like it should. [ARG (Meeting 39):] Add missing kind. Wording [5]. 13.47: [GB:] This is the only function returning boolean in the entire document that can raise an exception on an inappropriate argument. That runs counter to basic design principles for the previous two versions of the standard. It should simply return false like all of the rest. [Randy:] Probably an oversight. The wording should be similar to 13.48 (to motivate the notion that inappropriate stuff just returns False. [ARG (Meeting 39):] The exception text is just extra junk, just remove last line. Use the 13.48 style wording. Wording [6]. 13.50: [GB:] In ASIS'95 the Enclosing_Element interface had a long piece of application advice that is still important in ASIS'05. It should be kept. [Randy:] All "application advice" was removed from the standard and placed into the AASIS as "usage notes". There is way too much junk in the standard which has nothing to do with defining it, and given the copyright situation, it is very unlikely that any non-implementers will ever see the actual standard. So "usage notes" are better off distributed separately from the standard. Given the advice to not use the second parameter in "portable programs", it might make sense to make the that version of the routine obsolscent. In any case, there is normative wording about the meaning of Expected_Enclosing_Element missing. That needs to be added, not some rambling non-normative notes. [ARG (Meeting 39):] This (the version with two parameters) is a really weird function, as you are actually guessing what your response is going to be. And the behavior is defined to be non-portable. Let's just make this function (the version with two parameters) obsolescent, with implementation-defined semantics for the second parameter (implementations can keep doing whatever it is they currently do). No one wants this note to show in the standard. Wording [7]. 15.9: [GB:] This interface, alone of all of the interfaces in ASIS, returns an “empty” element instead of a Nil_Element for a syntactic entity that does not exist. This is not appropriate. It should return a Nil_Element and shoul d not invent yet another form of implicit element when there is no reason to do so. Just like for every other syntactic query, if some optional element is not present then return Nil_Element. [Randy:] The reasons for this decision are pretty simple: if the routine returned Nil_Element in this case, there would be no practical way to find out whether you have a task or protected object. All of the _subtype routines defined by SI-04 return useful answers in many cases where their obsolscent counterparts would have returned the useless Nil_Element (for 'Class and for anonymous access types, for example). All of those issues have workarounds, but they make writing ASIS programs a lot harder than they have to be. I suggest that we reject this comment, as we carefully considered these semantics (twice!). [ARG (Meeting 39):] No one disagrees with Randy's position. No change is needed. 15.11: [GB:] A_Defining_Name does not have a Declaration_Kinds value. Rather, the Corresponding_Constant_Declaration returns an element that has a Declaration_Kinds value. It is the returned element that has one of the kinds listed (Not_A_Declaration, A_Constant_Declaration, A_Deferred_Constant_Declaration). Suggested correction: Name expects an element that has the following Element_Kinds: A_Defining_Name Returns an element that has one of the following Element_Kinds: A_Declaration that has one of the following Declaration_Kinds: A_Constant_Declaration A_Deferred_Constant_Declaration A_Pragma [ARG (Meeting 39):] We agree with the basic suggestion (noting that the Not_An_Element case is missing from the suggestion). But it appears that part of the intent is that Status_Error is raised if the Defining_Name does not identify a constant declaration. We need wording to cover that. We can fold that wording into the exception raising statement. Once we do that, we don't need separate wording about the expected element kinds, so drop that. "...Value_Error for an element that has an Element_Kind is not A_Defining_Name or if Name does not designate a constant declaration." Wording [8]. 15.30: [GB:] "Returns false for any unexpected Element." and "Raises ... for any element that does not have one of these expected kinds.". Pick one. The previous standard took the first stand. No boolean interfaces were allowed to raise exceptions for unepxected kinds. Suggested correction: Eliminate the final paragraph about raising an exception. [ARG (Meeting 39):] As with 13.47, just extra junk, remove it. Wording [9]. 15.47: [GB:] This function (Progenitor_List) is located in the wrong place and defined in a very odd and inconsistent fashion. 1)In the Ada 05 Reference Manual, an interface_list is part of a type_definition and not part of a type declaration. So this function needs to be declared in Asis.Definitions and not in Asis.Declarations. 2)Paragraph 1 states "Declaration specifies the declaration to query." and yet the function interface parameter is "Declaration : Asis.Definition;" which indicates that someone was thinking half way correctly (the function should take a type definition) but was mistakenly calling this a Declaration. I suggest to move this interface to Asis.Definitions so that it is with all of the other interfaces that query Definitions. Change the documentation to specify all of the Definiition types that are appropriate rather than all of the types that have definitions that would be appropriate. [Bill Thomas:] See the ARM 7.3 (3/2) and 9.1 (2/2) as examples that 15.47 is addressing. [ARG (Meeting 39):] (1) is wrong; interface_list is part of private types which are declarations, not definitions. Besides, Progentitor_List (16.40) is already provided for definitions. However, further investigation shows that 16.35 (Ancestor_Subtype_Indication) is defined only for A_Private_Extension_Definition (even though there is no such thing in the Ada grammar; private extensions are declarations, not definitions). So the appropriate thing is to add the private type "definition" kinds to 16.40 as needed and delete 15.47 altogether. [Randy:] The discussion at the meeting failed to consider tasks and protected types. Task and protected types have definitions, but the interface_list is not part of the definitions, it is only in the declaration. As such, we still need the 15.47 routine, and there is no reason to change it. Thus all we should do is fix the parameter subtype and add A_Private_Extension_Definition to 16.40 (the latter isn't required, but given the existence of a private extension "definition" in ASIS, it ought to be included there). Wording [10]. 15.48: [GB:] There is no A_Null_Procedure_Declaration kind defined in the standard. Presumably this is a leftover from a previous edit. Remove it from the list. [Randy:] He's right. [ARG (Meeting 39):] Delete it. Wording [11]. --- [GB:] Previous versions of ASIS used a design rule that said (a) all Kinds are defined in package Asis and all Kind() queries were defined in package Asis.Elements. The function Overriding_Indicator_Kind breaks that pattern. Unfortunate. Consider moving this interface to Asis.Elements where all of the other Kind() functions reside. [Randy:] Sounds like a junk rule to me; this routine is only meaningful for declarations. I thought "ASIS should be well engineered." (D.3.1). Putting queries far away from their use surely does not qualify as "well engineered". Nevertheless, we should probably match the existing style, no matter how idiotic. [ARG (Meeting 39):] Move it just before Mode_Kind in Section 13. Wording [11]. 16.18: [GB:] Only An_Access_Definition is a member of Definition_Kinds. The other three, A_Pool_Specific_Access_To_Variable, An_Access_To_Variable, and An_Access_to_Constant are Access_Type_Kinds. The Kinds section needs to be reworded. Suggest: Definition expects an element that has one of the following Definition_Kinds: An_Access_Definition that has one of the following Access_Definition_Kinds: An_Anonymous_Access_To_Variable An_Anonymous_Access_To_Constant or expects an element that has one of the following Type_Kinds: An_Access_Type_Definition that has one of the following Access_Type_Kinds: A_Pool_Specific_Access_To_Variable An_Access_To_Variable An_Access_To_Constant [ARG (Meeting 39):] Fix as suggested. Wording [12]. 18.22, 18.23, 18.24: [GB:] Why does Return_Object_Specification not have “Extended_” in the name when Extended_Return_Statements and Extended_Return_Exception_Handlers handle the same kind of object and are burdened with the extra long name? [Randy:] Probably because these directly mirror the names of these constructs within the Ada Standard. In particular, "extended_return_statements" returns statements from an extended_return_statement. The item that an extended_return_statement declares is a return object. (A normal return has one as well, but that one doesn't have a "specification".) Not sure that any name changes are warranted. [ARG (Meeting 39):] No change is needed. 20, 20.25: [GB:] Paragraph 7 of section 20 "...program text cannot be located..." directly contradicts paragraph 5 of section 20.25 "An implementation shall make text available for all explicit elements." Similarly in section 20.5 the NOTE says "nor does it specify that the text of a compilation unit has any particular lifetime". Suggest that the Implementation Requirment in 20.25 be removed. [Randy:] All of these items are original ASIS '95 text. It seems like a big non-portability to say to say that the text may disappear at anytime. It seems like there ought to be minimum requirements on when it can be missing. [ARG (Meeting 39):] Add "presuming text exists for the enclosing compilation (see the Ada Standard 10.1(2))" to 20.25. (Note that compilation means "source file" here, but we don't want to talk about files.) Wording [13]. [Editor's note:] "presuming" doesn't make much sense in a "shall" rule; I replaced it with "if". 23 Global: [GB:] "and View" should be "and Asis.Views.View" (many type declarations), and similarly for "and View_Declaration". Neither of these is visible at the point of these type declarations. [Randy:] Yes, should fix. [ARG (Meeting 39):] Add "Views." to the front of all of the type declarations. We don't need "Asis." as that is the parent unit of all of these packages. But we do need "Declarative_Regions." for View_Declarations as it is declared in that subpackage. Wording [14]. 23.2.1: [GB:] The ordering of the subtypes is different than the ordering of the corresponding functions. For example. Callable_View_Kinds comes before Object_View_Kinds but Is_Object_Or_Value comes before Is_Callable making their correspondence far less apparent. Reorder the two lists so that they match. [ARG (Meeting 39):] Fix the order. Wording [15]. 23.2.2: [GB:] The marker (2) is referenced in the text but the (1) marker is not. [Randy:] Probably should be "one in the declaration {at (1)}" [ARG (Meeting 39):] Follow Randy's suggestion. Wording [16]. 23.11.8: [GB:] All previous sections in the document use the form "Function XXX returns blah blah." This section suddenly starts with "XXX yields blah blay." [Randy:] I tried to normalize all of this text, but it doesn't surprise me that I missed some. It was wildly different originally. This clause was originally written by four different people, and everyone did it differently. [ARG (Meeting 39):] Try to make the wording consistent. Wording [17]. --- !appendix From: Randy Brukardt Sent: Wednesday, December 30, 2009 7:34 PM The discussion of SI99-0057-1 reads: 15.47: "Declaration : in Declaration" should be fixed. But the original comment is wrong as 16.40 is defined for definitions; this routine is only intended for use on declarations. Ada syntax includes the progenitor list in some declarations (such as private extensions) which doesn't have definitions. Thus this routine is needed. Someone comments that ASIS seems to define "definitions" for some of these, but we have no idea how they are defined (there is no indication in the ASIS standard what these things not found in the Ada grammar mean). Tucker says that Ancestor_Subtype_Indicator is just defined on A_Private_Extension_Definition. This is very similar to the progenitors case. So certainly the "definition" contains the private kinds. So we need to get rid of 15.47 and beef up the list of expected stuff in 16.40 to include the various sorts of private types. Probably add an AASIS note to explain the ASIS has "definitions" for private types even though Ada does not have any such thing, so private types can come here. --- However, this is wrong, as the discussion totally focused on the private case and ignored the task and protected cases. Task and protected types in Ada *have* definitions, but those definitions do *not* include the interface_list. Indeed, looking at part of 3.7.9 Definition_Kind: A_Private_Type_Definition, -- 7.3(2) -> Trait_Kinds A_Tagged_Private_Type_Definition, -- 7.3(2) -> Trait_Kinds A_Private_Extension_Definition, -- 7.3(3) -> Trait_Kinds A_Task_Definition, -- 9.1(4) A_Protected_Definition, -- 9.4(4) Note that 7.3(2) and 7.3(3) are the syntax for private_type_declaration and private_extension_declaration, which do include interface_list. But 9.1(4) and 9.4(4) do not include interface_list. Therefore, we do need 15.47 and we should definitely not delete it. We surely should fix the parameter to have the correct subtype, but no other changes seem to be needed. There is a question whether we ought to add A_Private_Extension_Definition to 16.40, but given that ASIS says that such a thing exists (even if Ada doesn't), it probably is a good idea for consistency if nothing else. A much more radical change would somehow include the progenitors in the task_definition and the protected_definition. But that is getting way too far from the Ada syntax for my taste (and this is the syntactic part of the interface that we are talking about). Any thoughts? ****************************************************************