!standard 1.1 09-12-21 SI99-0053-1/04 !standard 1.1.2 !standard 1.1.3.2 !standard 1.1.3.4 !standard 1.1.4 !standard 2.1.1 !standard 2.1.2 !standard 2.3 !standard 2.4.5.1 !standard 4.0 !standard 6.9 !standard 6.10 !standard 9.5 !standard 9.6 !standard 9.7 !standard 9.8 !standard 9.9 !standard 10.8 !standard 10.9 !standard 10.10 !standard 13.3 !standard 13.56 !standard 15.18 !standard 15.20 !standard 15.29 !standard 15.31 !standard 15.41 !standard 16.19 !standard 16.29 !standard 16.32 !standard 17.1 !standard 17.6 !standard 17.7 !standard 17.8 !standard 17.29 !standard 18.31 !standard 19.1 !standard F.3 !class Binding Interpretation 09-06-01 !status ARG Approved 8-0-4 09-11-06 !status work item 09-06-01 !status received 09-06-01 !priority Medium !difficulty Medium !qualifier Omission !subject Open issues in the ASIS syntactic subsystem !summary Correct various issues in the ASIS standard. !question (See !discussion.) !recommendation (See summary.) !wording [1] Globally remove the 'a' in front of "Nil_Element" and other "Nil_xxx"s. Treat this as the correction of a typo (that is, don't mark this as a change in document versions that show changes). [2] Replace the 1st paragraph of 1.1.4 by: ASIS reports all operational errors by raising an exception. Whenever an ASIS implementation raises one of the exceptions declared in package Asis.Exceptions, it will indicate the cause of the error by including an exception message and by setting the value returned by the Status query before raising the exception. The possible values for Status are indicated below. Delete "Diagnostic messages may be more specific." from 1.1.4. Replace the 2nd through 4th paragraphs of Section 4 by: ASIS reports all operational errors by raising an exception. Whenever an ASIS implementation raises one of the exceptions declared in package Asis.Exceptions, it will indicate the cause of the error by including an exception message and by setting the value returned by the Status query before raising the exception. The possible values for Status are indicated in the definition of Error_Kinds in the next clause, with suggestions for the contents of the exception message as a comment. The Status query is provided in the Asis.Implementation package to supply more information about the reasons for raising any exception. ASIS applications are encouraged to follow this same convention whenever they explicitly raise any ASIS exception--always record a Status prior to raising the exception, and include a meaningful exception message. In 6.9, modify the paragraph added by SI99-0047-1: "...an Asis.Errors.Error_Kinds value [and a Diagnosis string are]{is} stored..." Delete 6.10. Add in Section F: F.3 Obsolescent Features in package Asis.Implementation F.3.1 Introduction for Obsolescent Features in package Asis.Implementation In addition to the interfaces defined in section 6, the library package Asis.Implementation also shall provide interfaces equivalent to the obsolescent ones described in the following subclauses. F.3.2 function Diagnosis This function has been superceded by the Ada function Ada.Exceptions.Exception_Message. Use of the function Diagnosis is not recommended in new programs. function Diagnosis return Wide_String; Returns a string value describing the most recent error. Whenever an error condition is detected, and any ASIS exception is raised, an Asis.Errors.Error_Kinds value and a Diagnosis string are stored. The Diagnosis function returns the diagnostic message describing the most recently recorded error. Note that Diagnosis values are implementation dependent and may vary greatly among ASIS implementations. Function Diagnosis will typically return a null string if Status = Not_An_Error. Note: Unless the diagnosis string has been set explicitly, we recommend that function Diagnosis returns the same string as Ada.Exceptions.Exception_Message for the exception raised by the most recent error. [Editor's note: ASIS doesn't have Implementation Advice, sadly. This is what we decided to do in 17.1.] [3] Delete the 6th paragraph of 13.3 (the one starting "Results of this query may vary...") Delete the 4th paragraph of 15.18 (the one starting "Results of this query may vary...") Delete the 4th paragraph of 15.20 (the one starting "Results of this query may vary...") Delete the 3rd paragraph of 15.29 (the one starting "Results of this query may vary...") Delete the 3rd paragraph of 15.31 (the one starting "Results of this query may vary...") Delete the 3rd paragraph of 15.41 (the one starting "Results of this query may vary...") Delete the 4th paragraph of 16.19 (the one starting "Results of this query may vary...") Delete the 3rd paragraph of 16.29 (the one starting "Results of this query may vary...") Delete the 4th paragraph of 18.32 (the one starting "Results of this query may vary...") Delete the 3rd paragraph of 19.1 (the one starting "Results of this query may vary...") [4] Delete "compilation" whereever it preceeds "environment": from the Introduction (two places), 1.1 (two places), and 1.1.2. Delete "for a given Ada implementation" from 1.1.3.1 and the glossary entry for ASIS implementation. Replace the body of 2.1.1 by: [Randy:] Suggestion 1: Replace 2.1.1 by: The Ada *environment* contains the compilation units of a partition. The Ada Standard defines the environment as a conceptual declarative_part that forms the outermost declarative region of the context of any compilation. The Ada environment may be created by an Ada implementation, some other tools, or by a stand-alone ASIS implementation. The mechanisms for creating an environment and for adding compilation units are implementation-defined. The environment may be represented by a persistent database, by a distributed set of files, or directly by Ada source code. Replace the first paragraph of 2.1.2 by: ASIS requires the user of the interface (i.e., ASIS application) to establish the Ada environment. This is done through the context. [5] Replace the first paragraph of 1.1.3.2 by: Conformance documentation shall be available for an implementation claiming conformance to this International Standard. Change "conformance document" to "conformance documentation" in paragraphs 2 and 3 of 1.1.3.2. Delete paragraphs 4 through 6 of 1.1.3.2. [6] In 1.1.3.4, Delete the last two categories and their associated text. [7] In 2.3, replace the bullet for Asis.Elements with: * Asis.Elements – This child package encapsulates a set of queries that operate on all elements and some queries specific to A_Pragma elements (see Section 13). The element kinds Element_Kinds, defined in package Asis, are defined as a set of enumeration types describing the various kinds of elements. ASIS offers a hierarchical classification of elements. At the highest level, the Element_Kinds type provides literals that define "kinds" or classes into which all non-nil elements are grouped. Element_Kinds are: o Not_An_Element o A_Pragma o A_Defining_Name o A_Declaration o A_Definition o An_Expression o An_Association o A_Statement o A_Path o A_Clause o An_Exception_Handler Elements in each of the Element_Kinds classes, with the exception of An_Exception_Handler, can be further classified by a subordinate kind at the next level in the hierarchy. [8] In 2.5.4.1, modify the second bullet: All queries {other than simple Boolean or enumeration value queries that have}[with] a Context parameter of mode *in* raise ASIS_Inappropriate_Context if the Context value is not open. ... [9] Modify the last paragraph of 9.8: Returns True if Left and Right designate Container values that contain the same set of compilation units, {where two compilation units are the same when Is_Equal on the corresponding Compilation_Units returns True,} and returns False otherwise. The Container values may have been defined from different Context values. [10] Modify the last paragraph of 9.9: Returns True if Is_Equal(Left, Right) and the Container values have been defined from {Is_Identical}[Is_Equal] Context values, and returns False otherwise. [11] Modify the first sentence of 9.5 and 10.8: This query will never return a unit with {kinds} A_Configuration_Compilation or {A_Nonexistent_Declaration}[a Nonexistent unit kind]. Modify the fourth paragraph of 9.6 and 10.9: This query will never return a unit with {kinds} A_Configuration_Compilation or {A_Nonexistent_Body}[a nonexistent unit kind]. Modify the fourth paragraph of 9.7 and 10.10: This query will never return a unit with {kinds} A_Configuration_Compilation{, A_Nonexistent_Declaration, or A_Nonexistent_Body}[a nonexistent unit kind]. Add a new clause after 9.7: 9.8 function Configuration_Compilation_Units function Configuration_Compilation_Units (The_Container : in Container) return Asis.Compilation_Unit_List; The_Container specifies the Container to query. Returns a list of all configuration compilation units contained in The_Container. Individual units will appear only once in an order that is not defined. A Nil_Compilation_Unit_List is returned if there are no configurations units within The_Container. All units in the result will have an Enclosing_Container value that Is_Identical to The_Container. Raises ASIS_Inappropriate_Context with a Status of Value_Error if the Enclosing_Context(The_Container) is not open. Add a new clause after 10.10: 10.11 function Configuration_Compilation_Units function Configuration_Compilation_Units (The_Context : in Asis.Context) return Asis.Compilation_Unit_List; The_Context specifies a program Context environment. Returns a list of all configuration compilation units contained in The_Context. Individual units will appear only once in an order that is not defined. A Nil_Compilation_Unit_List is returned if there are no configurations units within The_Context. All units in the result will have an Enclosing_Container value that Is_Identical to The_Container. Raises ASIS_Inappropriate_Context with a Status of Value_Error if the The_Context is not open. [12] Modify Hash bullet in 2.2.3.4: * Asis.Element.Hash (13.56) - Returns a {numeric hash value}[convenient name] for an object of type Asis.Element. Replace all of the text in 13.56 by: Returns an implementation-defined value which is a function of the value of Element. If A and B are ids such that Is_Equal (A, B) is true, Hash(A) equals Hash(B). Implementation Note: This function should produce a result (not raise an exception) when passed Nil_Element. [13] Add two new Notes in front of the existing note: Note 1: An alternative to using this function would be to use Asis.Expressions.Views.Corresponding_View (see 23.17.1) to retrieve a semantic view of the expression, check if it is an object or value with Asis.Views.Is_Object_or_Value (see 23.2.1), and, assuming it is, use Asis.Object_Views.Nominal_Subtype (see 23.5.1) to retrieve the subtype. The retrieved subtype will include anonymous and classwide subtypes so complete analysis can be done without many special cases. Note 2: We recommend that the type returned in the implementation-defined cases be a type determined by the context. [14] In 17.6, 17.7, and 17.8, change the parameter subtype to "Asis.Name". Replace the first paragraph of 17.6 with: Reference specifies a name to query. [15] Replace the last bullet in 17.29 by: Expression is a call to a dispatching operation of a tagged type which is not statically determined. !discussion Following are many of the editorial comments from ARG members on the ASIS pre-CD draft that were considered either: (1) A significant semantic change; (2) An incompatible change; (3) A heck of a lot of work. Many of these are official comments from the US on the ASIS committee draft, so answers are required. These are marked with {CD-Comment}. Some of the more complex questions have been moved to SI99-0058-1 for additional work. ======= Global changes -- [John:] Sometimes dependences is spelt dependencies. Could be tidied up. [Randy:] So far as I can tell, the author of this clause thought that the plural of "dependence" was "dependencies". I don't see any use of "dependences" anywhere. Indeed, that is true in the entire document. There are 18 uses of "dependencies" scattered throughout the Standard, and no uses of "dependences". Most are in the phrase "semantic dependencies"; that probably is what I would have written myself. Do we need to do this as a global change?? [ARG (Meeting 39):] No, don't make any change. --- [John:] Also why say "Returns a Nil_Element". Surely there is only one so why not say "Returns Nil_Element"... [Randy:] This standard is very consistent about saying "returns a nil_element"; I found 89 occurrences of "returns a nil_" in the standard. One could treat this change as a typo (and not mark it as a change), but there are many other sorts of uses of "a nil_xxx", which probably ought be changed too. Too much to do right now. [ARG (Meeting 39):] Remove the 'a' in front of "Nil_Element" and other "Nil_xxx"s. Treat this as the correction of a typo (that is, don't mark this as a change in document versions that show changes). Wording [1]. --- [Steve:] {CD Comment} Some places that mention raising an exception mention raising it with a status value (e.g., 10.11). Others do not (e.g. 9.3), Is this ok? It seems like a status value should always be specified. [Randy:] It seems like a lot of work (heck, it *is* a lot of work!) to make such a global change to the existing wording. We need to decide the importance of this status value. The only ASIS exception that really gets any use out of status is ASIS_Failed. It pretty much can be raised by any routine, and the reasons might be of some value. But they're never specified. For other exceptions, Status is just useless baggage. With the values specified, it provides *less* information than the exception name does, as the value is specified to be the same for virtually all occurrences of particular exceptions. The exception message would have more useful information. For this reason, I recommend that we make no change here. On a side issue, Diagnosis should be obsolescent. Diagnosis is better handled using Exception_Messages, which can be usefully used by the application for its own exceptions as well. And there is no reason for duplicate functionality. [ARG (Meeting 39):] For most of the other exceptions, Status would always be "Value_Error". It is not worth specifying that. Make Diagnosis obsolescent, suggesting the use of Exception_Message instead. Add Implementation Advice that Exception_Message and Diagnosis return the same string. Wording [2]. --- [Randy:] {CD comment} There are a number of "allowed variations" that we didn't consider when we tightened down the requirements in order that source transformation tools would work more portably (see SI99-0025-1). We ought to consider whether we want to eliminate those permissions, as they are very similar to the ones we did eliminate: 13.3, 19.1 (context clause normalization) 15.18, 16.19, 18.32 (formal parameter profile normalization) 15.20, 15.29, 15.31 (multi-name declaration normalization) - We eliminated this permission for objects, but use clauses of all kinds still can be normalized 15.41 (multi-name generic formal declaration normalization) - Not clear that we actually allow this, having dropped this for ordinary object declarations. 16.29 (multi-name discriminant specification normalization) I propose that we delete the paragraphs that include "Results of this query may vary across ASIS implementations" from each of the named clauses above. My presumption was that we intended to eliminate all of these, but it would be too much of a semantic change to do it without ARG discussion. (Previously, we've been told that ASIS users would have significant problems with an implementation that took advantage of these permissions, and thus none do. Then why have them??) [ARG (Meeting 39):] Not all of these transformations are semantically neutral; those should never have been allowed in the first place. We decide to drop all of these permissions. Wording [3]. [Dan Eilers, via SIGAda review:] {CD comment} ASIS can be implemented both by extracting semantic information from Ada compilation environments, or by a stand-alone ASIS implementation that directly analyzes Ada source code. Some ASIS clauses are properly neutral toward implementation techniques, while others seem to imply that an Ada compilation system must necessarily be involved. For instance, references to "the given Ada implementation" in 1.1.3.1 and Annex A ought to be modified or removed. [Randy:] Since a stand-alone ASIS implementation already exists (Gela-ASIS), the ASIS standard needs to reflect that. However, Dan's specific suggestion (replacing "the Ada environment" with "Ada source code" - see his e-mail) goes too far and would leave the semantics of many ASIS operations completely unspecified. I think it would be better to leave the definition of ASIS alone: it is an interface to an Ada environment as defined by the Ada Standard. (That also is preferable in that ASIS name ought to be meaningful and thus it ought to interface to something - "interface" is not a noun!) How that environment is created is not relevant. That means that the best fix is simply to make it clear early in the Standard that "an Ada environment" may be created by a stand-alone ASIS implementation as well as with an Ada compilation system. That is, "an Ada implementation" in the ASIS standard is not necessarily a compiler. This can be done by rewriting 2.1.1 to say this. Any wording about "compilation environment" ought to be changed, even with this easy fix. "compilation" ought to be deleted whereever it preceeds "environment": from the Introduction (two places), 1.1 (two places), and 1.1.2. (It also appears in 2.1.1, but I'm assuming that clause will be totally replaced.) Dan also suggested deleting "for a given Ada implementation" from 1.1.3.1 and the glossary entry for "ASIS implementation", which seems harmless. [ARG (Meeting 39):] We should follow Randy's recommendation. Wording [4]. ======= 1.1.3.2 Implementation conformance documentation [Randy:] {CD comment} Has any implementation ever done this? This seems to *require* duplicate documentation, and in particular the AdaCore approach of providing that documentation via source code does not meet these requirements. (Surely the source code does not "have the same structure as this International Standard, with the information presented in the equivalently numbered clauses, and subclauses".) I know Robert Dewar would say that any documentation requirement is rubbish. We ought to consider replacing this clause with something realistic that doesn't specify the form of the documentation. [US comment:] The clause has very specific requirements on the form of conformance documentation for an ASIS implementation. It is very overspecified; it requires separate documentation of a particular form. Many useful forms of documentation would not qualify (such as documentation via on-line tools), and simply does not reflect reality. [ARG (Meeting 39):] Change "conformance document" to "conformance documentation". Drop the last two lines of the first paragraph. Get rid of the last three paragraphs ("shall be documented" is not used in the ASIS Standard). Wording [5]. 1.1.3.4 Application conformance categories [Randy:] {CD comment} Does the whole idea of a conforming application mean anything useful? Does anyone care what kind of application something is, especially in the absence of any way to verify that category? I suppose there might be value to the idea of a "portable application" that depends only on required ASIS functionality, but the other categories seem worthless - if you are depending on implementation-specific behavior (of any kind), the application may not work on an another ASIS implementation. No one cares why! OTOH, one can argue for leaving something that is of dubious value if there isn't a obvious better approach. Not sure if that holds here. [ARG (Meeting 39):] Delete the last two items. An application using extensions is not portable, period, so it doesn't conform to anything. Wording [6]. --- 2.3: [Greg:] In the bullet for Asis.Elements, it would be nice to have the list of Element_Kinds as a bulletized list. [Randy:] Another question is why this information (which is found in package Asis) is being described here. It appears that they want to talk about it in later bullets. But it's very confusing, because the section reference to section 13 is referring to the package Elements and not to the clause about Element_Kinds where this information is defined. Beyond that, it would be best to organize this into syntactic and semantic subsystem parts. So I think we need to consider a serious reorganization of this clause. [ARG (Meeting 39):] Move "(see section 13)" to the end of the first sentence. Make the list of kinds into a bullet-ed list. Wording [7]. 2.4.5.1: [Randy:] {CD comment} This clause has: * All queries with a Context parameter of mode IN raise ASIS_Inappropriate_Context if the Context value is not open. The Status is set to Value_Error. This statement is a lie (or a conflict) for all of the functions in section 8, which have defined results in this case: Is_Open(!), Is_Equal, Is_Identical, Exists, and so on. We surely don't want any of them raising an exception. For section 10, we've added an explicit version of this statement to each routine (similarly to what we did for ASIS_Inappropriate_Element). Section 9 already has such a statement. Should we modify or remove this statement? Should we add "Raises ASIS_Inappropriate_Context with a Status of Value_Error if The_Context is not open." to routines with a context type parameter outside of Section 8-10? (These are all in sections 12, 13, and [mostly] 15.) [ARG (Meeting 39):] Just fix the incorrect bullet. Steal the weasel wording from the fourth bullet. Wording [8]. 9.8: Is_Equal (containers) [Steve:] {CD comment} When this section refers to "the same set of compilation units", which equality operator on compilation units (Is_Equal, Is_Identical, or something else) is being implicitly referenced? [Randy:] Since "compilation units" is in lower case, it is most likely the Ada concept of compilation units that is being referenced (although I can't be certain because of the lack of an underscore). Thus the ASIS operators are irrelevant. Beyond that, I don't know what is meant and don't want to make an unintentional semantic change. [ARG (Meeting 39):] Is_Equal should be defined in terms of Is_Equal on the individual elements. Add "where two compilation units are the same when Is_Equal on the corresponding Compilation_Units returns True." Wording [9]. 9.9: Is_Identical (containers) [Steve:] Question: is the definition correct here? The definition refers to "Is_Equal Context values"; should that be replaced with "Is_Identical Context values"? [Randy:] Seems likely, since usually "Is_Identical" requires things to be from the same context. But I don't want to change semantics without discussion. [ARG (Meeting 39:)] All other Is_Identicals require constituents to be Is_Identical, so this one ought to as well. Wording [10]. Section 9: [Steve:] Should there be a query for getting the A_Configuration_Compilation unit (if any) associated with a container? Consider the GNAT or Rational Apex implementations, where a set of configuration pragmas may be associated with a single project file (for GNAT) or subsystem view (for Apex). If this notion does not make sense for a given implementation, then this query could return a null result. [Randy:] Humm. There isn't currently *any* query to retrieve an A_Configuration_Compilation unit from a context or container. The only way to reach one is to ask about the enclosing element of a Configuration_Pragma (13.4). One thinks that might be on purpose. A more general question is how much of the project file (or equivalent) should ASIS be exposing? I don't have a good answer to that question; it's not clear to me that containers have any real use for ASIS applications (at least not as it is currently structured). [ARG (Meeting 39):] There should be such a query. Add function Configuration_Compilation_Units (The_Container : in Container) return Asis.Compilation_Unit_List; The_Container specifies the Container to query. Returns a list of all configuration compilation units contained in the Container. Individual units will appear only once in an order that is not defined. A Nil_Compilation_Unit_List is returned if there are no configurations units within the Container. All units in the result will have an Enclosing_Container value that Is_Identical to the Container. Raises ASIS_Inappropriate_Context if the Enclosing_Context(Container) is not open. In 9.6 and 9.7, change "nonexistent unit kinds" to "A_Nonexistent_Declaration" and "A_Nonexistent_Body". Fix 9.7 to say that it only returns units, not not bodies or subunits or pragmas. Make similar changes to 10.9 and 10.10, and add a new routine similar to the one above. Wording [11]. 13.56 Hash [John:] You may recall that I objected to the use of buckets in the RM somewhere on the grounds that they don't have to be implemented by buckets. I guess this is less sensitive and in any case it says "buckets" and not buckets. [Randy:] I'd prefer the Ada 2005 definition (which we used for Ids - 21.2), rather than this free association version. (For instance, what does a "continuous uniform hash" have to do with this? I can't do that for identifiers in an Ada program, and they're wanting it for *all* of the elements of a program? Sheesh.) It's not technically wrong, though, because while they spend a lot of time explaining what a good hash function is, they never actually try to require that (probably because it is impossible!). But if they aren't requiring it, why fill the standard with this text? Anyone can read this in Knuth or on Wikipedia if needed. So I'd suggest making the first sentence an AASIS note, replacing the rest of it by the definition used in 21.2 (using Is_Identical rather than Is_Equal). But is it worth doing?? [Erhard:] 2.2.3.4 also has a junk description for Hash. Fix it too if we fix this one. [ARG (Meeting 39):] Remove the entire text of this clause, and replace by wording similar to that of 21.2. Replace 2.2.3.4 Hash by: "returns a numeric hash value for..." Wording [12]. 17.1 Corresponding_Expression_Type [Brad:] "Returns an implementation-defined result if the expression is an attribute reference {other than Base}, aggregate..." I do not understand why an implementation defined result needs to be returned here if the expression is an aggregate, attribute reference, etc. I think I would rather see well defined behaviour such as either an exception or returning Nil_Element if not supported. Why does a named number or numeric literal return Nil_Element while a string literal return something implementation defined? [Randy:] We discussed this extensively, read the SI for the details. The very short answer is that this function is essentially obsolete (but too commonly used to make obsolescent), we didn't want to change the behavior of existing implementations, and no defined result makes sense in this cases. Please tell me if you want to revisit this and I'll put it on the open issues list (I think we should have made this function obsolescent, given we suggest an alternative that gives useful information always in the Usage Notes. In that case, the implementation-defined behavior is OK - we don't want to make implementers spend any time of obsolete stuff. But we did consider that possibility the last time, and didn't do that, not really sure why). [Brad:] I do recall the discussions, it seems to me that making the function obsolescent is a good idea also, if that is a possibility. I think it would be good to discuss that one point again. [ARG (Meeting 39):] Add a Note (really Implementation Advice): We recommend that the type returned in the implementation-defined cases be a type determined by the context. Make the Usage Note added by SI99-0045-1 the first regular note. Wording [13]. 17.3 Name_Image [Brad:] Should this function also accept an expanded name? This is the only defining_name_kind that is missing here. [Randy:] Makes sense, it doesn't seem that it ought to be necessary to drill down to the various parts of a defining name if you just want the string. But as this is an expansion of semantics, it ought be be discussed by everyone. [ARG (Meeting 39):] This function doesn't accept defining names; Defining_Name_Image is used for that. So no change is needed or desired. 17.6: Corresponding_Name_Definition [Brad:] Paragraph 2 states that it can return a defining_program_unit_name. Should this be A_Defining_Expanded_Name? The Defining_Name_Kinds type does not have defining_program_unit_name. [Randy:] This paragraph is clearly talking about the *Ada* syntax item defining_program_unit_name (and the same for the others). It doesn't have anything to do with any ASIS entities. I think you're supposed to be able to figure that out because they're given in all lower case, rather than the upper and lower of ASIS entities. But that is awfully subtle. Should this be reworded somehow (I couldn't think of a simple way)? [ARG (Meeting 39):] No change is needed. 17.7 Corresponding_Name_Definition_List [Brad:] Since this is "exactly like Corresponding_Name_Definition", which does it take an "entity reference" of type Element while the other routine takes an "expression" of type Expression? Shouldn't these be the same? [Randy:] I think so, since these are subtypes we can change them to match. But which one is wrong??? [ARG (Meeting 39):] In all of 17.6, 17.7, and 17.8, change the parameter subtype to "Asis.Name". Change the paramter text to "Reference specifies a name to query." Wording [14]. 17.29 Corresponding_Called_Function [Randy:] {CD comment} Corresponding_Called_Entity (18.28) has a bullet "Statement is a call to a dispatching operation of a tagged type which is not statically determined." (It also had a bullet about a dispatching call, but that is redundant with the above.) Shouldn't this routine use the same wording? They're both calls. I didn't want to introduce any incompatibility, so I didn't make a change here. [ARG (Meeting 39):] Use the longer text from 18.28 to replace the last bullet in this function. Wording [15]. !appendix From: Randy Brukardt Sent: Thursday, March 19, 2009 7:17 PM > General question: > Some places that mention raising an exception mention raising it with > a status value (e.g., 10.11). > Others do not (e.g. 9.3), Is this ok? > It seems like a status value should always be specified. Humm; it appears that the original ASIS standard was very inconsistent about this. In new text, we've always tried to specify what status value(s) should be returned. In 9.3, it appears to be Use_Error (based on the listing in 1.1.5). I don't have much energy for trying to find places where it is not specified and figuring out the appropriate status and then the appropriate wording. So are you volunteering to do that?? ;-) **************************************************************** From: Steve Baird Sent: Thursday, March 19, 2009 8:02 PM Could this be covered once and for all with some wording specifying that if any subprogram described in the Asis manual is specified to raise a particular exception in some case and if the no status value is specified, then the exception is raised with a status of Value_Error? **************************************************************** From: Randy Brukardt Sent: Thursday, March 13, 2009 8:20 PM Maybe, although that seems wrong in the particular case of 9.3 that you pointed out. That is a "not open" case, which seems to map to "Use_Error" according to 1.1.5. So I think it would still be necessary to look at all of the wording to see which ones shouldn't default to "Value_Error". The other possibility would be to just leave it unspecified. It's not clear to me that specifying the status is actually that helpful, given that the exception raised is specified, and surely the programmer can figure out somehow what routine raised the exception. The status doesn't seem to add much value after that if it is specified (especially if it is the same for most exceptions!). It would seem to be most useful if there were multiple reasons for an exception to be raised from a single routine (there does not seem to be much of that in ASIS). In Ada 2005, I would think that the exception message would be more helpful than this status (which might just be a leftover from before there were exception messages in Ada). What does everyone else think?? **************************************************************** From: Bill Thomas Sent: Friday, March 20, 2009 12:51 AM I don't see much benefit from specifying the status value. However, the inconsistency in having it specified some places and not in others, where the expected status is similarly clear) is somewhat annoying. But I'm not convinced that it is annoying enough to necessitate trying to specify the values throughout. **************************************************************** From: Dan Eilers Sent: Wednesday, September 9, 2009 12:29 PM Comments on the ASIS CD Typographical: p. xiv, Contents - F.8.7: "Artifical" => "Artificial" p. 34, 3.7.5, line 2: "overrriding" => "overriding" p. 39, 3.7.21, A_Mod_Attribute: extra ")" p. 39, 3.7.21, A_Priority_Attribute: extra ")" p. 40, 3.7.21, A_Stream_Size_Attribute: extra ")" p. 40, 3.7.21, A_Wide_Wide_Image_Attribute: extra ")" p. 40, 3.7.21, A_Wide_Wide_Value_Attribute: extra ")" p. 40, 3.7.21, A_Wide_Wide_Width_Attribute: extra ")" p. 59, 8.9, "(in particular," missing ")" p. 62, 9.5, "(Reference Manual 10.1.4(4)" missing ")" p. 115, 15.9, line 7: "is is not" => "is not" p. 135, 15.41, line 10, "Returns a a" => "Returns a" p. 143, 16.4, "each have have" => "each have" p. 174, 17.24, line 24: "of the the" => "of the" p. 178, 17.31, line 17: "has the the" => "has the" p. 178, 17.32, line 31: "has the the" => "has the" p. 326, F.8.7: "Artifical" => "Artificial" p. 341, Index, "Elememt 2.3" is misspelled, should be combined with "Element" Editorial: Earlier versions of ASIS were oriented toward extracting semantic information from Ada compilation libraries and/or compilation environments associated with an underlying Ada implementation. But the current version of ASIS contemplates "stand-alone" ASIS implementations (such as Gela-ASIS), not tied to any underlying Ada implementation. For example, 3.3 states: "An ASIS Context is associated with some set of Ada compilation units maintained by an underlying Ada implementation or a stand-alone ASIS implementation." Similarly, the ASIS Rationale (D.1) simply says: "ASIS provides a basis for implementing portable tools that are aimed at analyzing static properties in Ada source code." allowing for the possibility that these properties of the Ada source code may be extracted from the Ada source by a stand-alone ASIS implementation rather than being extracted from the Ada compilation libraries and/or compilation environments of an underlying Ada implementation. However, some harmful vestigial references to "underlying Ada implementation" or "Ada compilation environment" remain. These need to be removed. In particular: - - - - - - - - - - Introduction. "The Ada Semantic Interface Specification (ASIS) is an interface between an Ada environment (as defined by ISO/IEC 8652:1995(E)) and any tool requiring information from it. An Ada "An Ada environment includes valuable semantic and syntactic information." Proposed change: "The Ada Semantic Interface Specification (ASIS) is an interface for extracting valuable semantic and syntactic information from Ada source code". - - - - - - - - - - Introduction. "The ASIS interface consists of a set of types, subtypes, and subprograms which provide a capability to query the Ada compilation environment for syntactic and semantic information. Proposed change: "The ASIS interface consists of a set of types, subtypes, and subprograms which provide a capability to extract syntactic and semantic information from Ada source code." - - - - - - - - - - Introduction. "The type Context helps identify the compilation units considered to be analyzable as part of the Ada compilation environment." Proposed change: delete "as part of the Ada compilation environment" - - - - - - - - - - 1.1 Scope "The Ada Semantic Interface Specification (ASIS) is an interface between an Ada environment (as defined by ISO/IEC 8652:1995(E)) and any tool requiring information from this environment. An Ada environment includes valuable semantic and syntactic information." Proposed change: "The Ada Semantic Interface Specification (ASIS) is an interface for extracting valuable semantic and syntactic information from Ada source code". - - - - - - - - - - 1.1 Scope "This International Standard specifies the form and meaning of the ASIS interface to the Ada compilation environment." Proposed change: delete "to the Ada compilation environment". - - - - - - - - - - 1.1 Scope "This International Standard is applicable to tools and applications needing syntactic and semantic information from the Ada compilation environment." Proposed change: "This International Standard is applicable to tools and applications needing syntactic and semantic information from Ada source code. - - - - - - - - - - 1.1.2 Structure "Section 2 identifies the ASIS technical concepts. Here the Ada compilation environment to which ASIS interfaces is described." Proposed change: delete "Ada compilation" - - - - - - - - - - 1.1.3.1 Implementation conformance requirements "An ASIS implementation includes all the hardware and software that implements the ASIS specification for a given Ada implementation ..." Proposed change: delete "for a given Ada implementation" - - - - - - - - - - 2.1 Ada compilation environment "ASIS is an interface between an Ada environment as defined by the Ada Standard and any tool requiring information from this environment, as shown in Figure 2. Proposed change: "ASIS is an interface providing syntactic and semantic information from Ada source code to tools requiring such information, as shown in Figure 2." - - - - - - - - - - Figure 2 - ASIS as interface to Ada compilation environment Proposed change: Figure 2 - ASIS as interface to collection of Ada source code - - - - - - - - - - 2.1.2 ASIS notion of the Ada compilation environment "Compilation_Unit also is an abstraction, which represents information about some physical object from the "external world". This physical object is treated by the underlying Ada implementation as the corresponding Ada compilation unit or as a result of compiling a configuration pragma." Proposed change: delete obscure reference to "some physical object from the external world", and "treated by the underlying Ada implementation", to simply refer to Ada source code. - - - - - - - - - - 2.3 "An ASIS Context is associated with some set of Ada compilation units maintained by an underlying Ada implementation." Proposed change: delete "maintained by an underlying Ada implementation". - - - - - - - - - - 2.3 "If an Ada implementation supports the notion of a program library or "library" as specified in section 10(2) of the Ada Standard, then an ASIS Context value can be mapped onto one or more implementor libraries represented by Containers." Proposed change: delete this sentence, or at least remove the reference to "an Ada implementation". - - - - - - - - - - 3.3 "An ASIS Context is associated with some set of Ada compilation units maintained by an underlying Ada implementation or a stand-alone ASIS implementation. Proposed change: delete "maintained by an underlying Ada implementation or a stand-alone ASIS." - - - - - - - - - - 9.1 "If an Ada implementation supports the notion of a program library or "library" as specified in Subclause 10(2) of the Ada Reference Manual, then an ASIS Context value can be mapped onto one or more implementor libraries represented by Containers." Proposed change: delete this sentence. - - - - - - - - - - 9.3 "Returns a minimal list of length one if the ASIS Ada implementation does not support the concept of a program library. In this case, the Container will have the same name as the given Context." Proposed change: delete this sentence. - - - - - - - - - - 10.22 function Can_Be_Main_Program Proposed change: delete this clause since it relies on the notion of an underlying implementation. - - - - - - - - - - 15.28 function Corresponding_Equality_Operator "Returns a Nil_Element if the Ada implementation has not defined an implicit "/=" for the "=". Implementations of this sort will transform a A/=B expression into a not(A=B) expression. The function call representing the not operation is Is_Part_Of_Implicit in this case." Proposed change: delete these sentences since they rely on the notion of an underlying implementation. - - - - - - - - - - 16.1 function Corresponding_Type_Operators "If a user-defined equality operator has been defined, an Ada implementation has two choices when dealing with an instance of the "/=" operator. a) treat A/=B as not(A=B), b) implicitly create a "/=" operator. Implementations that take the second alternative will include this implicit inequality operation in their result. Implementations that choose the first alternative are encouraged to hide this choice beneath the ASIS interface and to "fake" an inequality operation. Failing that, the function call, representing the not operation, must have Is_Part_Of_Implicit = True so that an ASIS application can tell the difference between a user-specified not(A=B) and an implementation-specific A/=B transformation." Proposed change: delete these sentences since they rely on the notion of an underlying implementation. - - - - - - - - - - 22.20 "NOTE If an Ada implementation uses implementation-dependent record components (Ada Standard 13.5.1 (15)), then each such component of the record type is included in the result." Proposed change: delete this sentence since it relies on the notion of an underlying implementation. - - - - - - - - - - Annex A Glossary "ASIS implementation". ASIS implementation. All the hardware and software that implement the ASIS specification for a given Ada implementation and that provide the functionality required by the ASIS specification. Proposed change: delete "for a given Ada implementation" - - - - - - - - - - Annex A Glossary "Compilation_Unit [type]". "Compilation_Unit [type]. An ASIS private type whose values denote an Ada compilation unit or configuration pragma from the environment denoted by some open ASIS context. A non-nil value of the Compilation_Unit type also contains information about some physical object from the "external world" treated by the underlying Ada implementation as the corresponding Ada compilation unit or as a result of compiling a configuration pragma." Proposed change: delete reference to "the underlying Ada implementation" - - - - - - - - - - Annex A Glossary "Context". "Context. A set of compilation units and configuration pragmas processed by an ASIS application. ASIS provides any information from a context by treating this set as if its elements make up an environment declarative part by modeling some view (most likely one of the views of the underlying Ada implementation) on the environment. Proposed change: delete "(most likely one of the views of the underlying Ada implementation)" - - - - - - - - - - **************************************************************** From: Tucker Taft Sent: Wednesday, September 9, 2009 2:01 PM I would rather make a statement early on that when we refer to "Ada Implementation" or "Ada Compilation Environment" we do not mean to exclude the possibility of a stand-alone ASIS implementation, rather than trying to adjust lots of existing wording with no net effect. I have trouble seeing how this vestigial wording is "harmful." **************************************************************** From: Dan Eilers Sent: Wednesday, September 9, 2009 2:28 PM > I have trouble seeing how this vestigial wording is "harmful." I consider it harmful because: 1) it erroneously implies that "stand-alone" implementations are second-class implementations. The current ASIS manual specifically criticizes implementations that regenerate or redundantly store Ada semantic information that supposedly already exists in Ada libraries (D.2.4, next-to-last bullet on p. 283); 2) it encourages compiler implementers to slow down their compilers by writing otherwise unneeded ASIS information to their program libraries, so as to be perceived as having a first-class ASIS implementation; 3) it clutters up the ASIS manual with huge gobs of junk regarding compilation environments, such as: D.4.1 Ada environment and compilation units D.4.2 ASIS context and inconsistency **************************************************************** From: Tucker Taft Sent: Wednesday, September 9, 2009 2:48 PM I'll admit we spent almost no time on the Rationale, and perhaps it should just be jettisoned, or slimmed down dramatically. On the other hand, in the normative part of the document, I don't sense any of the first-class/second-class distinction you mention. **************************************************************** From: Dan Eilers Sent: Wednesday, September 9, 2009 3:43 PM > I'll admit we spent almost no time on the Rationale, and perhaps it > should just be jettisoned, or slimmed down dramatically. On the other > hand, in the normative part of the document, I don't sense any of the > first-class/second-class distinction you mention. See for example: > Introduction. > > "The Ada Semantic Interface Specification (ASIS) is an interface between > an Ada environment (as defined by ISO/IEC 8652:1995(E)) and any tool > requiring information from it. An Ada "An Ada environment includes > valuable semantic and syntactic information." claiming that there is valuable semantic and syntactic information to be extracted from an Ada environment, coupled with Figure 2 (p. 9) showing that the compiler put this valuable information there. Then there is the contorted and confusing language about compilation_ units being abstractions repesenting physical objects from the external world made available, instead of referring simply to source code. 2.1.2 > Compilation_Unit also is an abstraction, which represents information > about some physical object from the "external world". > This physical object is treated by the underlying Ada implementation > as the corresponding Ada compilation unit or as a result of compiling > a configuration pragma. **************************************************************** From: Robert Dewar Sent: Wednesday, September 9, 2009 8:36 PM > I consider it harmful because: > > 1) it erroneously implies that "stand-alone" implementations are > second-class implementations. The current ASIS manual specifically > criticizes implementations that regenerate or redundantly > store Ada semantic information that supposedly already exists > in Ada libraries (D.2.4, next-to-last bullet on p. 283); Yes, indeed the implication is entirely erroneous, in fact complete nonsense. Not useful in any sense. > 2) it encourages compiler implementers to slow down their compilers > by writing otherwise unneeded ASIS information to their program > libraries, so as to be perceived as having a first-class ASIS > implementation; I would not worry about this point, I cannot imagine any compiler writers (certainly not us) being in the slightest bit influenced by non-normative musings of this kind :-) > 3) it clutters up the ASIS manual with huge gobs of junk regarding > compilation environments, such as: > > D.4.1 Ada environment and compilation units > D.4.2 ASIS context and inconsistency I agree this is junk **************************************************************** From: Randy Brukardt Sent: Thursday, September 10, 2009 9:56 PM ... > But the current version of ASIS contemplates "stand-alone" > ASIS implementations (such as Gela-ASIS), not tied to any underlying > Ada implementation. I'm not sure I agree. I don't think anyone (including the current ARG) has ever seriously "contemplated" stand-alone ASIS implementations. Surely, the standard was not designed for that purpose, and the various wording points you note make that clear. Now, given that someone has actually gone out and created a stand-alone ASIS implementation, perhaps the standard ought to be revised to reflect that. But I think that is a *new* comment, not something that should be considered editorial. And we need to discuss a proper response to the idea of stand-alone ASIS implementations (which could be quite different than just deleting some phrases from the standard). In any case, I'm currently collating the ASIS comments for the US. Dan, do you want this basic comment included in that package? (While I expect that we will work on comments other than those formally submitted, we will obviously respond to all comments that are formally submitted. So including it in the official comments package seems like the best way to ensure that it is addressed.) **************************************************************** From: Randy Brukardt Sent: Thursday, September 10, 2009 10:11 PM ... > 3) it clutters up the ASIS manual with huge gobs of junk regarding > compilation environments, such as: > > D.4.1 Ada environment and compilation units > D.4.2 ASIS context and inconsistency You could have just stopped with "The ASIS standard is cluttered with huge gobs of junk." ;-) We made a conscious decision not to try to fix stuff that is historical in nature (as the vast majority of Annex D is). Indeed, it would be easy to argue that none of Annex C or D (nor most of Section 2) belong in the standard in the first place -- they're background material that has no reason to be in the standard. The trouble is that trying to fix these huge gobs of junk takes huge gobs of time, and it is really easy to delete something that is actually important. (That has already happened several times that I know of...) Since hardly anyone is ever going to see this standard (given the prices for standards), getting the normative stuff right has been the focus of our efforts. Pretty much every clause that we've looked at in detail has needed major changes to have acceptable preciseness. The best way to make this thing sane would be to start over, but that is much too large of a job (and of course it would introduce its own set of problems). **************************************************************** From: Dan Eilers Sent: Thursday, September 10, 2009 10:52 PM > I'm not sure I agree. I don't think anyone (including the current ARG) > has ever seriously "contemplated" stand-alone ASIS implementations. I meant "contemplates" in the sense that the ASIS manual as it stands expressly allows "stand-alone" implementations, as stated in 3.3: "An ASIS Context is associated with some set of Ada compilation units maintained by an underlying Ada implementation or a stand-alone ASIS implementation." > In any case, I'm currently collating the ASIS comments for the US. > Dan, do you want this basic comment included in that package? Yes. I forwarded the comments to Bill Thomas in response to his Sept 5, 2009 request for comments from the SIGAda ASIS mailing list. > We made a conscious decision not to try to fix stuff that is > historical in nature (as the vast majority of Annex D is). I agree that it isn't worth anyone's time to try to fix Annex D. I would be happy with a big note at the front of it saying that it is being retained only for historical purposes, if it is kept at all. But I think the normative part of the standard deserves editing in at least the places I noted. ****************************************************************