From dewar@gnat.com Fri Jan 19 10:01:49 1996 Return-Path: Date: Fri, 19 Jan 96 09:19:21 EST From: dewar@gnat.com (Robert Dewar) To: asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil Subject: Re: Highlights of November ASISWG/ASSRG Meeting Content-Length: 1004 X-Lines: 20 Status: RO One comment "Moscow implementation of ASIS for the GNAT Ada 95 compiler. Their experience has been a valuable input for evolving the ASIS specifications to support Ada 95 for lightweight library environments and the development of the ASIS Library Model. An initial version of the prototype implementation of the ASIS interface for the GNAT compiler has been already implemented and was demonstrated at Ada-Europe'95. A paper describing the goals, problems, and implementation strategy of ASIS for the GNAT compiler will be included in the March/April 1996 issue of Ada Letters. A partial prototype of the ASIS implementation will be available in early 1996." The use of the term Library in connectin with Ada 95 is technically inappropriate. The removal of this word as a technical term in the Ada 95 RM is quite deliberate, and it is confusing for ASIS to propagate this confusion. The proper technical term in Ada 95 is compilation environment. I recommend apropriate changes in ASIS terminology. From Serge.Rybin@lglsun.epfl.ch Fri Jan 19 12:10:18 1996 Return-Path: Date: Fri, 19 Jan 1996 17:22:01 +0100 From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) To: asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com Subject: Re: Highlights of November ASISWG/ASSRG Meeting Cc: Alfred.Strohmeier@di.epfl.ch, zueff@such.srcc.msu.su Content-Length: 5396 X-Lines: 98 Status: RO > One comment > > "Moscow implementation of ASIS for the GNAT Ada 95 compiler. Their > experience has been a valuable input for evolving the ASIS > specifications to support Ada 95 for lightweight library environments > and the development of the ASIS Library Model. An initial version of > the prototype implementation of the ASIS interface for the GNAT > compiler has been already implemented and was demonstrated at > Ada-Europe'95. A paper describing the goals, problems, and > implementation strategy of ASIS for the GNAT compiler will be included > in the March/April 1996 issue of Ada Letters. A partial prototype of > the ASIS implementation will be available in early 1996." > > The use of the term Library in connectin with Ada 95 is technically > inappropriate. The removal of this word as a technical term in the > Ada 95 RM is quite deliberate, and it is confusing for ASIS to > propagate this confusion. > > The proper technical term in Ada 95 is compilation environment. I > recommend apropriate changes in ASIS terminology. Robert, I completely agree that the ASIS terminology, documentation, and, may be, even some aspects of the functionality which conver the notions of Environment and Library, require ramification. But there is another side of this coin. RM 95 uses the term "(compilation) environment" to define the legality of an Ada unit, and to impose some rules on making up the executable for an Ada program. Taking GNAT as an example, it is quite clear to say what is the Ada environment when compiler (binder or linker) is working - it has already got all its parameters (in particular, -I options), and it knows the values of all necessary environment variables, so it knows where it can look for the Ada sources (and object files) to be processed, and it what order it should perform searching for these sources. So GNAT (as a compilation system consisting on the compiler, the binder and the linker) can (and should!) use the notion of the Ada environment to check the legality (compilability) of an Ada unit, to check the consistency of a set of unit, to produce object code and to make up executables from the object files. And it definitely needs no notion of Ada Library - the notion of the Ada environment is all that it needs, and GNAT as any other Ada compilation system) deals with only one (version of the) Ada compilation environment at a time. But the question is - what is the Ada environment in the time when no one of the GNAT components (compiler-binder-linker) is working? Does the Ada Environment exist outside the Ada compiler (or, more general, Ada compilation system). If the answer is "yes", the next question is - how to define it? ASIS is not a compiler, it is of quite another kind. Its purpose is to obtain the information about Ada units. About what units? Before starting any processing of Ada units, ASIS should define two things: first, the set of unit to be considered, and second, the rules for making up the Ada environment (as defined by RM 95) from these units. In the case of GNAT it means that ASIS should be informed (by means of the corresponding parameters of the ASIS Library-level queries) which directories from the underlying file system and in what order should be considered by GNAT when it is called from inside ASIS. (in other word, all the -I options should be defined and frozen). So ASIS needs not one, but two notions - the first is the Ada environment as it is defined in RM 95, it is to be used for defining the legality (compilability) of a particular unit and for defining all the aspects of its static semantic (the final aim of ASIS), and the second is now called an ASIS Library, and it is to be used for defining the way of making up the Ada environment form something that is from the external world for ASIS. (In the case of GNAT this "external world" is a file system, in the case of some heavyweight Ada implementation it may be some database.) ASIS implementations are encouraged to be able to process several ASIS Libraries at a time, and this means that ASIS application can work with several quite different versions of the Ada environment simultaneously. So I am treating the problem you pointed out as follows: - ASIS in an interface between an ADA ENVIRONMENT and various tools requiring information from it; - ASIS (not ADA!) Library is an "internal" ASIS notion only, its purpose is to bridge the gap betveen an Ada environment and the external world; - It is quite possible to bridge this gap in different ways, connecting ASIS with the different parts of this external world. The term "ASIS Library" has two origins - RM 83 and the first ASIS (83) implementations which were developed for the heavyweight Ada compilation systems. ASIS 95 has already made a considerable progress in moving from the old, Ada-83-oriented compilation/Library model to the Ada-95-oriented model. I personally am not quite satisfied by the achieved results (too much stuff applicable only to the heavyweight compilers, too much from Ada-83). If ASIS is intended to be standardized for Ada 95, all of this definitely will require revising at least because of formal reasons. Shame on me, I have no enough resources to initiate the new round of the corresponding discussion in the ASIS WG forums right now, but I nave not given up with this idea. Sergey Rybin, ASIS-for-GNAT Project From dewar@gnat.com Sat Jan 20 15:27:26 1996 Return-Path: Date: Sat, 20 Jan 96 14:37:52 EST From: dewar@gnat.com (Robert Dewar) To: Serge.Rybin@lglsun.epfl.ch, asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com Subject: Re: Highlights of November ASISWG/ASSRG Meeting Cc: Alfred.Strohmeier@di.epfl.ch, zueff@such.srcc.msu.su Content-Length: 604 X-Lines: 11 Status: RO this is mostly a matter of thinking about things the right way. Note that there is NO SIGNIFICANT CHANGE in Ada 95 from Ada 83, only in the description. The Ada 83 RM is an as-if conceptual model, whose connection with the actual implementation is quite flexible. The GNAT compilation model is entirely consistent with the Ada 83 RM, but it takes some flexible thinking to understand that, which is why the language of Ada 95 has been changed. Similarly, it is hard for me to believe that anything in the ASIS library model is as rigid as you present. If it is, then it is plain wrong, even for Ada 83. From dewar@gnat.com Sat Jan 20 15:32:35 1996 Return-Path: Date: Sat, 20 Jan 96 14:35:39 EST From: dewar@gnat.com (Robert Dewar) To: Serge.Rybin@lglsun.epfl.ch, asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com Subject: Re: Highlights of November ASISWG/ASSRG Meeting Cc: Alfred.Strohmeier@di.epfl.ch, zueff@such.srcc.msu.su Content-Length: 397 X-Lines: 7 Status: RO a compilation environment for GNAT is simply a set of sources, nothing more, nothing less. An ASIS "library" [still a bad term, should be environment] is a set of sources, nothing more nothing less. There is of course a requirement that the set of sources be consistent in several senses, as outlined in the RM. For example, you cannot have a package body without its corresponding package spec. From Serge.Rybin@lglsun.epfl.ch Mon Jan 22 05:21:00 1996 Return-Path: Date: Mon, 22 Jan 1996 10:33:07 +0100 From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) To: asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com Subject: Re: Highlights of November ASISWG/ASSRG Meeting Cc: Alfred.Strohmeier@di.epfl.ch, zueff@such.srcc.msu.su Content-Length: 3678 X-Lines: 81 Status: RO Robert, > a compilation environment for GNAT is simply a set of sources, nothing > more, nothing less. Agreed. > An ASIS "library" [still a bad term, should be environment] Agreed > is a set of sources, nothing more nothing less. Agreed. I have no problem with defining this for ASIS-for-GNAT > > There is of course a requirement that the set of sources be consistent > in several senses, as outlined in the RM. For example, you cannot have > a package body without its corresponding package spec. But if you read the documentation of the (very important!) Asis_Compilation_Units.Semantic_Dependence_Order function from the last ASIS 95 draft ASIS 2.0.E, you may be rather surprised and, probably, angry - this function can return the unit lists containing inconsistent sets of units or the set of units having circular dependencies. I personally do not like this. And I am sure that in ASIS-for-GNAT these lists should always be empty. > this is mostly a matter of thinking about things the right way. Note that > there is NO SIGNIFICANT CHANGE in Ada 95 from Ada 83, only in the > description. The Ada 83 RM is an as-if conceptual model, whose connection > with the actual implementation is quite flexible. The GNAT compilation > model is entirely consistent with the Ada 83 RM, but it takes some flexible > thinking to understand that, which is why the language of Ada 95 has been > changed. I think the problem is that ASIS 95 is still inheriting a certain part of its terminology, conceptual model and functionality from ASIS 83, which was directly oriented on the heavyweight Ada 83 implementations which in turn directly implemented Ada 83 "as-if" model. As I understand the history of ASIS, its very first background was the concrete library systems of the Ada 83 implementations. Several months ago I initiated in the ASIS Working Group the discussion concerning the ASIS 95 Library model. My point of view was (and it is the same now), that if RM 95 did not define the notion of Library in a formal way, and if all it used for defining the overall structutre of an Ada program and the compilation process was environment, then ASIS 95 should completely follow this and it should not have any Library-oriented features it its terminology, conceptual model and functionality. But Steve Blake (Steve, corret me if I am wrong!) insisted that ASIS 95 should take into account the problems of the heavyweight Ada 95 implementations, for which ASIS could be implemented on the base of the internal structures of the heavyweight Ada Library without any processing of the Ada sources at all. I think that what we have in ASIS 95 now is some kind of compromise between the new Ada 95 environment-based compilation model and the old Ada 83 model being interpreted directly, but not in "as-if" way. Being deeply in the ASIS world and up to my ears in the ASIS-for-GNAT implementation problems, I've been thinking that this compromise is not bad as that, that it can be interpreted in a proper way for any ASIS implementation and any ASIS application. I was planning to reinitiate the discussion around the ASIS Library Model in ASIS WG forums, and your letters give me a good impact. (I do understand what could be the effect of such letters if they would be sent in the ISO technical committee responcible for ASIS standardization as the comments on the official draft of the ASIS standard). I hope other ASIS people will jount us in this discussion. > > Similarly, it is hard for me to believe that anything in the ASIS library > model is as rigid as you present. If it is, then it is plain wrong, even > for Ada 83. > Sergey Rybin, ASIS-for-GNAT Project. From Alfred.Strohmeier@di.epfl.ch Mon Jan 22 05:51:12 1996 Return-Path: Date: Mon, 22 Jan 1996 10:56:28 +0100 From: Alfred.Strohmeier@di.epfl.ch (Alfred Strohmeier) To: asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, Serge.Rybin@lglsun.epfl.ch Subject: Re: ASIS library/environment Cc: zueff@such.srcc.msu.su Content-Length: 2253 X-Lines: 72 Status: RO > From Serge.Rybin@lglsun.epfl.ch Mon Jan 22 10:33:16 1996 > Date: Mon, 22 Jan 1996 10:33:07 +0100 > From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) > To: asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, > dewar@gnat.com > Subject: Re: Highlights of November ASISWG/ASSRG Meeting > Cc: Alfred.Strohmeier@di.epfl.ch, zueff@such.srcc.msu.su > X-Sun-Charset: US-ASCII > > Robert, > > > a compilation environment for GNAT is simply a set of sources, nothing > > more, nothing less. > > Agreed. I agree too. > > > An ASIS "library" [still a bad term, should be environment] > > Agreed I agree too. > > > is a set of sources, nothing more nothing less. > > Agreed. I have no problem with defining this for ASIS-for-GNAT I agree too. > > > > > There is of course a requirement that the set of sources be consistent > > in several senses, as outlined in the RM. For example, you cannot have > > a package body without its corresponding package spec. Here I would not go too fast. I think that even for a compiler, you may want to relax some of the consistency constraints when you use the compiler in "syntax check only" mode. > > But if you read the documentation of the (very important!) > Asis_Compilation_Units.Semantic_Dependence_Order function from the > last ASIS 95 draft ASIS 2.0.E, you may be rather surprised and, > probably, angry - this function can return the unit lists containing > inconsistent sets of units or the set of units having circular > dependencies. I personally do not like this. And I am sure that in > ASIS-for-GNAT these lists should always be empty. There is certainly a need for tools helping the programmer to detect and remove circular dependencies. The same holds for "repairing" an environment: e.g. the spec of a package is gone, but the body remains. If you have a heavyweight environment "inconsistencies" can never happen WITHIN this environment. But this does not mean that any "help" would be useless: well, you may want to import in your environment a whole set of files containing Ada sources. It should be possible to "analyse" this set, e.g. by an ASIS-based tool, even if it is not entirely consistent. > ... > > Sergey Rybin, > > ASIS-for-GNAT Project. > Alfred From Serge.Rybin@lglsun.epfl.ch Mon Jan 22 06:43:34 1996 Return-Path: Date: Mon, 22 Jan 1996 11:48:01 +0100 From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) To: asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, Serge.Rybin@lglsun.epfl.ch, Alfred.Strohmeier@di.epfl.ch Subject: Re: ASIS library/environment Cc: zueff@such.srcc.msu.su Content-Length: 2504 X-Lines: 55 Status: RO > > > There is of course a requirement that the set of sources be consistent > > > in several senses, as outlined in the RM. For example, you cannot have > > > a package body without its corresponding package spec. > > Here I would not go too fast. I think that even for a compiler, > you may want to relax some of the consistency constraints when you > use the compiler in "syntax check only" mode. > > > > > But if you read the documentation of the (very important!) > > Asis_Compilation_Units.Semantic_Dependence_Order function from the > > last ASIS 95 draft ASIS 2.0.E, you may be rather surprised and, > > probably, angry - this function can return the unit lists containing > > inconsistent sets of units or the set of units having circular > > dependencies. I personally do not like this. And I am sure that in > > ASIS-for-GNAT these lists should always be empty. > > There is certainly a need for tools helping the programmer to > detect and remove circular dependencies. The same holds for > "repairing" an environment: e.g. the spec of a package is gone, > but the body remains. > > If you have a heavyweight environment "inconsistencies" can never > happen WITHIN this environment. But this does not mean that any > "help" would be useless: well, you may want to import in your > environment a whole set of files containing Ada sources. It should > be possible to "analyse" this set, e.g. by an ASIS-based tool, > even if it is not entirely consistent. > > > Sergey Rybin, > > Alfred > The problem what we really have in ASIS 95 is finding the appropriate solution which has to be based on not single, but several compromises: - lightweight and heavyweight Ada 95 implementations; - upward compatibility of ASIS-83-based applications with ASIS 95 (I think most of them are based on and were developed for the heavyweight Ada(-83) libraries; - what we can strictly define in ASIS on the base of RM 95 and what (not only from RM-95-defined Ada compilation environment, but also from the "external world" which have some relation for composing the environment) can be interesting for ASIS-based tools. And another question directly concerning GNAT. GNAT is definitely a lightweight system. But its gnatmake utility makes some REcompilations; and gnatbl checks the consistency of the set of object files with the corresponding set of source files and reports about UNCONSISTENCIES, if any. The qiestion is - how to reflect these things in ASIS terms? Sergey. From dewar@gnat.com Mon Jan 22 09:43:21 1996 Return-Path: Date: Mon, 22 Jan 96 09:04:17 EST From: dewar@gnat.com (Robert Dewar) To: Serge.Rybin@lglsun.epfl.ch, asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com Subject: Re: Highlights of November ASISWG/ASSRG Meeting Cc: Alfred.Strohmeier@di.epfl.ch, zueff@such.srcc.msu.su Content-Length: 210 X-Lines: 4 Status: RO one important point here is that the asis folks want to see this standardized by ISO, and of course ISO will not put up with any substantial deviation from the RM 95 model, so they will fail unless they adapt! From dewar@gnat.com Mon Jan 22 09:46:34 1996 Return-Path: Date: Mon, 22 Jan 96 09:08:57 EST From: dewar@gnat.com (Robert Dewar) To: Alfred.Strohmeier@di.epfl.ch, Serge.Rybin@lglsun.epfl.ch, asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com Subject: Re: ASIS library/environment Cc: zueff@such.srcc.msu.su Content-Length: 1227 X-Lines: 23 Status: RO "Here I would not go too fast. I think that even for a compiler, you may want to relax some of the consistency constraints when you use the compiler in "syntax check only" mode." This is not relevant, the issue of doing syntax check only compilations is completely idependent of the issue of the compilation environment. By definition, no illegal unit can ever be introduced into a compilation environment by language defined means. As for inconsistent units etc, yes indeed, in the GNAT environment it is impossible for there to be inconsistent units or circular dependencies, since the GNAT environment is a set of consistent sources withou any such possibilities. In fact in a heavy-weight library system, you can easily imagine something equivalent. The only way that such siuations could arise is with extra-language library manipulation, e.g. a delete unit command. Well you can easily imagine an intelligent library manager that, when a unit is deleted, immediately deletes oher units to maintain consistency. The whole business of such inconsistencies is outside the language, and should therefore be outside the official standardized ASIS, and yes, for GNAT, these are always null lists and that is the end of it. From Alfred.Strohmeier@di.epfl.ch Mon Jan 22 10:39:38 1996 Return-Path: Date: Mon, 22 Jan 1996 16:01:58 +0100 From: Alfred.Strohmeier@di.epfl.ch (Alfred Strohmeier) To: Serge.Rybin@lglsun.epfl.ch, asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com Subject: Consistency of a set of Ada sources, for ASIS Cc: zueff@such.srcc.msu.su Content-Length: 779 X-Lines: 18 Status: RO I'll try to explain again what I didn't succeed to say well in the first time. Suppose you want to provide a tool that is able to pick up a set of Ada source files, and that makes a list of the contained compilation units, by name and nature e.g. (package or subprogram, spec or body, etc.) together with their mutual dependencies. It's clearly possible to build such a tool even if the set is not an "environment", i.e. some consistency rules are not satisfied. Whether such a tool can or cannot be built on top of ASIS depends on its definition, especially in regard with consistency rules. In some way I have the feeling that ASIS could be less "stringent" here than a compiler, as it does not have to generate code (therefore my comparison with a syntax checker). Alfred From rleif@mail.cts.com Mon Jan 22 14:03:19 1996 Return-Path: Date: Mon, 22 Jan 96 10:02 PST Content-Type: text/plain; charset="us-ascii" To: dewar@gnat.com (Robert Dewar) From: rleif@mail.cts.com (Robert C. Leif, Ph.D.) Subject: Re: ASIS library/environment Cc: Alfred.Strohmeier@di.epfl.ch, Serge.Rybin@lglsun.epfl.ch, asis@sw-eng.falls-church.va.us, sblake@alsys.com (Steve Blake), colket@smtp-gw.spawar.navy.mil Content-Length: 788 X-Lines: 21 Status: RO From: Robert C. Leif, Ph.D., PMIAC, Vice President & Research Director Ada_Med, A Division of Newport Instruments 5648 Toyon Road San Diego, CA 92115-1022 Tel. & Fax (619) 582-0437 e-mail rleif@mail.cts.com Date: 22 January, 1996 To: ASIS Group Subject: ASIS 95 Although, technically, ASIS 95 is not an Annex of Ada 95, it will be a de facto annex. Therefore, it would be appropriate to have ASIS 95 include the description of the specifications for an Ada 95 library. If this results, because of a real need, in some inconsistently with the Ada 95 language manual, then so be it. The real major risk factor in the use of Ada is the present waterfall approach to maintaining the language. The hypertext versions of the Ada 95 LRM should have a link(s) to the ASIS 95 documents. From dewar@gnat.com Mon Jan 22 21:18:34 1996 Return-Path: Date: Mon, 22 Jan 96 20:26:20 EST From: dewar@gnat.com (Robert Dewar) To: dewar@gnat.com, rleif@mail.cts.com Subject: Re: ASIS library/environment Cc: Alfred.Strohmeier@di.epfl.ch, Serge.Rybin@lglsun.epfl.ch, asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, sblake@alsys.com Content-Length: 451 X-Lines: 8 Status: RO "If this results, because of a real need, in some inconsistency with the Ada 95 language, then so be it." This will be a VERY hard sell with ISO, if you want ISO standardization, you will have to have *very* good justification of this. Of course you could just make the ASIS document a technical report, but then it will not have any real status. If you want it standardized, it absolutely MUST be consistent with Ada 95, I see no other possibility. From Serge.Rybin@lglsun.epfl.ch Tue Jan 23 07:34:48 1996 Return-Path: Date: Tue, 23 Jan 1996 11:22:01 +0100 From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) To: dewar@gnat.com, rleif@mail.cts.com Subject: Re: ASIS library/environment Cc: Alfred.Strohmeier@di.epfl.ch, Serge.Rybin@lglsun.epfl.ch, asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, sblake@alsys.com Content-Length: 1754 X-Lines: 34 Status: RO > "If this results, because of a real need, in some inconsistency with the > Ada 95 language, then so be it." > > This will be a VERY hard sell with ISO, if you want ISO standardization, > you will have to have *very* good justification of this. Of course you > could just make the ASIS document a technical report, but then it will > not have any real status. If you want it standardized, it absolutely MUST > be consistent with Ada 95, I see no other possibility. I think that the situation with the notion of Library in ASIS 95 is not as bad as that. At least, the consistency of ASIS 95 with Ada 95 is now being recognized as the primary aim of the ASIS revision process, and most of the old highweight-library-oriented ASIS functionality have already been either removed or revised. I think the main problems which still exist for ASIS Libraries are: - terminology: if the GNAT folks are against using the term "Library" for ASIS *95*, then ASIS folks have to think about it (this is only an example, in fact, ASIS 95 still contains some wording in the documentation, which may be strongly criticized from the RM 95 viewpoint); - the compromise between ASIS definitions and functionality which are applicable to the lightweight and to the heavyweight Ada 95 systems. May be, we should restructure the Asis_Compilation_Unit (it is the only ASIS package which may require restructuring) and to define it as the couple of the parent package defining the functionality applicable to all Ada 95 systems and based on RM 95 only, and its child package defining the functionality applicable to the heavyweight systems only and based on some invariant of the Ada-83-defined notion of an Ada program Library. Sergey Rybin. From dewar@gnat.com Tue Jan 23 09:35:34 1996 Return-Path: Date: Tue, 23 Jan 96 08:51:01 EST From: dewar@gnat.com (Robert Dewar) To: Serge.Rybin@lglsun.epfl.ch, dewar@gnat.com, rleif@mail.cts.com Subject: Re: ASIS library/environment Cc: Alfred.Strohmeier@di.epfl.ch, asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, sblake@alsys.com Content-Length: 2639 X-Lines: 54 Status: RO Sergey said "- terminology: if the GNAT folks are against using the term "Library" for ASIS *95*, then ASIS folks have to think about it (this is only an example, in fact, ASIS 95 still contains some wording in the documentation, which may be strongly criticized from the RM 95 viewpoint);" PLEASE! I am not speaking as a "GNAT folks" in making my comments. I think the GNAT team does not have any official position on this point. I am speaking as a member of he US IO WG9 delegation, and was *specifically* reacting to the statement: "> "If this results, because of a real need, in some inconsistency with the > Ada 95 language, then so be it."" It was not me that was raising the possibility of an inconsistency here, I was just reacting to it. In fact I think the difference between light weight and heavy weight approaches (I don't like the terms, they suggest a valud judgment, since it is hard to be in favor of heavy weight solutions!) is much smaller than people seem to think. Let me reiterate, the Intermetrics and GNAT approaches to the construction of the compilation environment are entirely consistent with he Ada 83 approach. Yes, it seems like this is false, but that's because people have read chapter 10 in the Ada 83 RM too literaly, accepting an as-if conceptual model as though it were an implementation requirement. We have changed the method of description in Ada 95 to make this clearer, but there is virtually no change in the language. Sure there are adjustments to be made, particularly when ASIS tries to take into account stuff that is completely outside the language. For instance, as I underdstand it, ASIS has a notion of an inconsistent environment (library), e.g. one in which a package body exists with no corresponding package spec. Since in GNAT a compilation environment is defined by a set of consistent sources, so such an inconsistency cannot arise in GNAT. Fine, no problem, it just means that this aspect of the ASIS definition, which is in any case outside the language, does not apply in the case of GNAT. As to the term library, it does indeed seem to me foolish to use this term. The Ada 95 definition abandoned this term precisely to avoid confusion, and I would recommend that ASIS follow suite, especially since the use of the term library in the ASIS 95 context seems to be causing exactly the kind of confusion that its removal from the RM was intended to prevent. Note hat he vestiges of the term library in the RM (in particular library unit) are historical artifacts, and indeed, in retrospec are mistakes, we should have changed library unit to environment unit. From Serge.Rybin@lglsun.epfl.ch Tue Jan 23 10:15:58 1996 Return-Path: Date: Tue, 23 Jan 1996 15:31:10 +0100 From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) To: Serge.Rybin@lglsun.epfl.ch, dewar@gnat.com, rleif@mail.cts.com Subject: Re: ASIS library/environment Cc: Alfred.Strohmeier@di.epfl.ch, asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, sblake@alsys.com Content-Length: 2828 X-Lines: 58 Status: RO > Sergey said > > "- terminology: if the GNAT folks are against using the term "Library" > for ASIS *95*, then ASIS folks have to think about it (this is only > an example, in fact, ASIS 95 still contains some wording in the > documentation, which may be strongly criticized from the RM 95 > viewpoint);" > > PLEASE! I am not speaking as a "GNAT folks" in making my comments. I think > the GNAT team does not have any official position on this point. I am > speaking as a member of he US IO WG9 delegation, and was *specifically* > reacting to the statement: > > "> "If this results, because of a real need, in some inconsistency with the > > Ada 95 language, then so be it."" Robert, I am affully sorry if I was inpolite and/or inprecise in this statement. My aim was to express the idea that, during the discussion of the ASIS as a draft standart, many of the people working with GNAT (and the Intermetrics compiler) may be against the use of the notion of Library in the ASIS specification. And already this is a reason for revising the terminology. I do understand that the position of a member of ISO delegation is of another kind. Excuse me if my text was the cause of such a misunderstanding. > It was not me that was raising the possibility of an inconsistency here, I > was just reacting to it. > > In fact I think the difference between light weight and heavy weight > approaches (I don't like the terms, they suggest a valud judgment, since > it is hard to be in favor of heavy weight solutions!) is much smaller > than people seem to think. I personally completely argee with you. But the problem is that ASIS 83, following the Ada 83 compilation systems for which it was implemented, was oriented namely on the literal interpretation of the Section 10 of RM 83! So in fact ASIS 83 was an interface NOT to an Ada 83 library, but to its literal interpretation. Now the problem is that ASIS 95 is trying to achieve some compromise between lightweight Ada 95 systems and Ada 95 systems which still use the literal interpretation of the old Ada 83 notion of library. (By the way, do you know the better terms than "lightweight" and "heavyweight"?) So we have two questions: first - should ASIS 95 really try to achieve such a compromise, or should it get rid of any literal interpretation of the old library notion? And second - if the copromise should be achieved in ASIS (as in ISO standard in near future), what is the best way for it? This problem may be reformulated in other words: between what and what is ASIS an interface? One side is clear - ASIS applications. But what is another side? Compiler? Ada implementation, which can include some "library system" or which may simply process Ada sources, as GNAT does? Ada 95 compilation environment, as it is defined in RM 95? Sergey Rybin From dewar@gnat.com Tue Jan 23 11:00:38 1996 Return-Path: Date: Tue, 23 Jan 96 10:18:23 EST From: dewar@gnat.com (Robert Dewar) To: Serge.Rybin@lglsun.epfl.ch, dewar@gnat.com, rleif@mail.cts.com Subject: Re: ASIS library/environment Cc: Alfred.Strohmeier@di.epfl.ch, asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, sblake@alsys.com Content-Length: 2491 X-Lines: 49 Status: RO Sergey says "Now the problem is that ASIS 95 is trying to achieve some compromise between lightweight Ada 95 systems and Ada 95 systems which still use the literal interpretation of the old Ada 83 notion of library. (By the way, do you know the better terms than "lightweight" and "heavyweight"?) So we have two questions: first - should ASIS 95 really try to achieve such a compromise, or should it get rid of any literal interpretation of the old library notion? And second - if the copromise should be achieved in ASIS (as in ISO standard in near future), what is the best way for it?" (note: no need to apologize Sergey, it was a natural confusion, I wear many hats, it is up to me to make clear which hat I am wearing :-) This is the wrong viewpoint. ASIS 95 should be governed by the semantic concepts in the 95 RM, and should not step outside this framework. Both the so called heavy- and ligh-weight implementations are consistent with the semantics of the 95 RM, so if ASIS 95 is consisten t with these semantics also, then it will be consistent with both styles oc implementatation. This should be the orientation of he design. How about someone chooses, for the purposes of focussing further discussion, ONE item from the proposed Ada 95 design that is somehow perceived as inconsistent with the lightweight approach (I would prefer the terms source-based and library-based to replace light-weight and heavy-weight in future!) Note that the use of the term library is confusing PRECISELY because whether or not you have a library in the Ada 95 implementation is dpeendent on whether you use a non-library or library based approach for implementation. There is no such semantic concept as library in Ada 95, it is a (perfectly reasonable, but only one of several) implementation approach to reflecting the concept of compilation environment in Ada 95. If ASIS 95 uses the term library as a *semantic* concept then this causes confusion, because hen the ASIS library has nothing to do with the implementation approach in an Ada 95 compiler that is library-based. If ASIS 95 uses library in the implementation based sense, then it is far too implementation specific, and certainly should not be part of the Ada standard, which is deliberately NOT that specific. However, I am unconvinced that we have anything more than a terminology problem here, so I propose let's not focus on the use of the term library, but rather on the actual technical semantic issues involved. From Serge.Rybin@lglsun.epfl.ch Tue Jan 23 12:45:24 1996 Return-Path: Date: Tue, 23 Jan 1996 18:04:31 +0100 From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) To: Serge.Rybin@lglsun.epfl.ch, dewar@gnat.com, rleif@mail.cts.com Subject: Re: ASIS library/environment Cc: Alfred.Strohmeier@di.epfl.ch, asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, sblake@alsys.com Content-Length: 5733 X-Lines: 104 Status: RO > Sergey says > > "Now the problem is that ASIS 95 is trying to achieve some compromise > between lightweight Ada 95 systems and Ada 95 systems which still use > the literal interpretation of the old Ada 83 notion of library. (By the > way, do you know the better terms than "lightweight" and "heavyweight"?) > > So we have two questions: first - should ASIS 95 really try to achieve such > a compromise, or should it get rid of any literal interpretation of > the old library notion? And second - if the copromise should be achieved > in ASIS (as in ISO standard in near future), what is the best way for it?" > > This is the wrong viewpoint. ASIS 95 should be governed by the semantic > concepts in the 95 RM, and should not step outside this framework. This discussion is really interesting! Robert, from the very beginning of it I have been being completely agree with you - both in respect of terminology and concerning the point that ASIS 95 should be completely inside the RM 95 semantic framework. Moreover, when I initiated the previous roung of the discussion concerning ASIS Library (spring-summer 95) in ASIS forum, all my arguments were similar to your (may be, they were more technical). But some people from ASIS WG insisted, that ASIS 95 would have to take into account the problems (peculiarities?) of library-based Ada 95 systems. I found thier arguments reasonable, and now I am trying to speak for some general position of the ASIS Workind Group, as I understand it now. May be, it is not my business, but, from the other side, I wonder why other people from ASIS WG do not jount us in the discussion. And some technical problems. Firstly let's consider a source-based implementation, or, even better, let's take GNAT as an example. When you call gcc for some .ad(b/s) file, you are in the current directory, you have some value assigned to the ADA_INCLUDE_PATH environment variable, you explicitely set the "-I" GNAT options and you explicitely indicate the source of the main (in the GNAT sense) unit. So the compiler has everything it needs to create the RM-95-devined environment from the "external world" objects when it is working. (The situation for gnatbl is similar). But what is an Ada environment when neither the compiler nor binder is working? (Here we can come to even more general question: what does it mean to implement ASIS *FOR* a particular compiler? Or, may be, even the whole question is a complete nonsesse, and I should ask: what does it mean to implement ASIS for a particular Ada implementation? Or - for a particular Ada environment? (But ASIS should be able to process several ASIS Libraries (= Ada environments??) at a time) But ASIS-for-GNAT is not a compiler, and it has to know what is an environment all the time when ASIS application is working. Technically this means that it should know the ordered set of the directories in the underlying file system in which it is allowed to look for the sources of ASIS Compilation Units, and it has also to rely on the fact that this set of directories and the content of any directory from it are remaining unchanged all the time when ASIS application is working with this Library/environment. So ASIS Library for GNAT can be defined by the ordered list of "-I" GNAT options. In case of GNAT there is no reason to keep any information about ASIS Library in the time between activatings the ASIS Environment by any of ASIS applications (Otherwise we can get a library-based ASIS imlementation for the source-based GNAT compiler!). The state of the underlying file system can be changed in dozens of different ways. So it is better for any ASIS application to start from recreationg the Ada environment from the very beginning on the base of the current state of the "external world". And the only way to do this is to recompile sources and to recreate the tree output files. (Of course, we may try to reuse the tree files on the base of some binder-like approach, but it would be no more than some optimisation). And now let's consider a library-based Ada implementation. It maintains some Ada library (or some collection of libraries) which exists at every time. For such systems ASIS is traditionally implemented on the base of the internal structures of such "vendor libraries", and ASIS Library is mapped onto some vendor library (or several libraries). It is very likely that a library-based Ada system uses the literal interpretation of the Ada 83 compilation model. It is also very likely that ASIS implementation works only with vendor library structures and it never calls to a compiler! (Note also, that opposite to the source-based situation, the number of ways to change the state of the vendor library is rather limited!). So ASIS (and only ASIS) can find out that some unit sets which are processed by it, are inconsistent, and some other unit sets contain circular dependencies. And the corresponding ASIS queries may be found by some users as being rather useful, even if they have no relation at all to RM 95. (There are some other queries in the last ASIS 95 draft which have no reasonable interpretation for source-based systems, but which can be found useful for the library-based systems) That is why I am speaking about the compromise. And I would repeat my suggestion with some detalisation: - to define ASIS 95 as the _core_ ASIS and the ASIS special need annexes; - all the content of the core ASIS should be govered by the semantic concepts from RM 95; - to define the ASIS Annex for the library-based Ada systems which use the literal interpretation of the Section 10 from RM 83; - to use the notion of ASIS Library and the term "Library" only for and in this Annex. Sergey Rybin. From dewar@gnat.com Tue Jan 23 21:58:32 1996 Return-Path: Date: Tue, 23 Jan 96 21:16:41 EST From: dewar@gnat.com (Robert Dewar) To: Serge.Rybin@lglsun.epfl.ch, dewar@gnat.com, rleif@mail.cts.com Subject: Re: ASIS library/environment Cc: Alfred.Strohmeier@di.epfl.ch, asis@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, sblake@alsys.com Content-Length: 2443 X-Lines: 49 Status: RO I still see nothing that needs compromising. I really don't see a problem. That is why I asked for ONE example of a problem .... - to define the ASIS Annex for the library-based Ada systems which use the literal interpretation of the Section 10 from RM 83; there is no such thing as RM 83, you would have to COMPLETELY recreate the semantics, and frankly I think this would NEVER fly in WG9, I think you would be wasting your time (if standardization is an objective). THe point is to abstract. Remember that there is no such thing as "the literal interpretation of the section 10 from RM 83", there is only over specified incorrect interpretations. In fact most commerical Ada library systems go WELL beyond this model (consider the links in the Alsys technology for instance). I think the problems here arise from starting from the wrong semantic base (namely an ovespecific misinterpretation of chapter 10 of the 83 RM). ASIS 95 needs to be thought out in terms of the semantic model in RM 95, nothing else can possibly be viable if you want to think of the ASIS standard as an annex of the RM (of course the ASIS standard will NOT be an annex to the RM, it will be a completely separate standard, but still I cannt see it being approved unless it is totaly compati ble semantically with the 95RM -- especially when I see no technical obstacles whatsoever to such compatibility. The problem is one of proper levels of abstraction. The whole point of ASIS is to provide static semantic information about an Ada 95 program, and of course the only comprenehsible semantic information relates to semantics in the 95 RM, and it is especially important that the terminology be kept the same, so that the definitions in the 95 RM apply properly. The so-called heavy-weight implementations of the Ada compilatoin environment, as I mentioned before, I prefer library-based as a term to heavy-wieght, are completely consistent with this Ada 95 semanitc model in chapter 10 of the 95 RM (if they are not, they are wrong!) Consequently any such implementation must be entirely consistent with an ASIS 95 that is RM 95 fconformant in this sense. Sure, it may make sense to add implementation dependent features that reflect particular aspects of a particular implementation (e.g. in GNAT it is certainly useful to be able to query time stamps of source files), but such special features cannot be a part of the standardized set of features. From prine@allware.com Tue Jan 23 22:26:02 1996 Return-Path: Date: Tue, 23 Jan 1996 21:50:00 -0500 (EST) From: Gilbert Prine To: rleif@mail.cts.com Cc: serge.rybin@lglsun.epfl.ch, asis@sw-eng.falls-church.va.us Subject: Re: ASIS library/environment Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 953 X-Lines: 17 Status: RO >Although, technically, ASIS 95 is not an Annex of Ada 95, it will be a de >facto annex. Therefore, it would be appropriate to have ASIS 95 include the >description of the specifications for an Ada 95 library. If this results, >because of a real need, in some inconsistently with the Ada 95 language >manual, then so be it. The real major risk factor in the use of Ada is the >present waterfall approach to maintaining the language. The hypertext >versions of the Ada 95 LRM should have a link(s) to the ASIS 95 documents. Excellent point. Furthermore, the ongoing discussion of an Ada 95 library specification is really implementation advice to implementers who wish to develop ASIS for an Ada 95 library (environment is a weak buzz-word for communicating ASIS to the important non-Ada 95 world, even if it is language-lawyer correct). My understanding is that implementation advice can be anywhere, including a de facto ASIS Annex. Gil Prine From rleif@mail.cts.com Tue Jan 23 23:52:25 1996 Return-Path: Date: Tue, 23 Jan 96 20:20 PST Content-Type: text/plain; charset="us-ascii" To: Gilbert Prine From: rleif@mail.cts.com (Robert C. Leif, Ph.D.) Subject: Re: ASIS library/environment Cc: serge.rybin@lglsun.epfl.ch, asis@sw-eng.falls-church.va.us Content-Length: 1869 X-Lines: 36 Status: RO >>Although, technically, ASIS 95 is not an Annex of Ada 95, it will be a de >>facto annex. Therefore, it would be appropriate to have ASIS 95 include the >>description of the specifications for an Ada 95 library. If this results, >>because of a real need, in some inconsistently with the Ada 95 language >>manual, then so be it. The real major risk factor in the use of Ada is the >>present waterfall approach to maintaining the language. The hypertext >>versions of the Ada 95 LRM should have a link(s) to the ASIS 95 documents. > >Excellent point. Furthermore, the ongoing discussion of an Ada 95 >library specification is really implementation advice to implementers >who wish to develop ASIS for an Ada 95 library (environment is a weak >buzz-word for communicating ASIS to the important non-Ada 95 world, >even if it is language-lawyer correct). My understanding is that >implementation advice can be anywhere, including a de facto ASIS Annex. > To: Gil Prine et al. From: Bob Leif We are in agreement. The ASIS document can define and name an entity which performs those functions that were previously ascribed to the library. In fact, it can serve as the higher level design document for a "library". A point of rank heresy. Why should the Ada source code be pure text? The compiler must get an output which is absolutely known to the programmer. However, hypertext markup could be embedded. I want a book form that includes the source "files" and the rest of the documentation. I also want color coding. As an author who collaborates, I have found that each author gets his/her own color. This would help for code reviews etc. The border or other part of the document can show what is the compilation state of the code. I want a user friendly Ada environment. You might be amused by my little note in this month's Ada letters. Bob Leif From dewar@gnat.com Wed Jan 24 01:22:10 1996 Return-Path: Date: Wed, 24 Jan 96 00:45:29 EST From: dewar@gnat.com (Robert Dewar) To: prine@allware.com, rleif@mail.cts.com Subject: Re: ASIS library/environment Cc: asis@sw-eng.falls-church.va.us, serge.rybin@lglsun.epfl.ch Content-Length: 1283 X-Lines: 24 Status: RO Gil Prine says "Excellent point. Furthermore, the ongoing discussion of an Ada 95 library specification is really implementation advice to implementers who wish to develop ASIS for an Ada 95 library (environment is a weak buzz-word for communicating ASIS to the important non-Ada 95 world, even if it is language-lawyer correct). My understanding is that implementation advice can be anywhere, including a de facto ASIS Annex." First, the phrase ASIS annex is somewhat misleading. In no sense is any ASIS document an annex of the standard, and I am not sure you want it to be -- precisely because if it *were* an annexe, then it would be subject to much more stringent consistency requirements, which I don't think you want. It is perfectly fine of course in the ASIS standard (that is what the final document would be, not an annex of the existing standard), to have implementation advice that discusses the mapping of ASIS into various possible implementation models of compilation environments including the possible library model of implementation. Actually as far as I can tell, the Intermetrics/GNAT approach is completely equivalent to the library approach from the point of view of ASIS. I still have not seen any specific points that would make this not be the case. From dewar@gnat.com Wed Jan 24 01:28:00 1996 Return-Path: Date: Wed, 24 Jan 96 00:51:48 EST From: dewar@gnat.com (Robert Dewar) To: prine@allware.com, rleif@mail.cts.com Subject: Re: ASIS library/environment Cc: asis@sw-eng.falls-church.va.us, serge.rybin@lglsun.epfl.ch Content-Length: 451 X-Lines: 11 Status: RO Bob Leif says "The border or other part of the document can show what is the compilation state of the code. I want a user friendly Ada environment." Sure, I think everyone agrees with this, and no one said that Ada source code must be pure text. In fact the standard has NOTHING WHATSOEVER to say about the way that source programs are represented. I am not sure however what this has to do with the semantic specification of the ASIS interface. From Serge.Rybin@lglsun.epfl.ch Wed Jan 24 09:53:16 1996 Return-Path: Date: Wed, 24 Jan 1996 15:10:51 +0100 From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) To: asis@sw-eng.falls-church.va.us Subject: Re: ASIS library/environment Cc: dewar@gnat.com Content-Length: 4126 X-Lines: 111 Status: RO ----- Begin Included Message ----- >From rybin Wed Jan 24 14:35:17 1996 To: dewar@gnat.com Subject: Private note - Re: ASIS library/environment X-Sun-Charset: US-ASCII Content-Length: 1444 Robert, if you are strongly against any use of the term/notion "Library" in respect to Ada 95, what about GNAT? See ali.ads: -- This package defines the internal data structures used for representation -- of Ada Library Information (ALI) acquired from the ALI files generated -- by the front end. See also lib.ads: -- This package contains routines for accessing and outputting the library -- information. It contains the routine to load subsidiary units. with Casing; use Casing; with Table; with Types; use Types; package Lib is -------------------------------------------- -- General Approach to Library Management -- -------------------------------------------- ... As for me, all this stuff looks OK, but it uses the term "Library"... :-) Sergey Rybin P.S. I am sending this message only to you :-) P.P.S. As for the general discussion around the ASIS library/environment, I think it would be nice to examine the concrete ASIS queries working with ASIS Compilation Units (first of all, to examine their functionality, may be, without any touching the terminology and wording used in their documentation at all. This examination can be done from two different viewpoints - RM 95 and only RM 95 should be the first, and library-based Ada systems may be the second. But it would require some preparations. Do you think that this work is worth to be done? ----- End Included Message ----- ----- Begin Included Message ----- >From dewar@gnat.com Wed Jan 24 14:53:28 1996 Date: Wed, 24 Jan 96 08:45:47 EST From: dewar@gnat.com (Robert Dewar) To: Serge.Rybin@lglsun.epfl.ch, dewar@gnat.com Subject: Re: Private note - Re: ASIS library/environment Content-Length: 1576 "if you are strongly against any use of the term/notion "Library" in respect to Ada 95, what about GNAT?" You misunderstand me, as I have mentioned several times in what I have written, the term library to refer to aspects of an implementation, particularly a library-based implementation is perfectly legitimate. In fact now things are much clearer, an implementation like Rational has a library, fine, but it is no longer a technical term in the RM, so it becomes absolutely clear that it is an implementation aspect, which does no reflect any semantic term in the RM. Probably it is not the best term to choose in connection with GNAT, but it is too late now to change, and in any case, also only reflects an implementation aspect of GNAT (the rule in GNAT is not to use terms that are in the RM incorrectly, but terms like library which are not in the RM have no preloaded meaning). The problem in ASIS is that it seems that (a) for the most part the term library is in fact referring to the technical term that should be compilation environment and (b) to the extent that this is not true, it is confusing, and probably over-specified. Actually, I think the trouble is that the term library in the ASIS definition *is* referring to a technical term, library as it existed in the Ada 83 RM, but that won't do, the Ada 83 RM no longe exists in the environment in which the ASIS standardization work is being carried out. P.S. I see no reason why your note should have been private! Probably it is helpful to forward both your question and this reply to the ASIS list. ----- End Included Message ----- I am completely adreed with Robert: if ASIS 95 formally define ASIS Library (or some other word, for example, ASIS Environment would be nice for me, but it has already been being used with another meaning in ASIS) as its own technical term WITHOUT any reference in its FORMAL definition on vendor Ada libraries and WITH clear definition of the relation between ASIS Library and RM-95-defined notion of a compilation environment, it will definitely make the subject of the current discussion much more clear, and some problems may simply disappear. Sergey Rybin. From dewar@gnat.com Wed Jan 24 15:10:53 1996 Return-Path: Date: Wed, 24 Jan 96 14:23:52 EST From: dewar@gnat.com (Robert Dewar) To: Serge.Rybin@lglsun.epfl.ch, asis@sw-eng.falls-church.va.us Subject: Re: ASIS library/environment Cc: dewar@gnat.com Content-Length: 1012 X-Lines: 16 Status: RO "I am completely adreed with Robert: if ASIS 95 formally define ASIS Library (or some other word, for example, ASIS Environment would be nice for me, but it has already been being used with another meaning in ASIS) as its own technical term WITHOUT any reference in its FORMAL definition on vendor Ada libraries and WITH clear definition of the relation between ASIS Library and RM-95-defined notion of a compilation environment, it will definitely make the subject of the current discussion much more clear, and some problems may simply disappear." Of course there would have to be a sound rationale for the introduction of such a concept, and in particular, it is of course not acceptable to embed into ASIS more specific requirements than are in chapter 10 of the 95 RM. However, in the form of implementation advice and permission, it is certainly in scope for the ASIS standard to discuss how it would be mapped to various implementations including bth library based and non-library based implementations. From Serge.Rybin@lglsun.epfl.ch Thu Jan 25 07:34:49 1996 Return-Path: Date: Thu, 25 Jan 1996 10:27:25 +0100 From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) To: Serge.Rybin@lglsun.epfl.ch, asis@sw-eng.falls-church.va.us, dewar@gnat.com Subject: Re: ASIS library/environment Content-Length: 3923 X-Lines: 68 Status: RO > "I am completely adreed with Robert: if ASIS 95 formally define ASIS > Library (or some other word, for example, ASIS Environment would be > nice for me, but it has already been being used with another meaning in > ASIS) as its own technical term WITHOUT any reference in its FORMAL > definition on vendor Ada libraries and WITH clear definition of the > relation between ASIS Library and RM-95-defined notion of a compilation > environment, it will definitely make the subject of the current > discussion much more clear, and some problems may simply disappear." > > Of course there would have to be a sound rationale for the introduction > of such a concept, and in particular, it is of course not acceptable to > embed into ASIS more specific requirements than are in chapter 10 of the > 95 RM. However, in the form of implementation advice and permission, it > is certainly in scope for the ASIS standard to discuss how it would be > mapped to various implementations including bth library based and > non-library based implementations. I would like to repeat my suggestion about the ASIS Annex for the library-based Ada systems, may be, with some more details. First of all, I completely agree, that ASIS (the *core* ASIS) should be defined completely in the limits of RM 95. That means - ASIS should process only consistent environments/Libraries. If for some library-based Ada system ASIS is implemented on the base of the structures of the "vendor library system" ("persistent intermediate image"), and if it never calls to the underlying compiler to check the consistency of the unit sets making up the ASIS Library, nevertheless it has to check the consistensy by some other means and it must provide information only about and from consistent ASIS Library. But the difference between source-based and library-based Ada systems consists not only in different ASIS implementation approaches which can be covered by implementation advices and permissions included in the ASIS (draft) standard. I think that we can rely on the fact that all library-based Ada systems are based on the literal interpretation of the Ada-83-defined notion of the program library (or some interpretation of this notion can be selected as the invariant for the library-based systems). If the ASIS implementation is really based on such a data stuctures, then it IS ABLE to provide some information about compilation/recompilation order, inconsistent unit sets, curcular dependencies etc. This information is complerely outside of all what can be defined and interpreted on the base of RM 95, but it can be retrieved for library-based Ada system, it have the common background for defining the corresponding queries and interpreting its results - the literal interpretation of Ada 83 program libraries, and, finaly, it is of certain importance for the users of library-based Ada systems. So, once again, my suggestion is: - to define ASIS (as a separate standart, not RM 95 annex) namely as the interface to Ada environment, as it is defined by RM 95, this standard should be complitely conformed with RM 95, it should not use or rely on any extra-language semantic; - to define the library-based-system-oriented annex for the *core* ASIS as additional interface not to Ada Environment, but to vendor Ada libraries in library-based Ada systems. This annex would definitely use some extra-language semantic, but it would be its primary aim! It may (should?) be defined on the base of some invariant of the vendor library, if the literal interpretation of Ada 83 libraries would have beenn found too restrictive. (Comare this with RM 95 itself: the core language has no formal relation to system programming or information systems, but RM 95 contains the corresponding annexes defining some invariants which are useful in these areas); Do you think that it may be an acceptable compromise? Sergey Rybin From dewar@gnat.com Thu Jan 25 09:02:26 1996 Return-Path: Date: Thu, 25 Jan 96 08:19:30 EST From: dewar@gnat.com (Robert Dewar) To: Serge.Rybin@lglsun.epfl.ch, asis@sw-eng.falls-church.va.us, dewar@gnat.com Subject: Re: ASIS library/environment Content-Length: 8201 X-Lines: 148 Status: RO "But the difference between source-based and library-based Ada systems consists not only in different ASIS implementation approaches which can be covered by implementation advices and permissions included in the ASIS (draft) standard. I think that we can rely on the fact that all library-based Ada systems are based on the literal interpretation of the Ada-83-defined notion of the program library (or some interpretation of this notion can be selected as the invariant for the library-based systems). If the ASIS implementation is really based on such a data stuctures, then it IS ABLE to provide some information about compilation/recompilation order, inconsistent unit sets, curcular dependencies etc. This information is complerely outside of all what can be ..." I do not agree. First the models of libraries used by different vendors are very different, and are NOT literally mapped to a naive reading of chapter 10. Consider the links in Alsys technology, or the Rational subsystems. Neither of these is anything close to a literal intepretation of chapter 10. Instead you need to devise an appropriate semantic mapping. The particular items that Sergey menions (compilation/recompilation order, inconsistent unit sets, circular dependencies) are actually all suscpeitble to well defined semantic specification, and have perfectly good meaning in terms of the RM 95 semantics, and in particular can perfectly well be defined rigorously in any implementation, including source based implementations. There are certainly issues that are implementation dependent. For instance, some implementations keep obsoleted units around in the library, others do not. The idea of an obsoleted unit being around is NOT something that makes good semantic sense, but it is certainly useful to be able to extract this information. You cannot begin to define this information in a rigorous semantic sense, since exactly what is considered obsolete is very much implementatin dependent. Similarly, a broken link in the Alsys system is something you would like to know about but has no abstract semantic definition that is implementation dependent. I don't know the Rational subsystems well, but I would be surprised if there isn't some interesting information that is specific to this arrangement. As another example, the issue of multiple units of the same name being around at the same time in the library is an interesting one. Clearly neither Ada 83 nor Ada 95 can tolerate such an idea from a semantic point of view, so you can't devise a proper semantic model for such nonsense, but in some systems, this kind of situation can either arise by accident, or in at least one system (Tartan I think, but I may remember wrong) it is actually legitimate to have such a situation arise (I have no idea if this can be mapped to chapter 10 -- probably, but you would have to be inventive). The important thing is to make a very strong separation between language design and implementation. If you tried to design a language with only compiler writers focussed on the implementation involved, you end up with a big confusion between semantics and implementation models, and I think that is to some extent what is happening here. ASIS is a language, it needs to be designed with the same requirements for semantic soundness as the core language. Yes, implementation considerations are important in arriving at the semantic specification, but are typically not part of the definition itself. Sergey talks of compromise, but I see neither the need nor the desirability of compromise, because I don't see different positions that need compromising here. Let's look at some of the requirements. The ASIS design must be consistent with the Ada 95 language semantics. The ASIS design must allow implementation approaches that are consistent with permissible (and reasonable) implementation approaches for Ada 95. I can't imagine that anyone objects to either of these requirements. I certainly can't imagine ISO standardizing a final product that does not meet these two requirements. I will repeat a request I made earlier, which I still have not seen a response to. Let's see a well specified example of a semantic requirement in ASIS that is potentially troublesome from the point of view of one of the above two requirements, and analyze it carefully. I think a lot of concern has been generated here that there is some kind of conflict between the library-based and source-based approaches with respect to ASIS semantics. That is not my view. My view is that there cannot be such conflict, since both implementation approaches are entirely consistent with the Ada 95 RM. It is perfectly reasonable in the ASIS design to allow for implementation dependent queries, but ASIS itself can only provide a framework for such enquiries. It cannot specify them in any semantic detail. A good example is the framework provided in Ada 95 itself for Restrictions pragmas, and Check names, where an implementaion is free to extend in an implementation defined manner. So if a given implementation has a concept of obsoleted units, or broken links, or invalid duplicate names, or glorf-zorks, then it is fine to have a general framework in ASIS for making queries about such items. Naturally no portable ASIS tools can use such queries, but they may be useful for implementation specific tools. I think we are partly seeing a historical effect too. In the days of Ada 83 implementations, when the general understanding was that only library based implementations were around, it might have made sense to try to standardize some extra-language details of such libraries, and indeed some of the early discussions of ASIS, and some of the design work leading up to ASIS 83 was precisely in this category (resulting from coordinating decisions between at least three different library implementations: Alsys, Telesoft and Rational). Such discussions are analogous for example to the work of the Uniformity Rapporteur Group. However, in the Ada 95 world, it is much less important to do such URG style work on library based implementations, because they are no longer so universal, given that several vendors (Intermetrics, Thompson, Ada Core Technologies, TLD, SGI, ..) are avoiding library-based approaches. Yes, there are certainly library based approaches still around (Tartan, Rational, RR, OCS), and here may be some utility in the library based approaches trying to coordinate common approaches. But the scope of such uniformity-based rules is smaller, and of course less significant. If you *do* manage to find some issue that is only relevant to library based systems in general, then portable ASIS applications can't use it anyway, so the definition of such implementatoin dependent features is less important. Note that source based systems also have their own brand of specialized "zork-glorf" implementation specific data. I gave one example, which is the time stamps of the source files. Source file names is another example. There may also be some interesting uniformity issues between source-based approaches, but again, these do not have nearly so much significance, given that this is only one possible approach. The right way to me to design the ASIS semantics is to first design a core semantics that is entirely driven by the Ada 95 RM semantics, then consider hooks for implementation specific queries. I can't say I understand the current ASIS design 100%, but from what I have understood, it is not far from this, and in fact is vey close to this, but is unnecessarily confusing from a conceptual point of view. To me, quite a bit of this confusion comes from the fact that both the design andterminology seem strongly influenced by the Ada 83 concept of libraries. The redesign of the language, and the replacement of the concept of library by that of compilation environment, is a big improvement, not so much in the actual semantics of the language, which have not significantly changed, but in the comprehension and description of the abstract models that are involved in describing the compilation structure. I think ASIS should take advantage of this important improvement! Robert From Serge.Rybin@lglsun.epfl.ch Thu Jan 25 10:30:10 1996 Return-Path: Date: Thu, 25 Jan 1996 15:53:11 +0100 From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) To: Serge.Rybin@lglsun.epfl.ch, asis@sw-eng.falls-church.va.us, dewar@gnat.com Subject: Re: ASIS library/environment Content-Length: 3932 X-Lines: 87 Status: RO Oh-ho-hohjushki-ho-ho... (This is in Russian, but it cannot be translated :-) The last Robert's posting in this discussions made me to be almost ready to give up in my attempts to express dome "compromise" viewpoint on the ASIS Library Model. I still do not understand why I have been trying to do this - I was completely argee with Robert's starting point, and I myself am developing the source-based ASIS implementation for the source-based Ada system. Below are my personal conclusions from this discussion. Some of them are questions, some - suggestions. 1. I am not completely sure that we can consider ASIS ONLY as a language. I think it is a bit more - it is an INTERFACE (of course, this may be treated as a terminology problem - every language may be considered as an interface, and vice versa. If so, I am ready to consider ASIS as a formal language only, but the question would be - what is the interpretation domain for this formal language. (I am sorry, but I am not sure that it is the proper English terminology, I simply use the direct translation of the Russian terms which are usially used in this situation) ). In other words, my question is - what is an Ada compilation environment from the ASIS viewpoint? RM 95 contains requirements which define the properies of the environments - but only from compiler's and "linker's" viewpoints. Should it be explicitely required in ASIS definition that ASIS queries can retrieve information only from and about consistent environment (that is from environmen which does not contain any inconsistent unit set)? (My guess is - it should.) Should ASIS require that the content of the environment should be frozen when an ASIS application is allowed to obtain information from it? (My guess also is - it should.) 2. What does it mean - to implement ASIS for a particular Ada 95 compiler? Or the question should be asked as "What does it mean - to implement ASIS for a particular Ada 95 implementation ( = compiler + ... (what else??) )". 3. This discussion gives a good starting point for detailed revision of the current ASIS 95 draft. I am sure that if this revision will be done, both the terminology and functionality should be examined, otherwise we will get the same problems in the future. Below are some examples from ASIS 2.0.E: Package Asis: ------------ ------------------------------------------------------------------------------ -- Abstract: -- -- The Ada Semantic Interface Specification is a layered vendor-independent -- open architecture. ASIS queries and services provide a consistent interface -- to information within the Ada Program Library. Clients of ASIS are -- shielded and free from the implementation details of each Ada vendor's -- proprietary library and intermediate representations. -- ------------------------------------------------------------------------------ Package Asis_Libraries: ---------------------- ------------------------------------------------------------------------------ procedure Open (Library : in out Asis.Library); ------------------------------------------------------------------------------ -- Library - Specifies the library to open -- -- Opens the ASIS Library (which may map onto a number of vendor Ada -- libraries) using the Library's associated name and parameter values. -- ... The idea of this paragraph is to say that an ASIS Library may correspond either to one vendor Library or to several vendor libraries. How can I apply this to GNAT? Package Asis_Compilation_Unit: ----------------------------- The main question is about the Semantic_Dependence_Order query - if an Ada Library is alloved to contain only consistent unit sets, how can it return the lists of inconsistent unit. Another problem - the definition of its semantic still use the notion of recompilation. Sergey Rybin From colket@smtp-gw.spawar.navy.mil Thu Jan 25 13:19:50 1996 Return-Path: Date: Thu, 25 Jan 1996 12:23:13 -0500 From: colket@smtp-gw.spawar.navy.mil (Currie Colket) Subject: ASIS library versus environment concerns To: "ASISWG/ASISRG" , "ASIS Technical" , "Robert Leif" , "Sergey Rybin" , "Alfred Strohmeier" , "Robert Dewar" , "Michael Berens" , "Gilbert Prine" , "Roy Bell" , "John Howard" Content-Type: text/plain; charset=US-ASCII Content-Description: cc:Mail note part Content-Length: 7025 X-Lines: 116 Status: RO Dear Robert D., Robert L., Sergey, Alfred, Michael, Roy, Gil, John, and all others listening in => The amount of email generated from a minor slip is incredible. I was out of the office for a week and when I returned, my mail bin was overflowing. A slip in my use of the term "library" has stired up a considerable amount of discussion. First I apologize for the slip - I should have used the word "environment" or term "compilation environment." But in a sense, I am glad to have gotten all the responses. Two ASISWG/ASISRG meetings ago, we tried to come to grips with the definition of ASIS under the Ada 95 concept of environment and we emerged with the following definition as reported in the highlights for the meeting => > 2. The ASIS Library Model has changed to support the changes from Ada 87 > to Ada 95. Ada 87 had notions of a library, compilation/recompilation order, > and obsolete units; Ada 95 replaces these notions with an Ada environment, > semantic dependencies, and a consistent set of the supporters of a unit. > ASIS has been redefined as follows: > The Ada Semantic Interface Specification (ASIS) is an interface between > an Ada environment as defined by ISO/IEC 8652 and any tool requiring > information from this environment. An Ada environment includes valuable > semantic and syntactic information. ASIS is an open and published > callable interface which gives CASE tool and application developers > access to this information. ASIS has been designed to be independent of > underlying Ada environment implementations, thus supporting portability > of software engineering tools while relieving tool developers from > having to understand the complexities of an Ada environment's proprietary > internal representation. > Earlier ASIS definitions assumed the presence of persistent data in > a heavyweight Ada program library. The current definition has no requirement > to maintain persistent data and thus facilitates the Ada95 GNAT compiler > ASIS implementation which maintains no persistent data in the environment. Consequently our stated goal is to provide an interface to an Ada environment and NOT an Ada program library. As Ada 95 evolved from Ada 83 (Ada 87), ASIS has also evolved. As mentioned, ASISWG/ASISRG has already decided that there is no requirement to maintain persistent data to be a conforming ASIS specification. Hence there is no requirement for a "library." Consequently, the ASIS design is intended to be consistent with the Ada 95 language semantics. There are also permissible implementation approaches to Ada 95. The ASIS design provides some interfaces that are consistent with reasonable implementation approaches for Ada 95. This would be expected for any ISO standard. The goal is to provide a semantic and syntatic interface to an Ada 95 environment that is valuable and useful to tool builders. This is what ASIS is all about. If a tool builder can use ASIS to extract needed semantic information from the Ada environment fast, cheap, and easy AND if the tool is relatively portable from one Ada implementation to another then I believe ASIS has done its job. This will encourage the building of powerful tools to support the development of Ada 95 applications. Although ASIS for Ada 83 is completed and mature, ASIS for Ada 95 is still evolving. ASIS for Ada 95 is planned to become a separate ISO standard and NOT an annex to Ada 95. As we evolve to a useful interface, keep in mind that a standard, such as ASIS, represents a concensus from the Ada community; to arrive at a concensus cooperation, communication, and sometimes compromise is required. Sometimes this can be achieved over email; sometimes it is best to discuss the issues face to face. The current version of ASIS 95 is identified as Version 2.0.E. For the most part, ASIS 95 has adopted the Ada 95 Environment Model. Yes, there are currently some interfaces that require an implementor to either maintain persistent data OR compute data from sources in the Ada 95 environment. These interfaces are currently in the ASIS specification as they are viewed to be valuable to tool builders (and some are concerned that compilation units might not be legal when placed into the compilation environment [See Ada 95 RM 10.1.4, Clause 6]). It is not expected that all ASIS implementations will support every ASIS interface. Even ASIS 83 has the data decomposition interfaces which are viewed as optional. The concept of having several levels of conforming ASIS implementations has been brainstormed, but not developed. Clearly interfaces supporting permissable Ada 95 implementation approaches would fall into this category. So far there has been no attempt to identify interfaces falling into this category. As ASIS is clearly evolving, our initial concern is for the ASIS interface to provide the right interfaces to be useful to a tool builder. Later concerns will address which ones are required and which ones are permissable. [Because of the obvious interest, this might be an excellent topic for our next meeting]. I think the current people working with ASISWG/ASISRG have done an outstanding job. This is specially commendable as all working on the ASIS Standard are doing so on their own nickel. The last time money was allocated for ASIS standardization work was FY89. We have come a long way since then because we all feel we are doing something valuable and important for the Ada community. ASIS for Ada 95 is still a long way from becoming a standard. There are still lots of opportunity for others to get involved and to make a contribution to the Ada community. The opportunity to provide better interfaces to support the OO community and the safety critical community are certainly there. There may be additional interfaces useful for Ada 95 code intended for the World Wide Web. There is still plenty of time to ensure your needs are met in the standard. I encourage all with strong interests to attend the next ASISWG/ASISRG meeting in Fort Lauderdale, Florida, USA from 11-12 March 1996. More details on the meeting will be posted to the net in early to mid February. If you would like to get ont the agenda now, please let me know. v/r Currie Colket Chair ASISWG/Chair ASISRG P.S. Email is the next best way to discussing issues (outside of face to face interactions). I encourage the current discussions be continued by email. I would appreciate it if we could move these discussions from the ASIS maillist to the ASIS-technical maillist. The ASIS-technical maillist is the appropriate place to discuss these issues. To get on this maillist, send email to: asis-technical-request@sw-eng.falls-church.va.us requesting you be added; please provide snail mail info and phone numbers. ASIS Technical is included as an addressee on this email. If you only get 1 email (2 if you are an addressee), you are not on the ASIS Technical maillist. From sblake@alsys.com Thu Jan 25 19:59:07 1996 Return-Path: Date: Thu, 25 Jan 1996 15:54:10 -0800 From: sblake@alsys.com (Steve Blake @pulsar) To: Michael_S_Berens@ccmail.orl.mmc.com, Rybin@LGLSun.EPFL.CH, alfred.strohmeier@di.epfl.ch, asis-technical@sw-eng.falls-church.va.us, bell@pseserv3.magec.com, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, jhoward@sky.net, prine@allware.com, rleif@crash.cts.com Subject: Re: ASIS library versus environment concerns Content-Length: 21213 X-Lines: 455 Status: RO :Sergey writes: :"But the difference between source-based and library-based Ada systems :consists not only in different ASIS implementation approaches which can :be covered by implementation advices and permissions included in the :ASIS (draft) standard. I think that we can rely on the fact that all :library-based Ada systems are based on the literal interpretation of :the Ada-83-defined notion of the program library (or some :interpretation of this notion can be selected as the invariant for the :library-based systems). If the ASIS implementation is really based on :such a data stuctures, then it IS ABLE to provide some information :about compilation/recompilation order, inconsistent unit sets, curcular :dependencies etc. This information is complerely outside of all what :can be ..." : :Robert writes: :I do not agree. First the models of libraries used by different vendors :are very different, and are NOT literally mapped to a naive reading of :chapter 10. Consider the links in Alsys technology, or the Rational :subsystems. Neither of these is anything close to a literal intepretation :of chapter 10. Instead you need to devise an appropriate semantic mapping. : :The particular items that Sergey menions (compilation/recompilation order, :inconsistent unit sets, circular dependencies) are actually all suscpeitble :to well defined semantic specification, and have perfectly good meaning :in terms of the RM 95 semantics, and in particular can perfectly well :be defined rigorously in any implementation, including source based :implementations. : :There are certainly issues that are implementation dependent. For instance, :some implementations keep obsoleted units around in the library, others :do not. The idea of an obsoleted unit being around is NOT something that :makes good semantic sense, but it is certainly useful to be able to :extract this information. You cannot begin to define this information :in a rigorous semantic sense, since exactly what is considered obsolete :is very much implementatin dependent. Similarly, a broken link in the :Alsys system is something you would like to know about but has no :abstract semantic definition that is implementation dependent. I don't :know the Rational subsystems well, but I would be surprised if there isn't :some interesting information that is specific to this arrangement. : :As another example, the issue of multiple units of the same name being :around at the same time in the library is an interesting one. Clearly :neither Ada 83 nor Ada 95 can tolerate such an idea from a semantic point :of view, so you can't devise a proper semantic model for such nonsense, but :in some systems, this kind of situation can either arise by accident, :or in at least one system (Tartan I think, but I may remember wrong) it is :actually legitimate to have such a situation arise (I have no idea if this :can be mapped to chapter 10 -- probably, but you would have to be inventive). The issue if consistency and inconsistency is vital to understanding the intended ASIS model and to the permissions extended to Ada environments. Consistency, as defined by the RM 95, is an attribute of compilation units that is enforced at compile-time (10.1.4(5)) and later for program execution 10.2(27). Consistency is not defined for the environment. This leaves the Ada environment open to many other implementation-defined methods for creating, adding, replacing, moving, and otherwise modifying the environment. There is no requirement that an Ada 95 environment be consistent all the time, or that its compilation units are consistent. Maintaining continuous consistency, or not enforcing it, is a choice made by each Ada implementation. GNAT is perfectly free to define its environment as containing only consistent units. Tartan and others, are alowed to consider inconsistent compilation units to be part of the Ada environment if they desire. The merits of either approach are not the issue. Can we agree that the semantics of consistency are cleary defined by Ada 95 and apply to compilation units within an environment, not to the environment itself? : :The important thing is to make a very strong separation between language :design and implementation. If you tried to design a language with only :compiler writers focussed on the implementation involved, you end up with :a big confusion between semantics and implementation models, and I think :that is to some extent what is happening here. : :ASIS is a language, it needs to be designed with the same requirements :for semantic soundness as the core language. Yes, implementation :considerations are important in arriving at the semantic specification, :but are typically not part of the definition itself. : :Sergey talks of compromise, but I see neither the need nor the desirability :of compromise, because I don't see different positions that need :compromising here. Let's look at some of the requirements. Rather than compromise, we just need the right level of abstraction. : :The ASIS design must be consistent with the Ada 95 language semantics. : :The ASIS design must allow implementation approaches that are consistent :with permissible (and reasonable) implementation approaches for Ada 95. : :I can't imagine that anyone objects to either of these requirements. I :certainly can't imagine ISO standardizing a final product that does not :meet these two requirements. I agree. These are among the goals defined by the ASISWG. : :I will repeat a request I made earlier, which I still have not seen a :response to. : :Let's see a well specified example of a semantic requirement in ASIS that :is potentially troublesome from the point of view of one of the above :two requirements, and analyze it carefully. There are many places in the commentary, as Sergey correctly points out, that are still holdovers from the ASIS 83 model. These need to be cleared up, to reflect the new ASIS 95 model and Ada 95 terminology. This we can easliy accomplish. If there are operations that conflict, let's identify them and fix them. : :I think a lot of concern has been generated here that there is some kind :of conflict between the library-based and source-based approaches with :respect to ASIS semantics. That is not my view. My view is that there :cannot be such conflict, since both implementation approaches are :entirely consistent with the Ada 95 RM. : :It is perfectly reasonable in the ASIS design to allow for implementation :dependent queries, but ASIS itself can only provide a framework for such :enquiries. It cannot specify them in any semantic detail. A good example :is the framework provided in Ada 95 itself for Restrictions pragmas, :and Check names, where an implementaion is free to extend in an :implementation defined manner. : :So if a given implementation has a concept of obsoleted units, or :broken links, or invalid duplicate names, or glorf-zorks, then it is :fine to have a general framework in ASIS for making queries about :such items. Naturally no portable ASIS tools can use such queries, :but they may be useful for implementation specific tools. Appropriate abstraction in the reporting of many implementation-specific attributes of the Ada environment can help ASIS tools remain relatively portable. For ASIS to report that a unit is consistent or not, is well within the framework of Ada 95. If ASIS were to specify causes or reasons for the inconsistency(ie recompilation, deletion), then that is where it steps beyond the framework (it doen't). : :I think we are partly seeing a historical effect too. In the days of :Ada 83 implementations, when the general understanding was that only :library based implementations were around, it might have made sense :to try to standardize some extra-language details of such libraries, :and indeed some of the early discussions of ASIS, and some of the design :work leading up to ASIS 83 was precisely in this category (resulting :from coordinating decisions between at least three different library :implementations: Alsys, Telesoft and Rational). Such discussions :are analogous for example to the work of the Uniformity Rapporteur :Group. : :However, in the Ada 95 world, it is much less important to do such :URG style work on library based implementations, because they are :no longer so universal, given that several vendors (Intermetrics, :Thompson, Ada Core Technologies, TLD, SGI, ..) are avoiding :library-based approaches. : :Yes, there are certainly library based approaches still around (Tartan, :Rational, RR, OCS), and here may be some utility in the library based :approaches trying to coordinate common approaches. But the scope of :such uniformity-based rules is smaller, and of course less significant. : :If you *do* manage to find some issue that is only relevant to library :based systems in general, then portable ASIS applications can't use it :anyway, so the definition of such implementatoin dependent features is :less important. : :Note that source based systems also have their own brand of specialized :"zork-glorf" implementation specific data. I gave one example, which is :the time stamps of the source files. Source file names is another :example. There may also be some interesting uniformity issues between :source-based approaches, but again, these do not have nearly so much :significance, given that this is only one possible approach. : :The right way to me to design the ASIS semantics is to first design a :core semantics that is entirely driven by the Ada 95 RM semantics, then :consider hooks for implementation specific queries. : :I can't say I understand the current ASIS design 100%, but from what I :have understood, it is not far from this, and in fact is vey close to :this, but is unnecessarily confusing from a conceptual point of view. This has been the goal and I think we are very close. We can clear up the confusion without starting over. :To me, quite a bit of this confusion comes from the fact that both :the design andterminology seem strongly influenced by the Ada 83 :concept of libraries. The redesign of the language, and the replacement :of the concept of library by that of compilation environment, is a big :improvement, not so much in the actual semantics of the language, which :have not significantly changed, but in the comprehension and description :of the abstract models that are involved in describing the compilation :structure. I think ASIS should take advantage of this important improvement! If this will help make ASIS acceptable to users, vendors, and ISO members, then I'm all for it. One of the goals for ASIS 95 is to minimize changes and impacts on existing ASIS 83 tools. I think we can improve ASIS still without changing the abstract model and basic functionality, mainly just changing terminology. Sergey writes: : :The last Robert's posting in this discussions made me to be almost ready to :give up in my attempts to express dome "compromise" viewpoint on :the ASIS Library Model. I still do not understand why I have been trying to :do this - I was completely argee with Robert's starting point, and I :myself am developing the source-based ASIS implementation for the :source-based Ada system. : :Below are my personal conclusions from this discussion. Some of them :are questions, some - suggestions. : :1. I am not completely sure that we can consider ASIS ONLY as a : language. I think it is a bit more - it is an INTERFACE (of course, : this may be treated as a terminology problem - every language may be : considered as an interface, and vice versa. If so, I am ready to : consider ASIS as a formal language only, but the question would be - : what is the interpretation domain for this formal language. (I am : sorry, but I am not sure that it is the proper English terminology, : I simply use the direct translation of the Russian terms which are : usially used in this situation) ). In other words, my question is - : what is an Ada compilation environment from the ASIS viewpoint? RM : 95 contains requirements which define the properies of the : environments - but only from compiler's and "linker's" viewpoints. The Ada compilation environment from the ASIS viewpoint should be an abstraction of a particular compiler's and "linker's" viewpoints. The ASIS implementation can share exactly the same view and details. While not required, an ASIS implementation is most likely to be used in tandem with a particular Ada compilation system. Stand-alone ASIS implementations may exist, based on some Ada compilation system like GNAT, and they may work fine in tandem with a different Ada compilation system. There may also be insurmountable incompatibilities with some systems. : Should it be explicitely required in ASIS definition that ASIS : queries can retrieve information only from and about consistent : environment (that is from environmen which does not contain any : inconsistent unit set)? (My guess is - it should.) This should be an ASIS implementation permission rather than a restriction. If GNAT-ASIS only recognizes consistent units in the environment, then GNAT-ASIS queries that return inconsistent units will always return nil information. That is a reasonable ASIS implementation permission. It is similarly reasonable for another ASIS implementation to return a list of units that are determined to be inconsistent. How the determination is made; from persistent information or on-the-fly is an irrelavent implementation detail and should not affect the portability of the ASIS tool. The ability to further analyze inconsistent units is again an ASIS implementation permission, not a requirement. Results of queries made on inconsistent units can vary. The ASIS application is at least aware (can be and should be) that it is dealing with an inconsistent unit, and that results are risky. : Should ASIS : require that the content of the environment should be frozen when an : ASIS application is allowed to obtain information from it? (My guess : also is - it should.) Enforcing such a requirement is beyond what I would want to have to try implement. How can GNAT-ASIS possibly do this? It should suffice to state in the user guide that ASIS is intended to work with an environment that is stable. Users will take the responsibility to ensure a safe environment if they expect safe results. Should an event occur that corrupts the environment during an ASIS invocation, ASIS has a mechanism to raise an exception and provide status/diagnosis information. : :2. What does it mean - to implement ASIS for a particular Ada 95 compiler? : Or the question should be asked as "What does it mean - to implement : ASIS for a particular Ada 95 implementation ( = compiler + ... (what : else??) )". I would argue that an Ada environment is more than just a set of Ada sources. Validity of extensions (ie .ada, .ads, .spc), the semantics of time stamps, the location of source files, whether or not there are source files, are all implementation-defined specifics that define a particular Ada environment. The Ada 95 "dialect" (predefined environment, supported annexes, implementation -defined characteristics) are going to vary from one Ada 95 compilation environment to the next. So, to implement ASIS for a particular Ada 95 compiler is to allow the ASIS implementation to share intimate knowledge of the Ada implementation details. GNAT-ASIS shared such details with GNAT. Thomson's ObjectAda ASIS will share such knowledge with the ObjectAda compilation system. A stand-alone ASIS implementation may be able to share certain aspects of different compilation environments to work effectively with them. I'm somewhat skeptical but hopeful. : :3. This discussion gives a good starting point for detailed revision of the : current ASIS 95 draft. I am sure that if this revision will be done, : both the terminology and functionality should be examined, otherwise : we will get the same problems in the future. : : Below are some examples from ASIS 2.0.E: : :Package Asis: :------------ : :------------------------------------------------------------------------------ :-- Abstract: :-- :-- The Ada Semantic Interface Specification is a layered vendor-independent :-- open architecture. ASIS queries and services provide a consistent interface :-- to information within the Ada Program Library. Clients of ASIS are :-- shielded and free from the implementation details of each Ada vendor's :-- proprietary library and intermediate representations. :-- :------------------------------------------------------------------------------ This definition just has not been updated yet to match the latest ASISWG efforts. See Currie Colket's response. This is easy to change. : : :Package Asis_Libraries: :---------------------- : :------------------------------------------------------------------------------ : : procedure Open (Library : in out Asis.Library); : :------------------------------------------------------------------------------ :-- Library - Specifies the library to open :-- :-- Opens the ASIS Library (which may map onto a number of vendor Ada :-- libraries) using the Library's associated name and parameter values. :-- ... : :The idea of this paragraph is to say that an ASIS Library may correspond either :to one vendor Library or to several vendor libraries. Multiple libraries are allowed (RM 95 10.1.4(9)) but must define a single environment. Perhaps adapting the existing ASIS 95 "library" to the new term "environment" and some additional wordsmithing will clear this up. :How can I apply this to GNAT? Provide GNAT-ASIS with the same information that GNAT compiler and binder needs to define the Ada environment: >From Sergey's previous writing: >Firstly let's consider a source-based implementation, or, even better, >let's take GNAT as an example. When you call gcc for some .ad(b/s) file, >you are in the current directory, you have some value assigned to the >ADA_INCLUDE_PATH environment variable, you explicitely set the "-I" >GNAT options and you explicitely indicate the source of the main (in >the GNAT sense) unit. So the compiler has everything it needs to >create the RM-95-devined environment from the "external world" objects >when it is working. (The situation for gnatbl is similar). But what is >an Ada environment when neither the compiler nor binder is working? How to do this with ASIS (using existing ASIS library terms): (please correct me if I'm wrong, I have not used GNAT) GNAT does not explicitly "name" a library, so the default ASIS Library name could be a null string. Alternatively, the library name could be the name of the current directory or some logical name which may be just ignored by the ASIS implementation. ASIS gets the real location by evaluating the same ADA_INCLUDE_PATH environment variable to obtain the list of directories containing the sources (Is this correct?). If the "-I" options are necessary, they could be provided through the Library Parameters attribute. Similarly, indicating the source of the main unit could be done with the Library Parameters attribute (I don't think this should be necessary): ASIS_Libraries.Associate(Library => My_Lib, Name => ASIS_Libraries.Default_Name, Parameters => "-I something, -I whatever, My_Prog"); ASIS_Libraries.Open would really just need to do some verification that the GNAT environment exists or is valid. If GNAT has left some files containing useful information, perhaps those could be opened and read. : : :Package Asis_Compilation_Unit: :----------------------------- :The main question is about the Semantic_Dependence_Order query - if an :Ada Library is alloved to contain only consistent unit sets, how can it :return the lists of inconsistent unit. Another problem - the definition :of its semantic still use the notion of recompilation. GNAT-ASIS just returns nil lists of inconsistent units. That's all it has to do. I will attempt to define the semantics without using the term "recompilation". To summarize, I see the main issues as these: 1. Terminology is a problem. a) ASIS environment and ASIS library conflict with Ada 95 environment. b) Consistency, and how ASIS implementation are allowed to deal with it, needs to be well defined. c) Some commentary in the latest draft needs revision. d) What is an Ada environment? e) What does it mean for ASIS to be implemented for a particular Ada environment? f) What is a stand-alone ASIS? 2. Compromise is not necessary. ASIS can be improved by solving the terminology problem. 3. ISO standardization will require ASIS to be compatible with the semantics defined by Ada 95. Use of implementation permissions and restrictions can be use to achieve the desired form of the standard. 4. It would be nice to have better terms than heavyweight and lightweight to describe Ada 95 environments. "Source-based" and "library-based" have been suggested. Other ideas? Steve Blake Thomson Software Products From dewar@gnat.com Thu Jan 25 20:32:37 1996 Return-Path: Date: Thu, 25 Jan 96 19:41:31 EST From: dewar@gnat.com (Robert Dewar) To: Michael_S_Berens@ccmail.orl.mmc.com, Rybin@lglsun.epfl.ch, alfred.strohmeier@di.epfl.ch, asis-technical@sw-eng.falls-church.va.us, bell@pseserv3.magec.com, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, jhoward@sky.net, prine@allware.com, rleif@crash.cts.com, sblake@alsys.com Subject: Re: ASIS library versus environment concerns Content-Length: 718 X-Lines: 16 Status: RO Steve writes" "Can we agree that the semantics of consistency are cleary defined by Ada 95 and apply to compilation units within an environment, not to the environment itself?" Ah ha! this explains a great deal. Steve I think you are using environment here in an informal sense, but in fact it is a well defined technical term in Ada 95 (see RM 95 chapter 10). The whole point of an environment in the technical sense is precisely that it is a consistent semantic view, and the rules are all a bout how a compiler must maint consistency of an environment. Yes, the informal notion is an important one, especially from an implementation point of view, but let's not complicate things by misusing technical terms :-) From sblake@alsys.com Thu Jan 25 21:27:24 1996 Return-Path: Date: Thu, 25 Jan 1996 17:43:38 -0800 From: sblake@alsys.com (Steve Blake @pulsar) To: Michael_S_Berens@ccmail.orl.mmc.com, Rybin@lglsun.epfl.ch, alfred.strohmeier@di.epfl.ch, asis-technical@sw-eng.falls-church.va.us, bell@pseserv3.magec.com, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, jhoward@sky.net, prine@allware.com, rleif@crash.cts.com, sblake@alsys.com Subject: Re: ASIS library versus environment concerns X-Lines: 48 Content-Length: 2193 Status: RO Robert writes: ""Can we agree that the semantics of consistency are cleary defined by Ada 95 and apply to compilation units within an environment, not to the environment itself?" Ah ha! this explains a great deal. Steve I think you are using environment here in an informal sense, but in fact it is a well defined technical term in Ada 95 (see RM 95 chapter 10). The whole point of an environment in the technical sense is precisely that it is a consistent semantic view, and the rules are all a bout how a compiler must maint consistency of an environment. Yes, the informal notion is an important one, especially from an implementation point of view, but let's not complicate things by misusing technical terms :-)" I guess I miss completely where the RM 95 requires the compiler to maintain the consistency of an environment. Specifically, RM 95 relaxes such a requirement 10.1.4(7): "When a compilation unit that is a subunit or the body of a library unit is added to the envivonment, the implementation may remove from the environment any preexisting version of the same compilation unit. When a given compilation unit is removed from the environment, the implementation may also remove any compilation unit that depends semantically on the given one." I interpret this to mean that an implementation may choose to leave units that depend semantically on removed units in the environment. This is how TeleSoft's TeleGen2 (now OCS PowerAda) works. The compiler is the only way to add or replace units to the environment. In this implementation, one or more existing compilation units can be made inconsistent by the replacing of a preexisting unit, but the environment still meets all the technical requirements of Ada 95. The compiler is charged with maintaining the consistent semantic view at compilation-time. The binder or builder must reject a main program whose needed units are not consistent (10.2(27)). If the consistency of an environment must always be maintained, then why is this implementation requirement necessary? How is this a misuse of technical terms? Don't consider this a challenge, just a desire to get it right. Steve Blake From Alfred.Strohmeier@di.epfl.ch Fri Jan 26 04:20:14 1996 Return-Path: Date: Fri, 26 Jan 1996 09:35:38 +0100 From: Alfred.Strohmeier@di.epfl.ch (Alfred Strohmeier) To: Rybin@lglsun.epfl.ch, asis-technical@sw-eng.falls-church.va.us, dewar@gnat.com, sblake@alsys.com Subject: ASIS context versus environment Content-Length: 1891 X-Lines: 42 Status: RO > From dewar@gnat.com Fri Jan 26 01:53:35 1996 > Date: Thu, 25 Jan 96 19:41:31 EST > From: dewar@gnat.com (Robert Dewar) > To: Michael_S_Berens@ccmail.orl.mmc.com, Rybin@lglsun.epfl.ch, > alfred.strohmeier@di.epfl.ch, asis-technical@sw-eng.falls-church.va.us, > bell@pseserv3.magec.com, colket@smtp-gw.spawar.navy.mil, > dewar@gnat.com, jhoward@sky.net, prine@allware.com, > rleif@crash.cts.com, sblake@alsys.com > Subject: Re: ASIS library versus environment concerns > > Steve writes" > > "Can we agree that the semantics of consistency are cleary defined by Ada > 95 and apply to compilation units within an environment, not to the > environment itself?" > > Ah ha! this explains a great deal. Steve I think you are using > environment here in an informal sense, but in fact it is a well > defined technical term in Ada 95 (see RM 95 chapter 10). The > whole point of an environment in the technical sense is precisely > that it is a consistent semantic view, and the rules are all a bout > how a compiler must maint consistency of an environment. > > Yes, the informal notion is an important one, especially from an > implementation point of view, but let's not complicate things by > misusing technical terms :-) > I really like Steve's approach, even though we may have to adapt the terminology. I still think it may be useful to be able to build a tool on top of ASIS that can do some useful work on a compilation unit even in some cases of inconsistencies (e.g. retrieve the names of the "withed" units). So in some way an ASIS implementation should work on a "set of compilation units", that we may call a "context" (typically defined in Unix by a list of paths). Within ASIS, queries about consistency will then make sense (whereas they do not if ASIS is only defined for an environment supposed to be always consistent.) Alfred Strohmeier From dewar@gnat.com Sun Jan 28 12:23:13 1996 Return-Path: Date: Sun, 28 Jan 96 11:37:53 EST From: dewar@gnat.com (Robert Dewar) To: Michael_S_Berens@ccmail.orl.mmc.com, Rybin@lglsun.epfl.ch, alfred.strohmeier@di.epfl.ch, asis-technical@sw-eng.falls-church.va.us, bell@pseserv3.magec.com, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, jhoward@sky.net, prine@allware.com, rleif@crash.cts.com, sblake@alsys.com Subject: Re: ASIS library versus environment concerns Content-Length: 1520 X-Lines: 29 Status: RO "I interpret this to mean that an implementation may choose to leave units that depend semantically on removed units in the environment. This is how TeleSoft's TeleGen2 (now OCS PowerAda) works. The compiler is the only way to add or replace units to the environment. In this implementation, one or more existing compilation units can be made inconsistent by the replacing of a preexisting unit, but the environment still meets all the technical requirements of Ada 95. The compiler is charged with maintaining the consistent semantic view at compilation-time. The binder or builder must reject a main program whose needed units are not consistent (10.2(27)). If the consistency of an environment must always be maintained, then why is this implementation requirement necessary? How is this a misuse of technical terms? Don't consider this a challenge, just a desire to get it right." OK, fair point, yes, it certainly seems that the RM allows obsoleted units to stay around in the environment. This means that it is reasonable to have an implementation-dependent query in ASIS asking about such units. Of course, since a compiler *may* remove them from the environment, it is legitimate to always answer that there are no such units around, and of course a portable ASIS implementation cannot ever rely on the answers to such queries. I guess a lot depends on whether you think of ASIS as a mechanism for writing portable tools. If so, then the design of ASIS should minimize implementation dependent stuff. From Alfred.Strohmeier@di.epfl.ch Mon Jan 29 03:24:17 1996 Return-Path: Date: Mon, 29 Jan 1996 08:50:14 +0100 From: Alfred.Strohmeier@di.epfl.ch (Alfred Strohmeier) To: Rybin@lglsun.epfl.ch, asis-technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, sblake@alsys.com Subject: (Main) program versus software components Content-Length: 509 X-Lines: 11 Status: RO Clearly, the goal of the RM is to define the semantics of a (main) program (so you know the effects of a running program). But tools are also dealing with sets of modules. And here I see a difference between the RM and ASIS. For sure, there should be no contradiction for the semantics of a (main) program, but I also think it would be useful e.g. to relax some constraints, so ASIS can be used to build tools for sets of software components (even if they are not the environment of a main program). Alfred From Serge.Rybin@lglsun.epfl.ch Mon Jan 29 04:50:05 1996 Return-Path: Date: Mon, 29 Jan 1996 10:15:32 +0100 From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) To: Michael_S_Berens@ccmail.orl.mmc.com, Rybin@LGLSun.epfl.ch, alfred.strohmeier@di.epfl.ch, asis-technical@sw-eng.falls-church.va.us, bell@pseserv3.magec.com, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, jhoward@sky.net, prine@allware.com, rleif@crash.cts.com, sblake@alsys.com Subject: ASIS library/environment - or ASIS Context? Content-Length: 5009 X-Lines: 92 Status: RO Alfred writes: "I really like Steve's approach, even though we may have to adapt the terminology. I still think it may be useful to be able to build a tool on top of ASIS that can do some useful work on a compilation unit even in some cases of inconsistencies (e.g. retrieve the names of the "withed" units). So in some way an ASIS implementation should work on a "set of compilation units", that we may call a "context" (typically defined in Unix by a list of paths). Within ASIS, queries about consistency will then make sense (whereas they do not if ASIS is only defined for an environment supposed to be always consistent.)" What do you think about the following way of revising ASIS 95: 1. The completely NEW ASIS notion of ASIS Context is used instead of ASIS Library or ASIS/Ada compilation environment. This notion is no more then some way to identify a "set of compilation units" to be processed by ASIS/ASIS application. It has formal relation neither to Library nor to environment. The notion of consistency is not applied to it at all. 2. ASIS (namely, the Asis_Compilation_Units package) contains two group of queries for getting the compilation units from the ASIS Context. The queries from the first group can get only compilable/legal/consistent units and only consistent unit sets, their semantics are completely defined by RM 95 (and only by RM 95), they are portable and should give the same results for the same Context in any ASIS implementation. The queries from the second group can return as much from the Context as they could (but they have to return at least all the units and all the unit sets which are obtainable from the same Context by the queries from the first group). They are allowed to return illegal units and inconsistent unit sets. RM 95 is only one part of their semantic framework, the other part is implementattion-defined. They are not portable, and they should not be used by portable applications. 3. The consistency is not the attribute of the ASIS Context, it is an attribute of the ASIS way (mode) of obtaining the information from the Context. And a short rational for this suggestion: (1) It requires a rather small, strightforward and well-localized changes to be made in the current ASIS 95 specification. (2) It does not lead to any changes in the overall ASIS semantics, it means only some "reloading" of the current semantics. (3) The current ASIS functionality may be completely kept (and even extended) by the queries from the second group. (4) This approach seems (to me :-) to be more natural for ASIS: ASIS cannot control the content of the Library/environment/Context it has got to process, but it can control its own way of processing, that is why the consistency requirements should be applied not to the part of the "external world" processed by ASIS, but to ASIS itself (I mean - to the ASIS-based processing of this "external world". If an ASIS application wants consistency, portability and reliability of the information obtained from the Context, it may get what it wants, but some useful (but - definitely implementation-dependent!) information may be lost. If the application wants to get as much information as possible, it also may get it, but without any garanty concerning consistency, portability and reliability. And in any case it will be the choice of the application. (5) The approach proposed above is very similar to what we can see in a compiler. The content of the Ada compilation environment is not under the control of the compiler. The compiler does not really require the environment to be consistent, it only obtains the information from it (and from the "external world" - as the indication to a unit (units) to be compiled). Bit its own approach are completely under its control. If the part of the environment it deals with (that is, the compiled unit and all its supporters) is consistent, it "produces the code", and the way of checking the consistency as well as the properties of the "code" (as the dynamic semantic of the language) are defined by RM 95, and this case is completely in the RM 95 semantic framework. But if the unit set involved in the compilation is not consistent, the only thing that the compiler is obliged to do according to RM 95 is to produce a diagnostic message, the properties of this message and its content are not defined by RM 95, but all the compilers use some reasonable, but implementation-dependent interpretations of RM 95 to produce some reasonable, but implementation-defined error messages. In fact this suggestion is the result of analyzing the recent discussion betveen Steve, Robert and Alfred. I also have some technical comment on this discussion, but I am going to prepare them as separate message. Sergey Rybin. From Serge.Rybin@lglsun.epfl.ch Mon Jan 29 07:26:11 1996 Return-Path: Date: Mon, 29 Jan 1996 12:44:29 +0100 From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) To: Michael_S_Berens@ccmail.orl.mmc.com, Rybin@LGLSun.epfl.ch, alfred.strohmeier@di.epfl.ch, asis-technical@sw-eng.falls-church.va.us, bell@pseserv3.magec.com, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, jhoward@sky.net, prine@allware.com, rleif@crash.cts.com, sblake@alsys.com Subject: Re: ASIS library versus environment concerns Content-Length: 14321 X-Lines: 310 Status: RO This message contains some technical comments on the Steve's, Robert's and Alfred's messages about the ASIS Library/Environment problem. I prepared my comments on weekend, and now (in the current state of the discussion) some of them may seem as obsolete. I beg you pardon if this is really so. Sergey Rybin. --------------------------------------------------------------------- Steve writes: "The issue if consistency and inconsistency is vital to understanding the intended ASIS model and to the permissions extended to Ada environments. Consistency, as defined by the RM 95, is an attribute of compilation units that is enforced at compile-time (10.1.4(5)) and later for program execution 10.2(27). Consistency is not defined for the environment." Let's have a look on these paragraphs from RM 95. RM 95, 10.1.4(5): When a compilation unit is compiled, all compilation units upon which it depends semantically shall already exist in the environment; the set of these compilation units shall be consistent in the sense that the new compilation unit shall not semantically depend (directly or indirectly) on two different versions of the same compilation unit, nor on an earlier version of itself. I would say, that this paragraph can be applied only to the situation when some unit is being compiled, it says about the consistency of not the whole environment, but of the certain part of the environment, namely, of a set of unit consisting of the unit being compiled and all units upon which it depends semantically. The rest of the world (and the whole world when nothing is being compiled) may be cosistent, inconsistent and even written in C. Moreover, I would say that the notion of compilation (as an action) is no more that the synonym ovf checking the legality of a unit being "compiled" (in a sense that a unit is legal if it is consistent with all its supporters (that in turn requires all the supporters to be legal) and obeys all the "Legality Rules" specified in RM 95. By the way, here we may say about the legality checking order instead of the compilation order.). Such things as producing object files or making any changes in "persistent intermediate images" are entirely implementation-dependent, and they have no relation to language semantic at all, they relate only to the optimization of the general processing of Ada programs in Ada implementation. And now RM 10.2(27): The implementation shall ensure that all compilation units included in a partition are consistent with one another, and are legal according to the rules of the language. First of all, 10.2(27) formally is about "all compilation units included in a partition", but not about an environment, and the partition itself is defined in RM 95 without any reference to the environment. There is no special wording in RM 95, but I think that this paragraph has to be interpreted in the context of the whole subsection 10.2 and in conjunction with 10.1.4. Like 10.1.4(5), 10.2(27) may be applied also only to some part of the environment (that is, to the units explicitly assigned to a partition or needed by these units (RM 95, 10.2(2-6), if the environment is something more then a partition. Then, 10.2(27) can be applied to the partition only when some executable is being created or when the partition is being executed by some pure interpreter (if we can imagine this). But if the executable has already been created, and if it can be used independently from the original Ada units, 10.2(27) cannot be applied, and all the partition/environment may be completely destroyed, but the executable will continue to have the semantic of the legal Ada program (partition). And the last thing about partitions - the notion of a partition is intended to be applied to a program when the program is completed (See RM 96 10.2 (5): "If a library_unit_declaration is needed, then so is any corresponding library_unit_body", but ASIS should be able to obtain information about "incomplete Ada programs. I dare say that RM 95 does not give the full definitions of the notions of the environment and the consistensy OF THE ENVIRONMENT. See RM 10.1.4(1): "Each compilation unit submitted to the compiler is compiled in the context of an environment declarative_part (or simply, an environment), which is a conceptual declarative_part that forms the outermost declarative region of the context of any compilation. At run time, an environment forms the declarative_part of the body of the environment task of a partition." It defines only some properties of the environments and it says only about the consistency IN THE ENVIRONMENT. It defines the environment only in a minimal extent which is enough for its own purposes - to define the dynamic semantic of a legal Ada program. A compiler is no more than some abstraction of a unit legality checker, and the only purpose of the notion of a legal program is to give a permission to speak about the dynamiv semantic. This definitely is not enough for ASIS. ASIS purpose is to provide the information about the static semantic of X (X = ASIS Compilation Units) from Y (Y = ASIS Library). What is "static semantic" is defined in RM 95. But RM 95 does not give enough background for defining Y, and the ASIS semantic of Y depends on the ASIS semantic of X. I think that has the direct relation to what Alfred writes in his last message: "Clearly, the goal of the RM is to define the semantics of a (main) program (so you know the effects of a running program). But tools are also dealing with sets of modules. And here I see a difference between the RM and ASIS. For sure, there should be no contradiction for the semantics of a (main) program, but I also think it would be useful e.g. to relax some constraints, so ASIS can be used to build tools for sets of software components (even if they are not the environment of a main program). Steve writes: "Can we agree that the semantics of consistency are cleary defined by Ada 95 and apply to compilation units within an environment, not to the environment itself?" And Robert replies: "Ah ha! this explains a great deal. Steve I think you are using environment here in an informal sense, but in fact it is a well defined technical term in Ada 95 (see RM 95 chapter 10). The whole point of an environment in the technical sense is precisely that it is a consistent semantic view, and the rules are all a bout how a compiler must maint consistency of an environment. Yes, the informal notion is an important one, especially from an implementation point of view, but let's not complicate things by misusing technical terms :-)" I think the problem is that Steve (as well as me) has to use the notion of environment in an informal sense, because its formal sense, as it is defined in RM 95, is not applicable/suitable/enough for ASIS. But this formal sense is definitely enough for Ada compilers. Steve writes: ":Sergey talks of compromise, but I see neither the need nor the desirability :of compromise, because I don't see different positions that need :compromising here. Let's look at some of the requirements. Rather than compromise, we just need the right level of abstraction." I completely agree. Now I think the term "compromise" is not really good in a way I've used it. Steve writes: "There are many places in the commentary, as Sergey correctly points out, that are still holdovers from the ASIS 83 model. These need to be cleared up, to reflect the new ASIS 95 model and Ada 95 terminology. This we can easliy accomplish. If there are operations that conflict, let's identify them and fix them." I would definitely prefer to have a formal definition of the ASIS Library/Environmen/Context(??) TECHNICAL term before starting to do this work in a systematic way. I have a feeling that some parts of the documentation and the functionality of the ASIS packages Libraries and Compilation_Units are not so good now - but I have no technical background to prepare the corresponding comments! Steve writes: "Appropriate abstraction in the reporting of many implementation-specific attributes of the Ada environment can help ASIS tools remain relatively portable. For ASIS to report that a unit is consistent or not, is well within the framework of Ada 95. If ASIS were to specify causes or reasons for the inconsistency(ie recompilation, deletion), then that is where it steps beyond the framework (it doen't)." Let's look on the sentence "For ASIS to report that a unit is consistent or not, is well within the framework of Ada 95." through the following optics. When a compiler is invoked, it is told by somebody from the "external world" about a unit (or units) to be compiled. It has no ability to decide whether or not it is really an Ada compilation unit - it is obliged to treat its input as a unit and to start to process it. And only during the processing it is able (and also obliged!) to find out whether or not the object passed to it as its input really is an Ada unit, whether or not it is compilable, consistent with its supporters, etc. If it finds out that the unit is either illegal, orsome of its supporters is illegal, or the unit is inconsistent with its supporters, then the compiler will have to indicate the unit being compiled as illegal, as stated in RM 95 1.1.3(4). But when ASIS is asked to get some Compilation Unit from the Library(/Environment/Context), it is the only instance who decides that the indicated unit is really a unit (or, in other words, that it exists in the Library). To say that unit A is inconsistent (with its supporters, ASIS should be sure that A is the ASIS Compilation Unit. RM 95 completely defines what is a legal/consistent unit, but it does not define what is an illegal/inconsistent unit (in a way other that by "negation" of the notion of a legal/consistent unit). If a unit is inconsistent, it is illegal, and all the rest is outside the framework of RM 95. Is this a too pedantical view of a subject of the discussion? Steve writes: "One of the goals for ASIS 95 is to minimize changes and impacts on existing ASIS 83 tools. I think we can improve ASIS still without changing the abstract model and basic functionality, mainly just changing terminology." If we can implement ASIS 83 on top of ASIS 95, can we consider the problem of the upward compatibility as solved at least in general sense? Sergey writes: ": Should ASIS : require that the content of the environment should be frozen when an : ASIS application is allowed to obtain information from it? (My guess : also is - it should.) And Steve replies: "Enforcing such a requirement is beyond what I would want to have to try implement. How can GNAT-ASIS possibly do this? It should suffice to state in the user guide that ASIS is intended to work with an environment that is stable. Users will take the responsibility to ensure a safe environment if they expect safe results. Should an event occur that corrupts the environment during an ASIS invocation, ASIS has a mechanism to raise an exception and provide status/diagnosis information." In general, I agree with Steve's position (It is almost I really wanted to say, but my wording was not quite clear :-( :-) The only way to enforce such a requirement in ASIS-for-GNAT is to check and re-check the time stamps of the source files making up the ASIS Library for GNAT. (I can imagine some reasonable "approximations" of this approach, but all of them are at least too resource-consuming to be considered as practically acceptable.) But what do you think about adding a special query to Asis_Libraries. This query may check if the state of an ASIS Library is the same as when the Library got its associations (was opened?) Of cource, the meanting of "the state is the same" will be implementation-dependent. It will be the choice of an ASIS application when and how often to check the stability of the Library it is processing. Sergey asks: " :How can I apply this [the definition of Libraries.Open] to GNAT?" And Steve replies: "How to do this with ASIS (using existing ASIS library terms): (please correct me if I'm wrong, I have not used GNAT) ..." Steve, your explanations completely correspond (except some low-level technical detailsw) to the definition of an ASIS Library which I am going to implement for GNAT But your and me are deeply inside the ASIS context, and, asking this question; I try to put myself on the position of an ASIS nwcomer having only "source-based" Ada experience. Steve writes: "To summarize, I see the main issues as these: 1. Terminology is a problem. a) ASIS environment and ASIS library conflict with Ada 95 environment. b) Consistency, and how ASIS implementation are allowed to deal with it, needs to be well defined. c) Some commentary in the latest draft needs revision. d) What is an Ada environment? e) What does it mean for ASIS to be implemented for a particular Ada environment? f) What is a stand-alone ASIS? 2. Compromise is not necessary. ASIS can be improved by solving the terminology problem. 3. ISO standardization will require ASIS to be compatible with the semantics defined by Ada 95. Use of implementation permissions and restrictions can be use to achieve the desired form of the standard. 4. It would be nice to have better terms than heavyweight and lightweight to describe Ada 95 environments. "Source-based" and "library-based" have been suggested. Other ideas?" A really nice summary! I have only two remarks: (1) The formal definition of the ASIS term Library/Environment/Context(?) namely as the ASIS TECHNICAL term should be the starting point. (2) "Lightweight - source-based" and "heavyweight - library-based". I think, both variants are based on some implicit "common-sense reasonong" which should be made explicit by some explicit explanations. For me, the last variant ("source/library-based") gives a more clear hint about the nature of the corresponding Ada (and ASIS!) implemetation. What do you think about solving this problem by voting? From dewar@gnat.com Mon Jan 29 07:44:34 1996 Return-Path: Date: Mon, 29 Jan 96 07:08:07 EST From: dewar@gnat.com (Robert Dewar) To: Alfred.Strohmeier@di.epfl.ch, Rybin@lglsun.epfl.ch, asis-technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil, dewar@gnat.com, sblake@alsys.com Subject: Re: (Main) program versus software components Content-Length: 745 X-Lines: 15 Status: RO Alfred said "Clearly, the goal of the RM is to define the semantics of a (main) program (so you know the effects of a running program). But tools are also dealing with sets of modules. And here I see a difference between the RM and ASIS. For sure, there should be no contradiction for the semantics of a (main) program, but I also think it would be useful e.g. to relax some constraints, so ASIS can be used to build tools for sets of software components (even if they are not the environment of a main program)." Actually, the RM defines the concept of compilation environment independently of main programs, an environment is a collection of units with zero or more that are suitable for use as main programs, so there is no conflict here. From sblake@alsys.com Thu Feb 1 21:31:13 1996 Return-Path: Date: Thu, 1 Feb 1996 17:53:32 -0800 From: sblake@alsys.com (Steve Blake @pulsar) To: asis-technical@sw-eng.falls-church.va.us Subject: Re: ASIS library/environment, continued Content-Length: 30231 X-Lines: 655 Status: RO Here are some responses to a collection of recent discussion topics. :Robert: : :This means that it is reasonable to have an implementation-dependent :query in ASIS asking about such units. Of course, since a compiler :*may* remove them from the environment, it is legitimate to always :answer that there are no such units around, and of course a portable :ASIS implementation cannot ever rely on the answers to such queries. : :I guess a lot depends on whether you think of ASIS as a mechanism for :writing portable tools. If so, then the design of ASIS should minimize :implementation dependent stuff. : We want portable ASIS applications to be able to rely on results of certain ASIS queries that can be answered differently by various ASIS implementations. If an ASIS tool receives compilation units from a query's inconsistent list, then it can rely on the fact that those compilation units are inconsistent. I cannot rely on analyzing those units with meaningful results, and this is where the reliability guarantee should end as far as ASIS is concerned. : :Alfred: : :Clearly, the goal of the RM is to define the semantics of a :(main) program (so you know the effects of a running program). :But tools are also dealing with sets of modules. And here I see a :difference between the RM and ASIS. For sure, there should be no :contradiction for the semantics of a (main) program, but I also :think it would be useful e.g. to relax some constraints, so ASIS :can be used to build tools for sets of software components (even :if they are not the environment of a main program). : :Robert: : :Actually, the RM defines the concept of compilation environment :independently of main programs, an environment is a collection of :units with zero or more that are suitable for use as main programs, :so there is no conflict here. These are both good points. ASIS provides information about both the compile-time environment and the "link time" and "run time" environment. (RM 10(3)). Perhaps we can look at ASIS as being an interface to an Ada environment at any point in time except when it is being modified (ie, when a compilation tool (compiler, binder, formatter, optimizer, etc) is modifying it). An ASIS tool can make queries before or after compilations, and before or after programs are created. ASIS must be useful to be successful. So the problem is to find a way to define its operations in a way that can be acceptable to the ISO, and yet address implementation permissions whose possibilities are beyond the formal descriptions of Ada 95. :Sergey: : :What do you think about the following way of revising ASIS 95: : :1. The completely NEW ASIS notion of ASIS Context is used instead of : ASIS Library or ASIS/Ada compilation environment. This notion is no : more then some way to identify a "set of compilation units" to be : processed by ASIS/ASIS application. It has formal relation : neither to Library nor to environment. The notion of consistency is : not applied to it at all. It must relate somehow to the Ada environment, otherwise how will the set of units be determined? : :2. ASIS (namely, the Asis_Compilation_Units package) contains two group : of queries for getting the compilation units from the ASIS Context. : The queries from the first group can get only : compilable/legal/consistent units and only consistent unit sets, : their semantics are completely defined by RM 95 (and only by RM 95), : they are portable and should give the same results for the same : Context in any ASIS implementation. The queries from the second : group can return as much from the Context as they could (but they : have to return at least all the units and all the unit sets which : are obtainable from the same Context by the queries from the first : group). They are allowed to return illegal units and inconsistent : unit sets. RM 95 is only one part of their semantic framework, the : other part is implementattion-defined. They are not portable, and : they should not be used by portable applications. The notion of consistency can be hidden or abstracted away in many ways without changing the existing ASIS functional model. : :3. The consistency is not the attribute of the ASIS Context, it is an : attribute of the ASIS way (mode) of obtaining the information from : the Context. : Consistency is not the attribute of anything except dependence between units. This dependence is formally defined by Ada 95. If we try to make consistency an ASIS defined paradigm, I think we will be heading for trouble. :And a short rational for this suggestion: : :(1) It requires a rather small, strightforward and well-localized changes : to be made in the current ASIS 95 specification. : :(2) It does not lead to any changes in the overall ASIS semantics, it means : only some "reloading" of the current semantics. : :(3) The current ASIS functionality may be completely kept (and even : extended) by the queries from the second group. ASISWG has defined a toolkit layer as a place for such extensions. : :(4) This approach seems (to me :-) to be more natural for ASIS: ASIS cannot : control the content of the Library/environment/Context it has got to : process, but it can control its own way of processing, that is why the : consistency requirements should be applied not to the part of the "external : world" processed by ASIS, but to ASIS itself (I mean - to the ASIS-based : processing of this "external world". ASIS defines (or can be clarified to define) implementation permissions such that each ASIS implementation can choose to support only consistent units, or both consistent and inconsistent units. So each ASIS implementation clearly can control its own way of processing the Ada environment. : : If an ASIS application wants consistency, portability and : reliability of the information obtained from the Context, it may : get what it wants, but some useful (but - definitely : implementation-dependent!) information may be lost. If the : application wants to get as much information as possible, it also : may get it, but without any garanty concerning consistency, : portability and reliability. And in any case it will be the choice : of the application. We have this capability now. : :(5) The approach proposed above is very similar to what we can see in a : compiler. The content of the Ada compilation environment is not : under the control of the compiler. The compiler does not really : require the environment to be consistent, it only obtains the : information from it (and from the "external world" - as the : indication to a unit (units) to be compiled). Bit its own approach : are completely under its control. If the part of the environment it : deals with (that is, the compiled unit and all its supporters) is : consistent, it "produces the code", and the way of checking the : consistency as well as the properties of the "code" (as the dynamic : semantic of the language) are defined by RM 95, and this case is : completely in the RM 95 semantic framework. But if the unit set : involved in the compilation is not consistent, the only thing that : the compiler is obliged to do according to RM 95 is to produce a : diagnostic message, the properties of this message and its content : are not defined by RM 95, but all the compilers use some : reasonable, but implementation-dependent interpretations of RM 95 : to produce some reasonable, but implementation-defined error : messages. : An ASIS implementation can work much the same way. An ASIS implementation can share the same unit management services as the compiler (ie. fetch units, check time stamps, etc). If units are consistent, ASIS can "produce the answer" to the query. If a unit set is not consistent, ASIS is obliged to either ignore them, or include them in the inconsistent list of the dependence queries. There are no requirements for ASIS implementations to support semantic or syntactic queries made on units that are inconsistent. Some queries might easliy be supported for inconsistent units, for example, ASIS_Compialtion_Units.Name. But also, ASIS_FAILED can be raised if the argument or result is an inconsistent unit. (This needs to be documented). : : :Steve writes: : :"The issue if consistency and inconsistency is vital to understanding the : intended ASIS model and to the permissions extended to Ada environments. : Consistency, as defined by the RM 95, is an attribute of compilation units : that is enforced at compile-time (10.1.4(5)) and later for program execution : 10.2(27). Consistency is not defined for the environment." : :Let's have a look on these paragraphs from RM 95. : :RM 95, 10.1.4(5): : : When a compilation unit is compiled, all compilation units upon which it : depends semantically shall already exist in the environment; the set of : these compilation units shall be consistent in the sense that the new : compilation unit shall not semantically depend (directly or indirectly) on : two different versions of the same compilation unit, nor on an earlier : version of itself. : : :I would say, that this paragraph can be applied only to the situation :when some unit is being compiled, it says about the consistency of not :the whole environment, but of the certain part of the environment, :namely, of a set of unit consisting of the unit being compiled and all :units upon which it depends semantically. The rest of the world (and :the whole world when nothing is being compiled) may be cosistent, :inconsistent and even written in C. Agreed, the compiler only cares that about the supporters (ASIS term) of the unit being compiled. This is the compile time environment. : :Moreover, I would say that the notion of compilation (as an action) is :no more that the synonym ovf checking the legality of a unit being :"compiled" (in a sense that a unit is legal if it is consistent with :all its supporters (that in turn requires all the supporters to be :legal) and obeys all the "Legality Rules" specified in RM 95. By the :way, here we may say about the legality checking order instead of the :compilation order.). Such things as producing object files or making :any changes in "persistent intermediate images" are entirely :implementation-dependent, and they have no relation to language :semantic at all, they relate only to the optimization of the general :processing of Ada programs in Ada implementation. Right. : :And now RM 10.2(27): : : The implementation shall ensure that all compilation units included in a : partition are consistent with one another, and are legal according to the : rules of the language. : :First of all, 10.2(27) formally is about "all compilation units :included in a partition", but not about an environment, and the :partition itself is defined in RM 95 without any reference to the :environment. A partition (program) executes in the context of an environment task that implicitly forms the environment declarative_part. (10.2(8)). This run-time environment shares the same declarative_part as the compile time environment, at least ASIS needs to operate under that assumption. : :There is no special wording in RM 95, but I think that this paragraph :has to be interpreted in the context of the whole subsection 10.2 and :in conjunction with 10.1.4. Like 10.1.4(5), 10.2(27) may be applied :also only to some part of the environment (that is, to the units :explicitly assigned to a partition or needed by these units (RM 95, :10.2(2-6), if the environment is something more then a partition. Then, :10.2(27) can be applied to the partition only when some executable is :being created or when the partition is being executed by some pure :interpreter (if we can imagine this). But if the executable has already :been created, and if it can be used independently from the original Ada :units, 10.2(27) cannot be applied, and all the partition/environment :may be completely destroyed, but the executable will continue to have :the semantic of the legal Ada program (partition). And the last thing :about partitions - the notion of a partition is intended to be applied :to a program when the program is completed (See RM 96 10.2 (5): "If a :library_unit_declaration is needed, then so is any corresponding :library_unit_body", but ASIS should be able to obtain information about :"incomplete Ada programs. The executable runs as part of the environment task, so even if you remove parts of the Ada environment only assiciated with the compile time environment (ie, sources, persistent info, ALI files, whatever...), the anonymous implicit run time environment remains with the executable partition. Such removal would severly cripple ASIS which will rely on the overall compile time and run time Ada environment to produce static semantic information dealing with the program execution view, ie elaboration order. : :I dare say that RM 95 does not give the full definitions of the notions :of the environment and the consistensy OF THE ENVIRONMENT. See RM :10.1.4(1): : : "Each compilation unit submitted to the compiler is compiled in : the context of an environment declarative_part (or simply, an : environment), which is a conceptual declarative_part that forms : the outermost declarative region of the context of any : compilation. At run time, an environment forms the : declarative_part of the body of the environment task of a : partition." : :It defines only some properties of the environments and it says only :about the consistency IN THE ENVIRONMENT. It defines the environment :only in a minimal extent which is enough for its own purposes - to :define the dynamic semantic of a legal Ada program. A compiler is no :more than some abstraction of a unit legality checker, and the only :purpose of the notion of a legal program is to give a permission to :speak about the dynamiv semantic. Agreed. : :This definitely is not enough for ASIS. ASIS purpose is to provide the :information about the static semantic of X (X = ASIS Compilation Units) :from Y (Y = ASIS Library). What is "static semantic" is defined in RM 95. :But RM 95 does not give enough background for defining Y, and the ASIS :semantic of Y depends on the ASIS semantic of X. : If ASIS can be defined to address the overall compile time and run time Ada environment, as defined in 10.1 and 10.2, then that will be enough. : :Steve writes: : :"There are many places in the commentary, as Sergey correctly points out, : that are still holdovers from the ASIS 83 model. These need to be cleared : up, to reflect the new ASIS 95 model and Ada 95 terminology. This we can : easliy accomplish. : : If there are operations that conflict, let's identify them and fix them." : :I would definitely prefer to have a formal definition of the ASIS :Library/Environmen/Context(??) TECHNICAL term before starting to do :this work in a systematic way. I have a feeling that some parts of the :documentation and the functionality of the ASIS packages Libraries and :Compilation_Units are not so good now - but I have no technical :background to prepare the corresponding comments! : This can be done. : :Steve writes: : :"Appropriate abstraction in the reporting of many implementation-specific : attributes of the Ada environment can help ASIS tools remain relatively : portable. For ASIS to report that a unit is consistent or not, is well : within the framework of Ada 95. If ASIS were to specify causes or reasons : for the inconsistency(ie recompilation, deletion), then that is where it : steps beyond the framework (it doen't)." : :Let's look on the sentence "For ASIS to report that a unit is :consistent or not, is well within the framework of Ada 95." through the :following optics. When a compiler is invoked, it is told by somebody :from the "external world" about a unit (or units) to be compiled. It :has no ability to decide whether or not it is really an Ada compilation :unit - it is obliged to treat its input as a unit and to start to :process it. And only during the processing it is able (and also :obliged!) to find out whether or not the object passed to it as its :input really is an Ada unit, whether or not it is compilable, :consistent with its supporters, etc. If it finds out that the unit is :either illegal, orsome of its supporters is illegal, or the unit is :inconsistent with its supporters, then the compiler will have to :indicate the unit being compiled as illegal, as stated in RM 95 :1.1.3(4). : :But when ASIS is asked to get some Compilation Unit from the :Library(/Environment/Context), it is the only instance who decides that :the indicated unit is really a unit (or, in other words, that it exists :in the Library). To say that unit A is inconsistent (with its :supporters, ASIS should be sure that A is the ASIS Compilation Unit. RM :95 completely defines what is a legal/consistent unit, but it does not :define what is an illegal/inconsistent unit (in a way other that by :"negation" of the notion of a legal/consistent unit). If a unit is :inconsistent, it is illegal, and all the rest is outside the framework :of RM 95. : :Is this a too pedantical view of a subject of the discussion? Yes, in the sense that an ASIS implementation is free to use (and I would hope it would) the same services, or results of those services, the compiler and binder/linker uses to determine legality and consistency. This is what is meant by an ASIS implementation for a particular compilation system. Let's look at how ASIS compilation units are retrieved and when units are inconsistent. There are two methods to retrieve units: 1. Through the set of queries that provide either a list of unit declarations or bodies, or a single declaration or body by name. With this method, ASIS provides one or more units with no implied semantic dependence or relation to each other. If the units of the Ada environment are always kept consistent, like GNAT does, then only consistent units will ever be returned. If the Ada environment allows inconsistent units, then ASIS may return these inconsistent units, perhaps intermixed in a list with consistent units. Alternatively, ASIS may choose to weed the inconsistent units out of the list. This is an implementation permission. It is not a requirement because it may be prohibitively expensive to require an ASIS implementation to check the consistency of all units in the environment. Obtaining lists of unit this way is not the recommended way to analyze a subsystem, program, or partition. This can be documented as an application note. 2. Through the two unit dependence queries Semantic_Dependence_Order or Elaboration_Order. With this method, ASIS provides one or more units with semantic dependence determined by an explicit relation to each other. If the units of the Ada environment are always kept consistent, like GNAT does, then only the consistent units, and possibly the missing units lists will ever contain units. The inconsistent and circular units lists will always be empty. If the Ada environment allows inconsistent units, then ASIS may return these inconsistent units in the inconsistent units list, and possibly in the circular units list. Alternatively, ASIS may choose to weed the inconsistent units out of the list, and return them as missing units. This is also an implementation permission. This is the recommended way to analyze related units, because the ASIS tools can easily recognize consistent, inconsistent, missing, and circular units, and can choose to deal with them accordingly. I'm sure this is not clearly documented in ASIS 2.0.E. I'm writing it here in hopes that we can discuss it, and come to an agreement, and then add it to the next version. :Steve writes: : :"One of the goals for ASIS 95 is to minimize changes and impacts on existing : ASIS 83 tools. I think we can improve ASIS still without changing the abstract : model and basic functionality, mainly just changing terminology." : :If we can implement ASIS 83 on top of ASIS 95, can we consider the problem :of the upward compatibility as solved at least in general sense? This is more of a conceptual proof than anything else. I doubt it anyone will actually do this implementation. : : :Sergey writes: : :The only way to enforce such a requirement in ASIS-for-GNAT is to check :and re-check the time stamps of the source files making up the ASIS :Library for GNAT. (I can imagine some reasonable "approximations" of :this approach, but all of them are at least too resource-consuming to :be considered as practically acceptable.) : :But what do you think about adding a special query to Asis_Libraries. :This query may check if the state of an ASIS Library is the same as :when the Library got its associations (was opened?) Of cource, the :meanting of "the state is the same" will be implementation-dependent. :It will be the choice of an ASIS application when and how often to :check the stability of the Library it is processing. I just don't think this is a good idea. This is a solution for which there is really no problem. It is reasonable to place the burden of ensuring a stable environment firmly with the users. : : : : :(1) The formal definition of the ASIS term Library/Environment/Context(?) : namely as the ASIS TECHNICAL term should be the starting point. Yes, let's work on this. : :(2) "Lightweight - source-based" and "heavyweight - library-based". I think, : both variants are based on some implicit "common-sense reasonong" which : should be made explicit by some explicit explanations. For me, the last : variant ("source/library-based") gives a more clear hint about the : nature of the corresponding Ada (and ASIS!) implemetation. : What do you think about solving this problem by voting? : I'd really like to see us all do away with attempts to classify Ada implementations this way. With a little imagination, all these terms can be applied to all the existing Ada implementations I'm aware of. We can't possibly predict future implementations that might be "middleweight", source-library based, etc. ASIS simply needs to define an abstraction with implementation permissions and requirements that are fair and reasonable to all, and I think we are very close to that goal functionally. Terminology and documentation is where most remaining work needs to be done. : : : : :> Serge Rybin :> :> > Me (Roy Bell) :> > :> > If we can agree that ASIS facilities will be invoked from an environment :> > that supports directories and files I think there is a reasonable :> > solution to the controversy surrounding libraries and environments. I :> > am only familiar with the Ada 83 versions of ASIS for Rational and :> > Alsys, but I believe that the following statements should apply to the :> > GNAT version as well. :> :> Almost all you have said can be applied to the ASIS implementation for :> GNAT. But you propose the approach for implementing ASIS in the :> source-based environment, when the controversy is around the ASIS :> definition and conceptual model. : :I guess I don't understand the difference. ASIS must be careful not to force only implementations on environments that support directories and files. : :> :> > After I invoke the ASIS.Initialize operation I have to invoke the :> > ASIS.Associate operation. One of the parameters of the Associate :> > operation is the name of the "library", but in actuality I provide the :> > name of a directory. Both Rational and Alsys keep special stuff in :> > their directories, but they are just a directory. I get an error if I :> > provide the name of a directory that doesn't have the special stuff in :> > it. Perhaps GNAT doesn't need any special stuff in its directories. :> You provide the name of a directory because that is meaningful for your particular ASIS/Ada implementation. That is how the library is "named". There is no Ada 95 requirement that an Ada environment have anything to do with a directory. To assume such in your ASIS application, breaks the ASIS abstraction, and renders your tool unportable. This is not necessarily a bad thing, it's simply your choice. :> The fundamental GNAT principle is that the source code is the :> ultimate indicator of the status of your program. So in some sense GNAT :> processes only sources and produces only object files. There is :> neither cetntalized nor distributed library information produced and :> (re)used by GNAT itself. I don't want to be argumentative here, but I guess I don't understand why GNAT does not boast of supporting a powerful, flexible, muti-library environment. Why not? It supports definition of multiple ordered "directories" containing the sources, creates ALI files with dependency information, and optionally saves persistent information. Yet GNAT and other "lightweight" implementations promote the notion that they don't have an Ada library. Is this a marketing decision? Personally, I love the GNAT and Intermetrics "lightweight" models. I just don't understand why "library" has become such a bad word. Ada 95 suggests implementations can have a program library, even multiple libraries. Yet we claim we don't have them, but document environment variable, options, tools and other constructs to essentially provide the environment to the compilers. If we would just all 'fess up, it would make things much easier for ASIS. : :I agree that the source code should be the ultimate indicator of the :status of a program. The status of a program is only one of the things :I would like to know about the contents of a directory. I may have :introduce several complete programs into the same directory. I would :like to get the status of them all at the same time. I also may have a :directory full of reusable components. The application programs that :uses these components exist in another directory. As the Reuse :Coordinator for my project I find that many times I want to focus on the :reuse components as a collection and defer the study of the application :software to someone else. : ... : :> :> > We do not have to place all of our Ada units in the same location. :> > Rational, Alsys, and GNAT provide a way for us to gain visibility to Ada :> > units that have previously been "inserted" into an "environment" located :> > at some other location in the directory structure. I think that it :> > would be a nice addition for ASIS to give us the ability to obtain the :> > subset of Ada units that are physically located in the directory that I :> > have named. :> :> I do not know some other way to define an *ASIS* Library for GNAT other :> then to define the ordered set of directories with Ada sources. But it is :> an *implementation* decision/principle. Do you suggest to extend the :> ASIS semantic by the corresponding implementation-independent feature? : :Yes, this is exactly what I am suggesting. All compiler implementers :(including GNAT) keep their stuff in directories. An Ada program uses :Ada units found in an ordered set of directories as you put it. : We must be careful not to expect this of all Ada implementations. :> :> And another thing about ASIS-for-GNAT. ASIS Library has to contain all :> the predefined Ada stuff. Even if you indicate only one directory as :> making up the ASIS Library, ASIS-for-GNAT will use the current value of :> the ADA_UNCLUDE_PATH environment variable as (implicit) indication to :> add to your directory the directory containing the sources of the Ada :> predefined units and the GNAT Run-Time Library (RTL). And if you use :> the corresponding ASIS query to get the overall content of the Library, :> you will get the content of your directory PLUS all the predefined :> units PLUS RTL. So what do you think about the special ASIS query (or a :> special option in the existing queries) for obtaining only the :> "user-defined" content of the ASIS Libtary? (It also would be the :> natural and effective solution for the "directory content" problem in :> case of GNAT.) :> : :Great! I like both suggestions. The first being: give me the subset :of units that physically exist in the directory I have provided in the :name parameter of the associate routine. The second was something that :we used to be able to do with the old Rational LRM interfaces because :they provided a way to ignore predefined packages. You are describing an important and desired capability. The Unit_Origins type and Unit_Origin query currently attempt to answer it. However, we discussed some limitations in the design that would be nice to overcome. This distinction only maps to kinds of units, not which directories they come from. This is still an issue or action item within the ASISWG. I only disagree with the suggestion that ASIS expose directories as an implementation detail. Comments regarding alternatives are welcome. : : : :Sergey: :There are at least two probles here: : :1. If ASIS is defined completely in RM 95 semantic framework, what can it : say about illegal units and/or inconsistent unit sets, which are : outside the RM 95 semantic framework? : :2. All the implementation problems will grow up considerably (at least in : case of ASIS-for-GNAT), if ASIS-for-GNAT would try to say about the : illegal unit even a bit more that it is illegal. : : :So we have two suggestions to be considered for ASIS 95: : :- to operate with directories in order to structurize an ASIS : Library/Environment/Context; : :- to provide the ability to obtain only "user-defined" content of the : Library/Environment/Context (or of its part selected by means of ASIS : Directories); : I think there could be capability added to ASIS at the right abstract level to effectively provide the capability desired. I have some ideas and will propose them soon. Steve Blake From bell@pseserv3.fw.hac.com Mon Feb 5 11:43:13 1996 Return-Path: From: "Roy M. Bell" Subject: Re: ASIS library/environment, continued To: asis-technical@sw-eng.falls-church.va.us Date: Mon, 5 Feb 96 7:27:56 EST Cc: sat@pseserv3.fw.hac.com Mailer: Elm [revision: 70.85] Content-Length: 4636 X-Lines: 106 Status: RO > Steve Blake > > ASIS must be careful not to force only implementations on environments that > support directories and files. Why? What potential users would we be shuting out? > > I don't want to be argumentative here, but I guess I don't understand why > GNAT does not boast of supporting a powerful, flexible, muti-library > environment. Why not? It supports definition of multiple ordered > "directories" containing the sources, creates ALI files with dependency > information, and optionally saves persistent information. Yet GNAT and other > "lightweight" implementations promote the notion that they don't have an Ada > library. Is this a marketing decision? > > Personally, I love the GNAT and Intermetrics "lightweight" models. I just > don't understand why "library" has become such a bad word. Ada 95 suggests > implementations can have a program library, even multiple libraries. Yet we > claim we don't have them, but document environment variable, options, tools > and other constructs to essentially provide the environment to the > compilers. > > If we would just all 'fess up, it would make things much easier for ASIS. Why are the terms lightweight/heavyweight perferred over persistent? > :> Serge Rybin > :> > :> I do not know some other way to define an *ASIS* Library for GNAT other > :> then to define the ordered set of directories with Ada sources. But it is > :> an *implementation* decision/principle. Do you suggest to extend the > :> ASIS semantic by the corresponding implementation-independent feature? > :Me (Roy Bell) > : > :Yes, this is exactly what I am suggesting. All compiler implementers > :(including GNAT) keep their stuff in directories. An Ada program uses > :Ada units found in an ordered set of directories as you put it. > : > > We must be careful not to expect this of all Ada implementations. All compilation environments have to provide a way to partition the Ada units into multiple locations. Vendors of Ada 95 products can't think of skimping on this feature because (I am happy to say) there are too many predefined Ada units provided with Ada 95 for vendors to consider othewise. It appears that both Serge and I believe that this is an implementation-independent feature. > > :> > :> And another thing about ASIS-for-GNAT. ASIS Library has to contain all > :> the predefined Ada stuff. Even if you indicate only one directory as > :> making up the ASIS Library, ASIS-for-GNAT will use the current value of > :> the ADA_UNCLUDE_PATH environment variable as (implicit) indication to > :> add to your directory the directory containing the sources of the Ada > :> predefined units and the GNAT Run-Time Library (RTL). And if you use > :> the corresponding ASIS query to get the overall content of the Library, > :> you will get the content of your directory PLUS all the predefined > :> units PLUS RTL. So what do you think about the special ASIS query (or a > :> special option in the existing queries) for obtaining only the > :> "user-defined" content of the ASIS Libtary? (It also would be the > :> natural and effective solution for the "directory content" problem in > :> case of GNAT.) > :> > : > :Great! I like both suggestions. The first being: give me the subset > :of units that physically exist in the directory I have provided in the > :name parameter of the associate routine. The second was something that > :we used to be able to do with the old Rational LRM interfaces because > :they provided a way to ignore predefined packages. > > > You are describing an important and desired capability. The Unit_Origins > type and Unit_Origin query currently attempt to answer it. However, we > discussed some limitations in the design that would be nice to overcome. > This distinction only maps to kinds of units, not which directories they > come from. This is still an issue or action item within the ASISWG. > > I only disagree with the suggestion that ASIS expose directories as an > implementation detail. > > Comments regarding alternatives are welcome. > I believe there are the following three levels: 1) The set of Ada units that physically exist in the directory specified in the name parameter of the associate routine, 2) All other units introduced by the user (i.e., units that are not pre-defined), and 3) Pre-defined units. Perhaps there aren't any units in level 2, or perhaps there are thousands of units scattered throughout multiple locations on the disk. -- -- Roy M. Bell -- -- I am at the home of the most free wheeling hackers commercially available -- rmbell@most.fw.hac.com From sblake@alsys.com Tue Feb 6 12:57:30 1996 Return-Path: Date: Tue, 6 Feb 1996 09:05:55 -0800 From: sblake@alsys.com (Steve Blake @pulsar) To: asis-technical@sw-eng.falls-church.va.us, bell@pseserv3.fw.hac.com Subject: Re: ASIS library/environment, continued Cc: sat@pseserv3.fw.hac.com Content-Length: 6000 X-Lines: 143 Status: RO >> Steve Blake >> >> ASIS must be careful not to force only implementations on environments that >> support directories and files. > >Why? What potential users would we be shuting out? I'm trying to suggest that we avoid the use of the term directory, because it assumes too much about the details of the implementation of the source/unit structuring. Like the Russian PallAda, other Ada implementations such as OCSystems PowerAda, do not equate directory with library or source/unit container. >> >> I don't want to be argumentative here, but I guess I don't understand why >> GNAT does not boast of supporting a powerful, flexible, muti-library >> environment. Why not? It supports definition of multiple ordered >> "directories" containing the sources, creates ALI files with dependency >> information, and optionally saves persistent information. Yet GNAT and other >> "lightweight" implementations promote the notion that they don't have an Ada >> library. Is this a marketing decision? >> >> Personally, I love the GNAT and Intermetrics "lightweight" models. I just >> don't understand why "library" has become such a bad word. Ada 95 suggests >> implementations can have a program library, even multiple libraries. Yet we >> claim we don't have them, but document environment variable, options, tools >> and other constructs to essentially provide the environment to the >> compilers. >> >> If we would just all 'fess up, it would make things much easier for ASIS. > >Why are the terms lightweight/heavyweight perferred over persistent? I really have no preference of one term vs. the other. I'd like to see ASIS avoid attempts to classify Ada implementations using these kinds of terms, because these are gray-scale terms, not black and white. >> :> Serge Rybin >> :> >> :> I do not know some other way to define an *ASIS* Library for GNAT other >> :> then to define the ordered set of directories with Ada sources. But it is >> :> an *implementation* decision/principle. Do you suggest to extend the >> :> ASIS semantic by the corresponding implementation-independent feature? > >> :Me (Roy Bell) >> : >> :Yes, this is exactly what I am suggesting. All compiler implementers >> :(including GNAT) keep their stuff in directories. An Ada program uses >> :Ada units found in an ordered set of directories as you put it. >> : >> >> We must be careful not to expect this of all Ada implementations. > > >All compilation environments have to provide a way to partition the >Ada units into multiple locations. Vendors of Ada 95 products can't >think of skimping on this feature because (I am happy to say) there >are too many predefined Ada units provided with Ada 95 for vendors >to consider othewise. It appears that both Serge and I believe that >this is an implementation-independent feature. I agree in principle. It is an implementation permission though, not a requirement. > > >> >> :> >> :> And another thing about ASIS-for-GNAT. ASIS Library has to contain all >> :> the predefined Ada stuff. Even if you indicate only one directory as >> :> making up the ASIS Library, ASIS-for-GNAT will use the current value of >> :> the ADA_UNCLUDE_PATH environment variable as (implicit) indication to >> :> add to your directory the directory containing the sources of the Ada >> :> predefined units and the GNAT Run-Time Library (RTL). And if you use >> :> the corresponding ASIS query to get the overall content of the Library, >> :> you will get the content of your directory PLUS all the predefined >> :> units PLUS RTL. So what do you think about the special ASIS query (or a >> :> special option in the existing queries) for obtaining only the >> :> "user-defined" content of the ASIS Libtary? (It also would be the >> :> natural and effective solution for the "directory content" problem in >> :> case of GNAT.) >> :> >> : >> :Great! I like both suggestions. The first being: give me the subset >> :of units that physically exist in the directory I have provided in the >> :name parameter of the associate routine. The second was something that >> :we used to be able to do with the old Rational LRM interfaces because >> :they provided a way to ignore predefined packages. >> >> >> You are describing an important and desired capability. The Unit_Origins >> type and Unit_Origin query currently attempt to answer it. However, we >> discussed some limitations in the design that would be nice to overcome. >> This distinction only maps to kinds of units, not which directories they >> come from. This is still an issue or action item within the ASISWG. >> >> I only disagree with the suggestion that ASIS expose directories as an >> implementation detail. >> >> Comments regarding alternatives are welcome. >> > >I believe there are the following three levels: > 1) The set of Ada units that physically exist in the directory > specified in the name parameter of the associate routine, Remember, the name parameter does not necessarily name a directory. It can name a file that lists sublibraries, or could be just a logical name for a project, or could be a null string, or just about anything else. I know exactly what you mean, It's just hard to explain abstractly. > 2) All other units introduced by the user (i.e., units that > are not pre-defined), and > 3) Pre-defined units. > >Perhaps there aren't any units in level 2, or perhaps there are >thousands of units scattered throughout multiple locations on the disk. > > >-- >-- Roy M. Bell There also are levels that can include such units as: 4) implicit runtime support units supplied by the Ada implementation. These are not user defined and are not pre-defined. 5) Bindings to X, POSIX, ASIS, etc that can be supplied by the Ada vendor or some third party vendor. These are not user defined and are not pre-defined. It is very difficult for ASIS to assign some consistent and formal semantics to these levels. Steve Blake From Serge.Rybin@lglsun.epfl.ch Tue Feb 6 16:19:22 1996 Return-Path: Date: Tue, 6 Feb 1996 21:28:50 +0100 From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) To: asis-technical@sw-eng.falls-church.va.us, sblake@alsys.com, dewar@gnat.com, Alfred.Strohmeier@di.epfl.ch Subject: "Source-based" vs. "Library-based" (Re: Re: ASIS library/environment, continued) Cc: zueff@such.srcc.msu.su Content-Length: 12004 X-Lines: 246 Status: RO I really enjoy the current discussion about ASIS Library/Ada environment, and I think it is extremally useful. Having been thinking over Steve's recent responces, I've got (as I think :-) much more clear understanding of the difference between "soure-based" and "library-based" approaches in respect to ASIS problems. Steve writes (':' - me (Sergey Rybin): ":(2) "Lightweight - source-based" and "heavyweight - library-based". I think, : both variants are based on some implicit "common-sense reasonong" which : should be made explicit by some explicit explanations. For me, the last : variant ("source/library-based") gives a more clear hint about the : nature of the corresponding Ada (and ASIS!) implemetation. : What do you think about solving this problem by voting? : I'd really like to see us all do away with attempts to classify Ada implementations this way. With a little imagination, all these terms can be applied to all the existing Ada implementations I'm aware of. We can't possibly predict future implementations that might be "middleweight", source-library based, etc. ASIS simply needs to define an abstraction with implementation permissions and requirements that are fair and reasonable to all, and I think we are very close to that goal functionally. Terminology and documentation is where most remaining work needs to be done." I entirely support Steve's idea to get rid of this way of classifying Ada (and ASIS!) implementations. Now I completely argee with Robert that the description of Ada compilation model in RM 83 and RM 95 are semantically equivalent in respect to both Ada programs and Ada implementations. But I am still thinking that ASIS is sometning different than Ada implementation, and source-based and library-based ASIS implementations may have different semantics (I am ready to accept this, if it would have been explicitly said somewhere in ASIS documents!). To get rid of source/library based classification for ASIS (not Ada!) implementations, we have to clear up the meaning of the notions "source-based" and "library-based" for ASIS. Below is my attempt to do it. 1. The source-based approach ------------------------- The main principle of the source-based approach is usially formulated as "the source code is the ultimate indicator of the status of your program". Two points may require clarification: what does "source code" mean and what does "program" mean? As for the second point, we may reformulate this principle for Ada as "the source code of an Ada compilation unit is the ultimate indicator of the syntax of the unit, the source code of the unit together with the source codes of all its supporters are the ultimate indicator of the syntax and the semantic of the unit". But the situation with defining "the source text" (or, simply - "source") as an Ada/ASIS/Xxx? technical term is much harder. I am afraid that it is almost impossible to define it formally, and we have to consider "the source (text)" just in the same way as we are considering the notions of "point", "line", "plane" in the plane geometry (that is, as a primary, nondeterminable notion). We may only present some (indirect) explanations, such as "the source text may be something else than the plane text" or "the source text is the first instantion that directly reflect all the intents of a programmer". The "source-based approach" means that all the tools (compiler, binder/linker, ASIS etc.) dealing with an Ada program or with any collection of Ada units, really work only with (the current state of!) the sources of the Ada units. The producing and reusing of any other (persistent (?)) objects (in case of GNAT - object and ALI (Ada LIbrrary Information) files for successfully compiled units) may be considered only as some kind of optimization. 2. The library-based approach ------------------------- The general idea of a library-based Ada implementation is that the compiler stores some image of a successfully compiled unit in its library (this image was called as "persistent intermadiate representation" during this discussion), and, compiling a unit, the compiler processes the persistent intermadiate representations, but not sources of unit's supporters. A library-based ASIS implementation is the ASIS implementation which processes not the sources, but the persistent intermadiate representations of Ada units. We may consider a whide spectrum of the implementation-specific variations inside the library-based approach: if, compiling a unit, a compiler cannot find out its supporter among the persistent intermadiate representations which are kept in the library, it may try to find and to compile the source of the supporter, and the corresponding ASIS implementation may act in this way; an Ada implementation may include its own "intellectual" text editor, which (under the special option) may automatically invoke a compiler just after saving the modified version of a source, etc. But, at least for some of the library-based Ada implementations, the time gap may exist between changing the source of an Ada unit and changing its persistent intermadiate representation in the compiler library, and only the (successful!!)compilation of the modified source can bridge this gap. Let's further consider the "very lirteral" interpretation of the Ada 83 library model and the corresponding ASIS implementation based on persistent inte The difference between the sourve-based and the library-based approaches makes no difference on defining the legality of an Ada units or the semanzic of the (completed) Ada program. But if we want to obtain by means of ASIS queries, the infotrmation about the current state of the program somewhere in the middle of its development, the results may be rather different for the source-based and library-based approaches. Below is an example. 3. Obtaining the consistency-related information through the ASIS queries ---------------------------------------------------------------------- Steve (as the principle author of ASIS 2.0.E), as well as the rest of ASIS WG (as having not commented this so far) write (ASIS 2.0.E, Asis_Compilation_Units, the part of the documentation of the Semantic_Dependencies_Order query, lines 1067 .. 1083): -- As an example, given four units, A withs B, B withs C, and C withs D; -- if D is recompiled, the inconsistent list would minimally contain six -- units with the three pairs: -- -- DC CB BA -- -- The list indicates that units C, B, and A are inconsistent (the second -- units of each pair). Semantic dependencies such as B depends on C can -- also are indicated. The units C, B, and A are in an order that could be -- submitted to the compiler (a possible recompilation order). -- -- If a unit is inconsistent because the source for the unit has been -- edited (or otherwise been made inconsistent by some action of the user -- or implementation) then the unit references A_Nil_Compilation_Unit as the -- cause of the inconsistency. eg. (Nil A Nil B) would be a list of two -- inconsistent units, neither of which can point to a third unit as the -- cause for their being inconsistent. Let's consider this situation for a source-based and for a library-based ASIS implementation For the source-based ASIS no compilation or recompilation as well as no changes in units' sources can made units to be consistent or inconsistent. ASIS processes only sources, and only the current state of the sources. The source-based ASIS can classify units only as legal or illegal, and every unit set containing only legal units is always consistent, *IF* ASIS cannot access different sources for the same (in the sense of RM 95, 10.2(19)) compilation unit, and this fact is NOT implementation-dependent.As for illegal inits, the decision whether or not ASIS should retrieve them as belonging to ASIS Library, is implementation-dependent, and I do not know how to unterprete the consistency-related questions to a unit set containing illegal units. And for a ("very literal") library-based ASIS, recompilation without changing the source of D from previous example will make the units inconsistent, but any changing the source of D without its recompilation will not have any impact on the information retrieved through ASIS. And this implementation can never deal with illegal units, because no consistent intermediate imabe can be created for an illegal unit! 4. Consistency in an Ada environment and in ASIS Library ----------------------------------------------------- RM 95 10.1.4(5) says: When a compilation unit is compiled, all compilation units upon which it depends semantically shall already exist in the environment; the set of these compilation units shall be consistent in the sense that the new compilation unit shall not semantically depend (directly or indirectly) on two different versions of the same compilation unit, nor on an earlier version of itself. RM 10.2(19) says: The full expanded names of the library units and subunits included in a given partition shall be distinct. And RM 10.2(27) says: The implementation shall ensure that all compilation units included in a partition are consistent with one another, and are legal according to the rules of the language. Let's examine these points from the source-based and library-based viewpoints. The only cause of inconsistency in the source-based model is when an implementation can access different sources for the same Ada Unit when compiling some unit, producing the executable or getting the information about units. ("The same unit" means unit having the same fully expanded Ada name and the same body/spec sign). GNAT uses the special file names and search path rules to make this situation impossible, and ASIS-for-GNAT follows these rules. The question is: may an ASIS Library for a source-based Ada implementation be allowed to contain different sources for the same Ada unit? If the answer is "NO", there is no need at all to say about inconsistent unit sets for source-based ASIS. Another question: should the answer on the previous question be given as mandatory for source-based ASIS implementations? Next question - what should a (source-based!) ASIS do with illegal units? And for the library-based ASIS 95 we have Ada-83/ASIS83-defined picture in which the words "should be recompiled" have been systematically replaced by "is inconsistent (="should be recompied to (try to) be consistent again". The meaning and the possible causes of appearing of inconsistent unit sets are quite clear - some persistent intermadiate representations have been created for different versions of the same source! 5. The questions ------------- All the discussion above may be summarized in the following questions: (1) Can the principle :"the source code of an Ada compilation unit is the ultimate indicator of the syntax of the unit, the source code of the unit together with the source codes of all its supporters are the ultimate indicator of the syntax and the semantic of the unit" be applied to the library-based ASIS implementations? (Another version of this question: "Should this principle be mandatory for ASDIS?") (2) If the answer on the previous question is "Yes", the next question is: "What should be considered as the source code for a library-based system: the "usial" source code or only a (having been!) successfully compiled source code? If the answer is "No", the next question is: "What should be considered as the ultimate indicator of the syntax and the semantic of the unit?" (in library-based systems) (3) Should the answers on the previous questions be given as mandatory or implementattion-dependent in ASIS (future) standard. I would summarize these questions in one question: What is an object to which ASIS should provide an interface? :-) Sergey Rybin P.S. Sorry for my English and typos - its a bit late now :-( From sblake@alsys.com Tue Feb 6 21:21:48 1996 Return-Path: Date: Tue, 6 Feb 1996 17:37:50 -0800 From: sblake@alsys.com (Steve Blake @pulsar) To: asis-technical@sw-eng.falls-church.va.us Subject: Proposal for ASIS Environment/Library changes Status: RO Content-Length: 36289 X-Lines: 807 This proposal covers changes to ASIS 95 to addresses terminology issues regarding the environment and library. It also addresses two suggestions from the recent discussions: - to provide a means to structure an ASIS Environment/Context into containers for compilation units. - to provide the ability to obtain only "user-defined" content of the Environment/Context Summary of the proposed changes: 1. Provide documentation that describes the formal definitions of the terms Environment, Context, and Library as they are used within ASIS. 2. Asis.Environment is changed to Asis.Implementation (See the sample below). This terminology make more sense for operations like initialize and finalize which only apply to ASIS itself, not to any Ada term or requirement. Boolean queries that reveal support for various implementation permissions are encapsulated in a child package Asis.Implementation.Permissions. 3. Asis.Libraries is changed to Asis.Ada_Environments (See the sample below). The former type Library is now called Context, or Asis.Context. The operations to associate, open, close, etc are still there, but now they take an Asis.Context as an argument. 4. A new child package Asis.Ada_Environments.Libraries (See the sample below) provides an abstraction for an Asis.Library and Asis.Library_List. The query Defining_Libraries maps an Asis.Context to an Asis.Library_List if the underlying Ada implementation, or stand-alone ASIS supports the concept of a library or even multiple libraries. This abstraction allows tools to obtain a list structure that defines zero or more conceptual libraries which are logical containers of the compilation units within an Asis.Context. Any ASIS implementation on an Ada implementation that does not support the concept of a Library can avoid this abstraction by mapping the Context to a Nil_Library_List. This new Asis.Library is a private type rather than limited private. This allows construction of toolkit layer data structures and queries such as sets and membership operations to help classify and organize units. Several queries provide the ability to discern which units come from which Asis.Library. First, given a Compilation_Unit, Enclosing_Context provides the Asis.Context the unit was obtained from (This replaces the old Enclosing_Library). A new function Enclosing_Library returns the Asis.Library containing the unit. There is purposely very little to query from an Asis.Library other than Name, Is_Equal, and Is_Identical. This is all that is needed to separate an environment's predefined units from user defined units (unless they are purposely intermixed). This also lets tools find out if a given Asis.Library contains predefined Ada units. For example: 1. Fetch the predefined unit called "Ada". 2. Fetch the units that form its Asis.Family using Semantic_Dependence_Order 3. Map the Asis.Context into an Asis.Library_List 4. Use Enclosing_Library on each unit to define which Asis.Library values from the Asis.Library_List that contain the predefined units. GNAT-ASIS would map the list of directories containing the sources onto the Asis.Library_List and Name would return the directory name. It would be up to the ASIS tool to determine the meaning of the Asis.Library names. All ASIS implementations could at least map the Asis.Context to a list of one Asis.Library whose Name is that of the Asis.Context Name. This model does not impose any more requirements on possible implementations than the existing model does. An alternate name can be chosen for Asis.Library if there is too much resistance or confusion with the notion of an Ada library. The term should be appropriate since Ada 95 explicity mentions it as an allowed concept and implementation permission. Sample specs follow. I DID NOT TRY COMPILING THEM, they are just to convey the proposal. with Asis_Type_Primitives; ------------------------------------------------------------------------------ package Asis.Implementation is ------------------------------------------------------------------------------ -- Asis.Implementation -- ASIS 95 Draft Version 2.0.? -- February 1995 -- -- This package provides queries to initialize, finalize, and query the -- error status of the ASIS Implementation. -- ------------------------------------------------------------------------------ package Local_Renames is ----Renames that allow notational consistency between the ASIS package -- specifications and ASIS applications. package Asis renames Asis_Type_Primitives; end Local_Renames; use Local_Renames; ------------------------------------------------------------------------------ function Asis_Version return Asis.Asis_String; function Asis_Vendor return Asis.Asis_String; function Asis_Vendor_Version return Asis.Asis_String; function Asis_Vendor_Information return Asis.Asis_String; ------------------------------------------------------------------------------ -- Returns Asis_String values which identify: -- -- Asis_Version - the version of the ASIS interface, eg. "1.2" -- Asis_Vendor - the name of the vendor, eg. "Ada Inc." -- Asis_Vendor_Version - the vendor's implementation version, eg. "5.2a" -- Asis_Vendor_Information - vendor information, eg. "Copyright ..." -- ------------------------------------------------------------------------------ function Is_Initialized return Boolean; ------------------------------------------------------------------------------ -- Returns True if ASIS is currently initialized. -- ------------------------------------------------------------------------------ procedure Initialize (Parameters : in Asis.Asis_String := Asis.Nil_Asis_String); ------------------------------------------------------------------------------ -- Parameters - Specifies vendor specific parameters. -- -- Performs any necessary initialization activities. This must be invoked -- at least once before any other ASIS services are used. Parameter values -- are vendor dependent. The call is ignored if ASIS is already initialized. -- All ASIS queries and services are ready for use once this call completes. -- -- Raises Asis_Failed if ASIS failed to initialize or if the Parameters -- argument is invalid. Status will be Environment_Error or Parameter_Error. -- --|AN Application Note: --|AN --|AN The ASIS implementation may be Initialized and Finalized any number of --|AN times during the operation of an ASIS program. However, all existing --|AN Environment, Compilation_Unit and Element values become invalid when --|AN ASIS Is_Finalized. Subsequent calls to ASIS queries or services using --|AN such invalid Compilation_Unit or Element values are erroneous. --|AN ------------------------------------------------------------------------------ function Is_Finalized return Boolean; ------------------------------------------------------------------------------ -- Returns True if ASIS is currently finalized or if ASIS has never been -- initialized. -- ------------------------------------------------------------------------------ procedure Finalize (Parameters : in Asis.Asis_String := Asis.Nil_Asis_String); ------------------------------------------------------------------------------ -- Parameters - Specifies any implementation required parameter values. -- -- Performs any necessary ASIS termination activities. This should be invoked -- once following the last use of other ASIS queries. Parameter values are -- vendor dependent. The call is ignored if ASIS is already finalized. -- Subsequent calls to ASIS Environment, Compilation_Unit, and Element queries, -- are erroneous while the environment Is_Finalized. -- -- Raises Asis_Failed if the ASIS implementation failed to finalize. Status -- is likely to be Internal_Error and will not be Not_An_Error. -- ------------------------------------------------------------------------------ -- Whenever an error condition is detected, and any ASIS exception is raised, -- an Asis.Errors.Error_Kinds value and a Diagnosis string is stored. These -- values can be retrieved by the Status and Diagnosis functions. The -- Diagnosis function will retrieve the diagnostic message describing the -- error. -- -- Error information always refers to the most recently recorded error. -- -- Note that Diagnosis values are vendor dependent and may vary greatly among -- ASIS implementations. -- ------------------------------------------------------------------------------ function Status return Asis.Errors.Error_Kinds; ------------------------------------------------------------------------------ -- Returns the Error_Kinds value for the most recent error. -- ------------------------------------------------------------------------------ function Diagnosis return Asis.Asis_String; ------------------------------------------------------------------------------ -- Returns an Asis_String value describing the most recent error. -- -- Will typically return a Nil_Asis_String if Status = Not_An_Error. -- ------------------------------------------------------------------------------ procedure Set_Status (Status : Asis.Errors.Error_Kinds := Asis.Errors.Not_An_Error; Diagnosis : Asis.Asis_String := Asis.Nil_Asis_String); ------------------------------------------------------------------------------ -- Status - Specifies the new status to be recorded -- Diagnosis - Specifies the new diagnosis to be recorded -- -- Sets (clears, if the defaults are used) the Status and Diagnosis -- information. Future calls to Status will return this Status (Not_An_Error) -- and this Diagnosis (Nil_Asis_String). -- -- Raises Asis_Failed, with a Status of Internal_Error and a Diagnosis of -- Nil_Asis_String, if the Status parameter is Not_An_Error and the Diagnosis -- parameter is not the Nil_Asis_String. -- package ASIS.Implementation.Permissions is --|OP------------------------------------------------------------------------- --|OP Need query to determine if multiple object declarations are normalized --|OP to an equivalent sequence of single declarations. ------------------------------------------------------------------------------ function Is_Formal_Parameter_Named_Notation_Supported return Boolean; ------------------------------------------------------------------------------ -- Returns True if it is possible to detect usage of named notation. -- -- Returns False if this implementation will always change parameter lists -- using named notation to positional lists in function, subprogram, and -- entry calls. In that case, the Formal_Parameter query will always return -- a Nil_Element unless the parameter list is obtained with Normalized = True. -- -- This function affects association lists for aggregates, instantiations, -- discriminant lists, entry calls, and subprogram calls. -- ------------------------------------------------------------------------------ function Default_In_Mode_Supported return Boolean; ------------------------------------------------------------------------------ -- Returns True if the A_Default_In_Mode kind is supported by this -- implementation. -- --|95------------------------------------------------------------------------- --|95 function Generic_Parameters_Include_Defaults was deleted. Reason --|95 REDUNDANT. An implementation that includes defaults must always return --|95 normalized association lists. The query Generic_Actual_Part_Normalized --|95 provides this determination. --|95------------------------------------------------------------------------- --|95 function Generic_Actual_Part_Normalized was called --|95 Generic_Parameters_Normalized. ------------------------------------------------------------------------------ function Generic_Actual_Part_Normalized return Boolean; ------------------------------------------------------------------------------ -- Returns True if the query Generic_Actual_Part will always return artificial -- Is_Normalized associations using defining_identifiers instead of -- generic_formal_parameter_selector_names, and using default_expressions or -- default_names. -- -- if Generic_Actual_Part_Normalized then the query Generic_Actual_Part will -- always behave as if called with Normalized => True. --|95------------------------------------------------------------------------- --|95 function Record_Component_Associations_Normalized was called --|95 Components_Normalized. ------------------------------------------------------------------------------ function Record_Component_Associations_Normalized return Boolean; ------------------------------------------------------------------------------ -- Returns True if the query Record_Component_Associations will always return -- artificial Is_Normalized associations using defining_identifiers instead of -- component_selector_names. -- -- if Record_Component_Associations_Normalized then the query -- Record_Component_Associations will always behave as if called with -- Normalized => True. -- ------------------------------------------------------------------------------ function Is_Prefix_Call_Supported return Boolean; ------------------------------------------------------------------------------ -- Returns True if the ASIS implementation has the ability to determine -- whether calls are in prefix form. -- --|95------------------------------------------------------------------------- --|95 function Function_Call_Parameters_Include_Defaults was deleted. Reason --|95 REDUNDANT. An implementation that includes defaults must always return --|95 normalized association lists. The query --|95 Function_Call_Parameters_Normalized provides this determination. ------------------------------------------------------------------------------ function Function_Call_Parameters_Normalized return Boolean; ------------------------------------------------------------------------------ -- Returns True if the query Function_Call_Parameters will always return -- artificial Is_Normalized associations using defining_identifiers instead of -- formal_parameter_selector_names, and using default_expressions. -- -- if Function_Call_Parameters_Normalized then the query -- Function_Call_Parameters will always behave as if called with -- Normalized => True. -- --|95------------------------------------------------------------------------- --|95 function Call_Parameters_Include_Defaults was deleted. Reason --|95 REDUNDANT. An implementation that includes defaults must always return --|95 normalized association lists. The query --|95 Call_Statement_Parameters_Normalized provides this determination. --|95------------------------------------------------------------------------- --|95 function Call_Statement_Parameters_Normalized was called --|95 Call_Parameters_Normalized. ------------------------------------------------------------------------------ function Call_Statement_Parameters_Normalized return Boolean; ------------------------------------------------------------------------------ -- Returns True if the query Call_Statement_Parameters will always return -- artificial Is_Normalized associations using defining_identifiers instead of -- formal_parameter_selector_names, and using default_expressions. -- -- if Call_Statement_Parameters_Normalized then the query -- Call_Statement_Parameters will always behave as if called with -- Normalized => True. -- --|95------------------------------------------------------------------------- --|95 function Discriminant_Associations_Include_Defaults was deleted. Reason --|95 OBSOLETE. It is not possible to obtain either a normalized or --|95 unnormalized discriminant_association list for an unconstrained record --|95 or derived subtype_indication where the discriminant_associations are --|95 supplied by default; there is no constraint to query, and a Nil_Element --|95 is returned from the query Subtype_Constraint. ------------------------------------------------------------------------------ function Discriminant_Associations_Normalized return Boolean; ------------------------------------------------------------------------------ -- Returns True if the query Discriminant_Associations will always return -- artificial Is_Normalized associations using defining_identifiers instead of -- discriminant_selector_names. -- -- if Discriminant_Associations_Normalized then the query -- Discriminant_Associations will always behave as if called with -- Normalized => True. -- ------------------------------------------------------------------------------ function Is_Line_Number_Supported return Boolean; ------------------------------------------------------------------------------ -- Returns True if the implementation can return valid line numbers for -- Elements. -- -- An implementation may choose to ignore line number values in which case -- this function returns False. -- ------------------------------------------------------------------------------ function Is_Span_Column_Position_Supported return Boolean; ------------------------------------------------------------------------------ -- Returns True if the implementation can return valid character positions for -- elements. -- -- An implementation may choose to ignore column character position values -- within spans in which case this function returns False. This function will -- be False if Is_Line_Number_Supported = False. -- ------------------------------------------------------------------------------ function Is_Commentary_Supported return Boolean; ------------------------------------------------------------------------------ -- Returns True if the implementation can return comments. -- -- An implementation may choose to ignore comments in the text in which case -- the function Is_Commentary_Supported returns False. -- ------------------------------------------------------------------------------ function Attributes_Are_Supported return Boolean; ------------------------------------------------------------------------------ -- Returns True if an implementation supports compilation unit attributes. -- Returns False if all attributes will return Has_Attribute() = False. -- ------------------------------------------------------------------------------ function Minimal_Inconsistent_Units return Boolean; ------------------------------------------------------------------------------ -- Returns True if Relationships are implemented as a minimal set of -- relationships. -- --|95------------------------------------------------------------------------- --|95 function Implicit_Components_Supported is new. ------------------------------------------------------------------------------ function Implicit_Components_Supported return Boolean; ------------------------------------------------------------------------------ -- Returns True if the implementation provides elements representing -- implicit implementation-defined components. end ASIS.Implementation.Permissions; end Asis.Implementation; with Asis_Vendor_Primitives; ------------------------------------------------------------------------------ package Asis.Ada_Environments is ------------------------------------------------------------------------------ -- Asis.Ada_Environments - ASIS 95 Draft Version 2.0.? -- February 1995 -- -- Asis.Ada_Environments encapsulates a set of queries that map physical Ada -- compilation and program execution environments to logical ASIS environments. -- -- An ASIS Environment is associated with some set of Ada compilation units -- maintained by an underlying Ada implementation or a stand-alone ASIS -- implementation. After this association has been made, this set of units -- is considered to be part of the compile-time Ada environment, which forms -- the outermost context of any compilation, as specified in section 10.1.4 of -- the Ada 95 Reference Manual. This same environment context provides the -- implicit outermost anonymous task during program execution. -- --|IR Implementation Requirment --|IR --|IR The concrete mechanism of this association is vendor-specific: --|IR --|IR Each ASIS implementation will provide the means to construct an ASIS --|IR Context value that defines the environment declarative_part or --|IR "container" from which ASIS can obtain library units. --|IR ------------------------------------------------------------------------------ package Local_Renames is package Asis renames Asis_Vendor_Primitives; end Local_Renames; use Local_Renames; -- type Context is Limited private; -- Nil_Context : constant Context; ------------------------------------------------------------------------------ function Default_Name return Asis.Asis_String; ------------------------------------------------------------------------------ -- Returns the default context name. If there is no default context name, a -- Nil_Asis_String is returned. -- ------------------------------------------------------------------------------ function Default_Parameters return Asis.Asis_String; ------------------------------------------------------------------------------ -- Returns the default context parameters. If there are no default context -- parameters, a Nil_Asis_String is returned. -- ------------------------------------------------------------------------------ procedure Associate (Context : in out Asis.Context; Name : in Asis.Asis_String; Parameters : in Asis.Asis_String := Default_Parameters); ------------------------------------------------------------------------------ -- Context - Specifies the Context to associate -- Name - Specifies the name for the Context association -- Parameters - Specifies parameters to use when opening the Context -- -- Used to give name and parameter associations to a Context. The -- Has_Associations query is used to test whether or not a Context has -- been given name and parameter associations. The Name and Parameters -- queries are used to examine name and parameter associations. -- -- A Context has at most one set of name/parameter values associated with -- it at any time. Name and parameter associations cannot be modified while a -- Context is open Previous name and parameters associations for this Context -- are replaced by this call. -- -- ASIS implementations are encouraged, but not required, to validate the -- Parameters string immediately. It is recognized that some options cannot -- be completely validated until the Open is performed. An invalid Parameters -- value is reported by raising Asis_Failed with a Status of Parameter_Error. -- -- Raises Asis_Inappropriate_Context if the Context is open. -- ------------------------------------------------------------------------------ procedure Open (Context : in out Asis.Context); ------------------------------------------------------------------------------ -- Context - Specifies the Context to open -- -- Opens the ASIS Context using the Context's associated name and parameter -- values. -- -- Raises Asis_Inappropriate_Context if the Context is already open or if it -- is uninitialized (does not have associated name and parameter values). -- -- Raises Asis_Failed if the Context could not be opened for any reason. The -- most likely Status values would be Name_Error, Use_Error, Data_Error, and -- Parameter_Error. Other possibilities include Storage_Error and -- Capacity_Error. -- ------------------------------------------------------------------------------ procedure Close (Context : in out Asis.Context); ------------------------------------------------------------------------------ -- Context - Specifies the Context to close -- -- Closes the ASIS Context. Any previous Context name and parameter -- associations are retained. This allows the same Context to be re-opened -- later with the same associations. -- -- All Compilation_Unit and Element values obtained from the Context become -- invalid when it is closed. Subsequent calls to ASIS services using such -- invalid Compilation_Unit or Element values are erroneous. ASIS -- implementations will attempt to detect such usage and raise Asis_Failed in -- response. Applications should be aware that the ability to detect the use -- of such "dangling references" is implementation specific and not all -- implementations will be able to raise Asis_Failed at the appropriate -- points. Thus, applications that attempt to utilize invalid values may -- exhibit unpredictable behavior. -- -- Raises Asis_Inappropriate_Context if the Context is not open. -- ------------------------------------------------------------------------------ procedure Dissociate (Context : in out Asis.Context); ------------------------------------------------------------------------------ -- Context - Specifies the Context whose name and parameter associations are -- to be cleared -- -- Severs all previous associations for the Context. A Context that does not -- have associations (is uninitialized) will be returned unchanged. The -- Context variable is returned to its uninitialized state. -- -- Contexts that have been given Names and Parameters should be Dissociated -- when they are no longer necessary. Some amount of program storage may be -- tied up by the stored Name and Parameter strings. This space is only -- freed when a Context is Dissociated or when ASIS is Finalized. -- -- This operation has no physical affect on any vendor Ada environment. -- -- Raises Asis_Inappropriate_Context if the Context is open. -- ------------------------------------------------------------------------------ function Is_Equal (Left : in Asis.Context; Right : in Asis.Context) return Boolean; ------------------------------------------------------------------------------ -- Left - Specifies the first Context -- Right - Specifies the second Context -- -- Returns True if Left and Right designate the same Ada environments and the -- same set of associated compilation units. The Context variables may be -- open or closed. --### clarify -- -- Unless both Contexts are open, this operation is implemented as a pair of -- simple string comparisons between the Name and Parameter associations for -- the two Contexts. If both Contexts are open, this operation acts as a -- set comparison and returns True if both sets contain the same units (all -- unit versions are included in the comparison). -- --|AN Application Note: --|AN --|AN With some implementations, Is_Equal may be True before the Contexts --|AN are opened, but may be False after the Contexts are open. --|AN One possible cause for this is a sequence of events such as: --|AN --|AN 1) ASIS program A opens the Left Context for READ, --|AN 2) non-ASIS program B opens the Context for UPDATE, and creates a new --|AN version of the vendor Context, --|AN 3) ASIS program A opens the Right Context for READ, and gets the new --|AN version. --|AN ------------------------------------------------------------------------------ function Is_Identical (Left : in Asis.Context; Right : in Asis.Context) return Boolean; ------------------------------------------------------------------------------ -- Left - Specifies the first Context -- Right - Specifies the second Context -- -- Returns True if Left and Right both designate the value associated with -- one specific open ASIS Context variable. --### clarify -- -- Returns False otherwise or if either Context is not open. -- --|AN Application Note: --|AN --|AN No two physically separate open Context variables are ever Is_Identical. --|AN The value associated with an open ASIS Context variable is also directly --|AN associated with every Compilation_Unit or Element derived from that --|AN Context. It is possible to obtain these Context values by way of the --|AN Enclosing_Context and the Enclosing_Compilation_Unit queries. These --|AN Context values can be tested for identity with each other or with --|AN specific Context variables. An open ASIS Context variable and an --|AN Enclosing_Context value are only Is_Identical if the Compilation_Unit in --|AN question was derived specifically from that open ASIS Context variable. --|AN ------------------------------------------------------------------------------ function Exists (Context : in Asis.Context) return Boolean; ------------------------------------------------------------------------------ -- Context - Specifies a Context with associated name and parameter values -- -- Returns True if the Context is open or if the Context designates an Ada -- environment that can be determined to exist. -- -- Returns False for any uninitialized Context variable. -- --|IP Implementation Permissions: --|IP --|IP No guarantee is made that the Context is readable or that an Open --|IP operation on this Context would actually succeed. The associated --|IP parameter value for the Context may not be fully validated by this --|IP simple existence check. It may contain information that can only be --|IP verified by an actual Open. --|IP ------------------------------------------------------------------------------ function Is_Open (Context : in Asis.Context) return Boolean; ------------------------------------------------------------------------------ -- Context - Specifies the Context to check -- -- Returns True if the Context is currently open. -- ------------------------------------------------------------------------------ function Has_Associations (Context : in Asis.Context) return Boolean; ------------------------------------------------------------------------------ -- Context - Specifies the Context to check -- -- Returns True if name and parameter values have been associated with this -- Context. -- -- Returns False for an uninitialized Context. -- ------------------------------------------------------------------------------ function Name (Context : in Asis.Context) return Asis.Asis_String; ------------------------------------------------------------------------------ -- Context - Specifies the Context to check -- -- Returns the Name value associated with the Context. -- -- Returns a Nil_Asis_String if the Context is uninitialized. -- ------------------------------------------------------------------------------ function Parameters (Context : in Asis.Context) return Asis.Asis_String; ------------------------------------------------------------------------------ -- Context - Specifies the Context to check -- -- Returns the Parameters value associated with the Context. -- -- Returns a Nil_Asis_String if the Context is uninitialized. -- ------------------------------------------------------------------------------ function Debug_Image (Context : in Asis.Context) return Asis.Asis_String; ------------------------------------------------------------------------------ -- Context - Specifies the Context to represent -- -- Returns an Asis_String value containing implementation defined debugging -- information associated with the Context. -- -- The return value uses Asis.Text.Delimiter_Image to separate lines in -- multi-line results. The return value is not terminated with -- Asis.Text.Delimiter_Image. -- -- Returns a Nil_Asis_String if the Context is uninitialized. -- -- These values are intended for two purposes. They are suitable for -- inclusion in problem reports sent to the ASIS vendor. They can be presumed -- to contain information useful when debugging the implementation itself. -- They are also suitable for use by the ASIS application when printing simple -- application debugging messages during application development. They are -- intended to be, to some worthwhile degree, intelligible to the user. -- --|95------------------------------------------------------------------------- --|95 package Operations was deleted. ------------------------------------------------------------------------------ end Asis.Ada_Environments; ------------------------------------------------------------------------------ package Asis.Ada_Environments.Libraries is ------------------------------------------------------------------------------ -- Asis.Ada_Environments.Libraries -- ASIS 95 Draft Version 2.0.? -- February 1995 -- These declarations will be defined in Asis_Vendor_Primitives -- type Library is private; -- Nil_Library : constant Library; -- -- type Library_List is array (Asis.List_Index range <>) of Library; -- Nil_Library_List : constant Asis.Library_List (1 .. 0) := -- (1 .. 0 => Nil_Library); -- If an Ada implementation supports the notion of a program library or -- "library" as specified in section 10(2) of the Ada 95 Reference Manual, -- then an ASIS Context value can be mapped onto one or more vendor libraries. -- -- ASIS implementations could minimally map the Asis.Context to a list of -- one Asis.Library whose Name is that of the Asis.Context Name. ------------------------------------------------------------------------------ function Defining_Libraries (Context : in Asis.Context) return Library_List; ------------------------------------------------------------------------------ -- Context - Specifies the Context to define -- -- Returns a Library_List value that defines the single environment Context. -- Each non-Nil_Library will have an Enclosing_Context that Is_Identical to the -- Context argument. The order of Library values in the list is not defined. -- -- Returns a Nil_Library_List if the ASIS Ada implementation does not support -- the concept of a program library. -- -- Raises Asis_Inappropriate_Context if the Context is not open. -- ------------------------------------------------------------------------------ function Enclosing_Context (Library : in Asis.Library) return Asis.Context; ------------------------------------------------------------------------------ -- Library - Specifies the Library to name -- -- Returns the Context value associated with the Library. -- -- Returns the Context for which the Library value was originally obtained. -- Library values obtained through the Defining_Libraries query will always -- remember the Context from which they were defined. -- -- Because the type Context is limited private, this function is only -- intended to be used to supply a Context parameter for other queries. -- -- Raises Asis_Inappropriate_Library if the Library is a Nil_Library. -- ------------------------------------------------------------------------------ function Is_Equal (Left : in Asis.Library; Right : in Asis.Library) return Boolean; ------------------------------------------------------------------------------ -- Left - Specifies the first library -- Right - Specifies the second library -- -- Returns True if Left and Right designate library values that contain the -- same set of compilation units. The library values may have been defined -- from different Context values. -- ------------------------------------------------------------------------------ function Is_Identical (Left : in Asis.Library; Right : in Asis.Library) return Boolean; ------------------------------------------------------------------------------ -- Left - Specifies the first library -- Right - Specifies the second library -- -- Returns True if Is_Equal(Left, Right) and the library values have been -- defined from Is_Equal Context values. -- ------------------------------------------------------------------------------ function Name (Library : in Asis.Library) return Asis.Asis_String; ------------------------------------------------------------------------------ -- Context - Specifies the Library to name -- -- Returns the Name value associated with the Library. -- -- Returns a Nil_Asis_String if the Library is a Nil_Library. -- end Asis.Ada_Environments.Libraries; From Serge.Rybin@lglsun.epfl.ch Wed Mar 6 13:43:49 1996 Return-Path: Date: Wed, 6 Mar 1996 19:00:39 +0100 From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) To: asis-technical@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil Subject: ASIS and Ada environment (Comment on "Proposal for ASIS Environment/Library changes" Cc: Alfred.Strohmeier@di.epfl.ch Content-Length: 15549 X-Lines: 352 Status: RO Dear ASIS WG/ASIS RG, The recent discussions in the ASIS WG about Ada environment and ASIS Libraries/Environment/Context were very interesting and extremally useful. Summarizing the results, I've come to the conclusion, that the problem we have been trying to solve, was and still is, ill-structrurized. The last Steve's suggestions, presented as ASIS 2.0.F (preliminary) draft, make the situation much more better, but they are still an attempt to solve the non-structurized version of the problem. I would suggest to start the new round of the discussion from srtucturizing the problem of defining the top-level ASIS concepts. I think, that now the answers on the following questions still are not clear: 1. Can we use the RM(95)-defined notion of an Ada environment to give the general definition of ASIS? 2. Do we really need the notion of an environment for the general definition of ASIS? Do not kill me at the first second ( ;-) ), but now I think, that both answers are "NO", and I would suggest to define ASIS as an interface to Ada compilation units or to Ada compilation unit sets, and no more. Below you can find the rational for this "criminal" suggestion, the possible way of structuring the ASIS interface definition and terminology problem, the "environment-free" definition of an ASIS Context, and some questions related to Ada environment/ASIS Context I would like to make clear. I still have problems to find the good way to write all this stuff down, and I hope to prepare the revised version for ASIS WG meeting. Sergey Rybin, ASIS-for-GNAT Project. ================================================================= I. Ada environment. =============== 1. What is an Ada environment? -------------------------- RM 95, 10.1.4(1) says: Each compilation unit submitted to the compiler is compiled in the context of an environment declarative_part (or simply, an environment), which is a conceptual declarative_part that forms the outermost declarative region of the context of any compilation. At run time, an environment forms the declarative_part of the body of the environment task of a partition (see 10.2, ``Program Execution''). RM 95 10.2(10-13) says: The environment task for a partition has the following structure: task Environment_Task; task body Environment_Task is ... (1) -- The environment declarative_part -- (that is, the sequence of library_items) goes here. begin ... (2) -- Call the main subprogram, if there is one. end Environment_Task; The environment declarative_part at (1) is a sequence of declarative_items consisting of copies of the library_items included in the partition. The order of elaboration of library_items is the order in which they appear in the environment declarative_part 2. Requirements imposed on an Ada environment ------------------------------------------ RM 95 10.1.4 (5) says: When a compilation unit is compiled, all compilation units upon which it depends semantically shall already exist in the environment; the set of these compilation units shall be consistent in the sense that the new compilation unit shall not semantically depend (directly or indirectly) on two different versions of the same compilation unit, nor on an earlier version of itself. RM 95 10.2 (19) says: The full expanded names of the library units and subunits included in a given partition shall be distinct RM 95 10.2 (27) says: The implementation shall ensure that all compilation units included in a partition are consistent with one another, and are legal according to the rules of the language. 3. Consequences ------------ (1) Ana environment is no more than some auxiliary abstraction introduced in RM 95 for defining the legality of a single Ada compilation unit, and the legality and the dynamic semantic of a completed partition consisting on legal units. (2) The notion of an environment, as it is defined in RM 95, can only be applied either to a compiler when it compiles some unit, or to a system executing a partition ("executor") when the partition is executed. (3) Point (2) in anither words: the notion of an environment can be applied either to a single Ada compilation unit (together with its supporters), or to a completed partition. In the first case a compiler is informed "from outside", what "external object" should be used as an object to be compiled as an Ada compilation unit. In the second case an "executor" is informed "from outside", that the partition is completed, and what units make up the partition. (These are not the cases for ASIS!) (4) An Ada environment is always consistent, otherwise it is not an Ada environment, as well as an Ada unit is always a legal unit, otherwise it is not an Ada unit. In other words: all RM 95 says is said only about legal Ada units, completed partitions consisting on legal units and consistent environments. RM 95 says nothing about illegal units and inconsistent environments except that they are wrong, and it says nothing about incompleted partitions except they are not completed. II ASIS and Ada environment ======================== 1. What is ASIS? ------------ ASIS is an interface between Ada tools and Xxx[, providing the information about Yyys, contained in Xxx]. What is Xxx, and what are Yyys - these are the questions. (1) ASIS should provide information about software components written in Ada, for Ada tools processing these components. These components neither have to form the completed partition, nor they have to be in any dependency relations with each other, so there is no enough FORMAL reason to apply the RM-defined notion of an environment in this case. (2) ASIS should provide information about physical objects, whereas RM-defined Ada units, partitions and environment are only abstractions. (3) Is a tool really interested in Ada environment? For sure, it is interested in units, in their properties and in the relationships between them. (4) ASIS has to take into account the viewpoints of the following parts: - RM 95, at least when providing the white-box information about units; - underlying Ada compiler and "partition executor", and there may be important differences between source-based and library-based compilers' viewpoints, if we are considering some intermediate state of the software components maintained by a compiler, but not (the compilation of) a single unit or a completed partition); - tool builder; - Ada programmer working with the underlying compiler and using the ASIS-based tools, and this viewpoint is the background for the question: What is the ultimate indicator of the state of a particular Ada unit? Can we say, that these vewpoints are always the same or at least that they are conformant? III. Structurizing the problem. ========================= Step 1. +---------------------------------------------------- 1 | Ada tool +---------------------------------------------------- 2 | ASIS +---------------------------------------------------- 3 | "External objects" which are supposed to be ------------(*) | Ada compilation units | mainteined by an underlying Ada implementation | or which are supposed to be Ada sources | for a stand-alone ASIS +---------------------------------------------------- 4 | an underlying Ada implementation +---------------------------------------------------- (*) I would insist on this "which are supposed to be" instead of "which are treated as", because, before starting the corresponding processing, ASIS does not know, who is an Ada unit and who may be considered as an ASIS Compilation Unit, and who is not and may not (For example, "external objects" processed by a source-based ASIS are source texts, but only compilable sources are ASIS Compilation Units) Step 2. +---------------------------------------------------- 1 | Ada tool O o | ^ ^ +------------+-------+------------------------------- 2 | ASIS: | | | | | | +---+-------+-------------------------------- | | | | | | | (xxx) Asis Elements | | | | | +---+-------+--------------------------------- | | | | | | | | <------------- Asis.Compilation_Units queries | | | | yielding Units' black-box | | +---+ +---+ +---+ attribnutes and Asis.Elements | | | | | | | | Elemnts gateways | | +---+ +---+ +---+ | | ^ ^ ^ | | | | | +--------------- | +---+-------+------+---------- |Asis Context | | | | | X +--------------- | | | | | ^ | | | | | | Asis.Compilation_Units | | | | |<-----+--- queries, fetching Units | | | | | | from a Context | | | | | | | | +---+ +---+ +---+ +---+ | | | | | | | | | | Asis Compilation Units | | +---+ +---+ +---+ +---+ Candidates | | ^ ^ ^ ^ | +---+-------+------+------+------------------- | | | | | | | | | <--+--- Asis Context queries | | | | | +------------+-------+------+------+----------------- | | | | | X | | | | | ^ | | | | | | | +---+ +---+ +---+ +---+ +---+ | | | | | | | | | | | | +---+ +---+ +---+ +---+ +---+ | 3 | "External objects" ----------------------------- (**) | +---------------------------------------------------- 4 | an underlying Ada implementation +---------------------------------------------------- (**) A tool never interacts with the external world directly. On the first step it has to select the "external objects" it wants to work with, (that is, to define an Asis Context), on the second step it has to obtain from the the Asis Compilation Units he wants (and is able!) to process. So we have two different layers in ASIS for making some defintions and for imposing some rules - selecting the Asis Compilation Units candidates from the "external world", and selecting the "real" ASIS Compilation Units from the candidates. The questions are: (1) What rules should be imposed on each of these layers? (2) Does a tool really get information from an Ada environment (3) Where is an Ada environment on this picture? IV. The suggestion ============== The main idea is not to use the notion of an Ada environment when defining what is ASIS and when defining the ASIS interface itself (at least, at the upper layers of abstraction), and to define ASIS as an interface between an Ada tool and "external objects" which may be (not "are"!) treated as Ada compilation units by an underlying Ada implementation, and a stand-alone ASIS is defined as an interface to the external objects which may be treated as Ada sources. An Asis Context is associated with some set of external objects treated as ASIS (Ada?) Compilation Units candidates. If we say about namely Units candidates, but not Compilation Units, we san separate two important layers of abstraction: unstructurized "external world" -> ASIS Context ASIS Context -> ASIS Compilation Units This suggestion does not require to add or to delete any of the existing operations from Asis. But it requires to revise the semantics and the documentation of Semantic_Dependence_Order and of the queries yielding ASISA units from an ASIS Context. V. Questions ========= The first question is: should ASIS define, that an ASIS Context can contain AT MOST ONE ASIS Compilation Unit candidate for each full expanded Ada unit name? If the answer is "NO", how can ASIS define the semantics of the queries fetching ASIS Units by their names for the situation, wheh there is two or more candidates for the same Unit name? If the answer is "YES", let's consider the following fragment from ASIS 2.0.F draft: -- An ASIS Environment is associated with some set of Ada compilation units -- maintained by an underlying Ada implementation or a stand-alone ASIS -- implementation. After this association has been made, this set of units -- is considered to be part of the compile-time Ada environment, which forms -- the outermost context of any compilation, as specified in section 10.1.4 of -- the Ada 95 Reference Manual. This same environment context provides the -- implicit outermost anonymous task during program execution. If the answer is "YES", how can inconsistent Unit sets be obtained from a given ASIS Context by means of ASIS queries? And the next question is - what should be the rules for selecting ASIS Compilation Units from Units candidates? And the last question is - should ASIS say something concerning what is the ultimate indicator of the state of a unit, or should it remain this to be completely implementation-dependent. VI. "Source-based" vs. "Library-based" ================================= A while ago I sent the message with this subject ("Source-based" vs. "Library-based") in ASIS-Technical forum. Unfortunately, I've got no reply, and I do not know why - either because of my awful English, or because people had got tired after the previous discussion, or simply I had written a completely stupid things ;-) But I still think that in some situations differences between source-based and library-based Ada systems may lead to some important consequences. Now I would like to point out only one problem. Suppose we have a library-based Ada implementation which produces the "intermediate persistent images" of Ada units being compiled, and suppose we have an ASIS implementation based on these images. Then we would have an ASIS Context, containing only one extenal object (that is, "intermediate persistent image") for each ASIS Compilation Unit, but really this ASIS could provide the information from DIFFERENT Ada environments, if we still have ASIS defined as an interface to an Ada environment. Each "intermediate persistent image" provides the information from the environment which existed when it was created, and it does not reflect any changes and recompilations which might be made in the corresponding unit and its supporters after that. Of course, an ASIS application can (and should!) detect this situation, but the question is: if this is true, can we apply to this ASIS implementation the definition of an ASIS environment, given in ASIS 2.0.F and cited in the previous section.