ASISWG Meeting at Harris Computer Systems in Ft, Lauderdale, FL The ASIS Working Group met all day Monday and Tuesday, and all morning Wednesday, 6-8 March 1995 at the facilities of Harris Computer Systems Corporation in Ft. Lauderdale, Florida. The following people attended: Steve Blake, Thomson (formerly Alsys) Currie Colket, SPAWAR Dan Cooper, Boeing Bob Hokanson, Unisys Dan Rittersdorf, Harris Computer Systems Corporation Clyde Roby, IDA The primary goal of this meeting was to finalize the Ada specification for ASIS 95; two drafts brought before ASISWG had already been reviewed and Draft 5.0.A was reviewed by ASISWG at this meeting. ASISWG Goals We had distributed the following list of goals (and dates) after the summer 1994 ASISWG meeting. The primary goal of this meeting was to finalize the Ada specification for ASIS 95. Nov 94 Finalize the approach for ASIS 95 Categorize outstanding ASIS 83 deferred issues Proposed KINDS for ASIS 95 Mar 95 Finalize ASIS 95 KINDS Provide ASIS 95 in skeleton format Organize ASIS 83 Deferred Issues and Current Issues (*) Jun 95 Draft for public review (ASISWG) in ISO format (assume ASIS as an Annex to ISO Ada document) Propose ASIS library and compilation unit modifications (*) Remaining ASIS packages/units, e.g., IDs, etc. (*) Oct/Nov 95 Finalize ASIS 95 for Tri-Ada'95 distribution for public review (if we don't make this, then we can distribute for public review at STC'96 perhaps) (*) where items marked with "(*)" were inserted at this March meeting. We will try to have a draft ready for distribution to ASISWG at its June meeting. The goal to produce the draft version for public review by June was viewed to be ambitious. However, there would still be one more meeting before our planned distribution. We are somewhat on track. By the end of this March meeting we had pretty much accomplished the goals to date. ASIS 95 Kinds were finalized. ASIS 95 was provided in a skeleton format. Two drafts brought before ASISWG had already been reviewed by email and a newer Draft (5.0.A) was reviewed by ASISWG at this meeting. The ASIS 83 Deferred Issues were organized so that they could be closed. If we don't make a TRI-Ada'95 distribution, then we should aim for a STC'96 distribution. ISO Standardization of ASIS We discussed two alternatives to how ASIS 95 should be processed as an ISO standard: (1) as an Annex to the ISO Ada document, or (2) as a separate ISO standard and therefore as a totally separate document. Annexes can be added to an ISO standard; this implies minimal changes to the main body of the document of the existing ISO standard. The model of NUMWG's work being folded in as Annex A and Annex G is an example of this; but initially, it was a separate standard when it applied to Ada 83. Similarly, ASIS could be a separate standard and then folded into Ada2005. Currie will make a presentation at the next WG9 meeting, to be held in conjuction with ICSE'95 in Seattle, WA in late April. The goals of this presentation will be to establish ASIS as a work item and establish a standardization route for ASIS. On Wednesday morning, we further discussed the format of the ASIS 95 standard, although WG9 will probably make the final decision. We agreed to proceed as if ASIS would be a separate standard with the desire to eventually become part of the basic Ada standard. We discussed both options; thus, both the format of ASIS as an Annex to the ISO Ada 95 Standard and the format of ASIS as a stand-alone ISO stanard are shown below. STRUCTURE OF THE ASIS STANDARD (as an Annex to ISO Ada 95) X. Ada Semantic Interface Specification (ASIS) [text] X.x Title [text] - Syntax - - Name Resolution Rules - - Legality Rules - - Static Semantics - - Post Compilation Rules - - Dynamic Semantics - - Bounded (Run-time) Errors - - Erroneous Execution - - Implementation Requirements - [conformance] - Documentation Requirements - - Metrics - - Implementation Permissions - [allowable deviations] - Implementation Advice - - Examples - - Sections on each ASIS package - STRUCTURE OF THE ASIS STANDARD (as Stand-Alone document) Title pages Contents Forward Introduction Design Goals Acknowledgements Instructions for Comment Submission Interface Summary Interface Changes Changes Since Version x.y 1 General 1.1 Scope of the Standard 1.1.1 Extent of the Standard 1.1.2 Structure of the Standard 1.1.3 Conformity of an Implementation with the Standard 1.1.4 Method of Description and Syntax Notation 1.1.5 Classification of Errors 1.2 Normative References 1.3 Definitions 2 Section on ASIS package 3 Section on ASIS package ... N Section on ASIS package Glossary Index 200+ Issues and Issues Summary List The 200+ issue list is a list of issues generated during the development of ASIS for Ada 83 (Ada 87 -- ISO Ada). Many issues were incorporated into ASIS 1.1.1. We need to identify those still valid for ASIS 95 so as to not loose them. Gary Barnes generated a summary list for the April 1994 meeting in Boulder. What is the relationship between these two, i.e., the list of 200+ issues and the summary list that Gary developed at the April 1994 meeting? Should there be a mapping between each issue summary and the appropriate n (10-12 or whatever) issues? Currently, there is no maintenance of the 200+ issues list; it represents detail of the Issues Summary List. We also have no detailed mapping between the two. From a previous meeting (November 1994), Dan Rittersdorf has an action item to provide this detailed mapping. After some discussion, we decided to use the Ada 95 comment submission format as the format for keeping track of the issues for ASIS 95. We then began a discussion about the process "to get from here to there", i.e., from the 200+ issues to a new open issues list. The process below will reference the following pre-existing artifacts: PA1: "asis.1.1.historical" This file is also known as "the 200+" document. PA2: "ASIS83-Issues-Summary" The April 1994 document from Gary Barnes summarizes th "asis.1.1.historical" (PA1) issues. PA3: "ASIS95-Issues-Summary" The November 1994 document applied a status to each Summary Issue in the "ASIS83-Issues-Summary" (PA2), as well as new issues pertinent to the ASIS 95 revision process. The process below will create the following new artifacts: NA1: A mapping of PA3 <--> PA1 NA2: A modified version of PA1 with status and rationale. NA3: A mapping of PA2 <--> PA3 NA4: New issues entered into the database The process for handling the outstanding ASIS83 issues is then: 1: Produce a mapping of PA3 <--> PA1 (NA1). 2: Copy PA1, and to each entry, add "status" and "rationale" fields to generate an expanded historical file (NA2). Use NA1 to find the status from the corresponding PA3 issue. The rationale field with contain an explanation for the status (TBD). 3: Produce a mapping of PA2 <--> PA3 (NA3). 4: Add issues to the new database (NA4) for all issues in PA3 not mappable to PA2 (leftovers from NA3). The status for each new issue is to be carried over from PA3. 5: Add issues to the new database (NA4) for all issues in PA3 not mappable to PA1 (leftovers from NA1). The status for each new issue is to be OPEN. 6: Use the new database exclusively. ASISWG Charter The charter was distributed again for review. We decided that only minor changes needed to be made as we begin/continue our work on ASIS 95. Initial changes were made by the group present; these will be discussed further electronically before presenting the agreed upon updated charter to the entire ASISWG by the end of March. Both the current SIGAda approved Charter and the new proposed Charter are now located on the AJPO host. ASISWG Officers At the end of the last meeting (November 1994), ASISWG's officers included the following: Chair: Currie Colket Vice-chair: Steve Blake Recorder: Clyde Roby Vice-recorder: Dan Cooper Publicity/Meetings: Gary Bundy Archivist: Gary Barnes At this meeting, we learned that Gary Bundy of MITRE was promoted and that he no longer can participate in ASISWG; therefore, this position is once again open. We also learned that Gary Barnes of Rational was working in a new area, mainly unrelated to Ada, and will be unable to actively participate as much as he has in the past. Most of the archiving activities are automatic, but this may change in the future as we begin to log more information more formally for the development of the ASIS 95 specification as we progress more towards standardization. We are currently looking to fill the positions at the next ASISWG meeting. If anyone knows of somebody who is interested in this opportunity to be involved in the standardization of an important interface, please send email to roby@ida.org and colket@sw-eng.falls-church.va.us. Update on what ASIS users are doing Serge Rybin of Russia has been asking questions about the Ada 95 Library and has received excellent responses from others within ASISWG, particularly Steve Blake. Ada 95 has more relaxation about incomplete contents of the Ada library since it allows units compiled in other languages to be part of the Ada library. An interesting question: Must there be semantically complete and correct artifacts in the Ada library in order to use ASIS, or can ASIS handle imported units which may not be complete? Recent email discussion from Yoshimi Fujii (chackn@alsys-kke.co.jp) of Alsys in Japan indicates that they are planning to use ASIS in a tool to estimate performance. But they aren't exactly using ASIS. He would like to use it for estimating the necessary amount of heap space used at runtime. Yoshimi knows that ASIS is not intended to get dynamic (runtime) information, but, he thinks he can get some practical (runtime) information with ASIS. Recent email discussion from Rainer Koschke (Koschke@informatik.uni-stuttgart.de) indicates a continued interest in ASIS. In the department of Prof. Erhard Ploedereder, they are planning to develop a translator from Ada 83 to Ada 95. They will use the Rational compiler as a front end. The information they need is provided by an ASIS interface of the Rational compiler. Recent email discussion from Rod Martin (rjm@itd.dsto.gov.au) indicate that they are marketting a tool (called SEE-Ada written in Ada) that displays information about an input Ada program graphically. In particular SEE-Ada displays parent/child relationships such as Spec/Body, Subprogram/Encapsulating Subprogram, Subprogram Call/Subprogram Called etc. A utility Data_Filter obtains the above relationships using ASIS. It steps through all Compilation Units in an Ada library for a nominated main program and examines every Element (using Traverse_Elements). For certain elements information and relationships are recorded for SEE-Ada to display. Recent email discussion from Daniel Dolle (daniel.dolle@matra-transport.fr) of Matra Transport in France indicates that his firm writes software for automatic train operation. In order to ensure the safety of our systems they use a special programming technique: all computations are done at run-time with redundancy bits. Before the execution they analyse the source code and compute tables that enable them to know beforehand the redundant part of each variable at the end of a computation cycle. Any discrepancy between the computed and the expected redundancy causes an emergency brake. Until now they directly analysed the source code; now they are currently investigating whether it would not be easier to let a compiler do a compiler's work (syntactic analysis, identification, etc ...). A solution based on ASIS seems natural: vendor independency, use of a standard, etc. ... Universities: mainly NYU; also, the University of Central Florida is doing some work on the real-time issues relating to ASIS. New tools developed by US companies are being done by those companies with more active ASISWG members, e.g., Rational, Thomson (formerly Alsys/Telesoft), Unisys, Odyssey Research Associates, etc. In a recent print advertisement, Dynamics Research Corporation prominently mentioned ASIS. Dan Ehrenfried of Little Tree Consulting in Mountain View, California, is offering the LRM interfaces on top of ASIS 83. "LRM Interfaces" are a (no longer supported) Rational product which was the ancestor of ASIS. Dan's offering is an enhanced version of the LRM Interfaces: his product and ASIS both have the original Rational product as common ancestors. Many of the declarations are just renamings of the corresponding ASIS declarations; but the rest of it qualifies as a secondary, non-primitive layer above ASIS, implementing (among other features) the iterator capability that had been so hotly debated in past ASISWG meetings. How to best organize ASIS related information on the Internet We need a FAQ as well as an informational handout. After some discussion about possible directory structures on the AJPO's host machine (sw-eng.falls-church.va.us) in the /public/adaic/work-grp/asiswg directory, we decided upon the following (which was created on the AJPO host during the meeting): /public/adaic/work-grp/asiswg directory README ASISWG-Charter.txt (most recent charter) asiswg-members (list of ASISWG members) ASIS.FAQ ASISWG.FAQ asiswg-email (archive) asiswg-technical-email (archive) /asis README /issues README SUMMARY (one-liner for each issue) /issue001 README (link points to issue001 file below, not directory above) issue001 (contains text of issue) issue001.email (email of discussion) issue001.resolution issue001.etc historical historical-status /issueNNN README (link points to issueNNN file below, not directory above) issueNNN (other files as needed) /bibliography README (information and/or links) /V1.1.0 README (Ada source of specification) /examples README (examples as appropriate) /tests README (tests as appropriate) /V1.1.1 README (Ada source of specification) /examples README (examples as appropriate) /tests README (tests as appropriate) /V2.0.0 README (Ada source of specification) /examples README (examples as appropriate) /tests README (tests as appropriate) /secondary README (examples of secondary layer applications as appropriate) /meetings README (action items) (decisions) (minutes) Schedule Goals It should be noted that the .../examples and .../tests subdirectories will exist only when actual examples and tests exist. ASIS 95 design goals We briefly mentioned ASIS 95 design goals as we began to review some of the issues brought up in the last several months. Two prominent ones included: (1) minimize changes from ASIS 83 to ASIS 95, and (2) to the most extent possible, changes should be such that an automated tool or script can be used to assist in the conversion of a tool's source code with ASIS 83 code to ASIS 95 code. We reaffirmed these design goals as important. They are reflected in the design of ASIS95. Issues discussed at this ASISWG meeting ASIS provides two views of compilation units; a "black box" view is abstracted with the Compilation_Unit type, and a "white box" view is abstracted with the Element type. During the discussion of this issue, it was brought out that we should keep ASIS as primitive as possible, and let additional functionality be included in higher level or "Secondary Layer" of interfaces -- the ATIP project defined Secondary Layer for particular application areas as a Program View Layer (PVL). We could use so-called non-primitive, secondary layer, functions that are removed from ASIS 95 as examples of usage of ASIS that could be put into the public domain. Vendors are encouraged to contribute such secondary functions as examples. For background information, the following information is provided from a previous description of the ASIS/PVL ATIP: Views are effectively abstractions of ASIS information that focus on different aspects of an Ada program structure. At the start of the ATIP, candidate PVL Views discussed included: Control Flow, Reference (set of entities referenced in a declarative region), "Chunk" (identify transfer of control resulting from calls and propagated exceptions), Name Space, and Data Flow. The actual ASIS/PVL ATIP project has created four views: the Region View, Name Space View, Reference View, and Control Flow View. We also discussed one of Dan Ehrenfried's issues from a recent email message (the second one we will make a formal comment). The one discussed at the meeting dealt with the lack of unification of element nodes and compilation unit nodes. Another issue brought up was linked to Cheryl Barbasch's recent email message about a different type structure for ASIS -- different meaning stronger (other email had also supported such a view, although to varying degrees). Last year, we had already discussed a proposal based upon really stronger types and did not accept it. It was pointed out that all approaches to defining a type structure have advantages as well as disadvantages; there are always trade-offs. However, a secondary layer could be written above ASIS that supports a stronger typing model (this is the present group's proposal). This issue was also accepted as a formal comment. Finalize ASIS 95 Specification The work on finalizing the ASIS 95 specification consumed all day Tuesday as well as Wednesday morning before the break. Steve Blake had prepared some handouts from which the discussion was based. Many of the comments from the last ASISWG meeting had been incorporated in the Draft 5 of the ASIS specification presented at this meeting. As we discussed Steve's handouts, several minor changes were identified. The modified documents would be entered into the ASIS 95 issues list as Issue 001 with the title of "Proposed ASIS 95 Element_Kind Type Hierarchy." This will form the basis for ASIS 95 Element_Kinds. Draft 5 will form the basis for the ASIS 95 interfaces. The modified version would be entered into the ASIS 95 issues list as Issue 002, "Proposed change to ASIS 83 to produce ASIS 95 draft standard." It was recognized that there would be additional changes. However, issues 001 and 002 would serve as an excellent baseline from which to evolve. Some of the issues to be revisited include: * The Alternative_Kinds issue. * The use of the term "ordinary" in some of the type definitions. * Providing an example of each package's usage. These examples are intended to be provided for the accompanying ISO documentation; such examples will probably not be in the specification itself. * Combining or keeping separate Unit_Kinds and Element_Kinds? This led us back into a discussion of the "black box" versus "white box" discussion we had had earlier in the week. We decided that these _Kinds should be separate. Additonal issues were also discussed, as follows. It was noted that the definition of ASIS 95 was written so that it could be compiled with Ada 83. This does not preclude implementors from implementing ASIS 95 using Ada 95, though. This also does not preclude applications implemented on top of ASIS 95 from using Ada 95. Although the function ``References'' is conceptually a secondary function, of all the ASIS functions, this one is probably the most performance hungry. This is a primary reason why it should be kept as an ASIS primitive function. There was some discussion about leaving in a body_block related function due to ASIS 83 upward compatibility. The plan now is to leave the body block model like it currently is in ASIS 83, removing the proposed changes in ASIS 2.0.A. Several interfaces were REPLACEd in Draft 5; Steve will supply an appropriate rationale for these (some were already supplied, but Steve will make sure they are more complete). The main improvements in Draft 5's proposal are in its organization and the ease of use. We should keep many of the Boolean queries as secondary functions. We should probably keep a public domain package of these -- but only include those that are well-defined. This could be done in the future -- after ASIS 95 is defined. There was some discussion about what it means when enumeration literals should be treated as functions -- recall that they were always treated as parameterless functions, even in Ada 83. Should ASIS always return function related information or enumeration literal information? Enumeration literal information is what we decided; however, more appropriate rationale is needed. We decided to have ASIS treat enumeration literals as just that, enumeration literals. The inference that they are or are not treated as functions is up to client programs. This leads to two ASIS 95 changes from the way ASIS 83 works: 1. An_Enumeration_Literal_Specification is not appropriate for the queries Parameter_Profile and Result_Profile (formerly Parameters and Result_Type). 2. An enumeration literal (including a character literal) that appears in an expression will test as Expression_Kinds'An_Enumeration_Literal (or A_Character_Literal) not as Expression_Kinds'A_Function_Call. The key issue here is that change 2. is required in order for change 1. to be made. Steve agreed and will make sure both changes are in the next proposal. Should query functions return identity elements? The sense of the present ASISWG group was to leave it ias it is, i.e., as a normalizer. Note that, due to Steve's adoption of a naming convention (i.e., the "Corresponding_" prefix), the distinction between structural and semantic ASIS queries is cleanly divided. ASIS 95 artifacts 1. The ASIS 95 specification (draft standard) -- initially in ASCII, compilable with structured comments; then as a stand-alone standard OR as an Annex (Annex Q) to ISO/IEC 8652 (ISO Ada 95). 2. Introduction with design goals 3. Instructions for comment submission 4. Interface Summary 5. Changes from ASIS 83 6. Conformance requirements Each of the above artifacts should be versioned. ASIS 95 ISSUES RESOLUTION MODEL 1. Issue (comment) sent to ASIS-Comment 2. Comment semi-automatically entered into database Status: NEW (N) 3. New comment looked at Status: OPEN (O) 4. Act upon comment appropriately 4a. Status: APPROVED WITH MODIFICATION (M) 4b. Status: ACCEPTED or APPROVED (A) 4c. Status: CLOSED or REJECTED (X); with appropriate rationale 4d. Status: DEFERRED (D) to some later time 4e. Status: REFERRED (R) to the Secondary Layer 5. Comments with M or A status are incorporated into ASIS Status: IMPLEMENTED (I) or DONE (D) Such comments also include appropriate version number From the November 1994 ASISWG meeting, the following status had been defined: D Done already in either final ASIS 83 or current ASIS 95 A Accepted for ASIS 95, but not yet done U Undecided, still open for discussion X Rejected R Rejected for now, but keep revisiting L Rejected for now, but keep for potential higher layer Proposed ASIS 95 Issues Summary List (using ASIS 95 Resolution Model) Comment Date Last Std Ref/ IS# Stat Version Action Package Submitter Title --- ---- ------- --------- -------- --------- ------------------ 001 A 08-Mar-95 ASIS S. Blake Proposed ASIS 95 Element_Kind Type Hierarchy 002 A 08-Mar-95 ASIS S. Blake Proposed change to ASIS 83 to produce ASIS 95 draft std 003 O 08-Mar-95 ASIS D. Rittersdorf Traceability for outstanding ASIS 83 issues 004 O 08-Mar-95 ENV S. Rybin Library model for ASIS 95 005 O 08-Mar-95 STD J. Lonjers Proposed conformance rules 006 X 08-Mar-95 ASIS D. Ehrenfried Unification between Element nodes and Compilation Unit nodes 007 R 08-Mar-95 ASIS C. Barbasch Use stronger typing 008 O 08-Mar-95 ASIS D. Ehrenfried Flattening of node kinds 009 O 08-Mar-95 ASIS ASISWG Don't preclude a client/server ASIS implementation ASIS and the Verification Rapporteur Group Mr. Brian Wichmann, of the Verification Rapporteur Group (VRG) had expressed interest in the possibility of using ASIS as a means to verify that an Ada implementation was using SPARK, a safe subset of Ada for Safety Critical applications. The ASISWG discussed the concept and felt that ASIS would be an excellent approach for such a tool. Additional interfaces between ASISWG and the VRG might be needed to verify that ASIS 95 could support all the VRG's requirements. Client/Server discussion This idea was initially discussed at the November 1994 meeting of ASISWG. What many third-party tools want to do is to connect to a totally separate executable image of ASIS, rather than always have to link to ASIS and thus include a large amount of code in their tool's executable image. Currently a tool is tied to a particular implementation, version, etc. of an Ada compilation suite, of which ASIS is very tightly tied to. It's basically a configuration management problem. Eventually, we would like to see a separate ASIS engine and a separate executable -- in a client/server type of relationship. This would open the Ada tool market up considerably. Thus, the current issue is that the ASIS specification must be developed in such a way that it does not preclude a client/server implementation of ASIS. It is believed that ASIS can easliy be implemented using the Client/Server Model. An approach for building an ASIS Client/ Server would be an interesting activity after the ASIS95 draft standard is completed. Special Publication of AdaLetters A special publication of AdaLetters is being planned (for late 1995 or early 1996) and we had initially thought to include the ASIS 83 specification in it. After further discussion, we concluded that it should NOT include the ASIS specification. Rather, it should contain many articles about ASIS and how it is used. Future meetings 26-27 June 1995 during WAdaS'95 in the DC area 5-10 November 1995 during Tri-Ada'95; Options were discussed about a meeting the week prior to Tri-Ada'95 or the week after. The group decided to wait until June to select the dates of such a meeting. In addition, we should plan on a Birds-of-a-Feather session there.