!standard X.Y 06-11-12 SI99-0024-1/01 !class amendment 06-11-12 !status work item 06-11-12 !status received 06-11-12 !priority High !difficulty Hard !subject Provide a semantic model in addition to existing syntactic model !summary ASIS currently provides a model that is closely based on the syntax. This SI proposes to add a set of packages that provide a canonicalized semantic model, which captures more of the work already done by (the front end of) the compiler. !problem The current ASIS model is very tied to the syntactic structure of the program library. However, there are times when it is more efficient to use a more abstract, semantic model. This SI proposes such a model. In one sense, it may be thought of as defining a "symbol table" for the program library. !proposal SEMANTIC VS. STRUCTURAL MODEL This SI proposes that an additional set of packages be provided as part of ASIS that represent a semantic model of the program library. As currently defined, ASIS provides a structural model of the library, with a relatively limited set of semantic queries that allow references to be traversed to their definitions, and allow traversal between declarations and bodies, or partial and full declarations. The existing approach provides all the information inherent in the original source program, and as such, ensures that other tools can do all the same work that the compiler could do. However, the existing approach doesn't capture much of that work in a useful form, and instead essentially requires that it be performed by every tool. In this SI we propose to capture more of the work already performed by the compiler, and along the way attempt to canonicalize the information so that the many special cases inherent in the syntactic structure of the program library are reduced to a smaller number of semantic concepts that nevertheless still cover the entire realm of possibilities. One way to think about what we are doing is providing a "symbol table" for the program library. GUIDES TO CREATING SEMANTIC MODEL To guide our efforts, we need to decide on what level of information we want to capture. In particular, there is the information that is implementation independent, and simply captures the language-defined static semantic properties of the program. This we might call the "language-level" semantic information. At the next level down, there is information that reflects some of the decisions made by the implementation which might be useful to a tool, such as the layout of a record, or the linkname of a global object. This we might call the "representation-level" information. Finally, as we get to the "object-code level," there is the information about the range of code addresses associated with each line of source, and the layout of the stack frame for particular subprograms. For this initial effort, we propose to focus on the "language-level" implementation-independent semantic properties. We envisage that additional packages might be defined as some later point, or by particular ASIS implementations, that provide the lower level "representation" or "object-code" information. The second guide to our efforts is a list of the typical kinds of applications we imagine being built using this high-level semantic model. One kind of application would be an interpreter, both an interpreter of existing code, and an interpreter of simple expressions or statements typed into the program interactively after establishing a particular context. For example, one might invoke a tool that would essentially elaborate some part of the program library, and then allow the user to type in small test scripts in an Ada-like language which would be interpreted in the context of the given part of the library, as a kind of interactive unit testing capability. Another type of application would be one that attempted to determine the range of values that each variable within the program could have at run-time, based on an "abstract interpretation" or a data and control flow analysis of its logic. This is similar to an interpreter, except that it does not construct an entire run-time context, but rather an abstraction of it that allows run-time properties to be approximated, generally through an iterative algorithm that stabilizes on a fixed-point approximation. BASIC SEMANTIC MODEL The existing ASIS packages define "Elements" which correspond roughly to syntactic "constructs." We propose to define "entities" and "views" thereof that represent the semantic entities defined by the syntactic constructs. In some cases, there is almost a one-to-one correspondence between the entity and the construct, for example, with an exception. For others, such as a "typed view" there may be many different kinds of constructs that create typed views which nevertheless have relatively similar properties. Here are the kinds of entities and views we propose to include in our ASIS semantic model: - Program_Unit_View - Package_View - Subprogram_View - Task_Unit - Protected_Unit - Generic_View - Single_Entry - Entry_Family - Subtype_View - Typed_View - Callable_View - Exception In addition, we propose to define certain other abstractions that allow us to characterize or manipulate the above entities or views: - Direct_Visibility_View - Declarative_Region_View - Region_Part - Profile We use the term view only when there are multiple views possible for the same underlying entity. For a given subprogram, it is possible to have different formal parameter names and defaults, depending on the view. For a package, there is a limited view (associated with a "limited with"), a partial view (e.g. from the outside), a private view (e.g. from a child), and a full view (e.g. from inside the body). On the other hand, there is only one view of an exception. For a generic, the only thing that can vary by the view is the name of the generic, so it may not be worth considering these different views. Many entities and views of entities have declarative regions associated with them. We propose to represent a particular view of a declarative region as a set of "region parts," one for each distinct part of a declarative region. Here are the different kinds of region parts: - generic formal part - discriminant part - formal part - visible part - private part - public child part - private child part - body part In addition to being able to iterate through the declarations of a region part, we propose to support the lookup of an identifier within a region part, within a declarative region view, or within a direct visibility view. If the lookup is successful, the result would be a single non-overloadable declaration, or a list of overloadable declarations. A direct visibility view supports lookups in a particular context, looking into enclosing scopes and taking use visibility into account. Looking up in a region part or a declarative region view does not worry about enclosing scopes or use visibility, and corresponds more closely to what would be called "selective visibility." Because we are proposing a relatively large set of interfaces, we are not currently proposing wording, but rather are working to specify the queries to be provided using a more economical syntax than full Ada package specifications. Once we agree on the set of interfaces to be provided, we will then create actual Ada packages with corresponding detailed descriptions for each operation. DETAILED SEMANTIC MODEL In this section, we define the operations that can be performed on the various kinds of entities and views. The operations available are listed underneath each kind of entity/view. The operations are defined in a notation such as: Subtype_View: ... Is_Derived -> Boolean Parent_Subtype -> Subtype_View Is_Descendant(Subtype_View) -> Boolean The above means that the operation Is_Derived is defined on Subtype_Views and (implicitly) takes one parameter being a Subtype_View, and returns a Boolean result. The indented Parent_Subtype operation is defined only if the Is_Derived operations returns True, and it returns a Subtype_View as a result. Finally, the "Is_Descendant" operation is defined on Subtype_Views, and in addition to the (implicit) first parameter being Subtype_View, this takes an additional parameter (also a Subtype_View in this case), and returns a Boolean result. Hopefully this notation will be sufficiently clear to allow the set of operations to be understood and relatively easily updated, without worrying about continually revising a lot of Ada subprogram specifications. As indicated above, once we settle on the desired interfaces, we can write out the package specifications in full detail. Semantic Attributes: Entity_Or_View Kind_Of_Entity -> enum Expr_Denoting_Entity -> ASIS.Expression Has_Declaration -> Boolean Entity_Declaration -> ASIS.Declaration Entity_Identifier -> ASIS.Identifier Is_Overloadable -> Boolean Enclosing_Scope -> Declarative_Region Logical_Position_In_Region -> Natural Enclosing_Compilation_Unit -> ASIS.Compilation_Unit Is_Renaming -> Boolean Renamed_Entity -> Entity Is_Program_Unit -> Boolean Has_Body -> Boolean Entity_Body -> ASIS.Declaration Has_Stub -> Boolean Entity_Stub -> ASIS.Declaration Is_Compilation_Unit -> Boolean Is_Library_Unit -> Boolean Parent_Library_Unit -> Entity Representation_Items -> List of Representation_Items Contains_Declarative_Region -> Boolean Contained_Region -> Declarative_Region Region_Part Kind_Of_Region_Part -> enum (Generic_Formal_Part, 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, Child_Part) Enclosing_Region -> Declarative_Region Declarations -> List of Entitities Lookup(Identifier) -> Entity_Or_View Declarative_Region -> Enclosing_Entity -> Entity Has_Generic_Formal_Part -> Boolean Generic_Formal_Part -> Region_Part Visible_Parts -> List of Region_Parts Private_Part -> Region_Part (may be empty) Body_Part -> Region_Part (may be empty) Declarative_Region_View -> Region -> Declarative_Region Visible_Position_In_Region -> Natural Introduced_Position_In_Region -> Natural Visible_Children -> Set of Declarative_Region_Views Lookup(Identifier) -> Entity_Or_View Direct_Visibility_View -> Visibility_Stack -> List of Declarative_Region_Views Use_Visibility -> Set of Package_Views + Set of Subtype_Views Subprogram_View Subprogram_Profile -> Profile Is_Instance -> Boolean Instantiated_Generic -> Generic_Subp Actual_Part -> List of Associations Is_Abstract -> Boolean Is_Overriding -> Boolean Overrides -> Set of Subprograms Is_Null -> Boolean Is_Primitive -> Boolean Primitive_On_Types -> Set of Subtypes Is_Dispatching_Operation -> Boolean Associated_Tagged_Type -> Subtype_View Package_View Is_Limited_View -> Boolean Full_View -> Package View Is_Instance -> Boolean Instantiated_Generic -> Generic_Package Actual_Part -> List of Associations Is_Formal_Package -> Boolean Is_Pure -> Boolean Is_Preelaborated -> Boolean Is_Remote_Call_Interface -> Boolean Is_Remote_Types_Package -> Boolean Generic Entity Formal_Part -> Region_Part Current_Instance -> Entity Subtype_View Category -> {boolean, character, ordinary_enum, signed int, modular int, ordinary fixed, decimal fixed, float, access-to-obj, access-to-subp, record, record extension, array, task, protected, interface, private, private extension} Are_Of_Same_Type(Subtype_View) -> Boolean Is_First_Subtype -> Boolean Is_Secondary_Subtype -> Boolean Preconstraint_Subtype -> Subtype_View Constraint -> ASIS.Constraint First_Subtype -> Subtype_View Primitive_Subprograms -> List of Subprograms Is_Formal_Type -> Boolean Is_Aspect_Specified(Aspect) -> Boolean Is_Aspect_Directly_Specified(Aspect) -> Boolean Is_Constrained -> Boolean Constraint -> ASIS.Constraint Is_Definite -> Boolean Is_Derived -> Boolean Parent_Subtype -> Subtype_View Ultimate_Ancestor -> Subtype_View Is_Descendant(Subtype_View) -> Boolean Is_Ancestor(Subtype_View) -> Boolean Is_Incomplete_View -> Boolean Complete_View -> Subtype_View Is_Partial_View -> Boolean Full_View -> Subtype_View Is_Elementary -> Boolean Is_Universal -> Boolean Is_Scalar -> Boolean Base_Subtype -> Subtype_View Low_Bound,High_Bound -> Expression/Value/? Is_Discrete -> Boolean Is_Access -> Boolean Is_Anonymous_Access -> Boolean Is_Access_Parameter_Subtype -> Boolean Is_Access_Result_Subtype -> Boolean Static_Accessibility -> Natural Excludes_Null -> Boolean Is_Access_To_Object -> Boolean Designated_Subtype -> Subtype_View Is_Access_To_Constant -> Boolean Is_Pool_Specific -> Boolean Is_Access_To_Subprogram -> Boolean Designated_Profile -> Profile Is_Composite -> Boolean Is_Record -> Boolean Is_Array -> Boolean Is_Protected -> Boolean Is_Task -> Boolean Is_Tagged -> Boolean Is_Classwide -> Boolean Root_Subtype -> Subtype_View Is_Specific_Tagged -> Boolean Classwide_Subtype -> Subtype_View Is_Synchronized_Tagged -> Boolean Is_Interface -> Boolean Is_Abstract -> Boolean Progenitors -> List of Subtype_Views Has_Known_Discriminants -> Boolean Discriminants -> Region_Part Has_Unknown_Discriminants -> Boolean Has_Nondiscriminant_Components -> Boolean Nondiscriminant_Components -> Region_Part Is_Limited -> Boolean Has_Preelaborable_Initialization -> Boolean Needs_Finalization -> Boolean Contains_Task -> Boolean Typed_View Nominal_Subtype -> Subtype_View Is_Component -> Boolean Enclosing_Object -> Typed_View Is_Constant_View -> Boolean Is_Aliased_View -> Boolean Static_Accessibility -> Natural Callable_View Callable_Profile -> Profile Denoted_Callable_Unit -> Callable_Unit Is_Prefixed_View -> Boolean Prefix_Object -> Typed_View Unprefixed_Callable_View -> Callable_View Profile Parameters -> Region_Part Has_Result_Subtype -> Boolean Result_Subtype -> Subtype_View Has_Family_Index -> Boolean Family_Index_Definition -> Convention -> enum (Intrinsic_Convention, Ada_Convention, Protected_Convention, Entry_Convention, Other_Convention, Unspecified_Convention) Convention_Identifier -> ASIS.Identifier !wording TBD. !discussion --!corrigendum A.18.2(239/2) !ACATS test !appendix From: Robert A. Duff Date: Monday, November 13, 2006 9:00 AM > Here is a first draft of my SI on an ASIS semantic model. Thanks. Sergey Rybin (rybin@adacore.com) should be in on the discussion. ****************************************************************