!standard 23 10-03-10 SI99-0054-1/07 !standard 23.2.1 !standard 23.2.2 !standard 23.2.3 !standard 23.2.6 !standard 23.2.7 !standard 23.4.1 !standard 23.4.4 !standard 23.4.6 !standard 23.5.1 !standard 23.5.2 !standard 23.5.3 !standard 23.8.1 !standard 23.9.3 !standard 23.9.6 !standard 23.12.4 !standard 23.12.6 !standard 23.14.1 !standard 23.14.2 !standard 23.16.1 !class amendment 09-06-01 !status work item 09-06-01 !status received 09-06-01 !priority Medium !difficulty Medium !qualifier Omission !subject Open issues in the ASIS semantic subsystem !summary Make various fixes in the ASIS semantic subsystem as proposed in SI99-0024-1. !question (See !discussion.) !recommendation (See summary.) !wording ** This is incomplete ** [1] 23.2.7 Nested Declarative Regions Change the name of function Defining_Construct to Element_Defining_Region. Replace the second sentence of the second paragraph of text by: Function Element_Defining_Region returns the Asis.Element for the construct that defines the declarative region R. [2] 23.2.1 type View_Kinds and type View Replace this clause by: type View_Kinds is ( A_Boolean_Subtype, A_Character_Subtype, An_Ordinary_Enumeration_Subtype, A_Signed_Integer_Subtype, A_Modular_Integer_Subtype, An_Ordinary_Fixed_Subtype, A_Decimal_Fixed_Subtype, A_Float_Subtype, An_Access_To_Object_Subtype, An_Access_To_Subprogram_Subtype, An_Array_Subtype, A_Record_Subtype, A_Record_Extension, A_Task_Subtype, A_Protected_Subtype, An_Interface, A_Private_Subtype, A_Private_Extension, An_Incomplete_Subtype, A_Standalone_Object, A_Formal_Parameter_Object, An_Object_Renaming, A_Designated_Object, A_Component_Object, An_Attribute_Object, An_Aggregate_Object, A_Function_Result_Object, A_Named_Number, An_Attribute_Value, An_Expression_Value, A_Noninstance_Subprogram, A_Subprogram_Instance, A_Subprogram_Renaming, A_Protected_Subprogram, An_Imported_Subprogram, An_Attribute_Subprogram, An_Intrinsic_Subprogram, A_Designated_Subprogram, A_Protected_Entry, A_Task_Entry, A_Noninstance_Package, A_Package_Instance, A_Package_Renaming, A_Limited_Package_View, A_Generic_Package, A_Generic_Package_Renaming, A_Generic_Subprogram, A_Generic_Subprogram_Renaming, An_Exception, An_Exception_Renaming, A_Label_Statement_View, A_Block_Statement_View, A_Loop_Statement_View); subtype Subtype_View_Kinds is View_Kinds range A_Boolean_Subtype .. An_Incomplete_Subtype; subtype Object_View_Kinds is View_Kinds range A_Standalone_Object .. An_Expression_Value; subtype Callable_View_Kinds is View_Kinds range A_Noninstance_Subprogram .. A_Task_Entry; subtype Package_View_Kinds is View_Kinds range A_Noninstance_Package..A_Limited_Package_View; subtype Generic_View_Kinds is View_Kinds range A_Generic_Package .. A_Generic_Subprogram_Renaming; subtype Exception_View_Kinds is View_Kinds range An_Exception .. An_Exception_Renaming; subtype Statement_View_Kinds is View_Kinds range A_Label_Statement_View .. A_Loop_Statement_View; type View is interface; The tagged type View is the root of a hierarchy of types used to represent views on program entities. The distinct kinds of entities are enumerated by the type View_Kind. Subranges of this enumeration type are defined to correspond to the extensions of the View type. function Kind (V : View) return View_Kinds is abstract; function Is_Subtype (V : View'Class) return Boolean; function Is_Object_Or_Value (V : View'Class) return Boolean; function Is_Callable (V : View'Class) return Boolean; function Is_Package (V : View'Class) return Boolean; function Is_Generic (V : View'Class) return Boolean; function Is_Exception (V : View'Class) return Boolean; function Is_Statement (V : View'Class) return Boolean; V specifies the view to query for each of these functions. The View_Kind of an object V whose type is covered by View'Class may be determined by the Kind dispatching operation. In addition, Boolean queries Is_Object_Or_Value, Is_Callable, Is_Subtype, Is_Package, Is_Generic, Is_Exception, and Is_Statement, are provided to determine to which extension of View the specified view V belongs. For example, "Is_Callable(V)" is equivalent to "V in Callable_View'Class". [3] 23.5.1 type Object_View Add a new function after Is_Constant_View: function Is_Formal_Object (O : Object_View) return Boolean is abstract; Replace the text by: O specifies the view of an object to query for all of these functions. Function Is_Constant_View returns True if and only if the object O is a constant view of an object, or is a view of a value. Function Is_Formal_Object returns True if and only if the object O denotes a generic formal object. Function Nominal_Subtype returns the nominal subtype of the view. The returned Subtype_View corresponds to the subtype_indication, discrete_range, or type_definition that defined the nominal subtype of the object or value. The nominal subtype of a numeric literal or named number is a view of the corresponding universal base subtype. The nominal subtype of a use of an operator is that of the equivalent function call, namely the result subtype of the corresponding function. [4] 23.2.3 type Conventions Add to the last paragraph: ; the case of the result of this function is implemention-defined, but returning results in the same case as was used in the original compilation text is preferred. [5] 23.4.1 type Subtype_View Add a note at the end of the clause: Note: The characteristics of a subtype view depend on the location of the view; different views of the same subtype can get different answers from these functions. In particular, these functions respect privacy, so the characteristics can change depending on the visibility of the full view of the subtype. 23.4.6 Subtype Aspects Change the title of this subclause to "Representation and Operational Subtype Aspects". Add at the end of the subclause: function Is_Stream_Attribute_Available (S : Subtype_View; Attribute : Views.Language_Defined_Aspect_Kinds) return Boolean is abstract; S specifies the view of a subtype to query. Attribute specifies the stream attribute of interest; if it is not Read, Write, Input, or Output, raises Asis_Inappropriate_View. Returns True if the specified attribute of the subtype is available for S, and False otherwise. Note: Stream attribute availability depends on the location of the subtype view; different views of the same subtype can get different answers from this function. [6] 23.4.4 Derived Types and Primitive Subprograms Replace function Ultimate_Ancestor, its text, and the associated note, with: function Ultimate_Ancestors (S : Subtype_View) return Subtype_Vector is abstract; S specifies the view of a subtype to query. Function Ultimate_Ancestors returns all of the ancestors of the subtype S that are not themselves a descendant of any other type; the list will just be the type itself if Is_Derived (S) returns False and Progenitors (S) (see 23.8.3) returns an empty vector. function Root_Noninterface_Ancestor (S : Subtype_View) return Subtype_View'Class is abstract; S specifies the view of a subtype to query. Function Root_Noninterface_Ancestor raises Asis_Inappropriate_View if S is composite and Is_Interface (S) (see 23.8.3) is True. Otherwise, it returns the noninterface ancestor of the subtype S that is not itself a descendant of any other type; it will be the type itself if Is_Derived (S) returns False returns False. function Full_View_Root_Noninterface_Ancestor (S : Subtype_View) return Subtype_View'Class is abstract; S specifies the view of a subtype to query. Function Full_View_Root_Noninterface_Ancestor raises Asis_Inappropriate_View if S is composite and Is_Interface (S) (see 23.8.3) is True. Otherwise, it returns the full view of the noninterface ancestor of the subtype S that is not itself a descendant of any other type. NOTE: Function Root_Noninterface_Ancestor may stop on an incomplete or partial view. If the ultimate full view is needed, call Full_View_Noninterface_Ancestor instead. AASIS Note: The Full_View of the Root_Noninterface_Ancestor may be a derived type; Full_View_Root_Noninterface_Ancestor keeps going until the full view of an ancestor that has no non-interface ancestor. [7] 23.9.3 Callable view categorization. Add a new function at the end of the list of functions: function Is_Formal_Subprogram (C : Callable_View) return Boolean is abstract; Modify the end of second paragraph of text: ...An_Intrinsic_Subprogram, {or} A_Designated_Subprogram[, or A_Generic_Formal_Subprogram]), and returns False otherwise. Add in front of the note: Is_Formal_Subprogram returns True if the Callable_View denotes a generic formal subprogram, and returns False otherwise. [8] 23.5.2 Components of Objects Change the name of function Is_Component_Selected_Component to Has_Storage_Place_Attributes. Modify the first paragraph: O specifies the view of an object to query for each of these functions. {For all of these functions, if the view O is defined by an object renaming, the result is determined by the properties of the renamed object.} AASIS Ramification: For example, if we have Z : Natural renames O.C; Is_Component on a view of Z will return False. These functions are unusual; most of the functions in the semantic subsystem would either give the same result for both the renamed and original entity (making the point moot) or would return the value for the original entity. End Ramification. Modify the last paragraph: Function {Has_Storage_Place_Attributes}[Is_Component_Selected_Component] returns True if and only if the view O is of a selected component that {has storage place attributes}[denotes a component]. Functions Position, First_Bit, and Last_Bit, return a view of the value of a reference to the corresponding attribute of the given component O, or raise ASIS_Inappropriate_View if {Has_Storage_Place_Attributes}[Is_Component_Selected_Component] (O) returns False. [9] 23.8.1 Composite Subtypes Modify the second function: function [Contains_Task] {Has_Task_Part} (C : Composite_Subtype) return Boolean is abstract; Delete the function Has_Nondiscriminant_Region_Parts. Modify the third paragraph: ... Function [Contains_Task] {Has_Task_Part} returns True if and only if the type of the subtype C has a part that is {of} a task type {(whether visibly or only in the full definition). If subtype C is a class-wide subtype S'Class, then returns Has_Task_Part(S)}. ... Modify the last paragraph: [Function Has_Nondiscriminant_Region_Parts returns True if and only if the subtype C is a descendant of a record type, a record extension, a task type, or a protected type.] Function Nondiscriminant_Region_Parts returns a list of Region_Parts, one for each separate visible region part, each comprising components, entries, and protected subprograms from a single list of components or items {from the declaration of some ancestor of the type of subtype C. The returned list is empty if {subtype C is not a descendant of a record type, a record extension, a task type, or a protected type}[Has_Discriminant_Region_Parts (C) is False]. [10] Modify 23.14.1 as follows: 23.14.1 type Statement_View type Statement_View is interface and Views.View; The type Statement_View represents a view of a {named} statement {or of a particular statement label}. Modify 23.14.2 as follows: 23.14.2 function [Corresponding]{Element_For}_Statement function [Corresponding]{Element_For}_Statement (S : Statement_View) return ASIS.Statement is abstract; S specifies the statement view to query. Yields the ASIS.Statement value corresponding to the statement {view} S. {If S represents a label, the result is the ASIS.Statement having the label.} [11] Modify 23.2.2 as follows: 23.2.2 function Element_Denoting_View function Element_Denoting_View (V : View) return Asis.Element is abstract; V specifies the view to query. Returns an Asis.Element that denotes {(or defines)} the View V[.]{, with Element_Kinds of either An_Expression, or A_Definition with Definition_Kinds A_Type_Definition or A_Subtype_Indication. Calling Corresponding_View or Corresponding_Subtype_View, as appropriate, on the returned Asis.Element, will return a View equivalent to the given View. In the case of an expanded name, returns an Asis.Element representing the simple name (An_Identifier, An_Operator_Symbol, A_Character_Literal), rather than A_Selected_Component. Returns Nil_Element if there is no Asis.Element associated with the View.} {NOTE } This is one of the primary mechanisms for navigating from the Semantic Subsystem to the other parts of ASIS. [NOTE ]This is the element that includes the syntactic construct that caused the particular usage represented by the view. This is not the [declaration] {definition} of the view unless the view is of a [declaration] {subtype}. Modify 23.16.1 as follows: 23.16.1 function Corresponding_Subtype_View function Corresponding_Subtype_View ([Type_]Definition : in Asis.[Type_]Definition) return Asis.Subtype_Views.Subtype_View'Class; [Type_]Definition specifies the type definition {or subtype indication} to query. Returns a view that specifies the subtype denoted by [Type_]Definition. [Type_]Definition expects an element that has one of the following Definition_Kinds: A_Type_Definition A_Private_Type_Definition A_Tagged_Private_Type_Definition A_Private_Extension_Definition A_Task_Definition A_Protected_Definition A_Formal_Type_Definition {A_Subtype_Indication A_Discrete_Subtype_Definition A_Discrete_Range} Raises ASIS_Inappropriate_Element with a Status of Value_Error for any element that does not have one of these expected kinds. [12] Modify 23.2.6 as follows: 23.2.6 type Region_Part and type Region_Part_Kinds type Region_Part is private; type Region_Part_List is array (Positive range <>) of Region_Part; type Region_Part_Kinds is ( Generic_Formal_Part, Callable_Formal_Part, Discriminant_Part, Entry_Family_Index_Part, Record_Part, Extension_Part, Package_Visible_Part, Package_Private_Part, Task_Visible_Part, Task_Private_Part, Protected_Visible_Part, Protected_Private_Part, Body_Part, Block_Declarative_Part, Loop_Declarative_Part, {Public_}Child_Part{, Private_Child_Part}); Certain declarative regions are broken up into distinct parts, represented by the type Region_Part. The type Region_Part_Kinds enumerates the distinct kinds of region parts. {Callable_Formal_Part is the formal part of the region defined by a subprogram, entry, or accept statement. For a record type, Record_Part includes the non-discriminant components. For a record extension, the Extension_Part includes the components declared in the record_extension_part, and the Record_Part includes the other non-discriminant components. Public_Child_Part includes the public children of a library unit. Private_Child_Part includes the private children of a library unit. The Public_Child_Part and the Private_Child_Part might not include child units that are unreferenced by the units within the current context. The *visible* parts of a declarative region are those parts containing declarations that are visible outside the immediate scope of the region. As an example, for a type this could include a Discriminant_Part, a Record_Part, an Extension_Part, a Task_Visible_Part, and a Protected_Visible_Part. For a generic unit, this could include a Generic_Formal_Part, a Callable_Formal_Part, a Package_Visible_Part, and a Public_Child_Part.} ... function All_Region_Parts (R : Declarative_Region) return Region_Part_List; function Visible_Region_Parts (R : Declarative_Region) return Region_Part_List; [function Private_Part (R : Declarative_Region) return Region_Part; function Body_Part (R : Declarative_Region) return Region_Part;] {function Part_Of_Region(R : Declarative_Region; Part : Region_Part_Kinds) return Region_Part;} R specifies the declarative region to query for each of these functions. Function All_Region_Parts returns an array of the region parts comprising the declarative region R. Function Visible_Region_Parts returns an array of the visible parts of the declarative region R. [Function Private_Part returns the private part of the declarative region R. Private_Part returns an empty Region_Part if R has no private part, or if the private part of R is empty. Function Body_Part returns the body part of the declarative region R. Body_Part returns an empty Region_Part if R has no body part, or if the body part of R is empty.] {Part_Of_Region returns the specified part of the given region, or an empty Region_Part if the region does not have the given part or it is empty.} The declarative region of a loop statement or of a block statement has only [a body] {one} part. Other kinds of regions may have multiple region parts. [13] 23.5.3 Aliased Views and Dereferences Modify this clause is follows: function Is_Aliased (O : Object_View) return Boolean is abstract; [type Static_Accessibility_Level is range 0 .. ;] [Library_Level : constant Static_Accessibility_Level := 0; Deepest_Accessibility_Level : constant Static_Accessibility_Level; Incomparable_Accessibility_Level : constant Static_Accessibility_Level;] [function Static_Accessibility (O : Object_View) return Static_Accessibility_Level is abstract;] {function Has_Static_Accessibility_Level (O : Object_View) return Boolean is abstract; function Is_Library_Level (O : Object_View) return Boolean is abstract; function Is_Statically_Deeper_Than (O : Object_View; Compared_To : Object_View) return Boolean is abstract;} function Is_Dereference (O : Object_View) return Boolean is abstract; function Dereferenced_Value (O : Object_View) return Object_View'Class is abstract; function Is_Implicit_Dereference (O : Object_View) return Boolean is abstract; {function Is_Explicit_Dereference (O : Object_View) return Boolean is abstract;} O specifies the view of an object to query for each of these functions. Function Is_Aliased returns True if and only if the view O is aliased. [Function Static_Accessibility returns the static accessibility level of the view O, or raises ASIS_Inappropriate_View if Is_Aliased (O) returns False. The static accessibility level value 0 is returned if the view O is of a library level object. Incomparable_Accessibility_Level is returned if the view O is a dereference of an access-to-object parameter. Deepest_Accessibility_Level is returned if the view O is a dereference of an access-to- subprogram parameter.] {Function Has_Static_Accessibility_Level returns True if Is_Aliased(O) and the statically deeper relationship is defined for the accessibility level of the view O. Function Is_Library_Level returns True if Has_Static_Accessibility_Level(O) is True and the accessibility level is library level. Function Is_Statically_Deeper_Than raises ASIS_Inappropriate_View if Has_Static_Accessibility_Level returns False for either operand; otherwise it returns True if and only if the accessibility level of O is statically deeper than that of the object view Compared_To.} Function Is_Dereference returns True if and only if the object O is a dereference of an access-to-object value. Function Dereferenced_Value returns a view of the access value that was dereferenced in the dereference O, or raises ASIS_Inappropriate_View if Is_Dereference(O) returns False. Function Is_Implicit_Dereference returns True if and only if the object O is an implicit dereference of an access-to-object value. {Function Is_Explicit_Dereference returns True if and only if the object O is an explicit dereference (use of .all) of an access-to-object value.} [14] 23.9.6 Access-to-subprogram views At the end, modify: function Is_Implicit_Dereference (C : Callable_View) return Boolean is abstract; {function Is_Explicit_Dereference (C : Callable_View) return Boolean is abstract;} C specifies the callable view to query. Is_Implicit_Dereference returns True if and only if the callable view C is an implicit dereference of an access-to-subprogram value. {Is_Explicit_Dereference returns True if and only if the callable view C is an explicit dereference (use of .all) of an access-to-subprogram value.} [15] Modify 23.12.4 as follows: ... As seen from within itself, a generic unit is an instance (that is, the current instance of the given generic); it is not a generic unit. This function yields a view of that instance for generic G. {For example, given the generic package Ada.Text_IO.Enumeration_IO, Current_Package_Instance would return a view of a non-generic package which can be passed to the interfaces defined for Package_View, such as Visible_Part, Is_Full_View, etc.} Modify 23.12.6 as follows: ...As seen from within itself, a generic unit is an instance (that is, the current instance of the given generic); it is not a generic unit. This function yields a view of that instance for generic G. {For example, given the generic subprogram Ada.Unchecked_Deallocation, Current_Subprogram_Instance would return a view of a non-generic subprogram which can be passed to the interfaces defined for Callable_View, such as Callable_Profile, Is_Procedure, etc.} !discussion Following are all 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. We need to decide how (or whether) to handle these. Many of these are official comments from the US on the ASIS committee draft, so answers are required. These are marked with {CD-Comment}. We also have a few comments from Gary Barnes that were moved from SI99-0057-1 in order to prevent delaying that SI. ======= Section 23: [Jean-Pierre:] {CD comment} Current ordering of packages seems weird. We have: Asis.Views Asis.Program_Units Asis.Subtype_Views Asis.Object_Views Asis.Profiles Asis.Subtype_Views.Elementary Asis.Subtype_Views.Composite Asis.Callable_Views Asis.Object_Views.Access_Views Asis.Package_Views Asis.Generic_Views Asis.Exception_Views Asis.Statement_Views Asis.Declarations.Views Asis.Definitions.Views Asis.Expressions.Views Suggest grouping all "Views" packages, and grouping child packages after the corresponding parent, ie: - packages Asis.Subtype_Views.Elementary and Asis.Subtype_Views.Composite after Asis.Subtype_Views. - package Asis.Object_Views.Access_Views after Asis.Object_Views [Greg:] Seems reasonable. [Randy:] I've put this on the open issues list, for three reasons: (1) This order of packages is used in every place in the Standard where a list of packages is given (there are at least 5), so the change isn't as trivial as rearranging the order of the text; (2) Tucker had some reason for picking this order (I don't think it was random; he followed the same order from the beginning). We approved this as the order as well; (3) I know the order of the packages was chosen so that the result was compilable in that order. We don't want to reorder them into some order that isn't compilable. (And we also don't want forward references if we can help it.) I'm certain that, for instance, Profiles has to be defined before Callable_Views and Subtype_Views.Composite, but it of course depends on Subtype_Views. Indeed, the only reason Object_Views.Access_Views exists is to make compilation possible. I don't want to change this property without discussion. [ARG (Meeting 39):] Reorder the packages. Put the subtype related packages first, then the object related ones, and finally the others. Make sure that related lists are also changed (Randy thinks there are 5 such places). %% Finished wording change to handle %% --- [Jean-Pierre:] {CD Comment} Asis.Program_Units is the only one (with Asis.Profiles, see later) from the semantic interface whose name does not include "_view". OTOH, this package is about View_Declaration, not View. Note also that the only other package dealing with View_Declaration, Declarative_Region, is a subpackage of Asis.Views. Do the same with this package? [Greg:] Seems reasonable. [Randy:] I believe that Declarative_Region is nested because the package isn't compilable otherwise. (Limited with is too limiting here, we couldn't have function returns or operate on vectors). I don't think it ought to be nested, it's just a requirement of the interconnections that no one saw a way around. Indeed, I consider nested packages a last resort; a child is always better (more flexible maintenance, less junk dragged in, etc.) I don't think that we should be going in the other direction. You said "see later" about Asis.Profiles, but there aren't any comments on that here. [Jean-Pierre:] I checked, and I didn't make any comments on Asis.Profiles. [ARG (Meeting 39):] Program_Units and Profiles aren't views. Similarly, View_Declaration is not a view. (it can be thought of as "Declaration_of_View"). No change here. Section 23 global: [Jean-Pierre:] {CD comment} Names of queries doing the same thing are sometimes inconsistent: Element_Denoting_View, Defining_Construct, Corresponding_Statement (how is it different from Element_Denoting_View?) These all go from the semantic subsystem to the syntactic subsystem. And I just noted that to go from a view_declaration to the corresponding declaration, the function is just called "Declaration" (23.2.5). [Greg:] These seem to return different value/types. Perhaps these should all be "Corresponding_". [Randy:] I don't really want to argue about naming, that is a never-ending pit. I've always hated the name "Element_Denoting_View", for instance, but that doesn't seem to have gotten it changed. I'm not about to do unilaterally, especially as I don't really have a good idea for a name. "Corresponding_Element" would be consistent with the rest of ASIS, I guess. (But I dislike that naming, too, because it doesn't connote semantics in any sane way, and besides, any routine starting with "Corresponding_" is old junk that shouldn't be used in favor of this new, better way -- it would be best not to confuse them.) Anyway, I would suggest making concrete suggestions (preferably last year :-), rather than general gripes. [Jean-Pierre:] How about Corresponding_Syntactic_Element ? [Randy:] BTW, Defining_Construct is very different, since it takes a declarative_region (not a view), and returns the defining declaration's element. I'd expect that it would be used after getting the declarative_region of a view, and would have no relationship to the element of the view. Giving the function a similar name would be very confusing, I think. But we need examples before drawing any conclusions -- that's the whole reason for going with a CD, because we don't have those examples, so it is too early to freeze this in stone. [ARG (Meeting 39):] A Statement_View represents a label or a named statement (block, loop). But a label is *not* a statement. One idea is that Corresponding_Statement should be Target_Statement. Assigned to Tucker Taft. [Tucker Taft (Feb 24 2010):] Tucker proposed wording that clarifies the intent. Wording [10]. [ARG ASIS Subcommittee (Nov 6 2009):] 23.2.7: Change the name of "Defining_Construct" to "Element_Defining_Region". Change the text to: "Function Element_Defining_Region returns the Asis.Element for the construct that defines the declarative region R." Wording [1]. For Element_Denoting_View, this returns the name or expression associated with the view (not other kinds of things). Assigned to Tucker Taft. [Tucker Taft (Feb 24 2010):] Tucker proposed wording that clarifies the intent. Wording [11]. For Corresponding_Statement, the name ought to start with the word "Element". One thought is "Element_for_Statement". Wording [10]. --- [Gary Barnes (from SIGAda):] 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 all of 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. [ARG (Meeting 39):] Single character parameter names are OK for the first parameter; it is not intended that that parameter would be given with named notation (calls will typically be in prefix notation, and if not, positional notation is adequate for the first and often only parameter). But parameters other than the first should have meaningful names. This was assigned to Tucker Taft; he reported in February that there are very few subprograms with more than one parameter, and in general those already have meaningful names for parameters 2..N. No changes recommended. 23.2.1: View_Kinds [Randy:] {CD comments (FR, US)} It seems odd that A_Generic_Formal_Subprogram is a kind, but no other kind of formal parameter is a kind. Why is this different than a formal package (which just has a query), for instance? (This question inspired by Jean-Pierre.) [ARG ASIS Subcommittee (Nov 6 2009):] There is a Generic_Formal_Object as well. But there isn't a Generic_Formal_Package or Generic_Formal_Types. We surely don't want to duplicate all of the type routines. We need to be consistent. So get rid of the formal kinds from 23.2.1. Add Is_Formal_Subprogram to 23.9.3 (the kind would be A_Noninstance_Subprogram), and add Is_Formal_Object to 23.5.1 (the kind would be Standalone_Object). Wording [2, 3, 7]. --- [Gary Barnes (from SIGAda):] 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. [ARG (Meeting 39):] Assigned to Tucker Taft. ** [Put into Wording [2] when this exists.] [Tucker Taft (Feb 24 2010):] Here is the existing wording: The View_Kind of an object V whose type is covered by View'Class may be determined by the Kind dispatching operation. In addition, Boolean queries Is_Object_Or_Value, Is_Callable, Is_Subtype, Is_Package, Is_Generic, Is_Exception, and Is_Statement, are provided to determine to which extension of View the specified view V belongs. This seems unambiguous as to the meaning of these operations. Is_Callable(V) seems clearly equivalent to V in Callable_View'Class. How about if we add the following to the above paragraph: {For example, "Is_Callable(V)" is equivalent to "V in Callable_View'Class".} Wording [2]. [ARG ASIS Subcommittee (Nov 6 2009):] For all of the Is_xxx, make the parameters class-wide, and drop the "is abstract". Wording [2]. Reorder the Kinds and functions in the same order as the definition of the packages. Wording [2]. 23.2.2: Element_Denoting_View [Jean-Pierre:] {CD comment} There can be several elements denoting the same view. F.e., Pack.Var and Var (from Pack.Var) denote the same view. Does the returned element depend on how the view was originally obtained? [Randy:] I believe it does. It seems necessary to keep track of the source of a view, because other properties also can change (for instance, because of visibility). This case is a bit more annoying than those other properties, but it doesn't seem to be a hardship (one presumes a view includes an indication of the element from which it was derived). Perhaps we need an AASIS note here to mention this case. [ARG ASIS Subcommittee (Nov 6 2009):] Pack.Var and Var would most likely return different elements to represent the different names. When a view is synthesized, we would want to have a rule as to what you get. Do you (or do you not) get the expanded name (the full name of the entity). We need to have a global statement of what happens. For example, asking the Nominal_Subtype of an object (which can be an expression), we will need to know how to figure out what element you get. It might be easier to process a simple name if that is returned from Element_Denoting_View. Assigned to Tucker Taft. Addressed in Wording [11]. --- [Jean-Pierre:] {CD comment, misfiled under 23 global} Some queries create views that (possibly) have no corresponding syntactic element (Unadorned_Subtype, Base_Subtype, Classwide_Subtype, Unprefixed_Callable_View, Current_Package_Instance, Current_Subprogram_Instance). What is returned in that case? [Randy:] It's pretty clear to me that if there is no element as suggested above, either (1) Nil_Element is returned; or (2) an exception is raised. But which choice is best isn't clear to me, and in any case, we need some wording (users and implementers ought not have to guess!). [ARG ASIS Subcommittee (Nov 6 2009):] Element_Denoting_View returns Nil_Element if there is no such element. (Many views are synthesized; this routine should not create elements, it should only return ones that already exist in the program.) Element_Denoting_View never returns a Defining_Name; a regular Name (really an Expression) is returned. [Tucker Taft (Feb 24, 2010):] Wording [11] sufficiently addresses this. --- [inspired by Jean-Pierre, written by Randy:] {CD comment} We try to keep closely to the language of Ada semantics in the semantic subsystem. Is "Element_Denoting_View" really the right name for this function? "Denotes" as a technical term only applies to "usage names" (8.6(16)). But not all views (statement_views, for instance) and surely not all elements necessarily correspond to a "usage name". And are literals "usage names" for this purpose? We surely have views of "2" and elements representing "2", but I don't see a formal denotes relationship here. Perhaps we need to find a different name for this function. [ARG ASIS Subcommittee (Nov 6 2009):] "Denotes" is probably close enough for "2" and other literals. So no change is needed. 23.2.3 [Jean-Pierre:] {CD comment} What is the casing of the string returned by Convention_Identifier (like in the pragma, upper-case, implementation-defined)? [Greg:] This would seem to be implementation_defined. [Randy:] I'd say "unspecified" :-) But it probably shouldn't be. No idea what is best, though. [FR recommendation]: Specify that the case is implementation defined, with a recommendation to use the same casing as in the source. [ARG ASIS Subcommittee (Nov 6 2009):] Be consistent with the syntactic interface (for instance, see 10.20). So add: "The case of the result of this function is implemention-defined, but returning results in the same case as was used in the original compilation text is preferred." Wording [4]. 23.2.5: [Jean-Pierre: (commenting on Randy's recent update)] {CD comments (US & FR)} Can you really have anonymous /declarations/ (an anonymous subtype is introduced by having a definition in place of a subtype name - there is no declaration)? [Randy:] Humm, I got confused by definition vs. declaration. And apparently, you did too, since you later asked how Has_Declaration could return False. If an anonymous access type doesn't have a declaration, then that clearly gives you an answer! But it still seems to me that there are anonymous view_declarations -- or there are problems with this model. (Indeed, I think the latter is more likely.) I don't see how to get from unnamed things like unnamed blocks and single task types to their region parts (to be able to look at their contained declarations). You need to be able to get a declarative region; I was presuming that you got that from the declaration, but if they don't have declarations then you need some way to get them from the view. But I know there aren't any statement view processing operations, so you can't get the declarative region of a block or loop. I suppose you might stumble into one by processing a prefix, but I thought the sort of tools you wrote wanted completeness! Similarly, I don't see any operations to get the region from an anonymous definition of a task type or protected types. You can get the (single) object's declaration, but I would hope that objects haven't gained private parts! Moreover, for types you are *only* interested in the definition. The declaration is essentially irrelevant (because it has to be named, and many interesting types aren't named in Ada). You still want to know where the *definition* is declared (even if it is buried in a much larger declaration (record, subprogram, etc.)). But such a definition does not have a declaration, so you could never get to a point where you could even find out where it is declared. That makes it pretty hard to check nesting or the like. I don't know how to reconcile this. [ARG ASIS Subcommittee (Nov 6 2009):] function "Declaration" in 23.2.5 should be changed to "Element_For_View_Declaration" to be consistent with our previous naming scheme. %% Finished wording change to handle %% The original model was that only named things have View_Declarations. But there are many anonymous things in Ada. Consider the following use case: You want to add a rule to an Asis tool that there are no visible anonymous access types (no parameters, no objects, etc.) When you see an anonymous access subtype, you will need to find out whether the anonymous type is in the private part or the body (where it is OK) or the visible part. The only way to do that in the semantic interface is to get the declarative region of the declaration, and for that you need the View_Declaration. The group agree that there always has to be a declaration for a subtype, even if it does not have a name. Wording changes are needed. Assigned to Tucker Taft. [Tucker Taft (Feb 24 2010):] I understand the need for a declaration of a type and its first subtype. I don't understand the need for a declaration for a "secondary" subtype. [Randy: What about subtype_declarations? Subtype_indications in other contexts? Etc.] [ARG (Meeting #40):] After we agreed to the wording proposed in February, Tucker announces that he believes that Has_Declaration is still incorrect. He has another action item on this topic. Also see the next item. ** [Tucker Taft (Mar 9, 2010):] Modify 23.2.11 as follows: 23.2.11 Views and Declarations function Has_Declaration (V : View) return Boolean is abstract; function Declaration (V : View) return View_Declaration'Class is abstract; {function Is_Defined_In_Declaration(V : View) return Boolean is abstract; function Declaration_Containing_Definition(V : View) return View_Declaration'Class is abstract;} ... Function Has_Declaration returns True if and only if view V was defined by a declaration. {Has_Declaration returns True for both explicitly and implicitly declared subprograms.} Function Declaration returns the declaration that defines view V, or raises ASIS_Inappropriate_View if Has_Declaration (V) returns False. {Is_Defined_In_Declaration returns True if and only if view V was defined as part of a declaration. Is_Defined_In_Declaration always returns True given a view of a first subtype, even if the type is anonymous. Declaration_Containing_Definition returns the declaration that contained the definition of the view V, or raises ASIS_Inappropriate_View if Is_Defined_In_Declaration(V) returns False. For the first subtype of an anonymous type defined as part of an object declaration, Declaration_Containing_Definition returns the associated object declaration. For the first subtype of an anonymous type defined as part of the return subtype of a function declaration, Declaration_Containing_Definition returns the associated function declaration. If a non-first subtype is defined by a subtype_indication or discrete_range appearing within a declaration, then Is_Defined_In_Declaration returns True, and Declaration_Containing_Definition returns the Declaration containing the subtype definition.} ** End new wording. [Gary Barnes (February 11): The Defined_View interface is interesting in as much as it seems to be impossible. It takes an argument which is a View_Declaration. A View_Declaration can be created solely by taking an Asis.Declaration and invoking Corresponding_View_Declaration. Defined_View would expect to take such a View_Declaration and return a View. But Views only represent Asis.Expressions, Asis.Type_Definitions, and Asis.Statements. So there is no View variety that can be created starting with an Asis.Declaration (or an Asis.Defining_Name such as might be obtained by calling View_Defining_Name on the View_Declaration). [Randy:] My understanding of the model is that Defined_View returns a view of the name of the declaration. In Tucker's original model, all View_Declarations had names, so this made sense (although it ought to be more explicit). However, since that doesn't work very well, we may need to rethink this function. What exactly does this return a view of for anonymous declarations? In any case, note that no element need be associated with the view. A view of an anonymous subtype (from a component declaration, for instance) probably will not have an element associated. The only place element/view correspondence is required is where named entities are used or declared. In any case, clearer wording is needed here. [Tucker Taft (Feb 24 2010):] Tucker provided wording. [ARG (Meeting #40):] This wording seems problematic; there are more cases than just object declarations. Tucker will try again here. This item is related to the previous one. [Tucker Taft (Mar 9 2010):] Modify 23.2.5 as follows: 23.2.5 type Declarative_Region and type View_Declaration ... function Defined_View (D : View_Declaration) return View'Class is abstract; ... Function Defined_View returns the View defined by declaration D. If a declaration defines multiple views because the list of Identifiers has more tha[t]{n} one element, then a separate View_Declaration is associated with each view, just as though they were defined by separate declarations. {In the case of an object declaration that includes the definition of an anonymous type or a non-first subtype, Defined_View returns an Object_View, not a Subtype_View. Views returned by Defined_View, other than Subtype_Views, do not have an associated usage name Asis.Element, meaning that Element_Denoting_View will return Nil_Element.} ** End new wording. [Randy: I'm not sure of why you talk about objects here at all; many entities have embedded anonymous types and subtypes and you only mention one. Your model (which I still find unnecessarily pedantic) is that only named things have View_Declarations, so it is impossible for an anonymous type to have a View_Declaration.] 23.2.6 [Jean-Pierre:] {CD comment} What is a Child_Part ? [Greg:] I assume this is the child package (part) of the whole package tree. Should this be renamed? [Randy:] I think the Child_Part is the implicit declarative part where child packages live. But it's not clear to me that it is really separate. And shouldn't there be a private child part, too? All of these parts need a better explanation, the names are just here and we're supposed to guess what they mean. [US comment:] Most of the _Parts here are not formally defined by the Ada standard. Thus they need to be defined here. What is a Record_Part? Child_Part? Callable_Formal_Part? [ARG ASIS Subcommittee (Nov 6 2009):] These parts need formal definitions. The names in a context clause need to belong to some region part. That also needs to be added/defined. Assigned to Tucker Taft. [Tucker Taft (Feb 24 2010):] New wording provided. Wording [12]. --- [Jean-Pierre:] {CD comment} For Visible_Region_Parts: I had a hard time figuring out how a declarative region could have several visible parts. I thought of a generic package (formal part + package visible part), discriminated PO (disciminant and components). Are there others? Is it worth having this query? [Randy:] There is no other way to get visible parts (without the body and private parts), so I'm pretty sure we need the query. We surely need one if we have a private part query and a body part query. But whether it really needs to return a list (or whether all of these ought to return a list, if the private part and the private child part are separate), I can't say. [FR comment:] Specify the cases when a Declarative_Region can have multiple Region_Parts. [ARG ASIS Subcommittee (Nov 6 2009):] The model is that the single visible part of Ada is broken into multiple region parts. These part need to be defined. We presume that the wording assigned to Tucker in the previous item will explain this, too. 23.2.11 [Jean-Pierre:] {CD comment} I find the name Has_Declaration misleading, since every view has a declaration. Apparently, the intended purpose is rather Is_Defining_View or Is_Declaration_View. [Greg:] Ok, Is_Declaration_View seems best to keep consistent terminology. [Randy:] I agree there is a problem, but I'm not really sure what the intent is. You are suggesting the intent is that this particular view is a declaration. I suppose that is possible, but it could also mean Has_Explicit_Declaration (that's what *I* thought it meant). It's definitely clear we need a better name and wording to express the intent. It would help if we had a better explanation of the intent of View_Declaration. [Randy (summarizing later discussion):] Jean-Pierre mentioned in another discussion that an anonymous access type has a definition but no declaration. (Well, technically, it is part of some unrelated declaration, but surely we don't want to get a subprogram when we query for the declaration of a subtype!) So it appears that his original premise here is false. [Gary Barnes (November 4):] "Function Has_Declaration returns True if and only if view V was defined by a declaration." What does that mean? Views are not "defined" by anything. A View is a value obtained by starting with some Asis.Element. There are interfaces for obtaining View values from Asis.Expression elements and interfaces for obtaining View values from Asis.Type_Definition elements. There are no interfaces for obtaining View values from Asis.Declarations or Asis.Defining_Names which could possibly be used to justify the word "defined". Similarly, the Declaration interface in that same paragraph has the problem of, what does it really do? [Randy:] The intent is that "defined" is used in its technical Ada sense. The entire semantic subsystem is talking about Ada semantics unless it is clearly talking about something specific to ASIS (like an element). Probably need to make that clearer somewhere. Of course, this particular definition is a mess anyway (see previous discussion.) [ARG ASIS Subcommittee (Nov 6 2009):] The area clearly needs improvement, and seems to be related to the 23.2.5 changes. Assigned to Tucker Taft. Included in wording for 23.2.5 **Add xref**. [Gary Barnes (February 11):] Views represent Asis.Expressions, Asis.Type_Definitions, and Asis.Statements. Of these things only Expressions have the possibility of being or referencing something that has a declaration because they can be used to name entities. It would appear that Has_Declaration(View) can simply be implemented by this expression: Asis.Elements.Expression_Kind (Asis.Views.Element_Denoting_View (View)) in Asis.An_Identifier .. Asis.An_Attribute_Reference And if that is the case it is not obvious that the Has_Declaration interface needs to exist. If that is not the case then what other situations are there? [Randy:] Clearly, not all attribute references have declarations (consider Integer'First), so the above is clearly False. Beyond that, in Tucker we trust. :-) 23.2.12 [Jean-Pierre:] {CD Comment} It seems odd that all queries in this paragraph operate on Views, while Aspect_Items (23.2.9) operates on View_Declaration. [Greg:] True. Would you suggest changing 23.2.9 to just use Views then have the text clear that is expects a View_Declaration? [Randy:] I disagree that there is anything odd here. 23.2.9 is about finding out all of the aspects of a particular declaration. That doesn't seem useful away from declarations. OTOH, querying about individual aspects makes sense for any view. You might want to know if some use has Size specified, and forcing one to get the declaration in order to find out seems like excess work. You can then use functions like Object_Size to find out the specified value (of course, you have to know that you have an object in that case). Object_Size takes a view, of course, so it would be nasty to have to get a declaration just to find out if it is specified. I doubt this capability has much use other than Size and Alignment, but there it is quite important, I would think. Of course, this is another case that without examples, we can't really see what is or is not odd. [Jean-Pierre:] If it operates on a view, it would seem consistent to return only aspects that are visible for that view (f.e.: a subprogram from a package, with pragma import in the private part). Is it "imported" for a view from outside the package? [Randy:] Gee, I thought that was what it did. In this world, *everything* is a view, after all. Clearly we need some discussion. But note that you had me change various other wording to use Is_Aspect_Specified (X, Some_Aspect) returns True, which would not work if these were on view_declarations. [ARG ASIS Subcommittee (Nov 6 2009):] Operational aspects are clearly view-specific (otherwise "availability" of stream attributes could not be calculated). So this needs to be view-specific. There doesn't seem to be any need to change any wording. But 23.4.6 should use the same terminology as this clause. It should be called "Representation and Operational Subtype Aspects". Wording [5]. Calculating availability is hard. Add Is_Stream_Attribute_Available to 23.4.6. function Is_Stream_Attribute_Available (S : Subtype_View; Attribute : Views.Language_Defined_Aspect_Kinds) return Boolean is abstract; If Attribute is not Read, Write, Input, or Output, raises Asis_Inappropriate_View. Returns True if the specified attribute of the subtype is available for S, and False otherwise. Note: Stream attribute availability depends on the location of the subtype view; different views of the same subtype can get different answers from this function. Wording [5]. [I added this note as it is very important that the "correct" subtype view is used when calling this function. I added a similar note near all of the subtype properties (especially Is_Limited) in 23.4.1. Users could very easily forget that a subtype may be limited only in part of its scope. (I do!). - Randy] 23.4.4 [Jean-Pierre:] {CD comment} In function Ultimate_Ancestor: "If all of the ultimate ancestors are interfaces, Ultimate_Ancestor returns an unspecified one". I don't think this is very useful, I'd rather have it return the type itself. This gives a simple semantic to the query: it returns the ultimate non-interface ancestor. The only case where an interface would be returned is when S is an interface, and S itself would always be returned in that case. [Randy:] We talked about the intent of this function extensively, and I don't want to change the semantics on someone's whim. Besides, the proposed semantics don't sound any more useful than the original ones: you still can get abstract ancestors, just no longer interface ones. Why the difference? I suppose I could see an Ultimate_Non_Interface_Ancestor function and an Ultimate_Concrete_Ancestor function (well, really, Ultimate_Non_Abstract_Ancestor), but I wonder about the point. Besides, you don't always know if something is an interface, so inside of a generic body you'd stop on the formal (not an interface), but in the instance, you'd stop *before* the actual (if an interface). Yuck. [FR recommendation:] In this case, return the type itself. This would give a simple semantic to the query: it returns the ultimate non-interface ancestor. The only case where an interface would be returned is when S is an interface, and S itself would always be returned in that case. [ARG ASIS Subcommittee (Nov 6 2009):] Ultimate_Ancestor should return the entire set of ultimate ancestors (both interfaces and non-interfaces). Add Root_Noninterface_Ancestor, which returns the ancestor that has no non-interface ancestors. It must raise exception Asis_Inappropriate_View if there isn't any (can only happen is Is_Interface is True). See below for the change. ---- [Jean-Pierre:] In the NOTE: "If the ultimate full view is needed, call Full_View on the result of Ultimate_Ancestor". Unfortunately, this does not work, since the full view of a private type can be a derived type. You need to loop calling Full_View and Ultimate_Ancestor and until you reach a non partial view - i.e. the user has to write a thicker function for that case. In one of my own similar queries, I have a "Follow_Private" boolean parameter to tell the function if it should see through partial views or not. Both behaviours are useful... [Greg:] Well this is also a forward reference to Full_View. Perhaps section 23.4.4 and 23.4.5 should be reversed. I don't see why this won't work, only that it is inconvenient. What are you suggesting be changed? [Randy:] He's saying the note is wrong and needs to be rewritten or something. We were convinced that we didn't need a Ignore_Privacy flag for the reasons stated in the note, but since that is not true, the note should be deleted and the function changed to have such a parameter. Alternatively, we could just junk Ultimate_Ancestor, 'cause it don't work and no one can agree on what it should do (see above). [FR recommendation:] Add a "Follow_Private" boolean parameter to the Full_View query to tell the function if it should see through partial views or not. Both behaviours are useful. [ARG ASIS Subcommittee (Nov 6 2009):] The note is wrong. Add "Full_View_Root_Noninterface_Ancestor" to get this value. Suggest to replace Ultimate_Ancestor by: function Ultimate_Ancestors (S : Subtype_View) return Subtype_Vector is abstract; S specifies the view of a subtype to query. Function Ultimate_Ancestors returns all of the ancestors of the subtype S that are not themselves a descendant of any other type; the list will just be the type itself if Is_Derived (S) returns False and Progenitors (S) (see 23.8.3) returns an empty vector. function Root_Noninterface_Ancestor (S : Subtype_View) return Subtype_View'Class is abstract; S specifies the view of a subtype to query. Function Root_Noninterface_Ancestor raises Asis_Inappropriate_View if S is composite and Is_Interface (S) (see 23.8.3) is True. Otherwise, it returns the noninterface ancestor of the subtype S that is not itself a descendant of any other type; it will be the type itself if Is_Derived (S) returns False returns False. function Full_View_Root_Noninterface_Ancestor (S : Subtype_View) return Subtype_View'Class is abstract; S specifies the view of a subtype to query. Function Full_View_Root_Noninterface_Ancestor raises Asis_Inappropriate_View if S is composite and Is_Interface (S) (see 23.8.3) is True. Otherwise, it returns the full view of the noninterface ancestor of the subtype S that is not itself a descendant of any other type. [Is this wording right? Does it properly cover the case where the full view of a private type is derived from another type?? - RLB] NOTE Function Root_Noninterface_Ancestor may stop on an incomplete or partial view. If the ultimate full view is needed, call Full_View_Noninterface_Ancestor instead. AASIS Note: The Full_View of Root_Noninterface_Ancestor may be a derived type; Full_View_Root_Noninterface_Ancestor keeps going until the full view of an ancestor has no non-interface ancestor. Wording [6]. 23.5.1 [Jean-Pierre:] Last para: "Function Nominal_Subtype returns {a view of the definition of} the nominal subtype of the view" (This is a guess of the intent, but since subtypes may be anonymous, I don't see what else it could be). [Greg:] Your suggestion seems correct. [Randy:] Humm, do we want to require the view is of the definition? That may be far away from the object. I was expecting that this would return a view of the nominal subtype from the declaration of the object (if that makes sense): A : Integer; would return a view of *this* usage name Integer, not necessarily the one in Standard. You can find out the definition if you really need it, but for most purposes any view is good enough. Of course, if this is anonymous, it has to be given right with the object. Doesn't the nominal subtype always have to be available in some form in the object declaration?? The fact that the name doesn't include "definition" seems important to me. Of course, the difference is subtle, and would only matter if you wanted to go back to the syntactic subsystem and then do enclosing element sorts of things. Without examples, I'm not sure which is best. [Jean-Pierre:] In your example, I was thinking of returning a view "Integer" as a definition, like you would do for: A : Integer range 1..10; It would be surprising to get something totally different for those two cases. And you have to get something that can tell you the constraints! [Randy:] You can ask for the constraints of any subtype view (23.4.2), so I don't think that is relevant. Indeed, this semantic subsystem pretty much ignores definitions -- you can get the same information from any subtype_view whether it is of a usage or of a definition. The only time it matters is when you need to do something with elements, which hopefully will be rare. In any case, this cuts both ways. If you always get the definition, you could getting views that come from all over the program. It would be weird if Enclosing_Element (Nominal_Subtype(S)) sometimes was the place of the object declaration, sometimes of Standard, sometimes of System, etc. I wonder if we need a function here to get the definition for a view (or can that be easily accomplished in the syntactic interface)? I really have no idea what is best (or what view Tucker intended here, for that matter). We have to discuss it. [FR recommendation:] Correct the wording and specify which view is intended. [ARG ASIS Subcommittee (Nov 6 2009):] The view is of a subtype_indication, probably the one from the object declaration. Make Nominal_Subtype a separate paragraph, and add "The view is of a subtype_indication, usually all or part of the subtype_indication of the object_declaration." to the paragraph. Wording [3]. [ARG (Meeting #40):] Tucker notes that this wording isn't quite right, as an Object_View can be something other than an object declared by an object declaration. [Tucker Taft (Mar 9, 2010) Wording [3]. 23.5.2 [Jean-Pierre:] {CD comment} Second paragraph says: "Function Is_Component returns True if and only if the view O is of a component of an enclosing composite object." Consider: type Rec is record X : Integer; end record; R : Rec; Comp : Integer renames R.X; R1 : Rec renames R; What is the value of Is_Component for Comp? It is certainly "a view of a component of an enclosing composite object", so it should return True. But what is returned by Enclosing_Object? Is it a view of R from R.X in the rename? What is returned by Enclosing_Object for R1.X? Is it a view of R or a view or R1? [Randy:] I would have said that Comp is not a component, but the wording would need to clearly state that. In the second case, it should be a view of R1. I think the overriding principle here (for the whole subsystem) is that you stay as close as possible to the queried view while still correctly answering the question. But that meta-rule might be my imagination! And wording this is hard. [Randy (later):] I note this is a case of "is of", not "denotes", so the first answer is trivial (Comp is not a component). The second case is not so obvious, however. And this wording surely is subtle, I wonder if it would be valuable to make that clearer somehow. [ARG (Meeting 39):] Tucker explains that his model is that the semantic interface always looks through renames. The difference between "is of" and "denotes" was not intentional. [Probably we need to scrub the wording to remove as many "is of"s as possible.] It is pointed out, however, that that is not always appropriate to look through renaming (default parameters can differ on renamed routines). And in Jean-Pierre's example above, it is weird for Is_Component to be true, as no enclosing object is visible (there is no selected notation in Comp). The problem with Is_Component is really with the name; Denotes_Component or Has_Enclosing_Object would be better. Anyway, we need wording that by default, these operations ignore renames. But we better make it crystal clear when that is not true (Tucker says it follows from the Ada Standard, but we can't expect ASIS implementers and users to figure out whether that is the case.) [Editor's note: I have no idea what Tucker means by it "follows from the Ada standard". Surely the Is_Component case is not clear, the renamed object is not itself a component (it might denote a component).] [Tucker Taft (Feb 24 2010):] Modify 23.5.2 only to mention that these are properties of the renamed object, not the original object. Wording [8]. [Editor's note:*** Tucker informs me that my understanding of what he did is wrong; thus everything written here except the exact wording is wrong. I think what I wrote is the only meaningful interpretation for this functions, and object as strenuously as possible that Tucker's wording is misleading. I am begining to think that these routines are very dangerous, as they mix syntax and semantics; they need to be totally redesigned or junked. To be discussed ***] [ARG (Meeting #40):] Tucker is sure that these are the only set of properties which depend in part on the syntax form of the view. He thinks all other properties are of purely semantic and would be the same for both a renamed and original object. Randy is assigned an action item to check this. [Randy:] In 23.5.3, Is_Dereference, Is_Explicit_Dereference, and Is_Implicit_Dereference need this same wording. *** Add to wording [13]. Similarly, in 23.9.6, Is_Designated_Subprogram, Is_Explicit_Dereference, and Is_Implicit_Dereference need this same wording. *** Add to wording [14]. Finally, we need a general rule for other cases (At least for nominal_subtype and classification for object views; profile and result subtype operations for callable views) that the meaning of the original entity is used (not those of the renaming). *** Add wording [Tucker:] Pretty much disagree with everything Randy writes above. Suggests following the RM model exactly. Add notes to that effect. ---- [Jean-Pierre:] Note that "Obj" in "Pack.Obj" is a selected component (an expanded name), but Position, First_Bit and Last_Bit are clearly not applicable. [Randy:] We need another predicate to use for Position, etc. I named it Is_Component_Selected_Component for the lack of a better name, but that is a charter member of the department of redundancy department. Hopefully someone has a suggestion. [ARG (Meeting 39):] Rename this function to "Has_Storage_Place_Attributes". Wording [8]. 23.5.3 [Randy:] {CD Comment} We're unwilling to put any sort of static accessibility level stuff into the Ada language, because there are a number of cases where accessibility is incomparable. So why are we willing to put it into ASIS? Shouldn't we mirror the likely Amendment solution Ada language and replace this with an accessibility comparison of some sort?? [ARG ASIS Subcommittee (Nov 6 2009):] The comment is correct. We should have Is_Library_Level, and Has_Static_Accessibility_Level. No explicit levels. Is_Statically_Deeper_Than raising Asis_Inappropriate_View if either view does not have Has_Static_Accessibility_Level = True. Rewording assigned to Tucker Taft. [Tucker Taft (Feb 24 2010):] Wording [13]. [ARG (Meeting 40):] Accept above wording. Add an Is_Explicit_Dereference function. [Randy:] We need to add an Is_Explicit_Dereference function to callable views as well (to be consist). Wording [14]. 23.8.1 [Jean-Pierre:] For function Contains_Task, do we really mean part rather than subcomponent? [Randy:] I think the intent was that it includes a subtype that *is* a task, so I think "part" is correct. But the name does seem to imply that it only looks at components, so perhaps a better name is needed. (Not that I have one.) [Jean-Pierre:] Does the function Contains_Task return True if there is /visibly/ a task subcomponent, (consistent with the notion of view), or /really/ a task subcomponent? The same question applies to Needs_Finalization and Has_Preelaborable_Initialization. [Randy:] For the latter two functions, these are just implementing a language-defined predicate. So you just need to look in the RM to see what the definition of "needs finalization" and "preelaborable initialization" are. I'm sure there is no interest in inventing new semantics for these. OTOH, Contains_Task does not correspond to any language-defined concept, so the answer isn't clear, and the wording doesn't help determine that answer. I'd guess that visibility is involved, but surely that needs to be decided and clarified. [ARG ASIS Subcommittee (Nov 6 2009):] Contains_Task is "part", not "subcomponent". It does look through privacy. We need wording to explain that. Assigned to Tucker Taft. [Tucker Taft (Feb 24 2010):] Proposed wording update. Wording [9]. [ARG (Meeting #40):] What does this function do for a classwide limited type? It probably ought to return the answer that is appropriate for the associated specific type (otherwise it would always have to return True, because there *might* be an extension that contains a task). [Tucker Taft (Mar 9, 2010):] Add "If subtype C is a class-wide subtype S'Class, then returns Has_Task_Part(S)." to wording. Wording [9]. --- [Jean-Pierre:] {CD comment} Unless I forgot something, it seems that the only composite types for which Has_Nondiscriminant_Region_Parts returns false are array types. In this case, I'd rather call the query Is_Array_Type. [Randy:] This appears to be the predicate controlling the following routine. It would seem to be weird to be able to call Nondiscriminant_Region_Parts only for things that Is_Array_Type is False. (Besides, there already is an Is_Array predicate in 23.4.1, so we surely don't need another one.) I'll leave this as an open issue (as to whether to delete the predicate and just use "not Is_Array"). [ARG ASIS Subcommittee (Nov 6 2009):] We don't need this predicate at all; Nondiscriminant_Region_Parts can return an empty list is there is no parts. So delete the predicate and reword the last sentence to "The returned list is empty if subtype C is not a descendant of a record type, a record extension, a task type, or a protected type.". Wording [9]. --- [Jean-Pierre:] {CD comment} Also for Nondiscriminant_Region_Parts: "... from a single list of components or items of subtype C." I didn't understand what this means. [Randy:] I think he was referring to something like a single declaration list. Except that "declaration list" is only defined for packages and declarative parts. He's saying mainly that each separate extension's list of components consistutes a separate region part. The wording gets a bit awkward because task and protected types only have one list, but that list can contain more than components. I don't see a correct improvement right now (partly because of the lack of technical terms to use), but one seems warranted. [ARG ASIS Subcommittee (Nov 6 2009):] This sentence needs to be reworded. [Gary Barnes (Feb 2010):] "Function Nondiscriminant_Region_Parts returns a list of Region_Parts, one for each separate visible region part, each comprising components, entries, and protected subprograms from a single list of components or items of subtype C." That final part: "from a single list of components or items of subtype C." I have no idea whatsoever what that means. Until that part of the sentence thought I knew what it wanted. What single list? [Randy:] Already covered by a previous comment (see above). [ARG (Meeting #40):] Should Nondiscriminant_Region_Parts return a list of parts or one giant part? It's easier to ignore information than to add more information, so it should return a list of parts. Empty (extension) parts should be including - this will keep the number of returned items the same as the number of extensions. Private components also should be included. [Tucker Taft (Mar 9, 2010)]: Function Nondiscriminant_Region_Parts returns a list of Region_Parts, one for each separate visible region part, each comprising components, entries, and protected subprograms from a single list of components or items [of] {from the declaration of some ancestor of the type of} subtype C. Wording [9]. 23.12.4: [Jean-Pierre:] {CD comment} This function looks strange. It seems to imply that a view of G from within itself refers to the generic, and that this function gives the corresponding instance view. But what if the view of G given to the query is not from within itself? [Greg:] If you are outside the unit then is one of the cases where the exception is raised, correct? [Randy:] No, I think the idea is that you can retrieve a view of "the current instance" of a generic, from any view of the generic (with no more complications needed). This would not be the view of any particular instance, just "the current instance". I think the reason that this is a separate function is so that you don't have to find a usage name of the generic that is within the generic in order to retrieve this view. (And of course instance views are very different than generic views.) That said, it *is* a bit strange, but I think you could argue that the entire idea of the "current instance" is strange, so any representation of it necessarily will be too. I'm more interested as to why there aren't similar functions for the other places that "current instance" pops up in the language: inside tasks, protected objects, and type declarations. It would seem to make sense in all of those cases, too, if this is valuable. [ARG ASIS Subcommittee (Nov 6 2009):] Jean-Pierre says he now understands the intent. The associated element would probably be nil (that is, there aren't any explicitly in the source). The wording is still confusing. ** Tucker Taft will try to improve/clarify (but that might be impossible). Maybe an AASIS note/example?? ** [ARG (Meeting #40):] Tucker says that this allows you to use the queries for subprograms and packages on the generic unit. It allows us to not duplicate all of the functionality of subprograms and packages for generics. We don't have a similar need for task bodies or record declarations, thus we don't need equivalents there (this answers Randy's question of why we don't have them). Tucker will draft a user note to explain this. [Randy:] Musings: Aren't we being too pedantic if we won't consider a generic subprogram a subprogram, and a generic package a package? Just because the language standard insists on that rather un-intuitive definition doesn't mean that we have to copy it here.) Not sure if there would be any bad consequences, though. [Tucker Taft (Mar 9, 2010):] Added additional text to 23.12.4 and 23.12.6. Wording [15]. 23.14.2 [Jean-Pierre:] {CD comment} How is Corresponding_Statement different from Element_Denoting_View ? [Randy:] Anybody know? I don't see any difference right now. [ARG ASIS Subcommittee (Nov 6 2009):] This was covered under Section 23 global, above. 23.xx: [Jean-Pierre:] {CD comment} There isn't a package Asis.Statements.Views (how do you go from a statement to a statement view?) [Randy:] I don't know if there is much point. The only useful thing to do with a statement view would be to get the View_Declaration of a block or loop. There is nothing else that can be done with a statement view. (Of course, maybe there should be, see my rant elsewhere.) [ARG ASIS Subcommittee (Nov 6 2009):] This was covered under Section 23 global, above. --- [Jean-Pierre:] {CD comment} It would be nice to have a query that returns the expected type of an expression (especially for universal expressions). [Randy:] I presume that you are suggesting: function Expected_Type (Expr : in Expression_View) return Subtype_View'Class; But I'm dubious about the implementability of such a function. The expected type comes from the context, so the implementation cannot synthesize it (it has to know the context in detail in order to be able to do that). The net effect would be that the expected type would have to be stored in every expression tree node just in case someone wanted to query it with ASIS. And even that wouldn't work for subtrees, because there is a forest of expected types during resolution, so it couldn't be stored until after resolution (at which point Janus/Ada at least no longer has the information). Anyway, open issue. [ARG ASIS Subcommittee (Nov 6 2009):] This doesn't seem necessary, at least so long as literals and the like have the resolved type (not a universal type). There needs to be some wording or notes to explain what the intended subtype of views of parts of expressions is (especially for literals). [Tucker Taft (March 2010):] Modify the description of Nominal_Subtype as follows: (Wording [3]) Function Nominal_Subtype returns the nominal subtype of the view. [Function] The returned Subtype_View corresponds to the subtype_indication{, discrete_range, or type_definition that defined the nominal subtype of the object or value. The nominal subtype of a numeric literal or named number is a view of the corresponding universal base subtype. The nominal subtype of a use of an operator is that of the equivalent function call, namely the result subtype of the corresponding function.} [usually all or part of the subtype_indication of the object_declaration.] !appendix From: Randy Brukardt Sent: Monday, March 8, 2010 9:02 PM I had an action item to review the semantic subsystem to see if there are other functions other than the ones in 23.5.2 that would be affected by renaming. It seems to me that anything that depends on the subtypes given for an entity could be affected. In particular, if we have: Obj : Positive := 1; Ren : Natural renames Obj; and we query Nominal_Subtype (23.5.1) on a view of Ren, do we get a view of Natural or of Positive? I suspect that we would prefer to see Positive, but since there are two different answers possible here, we need to say something. Similarly, Is_Formal_Object returns True iff a view is a generic formal object. Is a renaming still such an object? Ren2 : Natural renames Formal; Again, I would think so, but we need to say that somewhere. This sort of thing can come up for many of the categorization functions, especially those that don't have a language definition. We have a similar issue with profiles of callable entities: subtype Upper_Case_Character range 'A' .. 'Z'; function Fooey (C : Upper_Case_Character) return Natural; function Ugh (C : Character) return Positive renames Fooey; The subtypes of the profiles of Ugh and Fooey differ, although we will always use that of Fooey for a call. We need to define which is returned. We can also get a similar problem to the second one above for Is_Entry and Is_Procedure: procedure Ren_Ent renames Some_Entry; Does Is_Entry return True or False for Ren_Ent? Does Is_Procedure return True or False for Ren_Ent?? In general, I see the default as *ignoring* renaming; the only time that we would want to not ignore it is in the functions of 23.5.2. So I think we might want a sentence to establish that principle up front: Unless otherwise specified, if a view V is of a renames of an entity, the result of a query on that view is that of the original renamed entity. I'm not sure if "up-front" should be just for Object_Views and Callable_Views, or way at the front. There is no renaming for (sub)types, so we don't need to consider them. For packages and exceptions, the properties don't change, so we don't need to worry about them, either. So its not clear whether we just need a rule for all Object_Views and Callable_Views; that might be the safest thing. --- However, it seems to me that we need a different rule for Is_Dereference and especially the new Is_Explicit_Dereference. Consider: Ren3 : Natural renames Ptr.all; If Is_Explicit_Dereference returned True for Ren3, that would be very strange -- this seems equivalent to the Is_Component case where we agree that the answer is False. So I think Is_Dereference, et. al. need the wording used for 23.5.2. I didn't find anything else like this. --- So we need a general rule and another exception for Is_Dereference, etc. Randy. P.S. Unrelated point. We added Is_Explicit_Dereference for object views. We probably need a matching routine in 23.9.6 for callable views (there also is an Is_Implicit_Dereference there). **************************************************************** From: Tucker Taft Sent: Monday, March 8, 2010 9:36 PM > I had an action item to review the semantic subsystem to see if there > are other functions other than the ones in 23.5.2 that would be > affected by renaming. > > It seems to me that anything that depends on the subtypes given for an > entity could be affected. In particular, if we have: > > Obj : Positive := 1; > Ren : Natural renames Obj; > > and we query Nominal_Subtype (23.5.1) on a view of Ren, do we get a > view of Natural or of Positive? I suspect that we would prefer to see > Positive, but since there are two different answers possible here, we > need to say something. The nominal subtype of an object defined by a renaming is that of the renamed object, so we don't *have* to say anything, but it might be friendly to do so. > Similarly, Is_Formal_Object returns True iff a view is a generic > formal object. Is a renaming still such an object? > > Ren2 : Natural renames Formal; > > Again, I would think so, but we need to say that somewhere. This sort > of thing can come up for many of the categorization functions, > especially those that don't have a language definition. In the RM it says: An object_renaming_declaration declares a new view [of the renamed object] whose properties are identical to those of the renamed view. I think we should obey that for all of the ASIS interfaces defined on Object_View the query the properties. > We have a similar issue with profiles of callable entities: > > subtype Upper_Case_Character range 'A' .. 'Z'; > function Fooey (C : Upper_Case_Character) return Natural; > > function Ugh (C : Character) return Positive renames Fooey; > > The subtypes of the profiles of Ugh and Fooey differ, although we will > always use that of Fooey for a call. We need to define which is returned. For a subprogram renaming, the RM says: A renaming-as-declaration declares a new view of the renamed entity. The profile of this new view takes its subtypes, parameter modes, and calling convention from the original profile of the callable entity, while taking the formal parameter names and default_expressions from the profile given in the subprogram_renaming_declaration. The new view is a function or procedure, never an entry. In so far as possible, the ASIS semantic interfaces should try to match that. I'm not convinced we should repeat all of this in ASIS, though perhaps we could include some of it in a NOTE? > > We can also get a similar problem to the second one above for Is_Entry > and > Is_Procedure: > > procedure Ren_Ent renames Some_Entry; > > Does Is_Entry return True or False for Ren_Ent? Does Is_Procedure > return True or False for Ren_Ent?? This example is not normally legal. You need to identify the task or protected object whose entry you are renaming. Hence "procedure Ren_Ent renames Tsk.Some_Entry" We also have prefixed views. The RM says that a renaming of an entry is a procedure, not an entry. We should follow that too, I would think. > In general, I see the default as *ignoring* renaming; the only time > that we would want to not ignore it is in the functions of 23.5.2. So > I think we might want a sentence to establish that principle up front: I would rather make the default as following the RM rules on renaming about the view defined by the renaming. The AARM has a note saying that if some property is not mentioned, then it remains the same in a renaming. We could have something to that effect, but if we make a general statement, it ought to be to point to the RM rules, in my view ("view", get it?). > Unless otherwise specified, if a view V is of a renames of an entity, > the result of a query on that view is that of the original renamed entity. > > I'm not sure if "up-front" should be just for Object_Views and > Callable_Views, or way at the front. > There is no renaming for (sub)types, so we don't need to consider > them. For packages and exceptions, the properties don't change, so we > don't need to worry about them, either. So its not clear whether we > just need a rule for all Object_Views and Callable_Views; that might be the safest thing. > > --- > > However, it seems to me that we need a different rule for > Is_Dereference and especially the new Is_Explicit_Dereference. Consider: > > Ren3 : Natural renames Ptr.all; > > If Is_Explicit_Dereference returned True for Ren3, that would be very > strange -- this seems equivalent to the Is_Component case where we > agree that the answer is False. So I think Is_Dereference, et. al. > need the wording used for 23.5.2. Hmmm... I believe I wrote the AI to say that Is_Component "sees through" renaming, and I would suggest that Is_Explicit_Dereference does so as well. > I didn't find anything else like this. > > --- > > So we need a general rule and another exception for Is_Dereference, etc. > > Randy. > > P.S. Unrelated point. We added Is_Explicit_Dereference for object > views. We probably need a matching routine in 23.9.6 for callable > views (there also is an Is_Implicit_Dereference there). Good point. **************************************************************** From: Randy Brukardt Sent: Monday, March 8, 2010 10:09 PM ... > > Similarly, Is_Formal_Object returns True iff a view is a generic > > formal object. Is a renaming still such an object? > > > > Ren2 : Natural renames Formal; > > > > Again, I would think so, but we need to say that somewhere. This > > sort of thing can come up for many of the categorization functions, > > especially those that don't have a language definition. > > In the RM it says: > > An object_renaming_declaration declares a new view > [of the renamed object] whose properties are > identical to those of the renamed view. > > I think we should obey that for all of the ASIS interfaces defined on > Object_View the query the properties. I guess I would be surprised that whether something is declared in a particular way is a "property", but I guess we can use this as the principle. We need *at least* an AASIS note to make that clear, it surely isn't clear to me and I doubt that many ASIS users would find it clear, either. ... > > We have a similar issue with profiles of callable entities: > > > > subtype Upper_Case_Character range 'A' .. 'Z'; > > function Fooey (C : Upper_Case_Character) return Natural; > > > > function Ugh (C : Character) return Positive renames Fooey; > > > > The subtypes of the profiles of Ugh and Fooey differ, although we > > will always use that of Fooey for a call. We need to define which is > > returned. > > For a subprogram renaming, the RM says: > > A renaming-as-declaration declares a new view of > the renamed entity. The profile of this new view > takes its subtypes, parameter modes, and calling > convention from the original profile of the callable > entity, while taking the formal parameter names > and default_expressions from the profile given > in the subprogram_renaming_declaration. The new > view is a function or procedure, never an entry. > > In so far as possible, the ASIS semantic interfaces should try to > match that. > > I'm not convinced we should repeat all of this in ASIS, though perhaps > we could include some of it in a NOTE? At least an AASIS note. And perhaps a user note as well. (The entire semantic subsystem suffers from this; it assumes knowledge of obscure corners of the Ada Standard that an ordinary user probably wouldn't have, and even implementers might not have. It's not always obvious that terms like "part" and "needs finalization" and "nominal subtype" are used with the formal meaning given in the Ada standard.) > > We can also get a similar problem to the second one above for > > Is_Entry and Is_Procedure: > > > > procedure Ren_Ent renames Some_Entry; > > > > Does Is_Entry return True or False for Ren_Ent? Does Is_Procedure > > return True or False for Ren_Ent?? > > This example is not normally legal. You need to identify the task or > protected object whose entry you are renaming. Hence "procedure > Ren_Ent renames Tsk.Some_Entry" > We also have prefixed views. > > The RM says that a renaming of an entry is a procedure, not an entry. > We should follow that too, I would think. So this is a case where the original entity is *not* used. I doubt that many (other than you) could divine that intention! > > In general, I see the default as *ignoring* renaming; the only time > > that we would want to not ignore it is in the functions of 23.5.2. > > So I think we might want a sentence to establish that principle up front: > > I would rather make the default as following the RM rules on renaming > about the view defined by the renaming. The AARM has a note saying > that if some property is not mentioned, then it remains the same in a > renaming. We could have something to that effect, but if we make a > general statement, it ought to be to point to the RM rules, in my view > ("view", get it?). He-he. Could you suggest some wording to that effect? ... > > However, it seems to me that we need a different rule for > > Is_Dereference and especially the new Is_Explicit_Dereference. Consider: > > > > Ren3 : Natural renames Ptr.all; > > > > If Is_Explicit_Dereference returned True for Ren3, that would be > > very strange -- this seems equivalent to the Is_Component case where > > we agree that the answer is False. So I think Is_Dereference, et. al. > > need the wording used for 23.5.2. > > Hmmm... I believe I wrote the AI to say that Is_Component "sees > through" renaming, and I would suggest that Is_Explicit_Dereference > does so as well. Ugh. So you did, but I didn't notice that until right now. I'm forever confused about "renamed entity" vs "entity from renaming" - that's why I used "original entity" in this write-up. Had I realized it earlier (like at the meeting or when you submitted it for that matter) I would have objected strenuously. There is no component in "Ren"! (And I would have written a different entry in the SI and a different AASIS note that actually reflected what you did...) I would *especially* object to Ren3 above being called an *explicit* dereference. There is no ".all" in "Ren3", so what the heck is explicit about it?? The notes from St. Petersburg reflect that: Is_Component (Ren) should be False, because this is no sign of a component name or enclosing object for "Ren" - it *surely* is not a selected component, yet you would have Is_Selected_Component (Ren) return True. If the routines were "Denotes_Component" and "Denotes_Selected_Component" instead, then one could claim that the result is True (because "denotes" looks through renames"). Obviously, we'll need to discuss this further. **************************************************************** From: Tucker Taft Sent: Tuesday, March 9, 2010 10:56 PM Here is an update to SI99-0054 [this is version /07 - Ed], which is a grab bag of issues identified during the ASIS review. I added a pair of new interfaces: Is_Defined_In_Declaration and Declaration_Containing_Definition to augment the existing interfaces Has_Declaration and Declaration. Has_Declaration and Declaration can now be limited to views of entities that were declared (explicitly or implicitly) with some sort of name. Is_Defined_In_Declaration and Declaration_Containing_Definition are for other kinds of anonymous types or subtypes that are defined as part of a declaration for something else, such as an object or a subprogram. Hopefully this will satisfy the need to find where something is defined, without having to say it has a "declaration" in the Ada sense. **************************************************************** From: Randy Brukardt Sent: Thursday, March 11, 2010 2:14 AM I've looked at Tucker's attempt to straighten this area out, and I guess it works. But it has a number of flaws in my view: (1) The definition of View_Declaration is way too pedantic for my taste. It is almost never relevant that an entity has a name when doing semantic queries. It is more important to know where an entity is created (by a declaration for something, but not necessarily this particular something). For ease-of-use purposes, more expansive definitions seem to be preferred. (2) I'd like to get more of the description of the model up front (with the types) rather than spreading it to various operations. (3) We need to explain how equality works on View_Declarations (they're not Views, remember). I had created a proposal for this area yesterday, not realizing that Tucker actually was going to do his homework immediately. I compounded the bug by managing to send my proposal only to myself! So I'm sending it to everyone to provide a contrasting proposal. Probably some merging of the two sets of wording would be preferred. Randy. P.S. View_Declaration is one area where I have to wonder if Gary isn't right, in that I don't see what can be done with it that can't reasonably be done with the syntactic interface. That's especially true if there are no anonymous View_Declarations, because then there is a one-to-one correspondence to elements. ---- OK, based on our discussions, here is some suggested wording for these clauses. I didn't mark the changes, that makes it too hard to follow. Feel free to suggest changes. 23.2.5 type View_Declaration and type Declarative_Region [Notes: I swapped the types so the text comes in the same order. Same for the header. For some reason the types were in reverse order of the text. I'd still consider changing the type name to Declaration_of_View (which still feels a bit less confusing to me - these have little to do with views), but it isn't a big deal.] type View_Declaration is interface; A View_Declaration specifies the declaration, if any, that defines a given view of an entity. For a declaration that declares multiple entities, each entity has a separate View_Declaration. The View_Declaration of an entity may have a name or may be anonymous. In particular, if a declaration defines multiple entities because the list of Identifiers has more than one element, then a separate View_Declaration is associated with each entity in the order of the list of identifiers. An access_definition (an anonymous access type) or subtype_indication included as part of a larger declaration are considered separate, anonymous View_Declarations declared immediately following the larger declaration. A class-wide type is considered declared immediately following the associated specific type. [Notes: I think this model ought to be up front, not scattered about other routines wording. I've left "subtype_indication" for now. To leave it out, we would have to say something explicitly about subtype_indications not being considered entities except for in subtype_declarations. Neither is very pretty. Should the anonymous declarations precede or follow the containing declaration? (It matters for the comparison operations defined later, but not for any "real" reason.)] The predefined "=" operator for View_Declarations returns True if the two View_Declarations represent the declaration of the same entity, including the same defining name (if any) and the same Asis.Declaration element (if any). [Notes: We need to say something about the meaning of "=" on View_Declarations. This wording probably needs to be adjusted to be similar to that for Views, which is one of your action items.] type Declarative_Region is private; A Declarative_Region represents a declarative region in which declarations may occur. function Defined_View (D : View_Declaration) return View'Class is abstract; function Element_for_View_Declaration (D : View_Declaration) return Asis.Declaration is abstract; function Declaration_Defining_Name (D : View_Declaration) return Asis.Defining_Name is abstract; function Is_Imported (D : View_Declaration) return Boolean is abstract; function Enclosing_Region (D : View_Declaration) return Declarative_Region is abstract; [Notes: We changed the name of "Declaration" to "Element_for_View_Declaration" at the St. Petersburg meeting, to be consistent with other routines returning elements and to avoid confusion with "Declaration" that operates on Views. I also changed "View_Defining_Name" to be "Declaration_Defining_Name", as these have little to do with views and everything to do with declarations. This really ought to start with "Element", as a Defining_Name is a kind of element, but that seems awfully wordy: "Element_for_Declaration_Defining_Name".] D specifies the view declaration to query for each of these functions. Function Defined_View returns the View defined by declaration D. This is a view of the declaration itself, not of any usage. Function Element_for_View_Declaration returns the Asis.Declaration corresponding to the declaration D. Nil_Element is returned if the View_Declaration does not correspond to an Asis.Declaration element (for instance, if View_Declaration represents a class-wide type). Function Declaration_Defining_Name returns the Asis.Defining_Name introduced by the declaration D. Nil_Element is returned if D is anonymous (does not introduce a name). For most declarations, Declaration_Defining_Name returns an identifier, but it can also return an operator symbol, a character literal (for an enumeration value), or an expanded name (for a child unit). [And the rest remains the same, I think.] 23.2.11 Views and Declarations function Has_Declaration (V : View) return Boolean is abstract; function Declaration (V : View) return View_Declaration'Class is abstract; ... Function Has_Declaration returns True if and only if view V has an associated View_Declaration, meaning that it has a logically separate declaration. Has_Declaration always returns True given a view of a first subtype, even if the type is anonymous. Has_Declaration returns True for explicitly and implicitly declared subprograms. Not all views have declarations, however. For example, views representing literals, dereferences, and the result of a function call don't have declarations. AASIS Note: Most entities have declarations. However, many Object_Views don't have declarations, as they represent objects or values that exist only during the evaluation of the appropriate expression. The following Object_Views don't have declarations: * literals (numeric, string) * dereferences * indexed components * slices * aggregates * short circuit operations * memberships * type conversions * qualified expressions * the result object of a function call Note that the result object of a function call is not declared at the call site, although it might be declared inside of the function (in an extended return statement). The callable view associated with a function call does of course have a declaration. [Anything missing here?? I think it is important to spell out the model in the AASIS, I always have to reimagine it. If we leave out subtype_indications, we would have to add them to a separate list here - RLB] End AASIS Note. Function Declaration returns the declaration that defines view V, or raises ASIS_Inappropriate_View if Has_Declaration (V) returns False. [I don't think we need anything else here. The definition of Has_Declaration and View_Declaration covers everything that we need to know.] ****************************************************************