From sblake@alsys.com Mon Jun 19 15:21:43 1995 Return-Path: Date: Mon, 19 Jun 1995 11:29:53 -0700 From: sblake@alsys.com (Steve Blake @pulsar) To: asiswg-technical@sw-eng.falls-church.va.us Subject: ASIS libraries and CU discussion Content-Length: 25482 X-Lines: 570 Status: RO During recent discussions of the exercise defining how GNAT-ASIS might implement ASIS library and CU queries, I attempted (erroneously) to define the ASIS 95 library model a bit too much in terms of the GNAT compilation model. After some thought, I realized the ASIS 95 library model must remain general and permissive enough to support both lightweight GANT style models and the traditional heavyweight models, without imposing unreasonable constraints on either. My responses here try to address the permissions and requirements an ASIS 95 standard should make, verses the choices an ASIS 95 implementation can make. I have also tried to add some to the terminology proposed by Serge. The exchanges have been enlightening and I am confident we now understand the library and CU changes necessary for ASIS 95 enough to create and evaluate a proposal. I'll try to circulate such a proposal ASAP. Note that this proposal will not yet address the issue of modularity (raised by Dan Eilers). If we can first agree on content and the model semantics, then we can proceed to organize it. Steve Blake >Serge. >--------- >Sergey Rybin, Noscow University, >ASIS-for-GNAT Project. > >--------------------------------------------------------------------- >1. There is a number of important differences in the sections 10 of > RM 83 and RM 95. Many of these differences concern not only terms, > but also the essence of the definition of the modular structure > of an Ada program and Ada compilation process. > >2. The most important differences between Ada 83 and Ada 95 having > the direct impact on the revision of the ASIS Library Model are: > > - the Ada 83 notions of > > - a library; > - a compilation/recompilation order; > - an obsolete unit > > have been removed from the Ada standard; > > - the new notions of > > - an environment; > - semantic dependencies; > - a consistent set of the supporters of a unit > > have been introduced instead of removed notions; > > - some *informal* analogies could be found between removed and > introduced notions, but only analogies, no more, removed and > inserted notions are quite different in formal sense. > Sounds good. >3. ASIS 95 Library Model should be based on the RN 95 as much as > possible. This means: > > - ASIS 95 should avoid relying on some implementation-dependent > assumptions concerning the internal vendor library structure and > internal vendor library handling; these assumptions may occur to > be *very* vendor-specific and formally (in respect to the Ada 95 > standard) incorrect; > > - ASIS 95 should use the Ada-standard-defined notions (an > environment, semantic dependencies in the environment, consistency > in the environment) to define formally the interface between ASIS > Library and vendor Ada compiler environment; > > - Of course, ASIS 95 (will) have to use some assumptions > concerning vendor Ada library/environment. If so, these > assumptions must be the well-defined and carefully evaluated > invariants of the vendor libraries/environments; > > - ASIS 95 should be careful not to inherit some Ada-83-dependent > features from the ASIS 1.1.1 Library model, if such features do > not conform to Ada 95 standard. I agree with this, but want to add the following point: The formal definition of ASIS 95 must be permissive especially in the library and compilation unit models, just as the Ada 95 Reference Manual is permissive about the ways environments and libraries can be implemented. For example, if we say ASIS 95 compilation units MUST all be consistent, then we are imposing an extreme hardship on a certain compilation model that does not remove units made obsolete by recompilation of units on which they semantically depend. The permissive approach would allow ASIS 95 compilation units that are consistent, inconsistent, and even only syntactically correct (another Dan Eilers suggestion). ASIS 95 needs to formally define the semantics of the CU states and offer queries that permit ASIS 95 client tools to deal with the possible allowances in a consistent manner. Each ASIS 95 implementation could then choose to support some subset (perhaps all) of the allowed CU states. More explanation follows in section 6. > >4. Terms and concepts. > ------------------- > It would be very important and helpful to define as formally as > possible the main terms using for the ASIS 95 Library Model > definition. I think at least the following terms should be > considered in this respect: > > - environment > - library > - compilable, legal > - is/was successfully compiled > > I have the following informal suggestions concerning these terms: > > o Environment/Library: > ------------------- > Environment should be considered by ASIS 95 specification as > compiler/vendor related notion (or, in other words, as a notion > being *external* for ASIS), and Library should be considered as > the ASIS (and only ASIS!)-related notion. *ASIS* Library is > constructed by ASIS implementation/application by means of the > related interfaces from Asis_Libraries and > Asis_Compilation_Units packages on the base of the (current > state of the) *vendor/compiler* environment; > I like the separation of the Ada term from the corresponding ASIS term. Here are some additional ideas for terminology. The Ada Environment is just as defined in the Ada 95 RM. The Vendor Ada Environment is the model defined by a particular compiler/vendor implementation. The ASIS Environment is an abstraction that performs several operations on, and queries information from, an Ada environment. The Ada Library is just as defined in the Ada 95 RM. The Vendor Ada Library is the model defined by a particular compiler/vendor implementation. The model may support multiple libraries that contain the set of all compilation unit texts. This model defines how a single environment is constructed for compilation or semantic analysis. The ASIS Library is an abstraction that generalizes the concept, legality rules, name resolution rules, and implementation permissions defined by the Ada 95 RM. The ASIS Compilation_Unit is an abstraction that generalizes Ada compilation_unit syntax, static semantics, legality rules, name resolution rules, post-compilation rules, and implementation permissions defined by the Ada 95 RM. > o Compilable/Legal: > ---------------- > The notion of "Compilable" could be applied to the *current > state* of a Compilation Unit included in the *current state* of > the environment; "Compilable" means *legal here and now*; this > term is both vendor/compiler environment-related and ASIS > Library related; ASIS Library could contain only compilable > units from the environment; The ASIS terms "consistent" and "legal" can be extended from the Ada 95 RM terms. A Unit is syntactically legal if it meets only the syntax rules of Ada. A Unit is semantically legal if it meets all the rules of Ada. A set of units is consistent if it meets the legality rules for consistent units defined in the Ada 95 RM 10.1.4(5). A Unit is consistent with other units if it is semantically legal and the set, inclusive of itself and all units upon which it semantically depends, is consistent. A consistent unit is available to be assigned or included in a partition. A unit is inconsistent with other units if the set, inclusive of itself and all units upon which it semantically depends, is not consistent. The unit is syntactically legal and is semantically legal only within its compilation unit boundary. There is no guarantee that the unit is semantically legal across its compilation unit boundary. An inconsistent unit cannot be included in a partition. ASIS 95 could represent the state of units with an enumeration type rather than with Boolean queries like Is_Consistent or Is_Obsolete: type Unit_State is (Not_A_State, A_Consistent_Unit, An_Inconsistent_Unit, A_Syntactically_Legal_Unit); ASIS syntax queries (ie Traverse_Element) should work correctly for consistent, inconsistent, and syntactically legal units. ASIS Semantic queries should work correctly for consistent units, and should work correctly for inconsistent units only within the unit's border. Semantic queries across the unit border of inconsistent units, and all semantic queries on syntactical legal units should be expected to raise ASIS_Failed. > > o Compilation: > ----------- > "Compilation" is *compiler-specific* notion; "Compilation" means > *an action*. *Successful compilation* has two results: > establishing the fact that the compilation unit is compilable > *at the moment of the compilation* and producing the code > ("object file"). It seems to be helpful to use the different > term - Semantic Checking or Compilability Checking - if NO CODE > is generated for a compilable/legal unit; > > o Is/was successfully compiled: > ---------------------------- > "Is/was successfully compiled" means that the unit is/was > compilable *at the moment of the compilation* and the code for > this unit has been obtained and inserted in the environment. > Recompilation means the replacing the code for the unit by the > new code for the same unit; "the same unit" means the unit with > the same *Ada* name in the same environment. >5. The first invariant: the content of the environment, > --------------------------------------------------- > or the source-based library. > --------------------------- > The first assumption concerning the environment which seems to be > general enough and important enough to be used as the invariant > for the ASIS Library Model definition is: > > Ada environment contains Ada Compilation Units in the source > form. > > Source texts of the Compilation Units should be used as primary > information sources (I am afraid I have a language problem here: > sources - sources :) for all information which could be retrieved > by ASIS queries (this means that all retrieved information should > (must?) correspond to the current state of Ada sources. (This is > an attempt to define *an abstraction*, but not to say something > important about *its implementation* !) Values of the objects of > the Asis.Compilation_Unit type should correspond to some source > texts in the environment. > Minor quibbles: This is OK as long as we don't assume that "source texts" are represented as files. The Ada 95 RM does not define the concept of a source file. Note that source texts do not provide ALL information for ALL ASIS queries. >6. The content of the ASIS Library. > ------------------------------- What's described here is a very reasonable way to define the implementation of GNAT-ASIS. However, for use as formal definitions of the ASIS 95 standard, these need to be much more permissive. > o ASIS Library should contain *all* compilable units (=sources) > from the corresponding environment, and it should contain *only* > compilable units (=sources) from the environment; It is too restrictive to say it should contain *only* compilable units. ASIS 95 must be permissive. If an ASIS implementation like GNAT-ASIS chooses to contain *only* compilable units (=sources) from the environment, then that is perfectly acceptable. > > o The content of all environments ASIS implementation/application > works with should be frozen from the Initialization till the > Finalization of the ASIS Environment. (When (and after) the > content of the environment is frozen, it *could (should? must?) > contain only one version of each compilation unit* ; each unit > is uniquely defined by its Ada name; > > o ASIS knows all about *the content* of the environment at the > moment of the ASIS Initialization (content means the set of Ada > sources here), but it knows nothing about *the history* of the > environment creation/modification; > Having a frozen environment/library during an invocation of ASIS is ideal and desired. However, ASIS 95 cannot make this a requirement because there is no reasonable way to enforce it. ASIS implementations that cannot recover from the effects of an ill-timed intrusive action can gracefully raise ASIS_Failed and report the reason through Status and Diagnosis operations. I think the time between Library opening and closing is when it is more critical to avoid updates. It should not be a required illegal action to open a library, do some ASIS queries, close the library, invoke a compiler, then reopen the library for more queries, all during the time ASIS is initialized (this may not be supported by some implementations). Similarly, ASIS 95 cannot assume a single version restriction applies within an Ada environment or Ada library, but it can within a single ASIS library. Different Ada libraries may contain different versions of units, but the assumption is that only a single version is made "visible" by some internal mapping or library search order, and that is the version constructed by ASIS. Every Ada implementation I know of offers multiple libraries with some (post-compilation) method for defining how units are selected for inclusion in a program. This is the same method a binder would use. Hence, I believe this assumption to be an invariant. This is one reason ASIS 95 needs a well defined model for consistent and inconsistent units. One library might contain a version of a consistent unit, and another might contain another version of the same unit that is inconsistent. Note that ASIS 83 and ASIS 95 do not offer specific queries to fetch versions of units. ASIS 95 uniquely identifies multiple versions of units across library boundaries by their ASIS_Compilation_Units.Unique_Name. Relations queries involving semantic dependencies can be required to only contain a single version of a unit. Regarding the "history", I'm really not sure exactly what that means. I think of history as information such as the dependency order, time of last update, consistency, and other similar things. Other potential historical information can be gained from (assuming they exist) examining dates of object files, creation dates of sources, etc. Those details may or may not be useful to an ASIS implementation. > o the compilability of the units (=sources) existing in the > environment can be checked only *after* the Initialization of > the ASIS Environment; > > o the means by which a Unit could be included in the *ASIS > Library* should be some Compatibility/Legality check, but *not* > the Compilation! This means that no new code could appear in the > environment after ASIS Initialization; > For the ASIS 95 standard, no compatibility checking during ASIS can be required for inclusion in the ASIS library. For some heavy-weight implementations, construction of library contents could just be a lookup with no legality check. To require them to reanalyze the environment/library would be unreasonable. For GNAT-ASIS, it seems that the legality check should be performed only on demand and only AFTER opening a library. See the next group of comments below. ASIS can require that no queries cause any update to the library. This rules out compilation (with code generation) from within ASIS but does not rule out an ASIS tool invoking a compiler through some other interface. > o If a Unit is compilable, it cannot be obsolete. It also could > not be tested as Unknown. Moreover, no inconsistency could be > found inside the set of the compilable units separated from the > frozen Ada environment to make up the content of ASIS Library. > The Unit_Kind Unknown is, and should remain, allowed for optional implementation protection of certain units. GNAT-ASIS can choose to never use Unknown. It is possible that inconsistency can be introduced without recompilation and during the frozen environment. This is due to the muti-library systems in all Ada implementations. In Thomson/Alsys RISCAda, a unit search order is defined by the library. Simply changing the search order can cause a compiled unit that was consistent under one search order to become inconsistent (obsolete) under another order. No recompilation is required to cause this change of consistency state. Since GNAT offers the same kind of ordering capability for searching source directories, I would bet it is possible for a unit to be compilable (consistent) using one ordering, and be (uncompilable) (inconsistent) under a different order. In between, that unit's source would not have changed, nor would it have been recompiled. The Ada environment would have remained frozen, only the Ada library definition changed. >7. Stand-alone ASIS implementation. > ------------------------------- > The subsection 6 above does not have any relation to any > *Compiler*. If ASIS implementation contains some > *compilability/legality checker*, it could process any sets of Ada > sources without having any compiler around this processing. So we > could change "compiler environment" to "Ada environment" in all > the stuff above and we could say about a *stand-alone ASIS 95 > implementation* (It was impossible for Ada 83!). I think this is a great idea and support it wholly. However, it does have some limitations described in the next section. > >8. Compiler-based ASIS Library. > --------------------------- > I am not completely sure that the next step after suggesting the > Library Model for A stand-alone ASIS 95 implementation would be > the really necessary thing. (In my opinion, the stand-alone ASIS > is all we really need, but I am not sure I completely understand > the bigger picture.) But it seems necessary to get ahead as much > as possible to investigate all variants. > There are several reasons why the stand-alone ASIS would not be all that's needed in the bigger picture. 1. It would rely on the assumption that sources are text files and are persistent. Not all Ada implementations support that assumption (I think Rational uses an internal source representation). Some sources contain non-Ada text that is preprocessed into a temporary Ada source before compilation. For some Ada implementations, preparation of a source file based environment suitable for the stand-alone ASIS might be near impossible, or at least more trouble than it's worth. 2. The stand-alone ASIS would have no knowledge of the semantics of the Ada implementation. Specifically it would not reflect: o the true elaboration order. o the exact closure of a program; ie runtime units implicitly "needed" for support of tasking. o implementation of the package standard; AARM 10.1.1(10a) o implementation defined pragmas. o whether pragmas were obeyed or ignored. o implementation defined record components. o attributes of the object code; file name, consistency o compiler capacity limitations. o compiler optimizations/transformations. o handling of generics where code is possibly generated at bind time. o the structure of implicit elements. o the structure of macro expanded instantiations. o internal information required to support the ASIS_Data_Decomposition annex. I'm sure there are more vendor-dependent semantic details that would be missing. >8.1. The Second Invariant: the Compilation. > ------------------------------------- > Two-step processing of the Ada units: compiling the individual > unit including generating the individual piece of code for the > unit and linking/binding these pieces of code into executable > code for the program may be considered as the invariant for Ada > implementations. > > The notion of Compilation as legality/compilability checking > TOGETHER with generating the piece of code for the compiled unit > may also be considered as invariant. > > And we have a small terminological problem here: traditionally we > are speaking about Ada compiler as about Ada implementation and > as about the "owner"/"handler"(?)/"processor(?)" of an Ada > Library. But sometimes the explicit separation of a compiler (as > the part of the implementation checking the legality of the > *individual* unit and generating the *individual* piece of code > for it) and a linker/binder (as the part of the implementation > processing the pieces of code for some set of units in order to > check the consistency of these set of code pieces and to make up > the executable program, if possible) makes the picture clearer. > I think the definition of the ASIS 95 Library is the case. > >8.2. The Content of the Compiler Environment. > --------------------------------------- > I think that the set of sources and the set of the related > pieces of code generated by the compiler (not all sources > could have related pieces of code) may be considered as the > invariant for the *compiler* environment. The main difference > between Ada 83 and Ada 95 in this respect is that in ada 83 the > compilation/recompilation order rules were responsible for the > consistency of the (set of the) pieces of code (or, in other > words, the consistency of code and the consistency of the > Library (sources) were the same things in Ada 83. But this is > not the case in Ada 95. We could produce the code for a unit and > change unit after that - and both the unit and its code > corresponding to the old version of the unit would remain in the > environment! > These implementation details should not be assumed by the ASIS 95 standard. >8.3. The Extended Second Invariant - > ------------------------------ > ASIS Library for Compilation Environment. > ---------------------------------------- > The general idea of defining the ASIS 95 Library for Ada 95 > compiler environment is to extend the invariant for Compilation > from 8.1 as follows: > > - the semantic dependencies defined for Ada Units (=Ada sources) > should be extended to the corresponding pieces of code: the > piece of code depends on its source and - in transitive manner > - on all other sources upon which the source depends. > > - the piece of code depends on *the concrete versions* of the > sources; the version of the source could be defined by the > time of its last update (I think we could hardly find better > invariant for the version of a source), so each piece of code > existing in the environment should "remember" the time stamps > of all sources upon which it depends. > > And the ASIS 95 Library for a *compiler* environment could be > defined just as the ASIS Library for the stand-alone ASIS > implementation with one extension only: ASIS considers not only > sources, but also related pieces of code. If so, we could define > some * "code-related" * queries as an addition to the > stand-alone ASIS 95. (The prototypes for such queries could > easily be found in ASIS 1.1.1): > > - Compilation Unit (=source) in an ASIS Library cannot be > obsolete, but its piece of code can; > > - Compilation Unit (=source) in an ASIS Library cannot be > inconsistent, but its piece of code can; > > - we may also ask about the set of recompilations (as > code-related actions) which are necessary to make some set > of code pieces consistent, or which may be made necessary > by changing some Compilation Unit (=source), we may also > require that this set of recompilations would be ordered. > A permissive ASIS 95 will cover both stand-alone and compiler-environment implementations. >9. GNAT: its role and its place. > ---------------------------- > Many of the suggestions above are inspired by the experience > obtained in our ASIS-for-GNAT project, by the GNAT compiler itself > (after having used GNAT as a tool in our project since the > beginning of this year I became a real fan of its compilation > model :), and by excellent paper of Robert Dewar "The GNAT > Compilation Model" (Ada Europe News, March 1995, Num.20, p.20-32) > > From the other side, GNAT could (and, may be, even should) be > considered as the "validation test" for the new ASIS Library > model, because its compilation model completely corresponds to the > Ada 95 RM and it violates most of the compilation-related and > library-related requirements of the Ada 83 RM. I have been working with heavy-weight Ada for many years. Recently, I have also become a fan of light-weight Ada too. I have a feeling the trend will be toward light-weight implementations. I hope ASISWG will consider all ASIS 95 implementations as "validation tests". If GNAT-ASIS is the first one, and it proves the library model works, that's great. If the Rational, THOMSON, Harris, DDC, or Intermetric's AdaMagic ASIS 95, or any other implementations cannot reasonably conform to the library model, then we need to change it.