!standard 23 10-01-11 SI99-0054-1/04 !standard 23.2.1 !standard 23.2.3 !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.9.3 !class Binding Interpretation 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 ** TBD ** !question ** TBD ** (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_View, 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. [Editor's note: This last paragraph is supposed to be rewritten.] [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 view is of a subtype_indication, usually all or part of the subtype_indication of the object_declaration. [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 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 Delete the function Has_Nondiscriminant_Region_Parts. 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 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]. !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 to rework the wording/model for Statement_Views ** [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). ** Tucker Taft will draft better wording for this **. For Corresponding_Statement, the name ought to start with the word "Element". One thought is "Element_for_Statement". ** Tucker Taft will do this as part of his previous homework item ** --- [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. ** Tucker Taft will make a pass through the packages and suggest needed changes to meet this ** 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.] [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. If might be easier to process a simple name if that is returned from Element_Denoting_View. ** Assigned to Tucker Taft to figure out necessary wording ** --- [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. ** Need wording to reflect 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" 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 to figure out necessary wording ** 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 ** --- [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. [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 ** 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]. 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).] ** Assigned to Tucker Taft ** ---- [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". Working [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 ** --- 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. ** Wording assigned to Tucker Taft ** --- [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. ** Wording assigned to Tucker Taft ** 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?? ** [We didn't cover my question of why there is not a corresponding function for type declarations, including task and protected objects. If this one is useful, the other would seem useful as well. If it isn't useful, an explanation of why would also be helpful. - Randy] 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). ** Assigned to Tucker Taft ** !appendix