!standard 2.4.5 09-09-14 SI99-0053-1/03 !class Binding Interpretation 09-06-01 !status work item 09-06-01 !status received 09-06-01 !priority Medium !difficulty Medium !qualifier Omission !subject Various comments on the ASIS CD !summary ** TBD ** !question ** TBD ** (See !discussion.) !recommendation (See summary.) !wording ** TBD ** !discussion Following are all of the technical comments filed by Gary Barnes (via SIGAda) on the ASIS CD. 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. 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. 13.10, 13.11, 13.12: [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. 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 indented (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. Additionally, I wonder if the original list is redundant as well: doesn't A_Type_Declaration already include all of A_Type_Definition?? [13.13 also has this possible problem.] 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. 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. 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.] 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. 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 rambing non-normative notes. 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's note:] 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!). 15.3: [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. 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 folllowing Element_Kinds: A_Declaration that has one of the folllowing Declaration_Kinds: A_Constant_Declaration A_Deferred_Constant_Declaration A_Pragma 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. 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. --- [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. 16.4, 16.8: [GB:] Ada 05 has Wide_Wide_Character. There is also the possibility of “type X is new Wide_Wide_Character;”. Technically there has always been the possibility of a user declaring an enumeration type with “a very great many” literals in it. With previous versions of the ASIS standard it was possible to dodge the problem and fall back on compiler implementation restrictions that would make it impossible for a user to, in any practical sense, declare an enumeration type with anything close to 2**32 literals in it. Now the language does this itself. This leads to problems with using the ASIS specification when analyzing programs that actually use this language built-in type. 16.4 function Implicit_Inherited_Declarations – when presented with a type definition consisting of “new Wide_Wide_Character” this interface has the potential for raising Storage_Error, both inside itself, which can be caught and turned into Asis_Failed, and also while in the process of returning a computed value, which cannot be caught. This limitation is not mentioned in the standard. 16.8 function Enumeration_Literal_Declarations – has the same sort of problem. In addition, it is easy to imagine that a programmer would have the ability to define other enumerations where either (a) the list of An_Enumeration_Literal_Specifications could not be created internally to the ASIS implementation or (b) could not be returned once created. The probable cause of such problems will be either (a) not enough stack, (b) not enough free memory is available, or even (c) the machine supporting the ASIS program does not have sufficient address space to even conceivably support the creation of such a list. The problem is fundamentally insurmountable. However it can be made somewhat less monumental and applications that wish to attempt analysis of such programs can be given a chance. Proposed change: Add these cautions in 16.4 and 16.8 May raise Asis_Failed with a Status of Storage_Error if the implementation is unable to create the result in the stack or memory space available and may raise Storage_Error if the result cannot be returned after being created. This is particularly likely if the Type_Definition involves Standard.Wide_Wide_Character but is possible with any “very large” enumeration type. Add the following interfaces so that applications have the ability to (a) know how many enumeration literals there are even if it may be unable to actually manipulate them all at one time, (b) obtain any given literal specification regardless of how many there may be, and (c) tell when they can “expect ” 16.4 and 16.8 to fail. In package Asis: type ASIS_Unsigned is ; If possible this type should have a ‘Last that is >=2**32 just so that it can support Wide_Wide_Character but that may not be possible for a 32-bit compiler on every a 32-bit machine. A minimal implementation requirement should be 2**32. If possible the range should cover whatever limit the compilation system has for enum types if that limit is > 2**32. In package Asis.Definitions: function Enumeration_Literal_Length (Type_Definition: in Asis.Type_Definition) return Asis.Asis_Unsigned; Returns the number of literals in An_Enumeration_Type_Definition. Raises Constraint_Error if the number is outside the range of ASIS_Unsigned. For a 32-bit compiler on a 32-bit machine this could be construed as telling the application that the enumeration has 2**32 literals and is probably either Wide_Wide_Character or a derivative thereof. Not a guarantee of course. function Enumeration_Literal_Specification (Type_Definitiion : in Asis.Type_Definition; Position : in Asis.ASIS_String) return Asis.Declaration; Returns the ’Val(’Wide_Value(Position)). Returns the An_Enumeration_Literal_Specification for the literal indicated by Position of the enumeration type. Position is a string, such as might result from a call to Asis.Declarations.Position_Number_Image. This eliminates portability range problems with respect to Asis defined types such as ASIS_Integer or ASIS_Unsigned and allows applications to create sparse maps from [Randy:] Surely, we don't want random musings like "Not a guarantee of course" in the normative wording! Otherwise, the idea is sound. More importantly, should the old function Enumeration_Literal_Declarations be made obsolescent? It seems dangerous to use, and annoying if you only want one literal. A second question: making the position a string adds extra steps into the common idiom of looping over all of the positions. Since we already are defining a type to represent position numbers (and that's what ASIS_Unsigned is here), we should use it in the function. (We should also consider adding a Position_Number function that returns the actual value.) Alternatively, we should just make the user use the semantic interface to get the literals if they need them for a type that is too long. Then we would only need a single new function to get views of the literals based on position numbers (there are already functions to get the bounds of a scalar subtype). 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 and 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 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. 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 that. 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. --- [GB:] All of the parameter names are single letters. Except for the new section 23, all of the ASIS interfaces uses "meaningful" parameter names. This section throws out that design criteria creating obscure interfaces. Bad design and one that cannot be fixed by implementers that might wish to present something more pleasant to their users. It also violates section D.3.1 "ASIS should be well engineered." [Randy:] ASIS 95 does a lousy job of being "well engineered" - no use of strong typing or even of the existing subtypes to reflect usage; organized by "kinds" rather than by putting related operations together; abuse of Ada terminology is common, among others. Starting over would be necessary to make ASIS "well engineered"!! Section 23 was designed to be called in prefix notation. That's not necessarily "badly engineered", it's just different. We should reconsider the single character parameters (which we did previously discuss), but we need to keep in mind that since Gary's employer is no longer supporting this process, we cannot afford to make wholesale changes to this document at this late stage. Changing the parameter names (which would have to be done by hand because single characters cannot be effectively search-and-replaced) would likely take a full day or more out of our very limited budget. --- 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. --- [GB:] The various Is_xxx functions are not well described. In particular, while I can imagine that Is_Callable is supposed to implement the test “Kind(View) in Callable_View_Kinds”, there is nothing in the description that would actually lend proof to that assumption. So improve the descriptions of these functions. --- 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)}" --- 23.11.8: [GB:] All previous sections in the document use the form "Function XXX returns blah blah." This sections 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. --- !appendix ****************************************************************