From owner-sigada-asis-tech@ACM.ORG Mon Oct 5 18:33:09 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (8.8.8+Sun/SMI-SVR4) id SAA02836; Mon, 5 Oct 1998 18:33:08 -0400 (EDT) Received: from mail.acm.org (mail.acm.org [199.222.69.4]) by cs.ida.org (8.8.7/8.8.7) with ESMTP id SAA05690 for ; Mon, 5 Oct 1998 18:33:07 -0400 (EDT) Received: from mail (mail.acm.org [199.222.69.4]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id SAA32486; Mon, 5 Oct 1998 18:21:38 -0400 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 1313929 for SIGADA-ASIS-TECH@ACM.ORG; Mon, 5 Oct 1998 18:21:37 -0400 Received: from mailgw.rational.com (mailgw.rational.com [192.232.7.78]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id SAA09456 for ; Mon, 5 Oct 1998 18:11:34 -0400 Received: from fort-ext.rational.com (fort-ext.pureatria.com [192.232.7.130]) by mailgw.rational.com (8.9.1/8.9.1/RATIONAL-mailgw) with SMTP id PAA06047 for ; Mon, 5 Oct 1998 15:21:44 -0700 (PDT) Received: from mailhub.rational.com by fort-ext.rational.com via smtpd (for [192.232.7.78]) with SMTP; 5 Oct 1998 22:21:44 UT Received: from cupmail0.rational.com (cupmail0-19.rational.com [172.19.8.250]) by mailhub.rational.com (8.8.7/8.8.7/RATIONAL-mailhub) with ESMTP id PAA27023 for ; Mon, 5 Oct 1998 15:21:43 -0700 (PDT) Received: from amber.rational.com (amber.rational.com [172.19.130.10]) by cupmail0.rational.com (8.9.1/8.8.7/RATIONAL-cupmail0) with ESMTP id PAA16199 for ; Mon, 5 Oct 1998 15:21:43 -0700 (PDT) Received: (from geb@localhost) by amber.rational.com (8.8.6/) id PAA06197 for sigada-asis-tech@acm.org; Mon, 5 Oct 1998 15:22:49 -0700 (PDT) Message-ID: Date: Mon, 5 Oct 1998 15:22:48 PST Reply-To: geb@RATIONAL.COM Sender: ACM SIGADA ASIS Technical Discussion Group From: "Gary E. Barnes" Subject: A_Configuration_Compilation Unit_Kind - seems a bit odd. To: SIGADA-ASIS-TECH@ACM.ORG Content-Length: 4208 Status: ORr From the June 1, 1998 ASIS 2.0.Q, A_Configuration_Compilation, -- Corresponds to the whole content of a -- compilation with no compilation_unit, -- but possibly containing comments, -- configuration pragmas, or both. -- Any Context can have at most one unit -- of A_Configuration_Compilation kind. -- A unit of A_Configuration_Compilation -- does not have a name. This unit -- represents configuration pragmas that -- are "in effect". One curious thing about this compilation Unit_Kind is that there are apparently no interfaces in the ASIS specification that are capable of returning a unit having this Unit_Kind. That would lead to the question, why does this Unit_Kind exist since it serves no purpose for the user of the interface? A second curious thing is the comment that "Any Context can have at most one unit of A_Configuration_Compilation kind." Since a Context is supposed to model an Ada compilation environment, and since Ada places no restriction on the number of pragma-only configuration compilations that may occur, why does ASIS create this restriction? A specific example would be a compilation context that consists of a user application area plus some number of separately compiled libraries. Each library may well have its own set (or sets) of configuration pragmas and then the application area itself could have a set (or sets). Such a situation makes the above comment a bit problematic. It also forces the Configuration_Pragmas interface into a confusing position. function Configuration_Pragmas (The_Context : in Asis.Context) return Asis.Pragma_Element_List; ------------------------------------------------------------------------------ -- The_Context - Specifies the Context to query -- -- Returns a list of pragmas that apply to all future compilation_unit elements -- compiled into The_Context. Pragmas returned by this query should -- have appeared in a compilation that had no compilation_unit elements. -- To the extent that order is meaningful, the pragmas should be in -- their order of appearance in the compilation. (The order is implementation -- dependent, many pragmas have the same effect regardless of order.) -- -- Returns a Nil_Element_List if there are no such configuration pragmas. -- -- Returns Element_Kinds: -- A_Pragma ------------------------------------------------------------------------------ A particular Asis.Context may well have multiple separate sets of configuration pragmas and deciding which set would apply to a future compilation may well hinge on knowing the future location (which Asis.Container perhaps?) of the future unit. Even delving into the past is a problem. An analysis program that wished to know which configuration pragmas applied to which units would be at a complete loss since it would not have any ready way to know which units might have been affected by the particular set chosen and returned. So, a) Am I correct that there are no interfaces for returning A_Configuration_Compilation unit? (If not, I'd be most curious about why it exists as a Unit_Kind?) b) Does ASIS really wish to pretend that at most one set of configuration pragmas can exist within a Context when that is not the case for Ada compilation systems? c) If so, any advice on what to return given a validated compilation system capable of having many different sets of configuration pragmas within a Context? (A Context may consist of nothing but a collection of libraries and have no obvious component that is "the main program", so determining the set affecting the main program may not be possible. Any other choice seems reminiscent of flipping a coin.) d) If not, how best to proceed? I'm not excited by the idea of heading off and implementing an ASIS 2.0 superset if I can find a better way. Gary E. Barnes From owner-sigada-asis-tech@ACM.ORG Thu Oct 8 20:01:49 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (8.8.8+Sun/SMI-SVR4) id UAA11038; Thu, 8 Oct 1998 20:01:48 -0400 (EDT) Received: from mail.acm.org (mail.acm.org [199.222.69.4]) by cs.ida.org (8.8.7/8.8.7) with ESMTP id UAA24521 for ; Thu, 8 Oct 1998 20:01:47 -0400 (EDT) Received: from mail (mail.acm.org [199.222.69.4]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id TAA42810; Thu, 8 Oct 1998 19:49:17 -0400 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 1332656 for SIGADA-ASIS-TECH@ACM.ORG; Thu, 8 Oct 1998 19:49:15 -0400 Received: from gw.sd.aonix.com (gw.alsys.com [136.175.17.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id TAA31000 for ; Thu, 8 Oct 1998 19:49:11 -0400 Received: from rasht.sd.aonix.com (mailhub.sd.aonix.com [136.175.1.80]) by gw.sd.aonix.com (8.9.1a/8.9.1) with SMTP id QAA17265; Thu, 8 Oct 1998 16:59:10 -0700 (PDT) Received: from puumba.telesoft by rasht.sd.aonix.com (4.1/TS-1.2c) id AA02908; Thu, 8 Oct 98 16:58:15 PDT Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id QAA23624; Thu, 8 Oct 1998 16:58:34 -0700 Message-ID: <199810082358.QAA23624@puumba.telesoft> Date: Thu, 8 Oct 1998 16:58:34 -0700 Reply-To: "Steve Blake @pulsar" Sender: ACM SIGADA ASIS Technical Discussion Group From: "Steve Blake @pulsar" Subject: Re: A_Configuration_Compilation Unit_Kind - seems a bit odd. Comments: To: geb@ACM.ORG To: SIGADA-ASIS-TECH@ACM.ORG Content-Length: 60386 Status: OR This took some digging and recollection. >From owner-sigada-asis-tech@ACM.ORG Mon Oct 5 15:39:02 1998 >Subject: A_Configuration_Compilation Unit_Kind - seems a bit odd. >To: SIGADA-ASIS-TECH@ACM.ORG > >>From the June 1, 1998 ASIS 2.0.Q, > > A_Configuration_Compilation, -- Corresponds to the whole content of a > -- compilation with no compilation_unit, > -- but possibly containing comments, > -- configuration pragmas, or both. > -- Any Context can have at most one unit > -- of A_Configuration_Compilation kind. > -- A unit of A_Configuration_Compilation > -- does not have a name. This unit > -- represents configuration pragmas that > -- are "in effect". > >One curious thing about this compilation Unit_Kind is that there are >apparently no interfaces in the ASIS specification that are capable of >returning a unit having this Unit_Kind. That would lead to the question, why >does this Unit_Kind exist since it serves no purpose for the user of the >interface? > The only interface that returns this unit kind is Enclosing_Compilation_Unit when given A_Pragma element obtained from Configuration_Pragms. This fact did not get documented and that needs to be fixed. >A second curious thing is the comment that "Any Context can have at most one >unit of A_Configuration_Compilation kind." Since a Context is supposed to >model an Ada compilation environment, and since Ada places no restriction on >the number of pragma-only configuration compilations that may occur, why does >ASIS create this restriction? > The limit of one seems to be absolutely wrong. There should be no limit. Configuration pragmas can be introduced from any number of "unitless" compilations. The A_Configuration_Compilation unit kind as the encloser of these pragmas is intended to yield valid unit attributes such as Text_Name. >A specific example would be a compilation context that consists of a user >application area plus some number of separately compiled libraries. Each >library may well have its own set (or sets) of configuration pragmas and >then the application area itself could have a set (or sets). > >Such a situation makes the above comment a bit problematic. It also forces >the Configuration_Pragmas interface into a confusing position. > > function Configuration_Pragmas (The_Context : in Asis.Context) > return Asis.Pragma_Element_List; > >------------------------------------------------------------------------------ >-- The_Context - Specifies the Context to query >-- >-- Returns a list of pragmas that apply to all future compilation_unit elements >-- compiled into The_Context. Pragmas returned by this query should >-- have appeared in a compilation that had no compilation_unit elements. >-- To the extent that order is meaningful, the pragmas should be in >-- their order of appearance in the compilation. (The order is implementation >-- dependent, many pragmas have the same effect regardless of order.) >-- >-- Returns a Nil_Element_List if there are no such configuration pragmas. >-- >-- Returns Element_Kinds: >-- A_Pragma >------------------------------------------------------------------------------ > >A particular Asis.Context may well have multiple separate sets of >configuration pragmas and deciding which set would apply to a future >compilation may well hinge on knowing the future location (which >Asis.Container perhaps?) of the future unit. > The assumption about an ASIS context is that it is a snapshot of the Ada environment at the time the ASIS tool is examining it. If the context is mapped to a set of vendor libraries then there is also the assumption that there is some ordering applied to the set for purpose of compilation unit visibility, config pragma applicability and other such things. The location of the library (ie container) that would hold future compilations seems to be a vendor specific detail or capability not addressed by ASIS. I would say that regardless of which library future compilation might be placed, they are still future and thus the configuration pragma "state" of the environment could only change if the environment were to change. So I feel that during the time an ASIS tool is examining the Context, there can be at most one set of configuration pragmas that apply. >Even delving into the past is a problem. An analysis program that wished to >know which configuration pragmas applied to which units would be at a >complete loss since it would not have any ready way to know which units >might have been affected by the particular set chosen and returned. > >So, > >a) Am I correct that there are no interfaces for returning > A_Configuration_Compilation unit? (If not, I'd be most curious about why > it exists as a Unit_Kind?) > There is just one: Enclosing_Compilation_Unit. >b) Does ASIS really wish to pretend that at most one set of configuration > pragmas can exist within a Context when that is not the case for Ada > compilation systems? I believe so. During the static snapshot ASIS there is only one that applies. While the compilation system can have many sets, each is only applicable in particular views of the Ada environment. Each different environment constitutes a different ASIS context. > >c) If so, any advice on what to return given a validated compilation system > capable of having many different sets of configuration pragmas within a > Context? (A Context may consist of nothing but a collection of libraries > and have no obvious component that is "the main program", so determining > the set affecting the main program may not be possible. Any other choice > seems reminiscent of flipping a coin.) > In multiple library systems there should be one library in the environment that is the default location for compilations. That is the one I would suggest be used to determine the set of config pragmas that apply. >d) If not, how best to proceed? I'm not excited by the idea of heading off > and implementing an ASIS 2.0 superset if I can find a better way. > >Gary E. Barnes > These are good questions that merit some discussion. At the risk of being overly verbose I include a former email thread on the config pragma design discussion. Steve -------------------------------------------------------------------- >From sblake@alsys.com Thu Apr 25 16:36 PDT 1996 Return-Path: Received: from rasht.alsys.com by pulsar.telesoft (5.x/SMI-SVR4) id AA00547; Thu, 25 Apr 1996 16:36:41 -0700 Received: from gw.alsys.com (pet) by rasht.alsys.com (4.1/TS-1.2c) id AA06537; Thu, 25 Apr 96 16:36:35 PDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by gw.alsys.com (4.1/SMI-4.1.1) id AA15504; Thu, 25 Apr 96 16:36:58 PDT Received: from gw.alsys.com by sw-eng.falls-church.va.us (8.7.1/) id XAA11166; Thu, 25 Apr 1996 23:13:18 GMT Received: from rasht.alsys.com (mailhub.alsys.com) by gw.alsys.com (4.1/SMI-4.1.1) id AA15353; Thu, 25 Apr 96 16:13:43 PDT Received: from pulsar.telesoft by rasht.alsys.com (4.1/TS-1.2c) id AA06178; Thu, 25 Apr 96 16:13:18 PDT Received: by pulsar.telesoft (5.x/SMI-SVR4) id AA06377; Thu, 25 Apr 1996 16:13:04 -0700 Date: Thu, 25 Apr 1996 16:13:04 -0700 >From: sblake@alsys.com (Steve Blake @pulsar) Message-Id: <9604252313.AA06377@pulsar.telesoft> To: asis-technical@sw-eng.falls-church.va.us Subject: more on configuration pragmas Content-Type: text Content-Length: 875 Status: RO If we add a query to provide the configuration pragmas from a context, we plug a semantic gap in ASIS. However, this exposes a problem, since now we will have elements (pragmas) that are orphans; they have no enclosing compilation unit and hence, we cannot get the usual attributes such as text_name, Time_Of_Last_Update, etc. A simple solution is to "stretch" the Unit_Kinds type by adding a literal called A_Configuration_Compilation. This would represent a unitless compilation that contains only one or more configuration pragmas. The only way to get such a unit_kind would be from Enclosing_Compilation_Unit given a configuration pragma. Now the A_Configuration_Compilation could be used to get meaningful attributes like those mentioned above. We really need to avoid adding a whole compilation abstraction, just to handle this special case. Comments? Steve >From dewar@gnat.com Thu Apr 25 17:09 PDT 1996 Return-Path: Received: from rasht.alsys.com by pulsar.telesoft (5.x/SMI-SVR4) id AA02659; Thu, 25 Apr 1996 17:09:22 -0700 Received: from gw.alsys.com (pet) by rasht.alsys.com (4.1/TS-1.2c) id AA07050; Thu, 25 Apr 96 17:09:17 PDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by gw.alsys.com (4.1/SMI-4.1.1) id AA15877; Thu, 25 Apr 96 17:09:40 PDT Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id XAA11811; Thu, 25 Apr 1996 23:48:56 GMT Received: by nile.gnat.com (5.0/1.20) id AA01294; Thu, 25 Apr 96 19:48:05 EDT Date: Thu, 25 Apr 96 19:48:05 EDT >From: dewar@gnat.com (Robert Dewar) Message-Id: <9604252348.AA01294@nile.gnat.com> To: asis-technical@sw-eng.falls-church.va.us, sblake@alsys.com Subject: Re: more on configuration pragmas Content-Type: text Content-Length: 428 Status: RO "We really need to avoid adding a whole compilation abstraction, just to handle this special case." Now that compilations have semantics in Ada 95,I think you definitely need a compilatoin abstraction. FOr instance when you get the configuration pragmas for a given unit, you need to be able to distingiush between a) those that apply only to the compilation in which the unit occurs b) those that apply to the entre library >From Serge.Rybin@lglsun.epfl.ch Fri Apr 26 03:52 PDT 1996 Return-Path: Received: from rasht.alsys.com by pulsar.telesoft (5.x/SMI-SVR4) id AA13043; Fri, 26 Apr 1996 03:52:11 -0700 Received: from gw.alsys.com (pet) by rasht.alsys.com (4.1/TS-1.2c) id AA00657; Fri, 26 Apr 96 03:52:09 PDT Received: from sicmail.epfl.ch by gw.alsys.com (4.1/SMI-4.1.1) id AA19505; Fri, 26 Apr 96 03:51:14 PDT Received: from lglsun7.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <19490-0@sicmail.epfl.ch>; Fri, 26 Apr 1996 12:46:16 +0200 Received: by lglsun7.epfl.ch (5.x/Epfl-4.11-c/MX) id AA05432; Fri, 26 Apr 1996 12:46:14 +0200 Date: Fri, 26 Apr 1996 12:46:14 +0200 >From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) Message-Id: <9604261046.AA05432@lglsun7.epfl.ch> To: asis-technical@sw-eng.falls-church.va.us, sblake@alsys.com, dewar@gnat.com Subject: Re: more on configuration pragmas Cc: Alfred.Strohmeier@di.epfl.ch X-Sun-Charset: US-ASCII Content-Type: text Content-Length: 6001 Status: RO Steve writes: "If we add a query to provide the configuration pragmas from a context, we plug a semantic gap in ASIS. However, this exposes a problem, since now we will have elements (pragmas) that are orphans; they have no enclosing compilation unit and hence, we cannot get the usual attributes such as text_name, Time_Of_Last_Update, etc. A simple solution is to "stretch" the Unit_Kinds type by adding a literal called A_Configuration_Compilation. This would represent a unitless compilation that contains only one or more configuration pragmas. The only way to get such a unit_kind would be from Enclosing_Compilation_Unit given a configuration pragma. Now the A_Configuration_Compilation could be used to get meaningful attributes like those mentioned above. We really need to avoid adding a whole compilation abstraction, just to handle this special case." And Robert replies: "Now that compilations have semantics in Ada 95,I think you definitely need a compilatoin abstraction. FOr instance when you get the configuration pragmas for a given unit, you need to be able to distingiush between a) those that apply only to the compilation in which the unit occurs b) those that apply to the entre library" I would agree with Steve, that ASIS should avoid a whole compilation abstraction. ASIS already has Context for Ada environment, and ASIS Compilation Unit for Ada compilation unit. It would complicate the ASIS situation too much if we add the ASIS notion (that is, the new ASIS type and corresponding queries) for Ada compilation. >From the other side, Robert is definitely right, that the cases a) and b) should be distingishable by means of ASIS queries. RM 95 10.1.5 (8) says: Post-Compilation Rules (8) Certain pragmas are defined to be configuration pragmas; they shall appear before the first compilation_unit of a compilation. They are generally used to select a partition-wide or system-wide option. The pragma applies to all compilation_units appearing in the compilation, unless there are none, in which case it applies to all future compilation_units compiled into the same environment. So, I would complete Steve's suggestion by suggesting to add to ASIS a new query, which would have a configuration pragma as its argument, and which would return a list of the ASIS Compilation_Units affected by this pragma. My point is, that an ASIS application would hardly be interested in the *compilation* in which a given configuration pragma has been placed, but it might be interested in the units affected by this pragma. And one general remark about the general problem of ASIS specification conformance to RM 95. If we would like to see ASIS 95 as an international standard, it should not contadict RM 95, and any formal contradiction between ASIS 95 and RM 95 would be a serious barrier for ASIS standardization process. The question is - what may, and what should be considered as a contadiction between ASIS 95 and RM 95? RM 95 is the definition of Ada 95 programming language. ASIS 95 is the definition of the way of obtaining some (not necessary all!) information about some (not necessary all!) objects defined by RM 95. For sure, all the information obtained through ASIS should be only about the objects defined by RM, and this information should be correct in respect to RM. But, I think, we shoul NOT require, that the WAY of obtaining this information should correspond to the WAY of defining Ada language in RM. If ASIS uses a RM-defined notion, it should use it in a RM-defined way. But ASIS does not have to use ALL RM-defined notions! And there is no harm to use ASIS-defined notions in ASIS-defined sense (of course, the less such "own" notions ASIS has - the better.) And now about the situation with configuration pragmas. Suppose, that ASIS has the notion of a configuration pragma. If ASIS is able to get the list of configuration pragmas contained into environment on their own, and for any configuration pragma (independently on the fact, whether or not this pragma is followed by some unit(s) in its "enclosing compilation") ASIS is able to get the list of "affected" units, this means, that ASIS can get useful information. And if ASIS does not contain the notion of compilation, and if it is not able to yield any information about the compilation in which a given configuration has appead, this mean, that ASIS can yield not all, but only partial information from the environment. Another problem is that the current ASIS specification contains some definitions, that really contradict with RM 95. For example, recently Robert pointed me out, that the Clauses.Representation_Clause_Name query must not return an Element of An_Attribute_Reference kind, because, according to RM-defined syntax, the corresponding clauses do NOT contain attribute reference as their structural component. (They contain ONLY attribute designator). Another (and a very hard) example is the situation with ASIS implicit elements). If we try make ASIS following the RM *WAY* of defining Ada language, we would get the document twice bigger, then RM 95, defining something about 1000 queries. So ASIS has to use some technique to shorten and to simplify the way of obtaining information about Ada program. If we use some definitions, which really contadict with what (not "*how*", but namely "*what*") is defined in RM, we would never see ASIS as international standard. So we really have a problem here. (By the way, I've failed to find in RM 95 any formal worlds stating, that configration pragmas can be inserted into environment on its own. All the discussions concerning environment, which I can find in RM, are about the environment and Ada compilation units only. Are general rules about pragmas from RM 2.8 and syntax enough to conclude, that configuration pragmas on their own may be contained into environment along with compilation units?) Sergey Rybin. >From dewar@gnat.com Fri Apr 26 06:36 PDT 1996 Return-Path: Received: from rasht.alsys.com by pulsar.telesoft (5.x/SMI-SVR4) id AA13339; Fri, 26 Apr 1996 06:35:41 -0700 Received: from gw.alsys.com (pet) by rasht.alsys.com (4.1/TS-1.2c) id AA05188; Fri, 26 Apr 96 06:36:01 PDT Received: from nile.gnat.com by gw.alsys.com (4.1/SMI-4.1.1) id AA20997; Fri, 26 Apr 96 06:36:15 PDT Received: by nile.gnat.com (5.0/1.20) id AA18725; Fri, 26 Apr 96 09:26:34 EDT Date: Fri, 26 Apr 96 09:26:34 EDT >From: dewar@gnat.com (Robert Dewar) Message-Id: <9604261326.AA18725@nile.gnat.com> To: Serge.Rybin@lglsun.epfl.ch, asis-technical@sw-eng.falls-church.va.us, dewar@gnat.com, sblake@alsys.com Subject: Re: more on configuration pragmas Cc: Alfred.Strohmeier@di.epfl.ch Content-Type: text Content-Length: 1135 Status: RO Fine, there is no requirement that things match up exactly, but if you DON'T match up the semantic model between ASIS and Ada 95 exactly, you will constantly make mistakes: Consider as a nice example Sergey's suggestion: "So, I would complete Steve's suggestion by suggesting to add to ASIS a new query, which would have a configuration pragma as its argument, and which would return a list of the ASIS Compilation_Units affected by this pragma. My point is, that an ASIS application would hardly be interested in the *compilation* in which a given configuration pragma has been placed, but it might be interested in the units affected by this pragma." This is not good enough, because in the case where a complete program is a compilation, you cannot tell whether a given configuratoin pragma was or was not part of the compilation, or whether it was separate compiled as a compilation of its own. This distinction will be CRITICALLY important for figuring out what is going on with configuration pragmas. The whole business of configuration pragmas is a much bigger earthquake to the language semantics than people are aware of! >From Serge.Rybin@lglsun.epfl.ch Fri Apr 26 07:42 PDT 1996 Return-Path: Received: from rasht.alsys.com by pulsar.telesoft (5.x/SMI-SVR4) id AA13827; Fri, 26 Apr 1996 07:42:31 -0700 Received: from gw.alsys.com (pet) by rasht.alsys.com (4.1/TS-1.2c) id AA07166; Fri, 26 Apr 96 07:42:30 PDT Received: from sicmail.epfl.ch by gw.alsys.com (4.1/SMI-4.1.1) id AA22443; Fri, 26 Apr 96 07:42:40 PDT Received: from lglsun7.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <27987-0@sicmail.epfl.ch>; Fri, 26 Apr 1996 16:39:21 +0200 Received: by lglsun7.epfl.ch (5.x/Epfl-4.11-c/MX) id AA05516; Fri, 26 Apr 1996 16:39:18 +0200 Date: Fri, 26 Apr 1996 16:39:18 +0200 >From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) Message-Id: <9604261439.AA05516@lglsun7.epfl.ch> To: Serge.Rybin@lglsun.epfl.ch, asis-technical@sw-eng.falls-church.va.us, dewar@gnat.com, sblake@alsys.com Subject: Re: more on configuration pragmas Cc: Alfred.Strohmeier@di.epfl.ch X-Sun-Charset: US-ASCII Content-Type: text Content-Length: 1849 Status: RO I have to agree twice, but I also have one objection. > Fine, there is no requirement that things match up exactly, but if you > DON'T match up the semantic model between ASIS and Ada 95 exactly, you > will constantly make mistakes: I agree with this. Moreover, I personally would prefer to see ASIS 95 as close to RM 95, as possible. > Consider as a nice example Sergey's suggestion: And here I have an objection - I do agree, that my suggestion remains some problems open, but I do not agree, that this is a mistake, unless we consider missing the information about compilations as a mistake. I would consider my suggestion as a compromise - it would allow to get some useful information without introducing new (significant) complexity in the ASIS specification. > > "So, I would complete Steve's suggestion by suggesting to add to > ASIS a new query, which would have a configuration pragma as its argument, > and which would return a list of the ASIS Compilation_Units affected by > this pragma. My point is, that an ASIS application would hardly be interested > in the *compilation* in which a given configuration pragma has been placed, > but it might be interested in the units affected by this pragma." > > This is not good enough, because in the case where a complete program is > a compilation, you cannot tell whether a given configuratoin pragma was > or was not part of the compilation, or whether it was separate compiled > as a compilation of its own. This distinction will be CRITICALLY important > for figuring out what is going on with configuration pragmas. Yes, we need the notion of compilation to answer questions like this. > The whole business of configuration pragmas is a much bigger earthquake > to the language semantics than people are aware of! ASIS users, where you are? Please, comment this! Sergey >From eachus@spectre.mitre.org Fri Apr 26 08:32 PDT 1996 Return-Path: Received: from rasht.alsys.com by pulsar.telesoft (5.x/SMI-SVR4) id AA15013; Fri, 26 Apr 1996 08:32:32 -0700 Received: from gw.alsys.com (pet) by rasht.alsys.com (4.1/TS-1.2c) id AA08224; Fri, 26 Apr 96 08:32:31 PDT Received: from mbunix.mitre.org by gw.alsys.com (4.1/SMI-4.1.1) id AA23969; Fri, 26 Apr 96 08:32:19 PDT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.6.10/8.6.9) with ESMTP id LAA08358; Fri, 26 Apr 1996 11:29:17 -0400 Received: from localhost (eachus@localhost) by spectre.mitre.org (8.6.4/8.6.4) id LAA10568; Fri, 26 Apr 1996 11:29:16 -0400 Date: Fri, 26 Apr 1996 11:29:16 -0400 >From: "Robert I. Eachus" Message-Id: <199604261529.LAA10568@spectre.mitre.org> To: asis-technical@sw-eng.falls-church.va.us Cc: Serge.Rybin@lglsun.epfl.ch, dewar@gnat.com Cc: Alfred.Strohmeier@di.epfl.ch, sblake@alsys.com In-Reply-To: <9604261046.AA05432@lglsun7.epfl.ch> (Serge.Rybin@lglsun.epfl.ch) Subject: Re: more on configuration pragmas Content-Type: text Content-Length: 1644 Status: RO I thought I saw an answer here, but 10.1.5(8) makes it legal for an implementation to support configuration pragmas as compilation units which only affect future units compiled into the library. So there are really two different questions: 1) Which configuration pragmas applied to THIS compilation unit when it was compiled? Answering this question is within the current ASIS model. 2) If I compile a compilation in this environment which does not contain configuration pragmas, which configuration pragmas apply? Looking at the two non-annex configuration pragmas (Suppress and Restrictions) it seems clear that many implementations will allow Suppress not only as a configuration pragma in a non-empty library, but to appear several times. The only behavior I can suggest without adding a "new" abstraction to ASIS is to allow an ASIS user access to the body of Standard. This unfortunately imposes a burden on implementations which use the GNAT style library model, since they have to track when configuration pragmas go into and out of force. However, if they support the full generality of configuration pragmas, they have to do most of this anyway. For example, a compilation of a of a library specification or generic unit is subject to the compilation pragma values in force was entered into the library, even if they have since been overridden, or are overridden in the current compilation. (Otherwise you would have inconsistant views of the library unit.) Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... >From eachus@spectre.mitre.org Mon Apr 29 09:01 PDT 1996 Return-Path: Received: from rasht.alsys.com by pulsar.telesoft (5.x/SMI-SVR4) id AA17568; Mon, 29 Apr 1996 09:01:40 -0700 Received: from gw.alsys.com (pet) by rasht.alsys.com (4.1/TS-1.2c) id AA02249; Mon, 29 Apr 96 09:01:28 PDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by gw.alsys.com (4.1/SMI-4.1.1) id AA17162; Mon, 29 Apr 96 09:01:42 PDT Received: from mbunix.mitre.org by sw-eng.falls-church.va.us (8.7.1/) id PAA21225; Mon, 29 Apr 1996 15:39:38 GMT Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.6.10/8.6.9) with ESMTP id LAA19221; Mon, 29 Apr 1996 11:40:19 -0400 Received: from localhost (eachus@localhost) by spectre.mitre.org (8.6.4/8.6.4) id LAA15387; Mon, 29 Apr 1996 11:40:12 -0400 Date: Mon, 29 Apr 1996 11:40:12 -0400 >From: "Robert I. Eachus" Message-Id: <199604291540.LAA15387@spectre.mitre.org> To: dewar@gnat.com Cc: asis-technical@sw-eng.falls-church.va.us In-Reply-To: <9604271457.AA29292@nile.gnat.com> (dewar@gnat.com) Subject: Re: more on configuration pragmas Content-Type: text Content-Length: 1994 Status: RO Robert Dewar said: > That's wrong, there is no burden, of course GNAT handles this fine, > it must! I thought that GNAT took advantage of 10.1.5(9) for some configuration pragmas. But my real point was that, if you don't, you could end up with two different configuration states applying to the same package specification, which makes zero sense. You either have to 1) require compilation to enter a unit into a library, which gnat doesn't do, 2) confine a library to a single directory, which again gnat doesn't do, 3) decide that configuration pragmas cannot be applied to a parent library once a descendant has been created, which gnat doesn't do, or 4) limit configuration pragmas compiled as stand alone units. For some pragmas, it probably isn't necessary, and I guess you could point to other implementation permissions than 10.1.5(9) such as D.4(15) for Queuing_Policy. But pragma Restrictions is a problem. Take for example No_Task_Allocators. At what point do you decide that a package specification is subject to a No_Task_Allocators restriction? (Note that if it is, the restriction applies to any program containing that package specification.) The problem case is if I have package specifications in one directory, and bodies in another. I can change package specifications without ever handing a unit in the parent library/directory explicitly to the compiler. I just assumed that you only allowed pragma Restrictions as a configuration pragma in an empty library, or applied as a part of one or more compilation units. (Incidently, I am not trying to generate pathological cases for ACVC tests. I would be perfectly happy with a "policy" on pragma restrictions which said that any restriction applied to any unit in the library/directory implictly applied to all programs linked in that directory.) Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... >From dewar@gnat.com Mon Apr 29 09:23 PDT 1996 Return-Path: Received: from rasht.alsys.com by pulsar.telesoft (5.x/SMI-SVR4) id AA17864; Mon, 29 Apr 1996 09:23:11 -0700 Received: from gw.alsys.com (pet) by rasht.alsys.com (4.1/TS-1.2c) id AA02886; Mon, 29 Apr 96 09:22:58 PDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by gw.alsys.com (4.1/SMI-4.1.1) id AA17555; Mon, 29 Apr 96 09:23:12 PDT Received: from nile.gnat.com by sw-eng.falls-church.va.us (8.7.1/) id QAA21997; Mon, 29 Apr 1996 16:04:17 GMT Received: by nile.gnat.com (5.0/1.20) id AA10817; Mon, 29 Apr 96 12:03:25 EDT Date: Mon, 29 Apr 96 12:03:25 EDT >From: dewar@gnat.com (Robert Dewar) Message-Id: <9604291603.AA10817@nile.gnat.com> To: dewar@gnat.com, eachus@spectre.mitre.org Subject: Re: more on configuration pragmas Cc: asis-technical@sw-eng.falls-church.va.us Content-Type: text Content-Length: 1042 Status: RO " For some pragmas, it probably isn't necessary, and I guess you could point to other implementation permissions than 10.1.5(9) such as D.4(15) for Queuing_Policy. But pragma Restrictions is a problem. Take for example No_Task_Allocators. At what point do you decide that a package specification is subject to a No_Task_Allocators restriction? (Note that if it is, the restriction applies to any program containing that package specification.) The problem case is if I have package specifications in one directory, and bodies in another. I can change package specifications without ever handing a unit in the parent library/directory explicitly to the compiler." No_Task_Allocators has to be consistent for all units in a partition, and the binder checks this. We record in the ali files (or wlil, this is not all coded yet), what configuratoin pragmas applied to a particular compilation. So of your possibilities, we actualy "enter the unit into a library", where library here is simply a record of the copilation in the ali file. >From dewar@gnat.com Mon Apr 29 17:05 PDT 1996 Return-Path: Received: from rasht.alsys.com by pulsar.telesoft (5.x/SMI-SVR4) id AA26604; Mon, 29 Apr 1996 17:04:45 -0700 Received: from gw.alsys.com (pet) by rasht.alsys.com (4.1/TS-1.2c) id AA16816; Mon, 29 Apr 96 17:04:44 PDT Received: from nile.gnat.com by gw.alsys.com (4.1/SMI-4.1.1) id AA27626; Mon, 29 Apr 96 17:04:58 PDT Received: by nile.gnat.com (5.0/1.20) id AA24074; Mon, 29 Apr 96 19:52:01 EDT Date: Mon, 29 Apr 96 19:52:01 EDT >From: dewar@gnat.com (Robert Dewar) Message-Id: <9604292352.AA24074@nile.gnat.com> To: dewar@gnat.com, eachus@spectre.mitre.org, sblake@alsys.com Subject: Re: more on configuration pragmas Cc: asis-technical@sw-eng.falls-church.va.us Content-Type: text Content-Length: 745 Status: RO "1. Compilation has less formal definition in the RM than environment. The representation of a compilation is implementation defined, and the ramifications are wide spread. See AARM 10.1(2b)." That's wrong I think. Compilation is a rigorously defined syntactic term, with production rules just like any other syntctic entity: 10.1.1(2) 2 compilation ::= {compilation_unit} Yes, of course the representation of a cmpilation is implementatoin dependent, it is no more nor less implementaton dependent than any other aspect of a concrete program. Source repreesntation is comletely outside the standard, and always has been. That being said, I think your proposal for handling compilaton semantics seems complete and straigtforward. >From danr@spartan.ssd.hcsc.com Tue Apr 30 06:36 PDT 1996 Return-Path: Received: from rasht.alsys.com by pulsar.telesoft (5.x/SMI-SVR4) id AA02910; Tue, 30 Apr 1996 06:36:14 -0700 Received: from gw.alsys.com (pet) by rasht.alsys.com (4.1/TS-1.2c) id AA06333; Tue, 30 Apr 96 06:36:14 PDT Received: from hawk.hcsc.com (ns.hcsc.com) by gw.alsys.com (4.1/SMI-4.1.1) id AA02872; Tue, 30 Apr 96 06:36:29 PDT Received: from tawny.ssd.hcsc.com by hawk.hcsc.com (5.61/harris-5.1) id AA24193; Tue, 30 Apr 96 09:31:18 -0400 Received: by tawny.ssd.csd.harris.com (5.61/CX/UX-7.1) id AA04398; Tue, 30 Apr 96 09:31:16 -0400 Received: by spartan.ssd.csd.harris.com (5.61/HARRIS-4.0) id AA02663; Tue, 30 Apr 96 12:29:41 GMT >From: danr@spartan.ssd.hcsc.com (Dan Rittersdorf) Message-Id: <9604301229.AA02663@spartan.ssd.csd.harris.com> Subject: Re: more on configuration pragmas To: tawny!alsys.com!sblake (Steve Blake @pulsar) Date: Tue, 30 Apr 1996 08:29:40 -0400 (EDT) Cc: dewar@gnat.com, eachus@spectre.mitre.org, asis-technical@sw-eng.falls-church.va.us In-Reply-To: <9604292043.AA22040@pulsar.telesoft> from "Steve Blake @pulsar" at Apr 29, 96 01:43:51 pm Reply-To: Dan.Rittersdorf@mail.hcsc.com X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 5695 Status: RO Steve, > > I don't believe ASIS needs an abstraction for Compilations. > > I base this on these reasons: > ... > > Let me illustrate the solution: > > There are two ways to get compilation pragmas: > > 1. Apply function Compilation_Pragmas to a Compilation_Unit. > > This will provide config pragmas that are applied to the CU in two ways: > 1. Those that appear in the text of the compilation of the Compilation_Unit. > 2. Those that have been applied "in force" to the environment prior to the > compilation of the CU. > > Pragmas "in force" may be overridden by pragmas that appear in the text. > Duplicates should be allowed but not required. > > If a compilation contains config pragmas that apply to more than one CU in > the compilation, then the Compilation_Pragmas will return the same list of > config pragmas when given each of the compilation's CUs. Corresponding > pragmas in each list will be Is_Equal. > > The Enclosing_Compilation_Unit of each pragma will be: > a) the "Compilation" represented by the new proposed Unit_Kind literal > "A_Configuration_Compilation" if the pragma was applied to the > environment. > b) the CU given as the argument to Compilation_Pragmas if the pragma > appeared in the text of the CU. > Good. This takes care of the "historical" issue. > > 2. Apply function Configuration_Pragmas to an Asis.Context. > > This will provide config pragmas that are applied to the Ada environment at > the current time, and thus apply to future CUs. > > The Enclosing_Compilation_Unit of each pragma will be the "Compilation" > represented by the new proposed Unit_Kind literal > "A_Configuration_Compilation" if the pragma was applied to the environment. > As well as the "current state" issue. These were the biggest worries I had about representing config pragmas. Very good. > > Now, ASIS programs can tell where the pragmas came from and how they were > applied. Since A_Configuration_Compilation is a Unit_Kind, the usual > attributes can be queried. > It should be well documented that the configuration pragma Elements obtained from the Compilation_Unit may not be in the list of configuration pragma Elements obtained from the Context. Some may have been "removed" (in an implementation-dependent manner) from the environment after compiling the compilation_unit. <> (Hmmm, is this allowed? I don't think so.) Imagine if some configiuration pragmas are in a source file "config.a", and you have an environmental management tool, say "a.rm" that could remove all pragmas or compilation units originating from a file. This may make it possible to take these pragmas "out of force" after some units have already been compiled. Are they still required to remain "in force" for future compilations in that environment? Or is leeway granted for this sort of ability? <> > > > Example: > > Compilation 1: pragma Foo(On); pragma Bar; -- assume Foo, Bar config pragmas > > Compilation 2: pragma Bar; procedure A; > > Compilation 3: pragma Bar; pragma Foo_Bar; -- more config pragmas > > Compilation 4: pragma Foo(Off); procedure B; procedure C; > > After compiling compliations 1,2, 3 and 4 into Context, we have: > > Configuration_Pragmas(Context) returns list of two: pragma Foo(On); pragma Bar;. > Enclosing_Compilation_Unit(pragma Foo(On);) is A_Configuration_Compilation > Unit_Kind representing Compilation 1. Same with Bar. > > Compilation_Pragmas(A) returns list of two: pragma Foo(On); pragma Bar;. > Enclosing_Compilation_Unit(pragma Foo(On);) is A_Configuration_Compilation > Unit_Kind representing Compilation 1. > Enclosing_Compilation_Unit(pragma Bar;) is A. > We can't require ASIS implementations to return the pragma Bar from > Compilation 1. However it is permitted and if returned, its > Enclosing_Compilation_Unit would be the A_Configuration_Compilation > representing Compilation 1. The two pragmas Bar would not be Is_Equal. > > Configuration_Pragmas(Context) returns list of three: pragma Foo(On); > pragma Bar; pragma Foo_Bar. > Enclosing_Compilation_Unit(pragma Foo(On);) is A_Configuration_Compilation > Unit_Kind representing Compilation 1. > Enclosing_Compilation_Unit(pragma Bar;) is A_Configuration_Compilation > Unit_Kind representing Compilation 3. Same with Foo_Bar. > Will the "pragma Foo(On)" from Compilation__Pragmas(A) be Is_Equal to that from Compilation_Pragmas(Context)? I believe they should be, but that may be difficult to implement. > > I am not aware of additional semantics of compilations. If there are any, > please let me know. > > Steve Blake > Pending resolution of the last question I had, I have to say, this looks sufficient to represent the semantics of compilations -- with the exception that I can't determine which compilation_units were compiled together. I don't feel that information is worth the effort of modeling compilations in a more concrete fashion, especially after trying to add the abstraction myself. Thanks for the excelent examples, Steve. -- ______________________________________________________________________________ Dan.Rittersdorf@Mail.HCSC.Com 178 Washington Street Harris Computer Systems Corporation Sparta, MI 49345-1324 Ft. Lauderdale FL 33309 Phone: +1 (616) 887-5431 ______________________________________________________________________________ >From Serge.Rybin@lglsun.epfl.ch Tue Apr 30 11:53 PDT 1996 Return-Path: Received: from rasht.alsys.com by pulsar.telesoft (5.x/SMI-SVR4) id AA08408; Tue, 30 Apr 1996 11:53:06 -0700 Received: from gw.alsys.com (pet) by rasht.alsys.com (4.1/TS-1.2c) id AA14301; Tue, 30 Apr 96 11:53:05 PDT Received: from sicmail.epfl.ch by gw.alsys.com (4.1/SMI-4.1.1) id AA08906; Tue, 30 Apr 96 11:53:17 PDT Received: from lglsun7.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <17047-0@sicmail.epfl.ch>; Tue, 30 Apr 1996 20:44:46 +0200 Received: by lglsun7.epfl.ch (5.x/Epfl-4.11-c/MX) id AA07701; Tue, 30 Apr 1996 20:44:42 +0200 Date: Tue, 30 Apr 1996 20:44:42 +0200 >From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) Message-Id: <9604301844.AA07701@lglsun7.epfl.ch> To: dewar@gnat.com, eachus@spectre.mitre.org, sblake@alsys.com Subject: Re: more on configuration pragmas Cc: asis-technical@sw-eng.falls-church.va.us X-Sun-Charset: US-ASCII Content-Type: text Content-Length: 8050 Status: RO Steve, in general your suggestion concering Configuration Pragmas looks good, but I am expecting some problems, and I an almost ready to ask some questions... Below is the first attempt :) > I don't believe ASIS needs an abstraction for Compilations. > > I base this on these reasons: > > 1. Compilation has less formal definition in the RM than environment. The > representation of a compilation is implementation defined, and the > ramifications are wide spread. See AARM 10.1(2b). > > 2. The value provided by the abstraction is not worth the effort and would > clutter an already busy interface. I entirely support both of these points. > 3. A simple solution provides all the semantics for compilations. > Add Unit_Kind A_Configuration_Compilation to represent unitless compilations > containing configuration pragmas. The main problem I am afraid of is, that compilation pragmas introduce the *historical* issues in the ASIS world. For example, what do you think about the situation, when come configuration pragma was inserted into environment, then some compilation units were compiled (affected by this pragma), and then this pragma was removed. Should this situation be considered just in the same way, if some supporter of a given unit was removed from the environment? But this is not the problem introduced by your suggestion - this is the problem with the definition of the semantics of compilation pragmas in RM 95. And - see a bit below - can we really speak about configuration pragmas as about some objects (entities???), which can be insetrted in and obtained from an Ada environment? > Let me illustrate the solution: > > There are two ways to get compilation pragmas: > > 1. Apply function Compilation_Pragmas to a Compilation_Unit. > > This will provide config pragmas that are applied to the CU in two ways: > 1. Those that appear in the text of the compilation of the Compilation_Unit. > 2. Those that have been applied "in force" to the environment prior to the > compilation of the CU. > > Pragmas "in force" may be overridden by pragmas that appear in the text. > Duplicates should be allowed but not required. > > If a compilation contains config pragmas that apply to more than one CU in > the compilation, then the Compilation_Pragmas will return the same list of > config pragmas when given each of the compilation's CUs. Corresponding > pragmas in each list will be Is_Equal. > > The Enclosing_Compilation_Unit of each pragma will be: > a) the "Compilation" represented by the new proposed Unit_Kind literal > "A_Configuration_Compilation" if the pragma was applied to the > environment. > b) the CU given as the argument to Compilation_Pragmas if the pragma > appeared in the text of the CU. > > > 2. Apply function Configuration_Pragmas to an Asis.Context. > > This will provide config pragmas that are applied to the Ada environment at > the current time, and thus apply to future CUs. > > The Enclosing_Compilation_Unit of each pragma will be the "Compilation" > represented by the new proposed Unit_Kind literal > "A_Configuration_Compilation" if the pragma was applied to the environment. What do you think about a function, which would say, what configuration pragmas affect the unit given as its argument? Would it be useful? Should it be a secondary query only? And now - the main question, which originates from some thoughts abot the terminological issues: RM 95 defines, what does it mean to compile a compilation unit into environment, but it does not say, that the result of a compilation (process) may or have to change an environment in any way. RM 95 stated, that the way of inserting COMPILATION UNITS (as Ada technical term!) (note - namely compilation units, and not configuration pragmas!) into environment is implementation-defined. >From the other side, 10.1.5 (8) says only that: Post-Compilation Rules (8) Certain pragmas are defined to be configuration pragmas; they shall appear before the first compilation_unit of a compilation. They are generally used to select a partition-wide or system-wide option. The pragma applies to all compilation_units appearing in the compilation, unless there are none, in which case it applies to all future compilation_units compiled into the same environment. Does this give enough formal background to conclude, that a compilation pragma (compiled on its own, without following compilation unit) may also be considered as inserted into environment? Another interpretation may be possible, and it looks as being more close to RM 95 in the formal sense: Configuration pragma is NOT incerted into environment, but being COMPILED, it changes the STATE of A COMPILER. As a result, it may affect the results of the following COMPILATIONS (as processes), but it may NOT affect the CONTENT of the ENVIRONMENT in which, according to RM 10.1.4(1) every COMPILATION (as a process) takes place. I would even say, that it is THE ONLY formally correct interpretation of RM 95, concerning the relations between compilation units, configuration pragmas, compilations (as processes) and environment. But it is very formal. May it be useful? > Now, ASIS programs can tell where the pragmas came from and how they were > applied. Since A_Configuration_Compilation is a Unit_Kind, the usual > attributes can be queried. How many ASIS Compilation Units of A_Configuration_Compilation kind may be contained into the same ASIS Context? Can the Name query be applied for a Compilation Unit of A_Configuration_Compilation kind? And what may be the meaning of the result? I'm afraid, too many questions about ASIS Compilation Units of A_Configuration_Compilation kind will have "implementation-defined" as an answer. > > > > Example: > > Compilation 1: pragma Foo(On); pragma Bar; -- assume Foo, Bar config pragmas > > Compilation 2: pragma Bar; procedure A; > > Compilation 3: pragma Bar; pragma Foo_Bar; -- more config pragmas > > Compilation 4: pragma Foo(Off); procedure B; procedure C; > > After compiling compliations 1,2, 3 and 4 into Context, we have: > ***** 1 ***** > Configuration_Pragmas(Context) returns list of two: pragma Foo(On); pragma Bar;. > Enclosing_Compilation_Unit(pragma Foo(On);) is A_Configuration_Compilation > Unit_Kind representing Compilation 1. Same with Bar. ****** 1 ***** > > Compilation_Pragmas(A) returns list of two: pragma Foo(On); pragma Bar;. > Enclosing_Compilation_Unit(pragma Foo(On);) is A_Configuration_Compilation > Unit_Kind representing Compilation 1. > Enclosing_Compilation_Unit(pragma Bar;) is A. > We can't require ASIS implementations to return the pragma Bar from > Compilation 1. However it is permitted and if returned, its > Enclosing_Compilation_Unit would be the A_Configuration_Compilation > representing Compilation 1. The two pragmas Bar would not be Is_Equal. > ****** 2 ****** > Configuration_Pragmas(Context) returns list of three: pragma Foo(On); > pragma Bar; pragma Foo_Bar. > Enclosing_Compilation_Unit(pragma Foo(On);) is A_Configuration_Compilation > Unit_Kind representing Compilation 1. > Enclosing_Compilation_Unit(pragma Bar;) is A_Configuration_Compilation > Unit_Kind representing Compilation 3. Same with Foo_Bar. ****** 2 ****** Shame on me, I cannot follow, why Configuration_Pragmas(Context) in *** 1 *** and *** 2 *** give different results. > Compilation_Pragmas(B) returns list of three: pragma Foo(Off); pragma Bar; > pragma Foo_Bar;. > Enclosing_Compilation_Unit(pragma Foo(Off);) is B. > Enclosing_Compilation_Unit(pragma Bar;) is A_Configuration_Compilation > Unit_Kind representing Compilation 3. Same with Foo_Bar. > > > > I am not aware of additional semantics of compilations. If there are any, > please let me know. > > Steve Blake > Sergey Rybin. >From Serge.Rybin@lglsun.epfl.ch Wed May 1 14:12 PDT 1996 Return-Path: Received: from rasht.alsys.com by pulsar.telesoft (5.x/SMI-SVR4) id AA12253; Wed, 1 May 1996 14:11:42 -0700 Received: from gw.alsys.com (pet) by rasht.alsys.com (4.1/TS-1.2c) id AA00553; Wed, 1 May 96 14:11:32 PDT Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by gw.alsys.com (4.1/SMI-4.1.1) id AA00373; Wed, 1 May 96 14:11:44 PDT Received: from sicmail.epfl.ch by sw-eng.falls-church.va.us (8.7.1/) id SAA01179; Wed, 1 May 1996 18:10:56 GMT Received: from lglsun7.epfl.ch by sicmail.epfl.ch with SMTP (PP) id <06940-0@sicmail.epfl.ch>; Wed, 1 May 1996 20:09:21 +0200 Received: by lglsun7.epfl.ch (5.x/Epfl-4.11-c/MX) id AA08165; Wed, 1 May 1996 20:09:19 +0200 Date: Wed, 1 May 1996 20:09:19 +0200 >From: Serge.Rybin@lglsun.epfl.ch (Serge Rybin) Message-Id: <9605011809.AA08165@lglsun7.epfl.ch> To: Serge.Rybin@lglsun.epfl.ch, dewar@gnat.com, eachus@spectre.mitre.org, sblake@alsys.com Subject: Re: more on configuration pragmas Cc: asis-technical@sw-eng.falls-church.va.us X-Sun-Charset: US-ASCII Content-Type: text Content-Length: 11420 Status: RO Steve, my main aim now is "to test" your suggestion from the ASIS standardization viewpoint. So, I am still going to ask new questions :) (In general, I like your suggestion, and I do not have anything as an alternative. But it would be better to ask as many "test questions" as possible now, but not a half a year late :) > >>>>>> > The main problem I am afraid of is, that compilation pragmas introduce the > *historical* issues in the ASIS world. For example, what do you think about > the situation, when come configuration pragma was inserted into environment, > then some compilation units were compiled (affected by this pragma), and then > this pragma was removed. Should this situation be considered just in the > same way, if some supporter of a given unit was removed from the environment? > > But this is not the problem introduced by your suggestion - this is the > problem with the definition of the semantics of compilation pragmas in RM 95. > > And - see a bit below - can we really speak about configuration pragmas as > about some objects (entities???), which can be insetrted in and obtained > from an Ada environment? > >>>>>> > > I don't think a complete history is required. Configuration pragmas applied > to an environment from the ASIS view just indicate the "current" state and > tell what will apply to future compilation units. An ASIS tool should be > able to reconstruct a history by analyzing the compilation units and the > dates and sources of config pragmas associated with them. In general, I'm almost ready to agree with this. But I still have some questions. You say: "... by analyzing the compilation units and the dates and sources of config pragmas associated with them" 1. What do you mean by "analyzing the sources of config pragmas" here. Now I'm afraid of any using of the word "source", when speaking about ASIS 95. (It started, when Robert explained me, that in some very important sense GNAT was NOT a source-based Ada implementation 8( So ASIS-for-GNAT also should not be (completely) "source-based" 8(( :) 2. How are you going to analyse dates? The only means we have is Asis_Compilation_Units.Time_Of_Last_Update, is not it? Let's consider its definition: ------------------------------------------------------------------------------ function Time_Of_Last_Update (Compilation_Unit : in Asis.Compilation_Unit) return Asis.Asis_Time; ------------------------------------------------------------------------------ -- Compilation_Unit - Specifies the unit to query -- -- Returns the time that this physical compilation unit was most recently -- updated in its vendor Ada library. This will often be the time of its -- last compilation. The exact significance of the result is vendor specific. -- Returns Nil_Asis_Time if the unit has a Nil or Nonexistent unit kind, or if -- the time of last update is not available, or not meaningful, for any -- reason. -- -- All Unit_Kinds are appropriate. ------------------------------------------------------------------------------ I would propose to change "Returns the time that this physical compilation unit was most recently updated in its vendor Ada library" by "Returns the time that this compilation unit was inserted into environment [represented by its enclosing Context]". I.e.- no "physical", no "most recently". > >>>>>> > What do you think about a function, which would say, what configuration pragmas > affect the unit given as its argument? Would it be useful? Should it be > a secondary query only? > >>>>>> > > Don't we have this already? How is this different than the existing > function Compilation_Pragmas that takes a compilation unit argument? > Sorry, I meant the "inverse" function - the function taking a configuration pragma as an argument and returning the list of Compilation Units affected by it. If we already have it too -- sorry twice, but I'm feeling a bit lost in ASIS at the moment :( You are right - ASIS is a VERY busy interface! > >>>>>> > And now - the main question, which originates from some thoughts abot > the terminological issues: RM 95 defines, what does it mean to compile > a compilation unit into environment, but it does not say, that the > result of a compilation (process) may or have to change an environment > in any way. RM 95 stated, that the way of inserting COMPILATION UNITS > (as Ada technical term!) (note - namely compilation units, and not > configuration pragmas!) into environment is implementation-defined. > >>>>>> > > Whatever the method, compiling or inserting compilation units and > compilations of just config pragmas changes the environment both logically > and physically. And this point seems to me as being really important from the formal viewpoint. And I would suggest to all of us to examine it again. > > > >>>>>> > >From the other side, 10.1.5 (8) says only that: > > > Post-Compilation Rules > > (8) > Certain pragmas are defined to be configuration pragmas; they > shall appear before the first compilation_unit of a compilation. > They are generally used to select a partition-wide or system-wide > option. The pragma applies to all compilation_units appearing in > the compilation, unless there are none, in which case it applies > to all future compilation_units compiled into the same > environment. > > Does this give enough formal background to conclude, that a compilation > pragma (compiled on its own, without following compilation unit) may also > be considered as inserted into environment? Another interpretation may be > possible, and it looks as being more close to RM 95 in the formal sense: > > Configuration pragma is NOT incerted into environment, but being > COMPILED, it changes the STATE of A COMPILER. As a result, it may > affect the results of the following COMPILATIONS (as processes), > but it may NOT affect the CONTENT of the ENVIRONMENT in which, according > to RM 10.1.4(1) every COMPILATION (as a process) takes place. > > I would even say, that it is THE ONLY formally correct interpretation > of RM 95, concerning the relations between compilation units, configuration > pragmas, compilations (as processes) and environment. But it is very formal. > May it be useful? > >>>>>> > > Config pragmas don't change the state of a compiler, they change the state > of the environment. Can you provide any *formal* background for this? > They may affect future compilations by causing the > compiler to act in different ways. I don't think we can say they may not > affect the content of the environment, which I think is > implementation-defined. The phrase "the content of the environment is implementation-defined" is a universal solution to the most of the ASIS problems with an environmemt and configuration pragmas (and I'm not kidding here!). But we should be wery careful with it - ASIS should not use this solution for the situations, which are NOT classified as "implementation-defined" in RM 95! > I have no problem with the notion that compilation pragmas are inserted > into an environment. I am almost ready to joint you, but I'm afraid, we still have a problem here. May be, this problem is not specific to config pragmas, I would say, that we have a general terminological problem here. Let me try to reformulate my points: 1. In Ada 83, the successful compilation was defined as changing the state of the Ada library. RM 95 avoids (I think, it does this intentionally) any words, which would connect compilation (as process and its results) and any changes in an environment. I think, ASIS should follow this principle. 2. RM 95 defines an environment as (10.1.4 (1, 2)) "a conceptual declarative part, ..." containing library items (but not compilation units!), and 2.8(7) allows pragmas to be plased "at any place where a compilation_unit would be allowed". [Oops, step away from ASIS: it looks like ether we do not have enough formal background for obtaining compilation units from an environment (but library items only, that is, without any context clauses!), and we have no formal backgrounds for obtaining subunits - they are not library items; or RM 95 simply is not precise enough in 10.1.4: in 10.1.4 (1, 2) it says about an environment as about containing library ITEMS, and in our favourite paragraph 10.1.4 (5) it already says about compilation UNITS existing in the environment. Back to ASIS] Moreover, it is only an implementation advise, but you can see in 2.8(19): "A pragma used to configure the environment by adding, removing, or replacing library_items." It sounds like a (configuration) pragma can modify the enfironment, being outside it. So, I'm repeating my question: we DO have some background to say, that at least one thing from compilation units and library items exist in an environment. Do we have enough FORMAL reasons to say, that pragmas also may exist in the environment? And, coming back to your suggestion - if we really have this problem, and if this problem is only a terminological problem, the solution may be to use "as if" definition style and wording. > >>>>>> > > Now, ASIS programs can tell where the pragmas came from and how they were > > applied. Since A_Configuration_Compilation is a Unit_Kind, the usual > > attributes can be queried. > > How many ASIS Compilation Units of A_Configuration_Compilation kind may > be contained into the same ASIS Context? Can the Name query be applied > for a Compilation Unit of A_Configuration_Compilation kind? And what > may be the meaning of the result? > > I'm afraid, too many questions about ASIS Compilation Units of > A_Configuration_Compilation kind will have "implementation-defined" as > an answer. > >>>>>> > > As you assumed, the number of A_Configuration_Compilation entities is of course > implementation-defined. The Name query can be applied but should return a > null string. The Text_Name query would probably be the most useful and > meaningful query. > > Other queries: > > Unique_Name: implementation-defined, but could use Text_Name or > Time_Of_Last_Update to construct something unique. > Exists: meaningful. > Can_Be_Main_Program: False. > Is_Body_Required: False. > Text_Form: meaningful. > Object_Name: null string. > Object_Form: null string. > Compilation_Command_Line_Options: meaningful. > Time_Of_Last_Update: meaningful. > Compilation_Cpu_Time: meaningful. Looks reasonable. What about the black-box decomposition of a Compilation unit of A_Configuration_Compilation kind? :) > ... > > This raises an interesting point about implementation permissions, because > a valid result of Configuration_Pragmas(Context) could be a list of four; > pragma Bar appearing twice. This is similar to permissions allowed on with > clauses where multiple with clauses naming the same library unit may only be > reported once by ASIS. Again, just one of many implementation variances we > must allow. And here I would like to echo Robert, when he said: "The whole business of configuration pragmas is a much bigger earthquake to the language semantics than people are aware of!" Sergey. From owner-sigada-asis-tech@ACM.ORG Fri Oct 9 15:50:46 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (8.8.8+Sun/SMI-SVR4) id PAA13066; Fri, 9 Oct 1998 15:50:45 -0400 (EDT) Received: from mail.acm.org (mail.acm.org [199.222.69.4]) by cs.ida.org (8.8.7/8.8.7) with ESMTP id PAA15476 for ; Fri, 9 Oct 1998 15:50:44 -0400 (EDT) Received: from mail (mail.acm.org [199.222.69.4]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id PAA29024; Fri, 9 Oct 1998 15:38:43 -0400 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 1338624 for SIGADA-ASIS-TECH@ACM.ORG; Fri, 9 Oct 1998 15:38:42 -0400 Received: from mailgw.rational.com (mailgw.rational.com [192.232.7.78]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id PAA15164 for ; Fri, 9 Oct 1998 15:38:35 -0400 Received: from fort-ext.rational.com (fort-ext.pureatria.com [192.232.7.130]) by mailgw.rational.com (8.9.1/8.9.1/RATIONAL-mailgw) with SMTP id MAA20043; Fri, 9 Oct 1998 12:48:53 -0700 (PDT) Received: from mailhub.rational.com by fort-ext.rational.com via smtpd (for [192.232.7.78]) with SMTP; 9 Oct 1998 19:48:53 UT Received: from cupmail0.rational.com (cupmail0-19.rational.com [172.19.8.250]) by mailhub.rational.com (8.8.7/8.8.7/RATIONAL-mailhub) with ESMTP id MAA16022; Fri, 9 Oct 1998 12:48:52 -0700 (PDT) Received: from amber.rational.com (amber.rational.com [172.19.130.10]) by cupmail0.rational.com (8.9.1/8.8.7/RATIONAL-cupmail0) with ESMTP id MAA15861; Fri, 9 Oct 1998 12:48:51 -0700 (PDT) Received: (from geb@localhost) by amber.rational.com (8.8.6/) id MAA08094; Fri, 9 Oct 1998 12:49:58 -0700 (PDT) Message-ID: Date: Fri, 9 Oct 1998 12:49:57 PST Reply-To: geb@RATIONAL.COM Sender: ACM SIGADA ASIS Technical Discussion Group From: "Gary E. Barnes" Subject: Re: A_Configuration_Compilation Unit_Kind - seems a bit odd. Comments: To: "Steve Blake @pulsar" To: SIGADA-ASIS-TECH@ACM.ORG In-Reply-To: Your message of Thu, 8 Oct 1998 16:58:34 -0700 Content-Length: 7378 Status: OR > >One curious thing about this compilation Unit_Kind is that there are > >apparently no interfaces in the ASIS specification that are capable of > >returning a unit having this Unit_Kind. That would lead to the question, > >why does this Unit_Kind exist since it serves no purpose for the user of > >the interface? > > The only interface that returns this unit kind is Enclosing_Compilation_Unit > when given A_Pragma element obtained from Configuration_Pragms. This fact > did not get documented and that needs to be fixed. Ah! Although since apparently nothing can be done with such a unit (eg. Unit_Full_Name returns "") I might have thought Enclosing_Compilation_Unit would return Nil for those pragmas. Then there is no need for that Unit_Kind and the various compilation unit interfaces could eliminate all of the related "this does not return a" verbiage. Giving the pragmas a physical ASIS unit value to call home works ok for me. The Rational compiler actually does have physical "units" that contain the pragmas. So, for us, they have Text_Name's and other such. > >A particular Asis.Context may well have multiple separate sets of > >configuration pragmas and deciding which set would apply to a future > >compilation may well hinge on knowing the future location (which > >Asis.Container perhaps?) of the future unit. > > The assumption about an ASIS context is that it is a snapshot of the Ada > environment at the time the ASIS tool is examining it. If the context > is mapped to a set of vendor libraries then there is also the assumption > that there is some ordering applied to the set for purpose of compilation > unit visibility, config pragma applicability and other such things. The > location of the library (ie container) that would hold future compilations > seems to be a vendor specific detail or capability not addressed by ASIS. Ordering? Even if there is some kind of ordering amoung the libraries, why assume there is an ordering amoung the pragmas? Rational has "ordering" amoung libraries (library A can reference library B but not the reverse, etc.) but that library ordering in no way directly affects the compilation order for units and it very much does not affect the selection of configuration pragmas that apply to each unit. I agree that the location of a library, even the definition of the term "library", and the rules that determine the set of configuration pragmas applying to a compilation unit are vendor specific. And as such, the specific details of that algorithm is not a good thing to be addressed by ASIS. (Is there even a finite set of such details?! 8^)) > I would say that regardless of which library future compilation might be > placed, they are still future and thus the configuration pragma "state" > of the environment could only change if the environment were to change. > > So I feel that during the time an ASIS tool is examining the Context, there > can be at most one set of configuration pragmas that apply. In our environment there are any number of sets of pragmas and which set applies to which compilation unit is determined by physical proximity to that unit. So I agree that the pragma "state" is unchanging and I agree that, for each unit, there is at most one set of pragmas that apply. However that does not give me any way to reasonably answer the question "What set of pragmas apply to this Asis.Context?" There is no such set for Rational unless a) the context contains only one library or b) all contained libraries happen to have identical sets. If a unit happens to be compiled in one library then one set applies, if it happens to be compiled in another library then another set applies, and in still a third library there might not be any pragmas that apply. All three libraries can be in the same Ada environment and in the same Asis.Context. > >b) Does ASIS really wish to pretend that at most one set of configuration > > pragmas can exist within a Context when that is not the case for Ada > > compilation systems? > > I believe so. During the static snapshot ASIS there is only one that applies. > While the compilation system can have many sets, each is only applicable in > particular views of the Ada environment. Each different environment > constitutes a different ASIS context. Unfortunate. An Ada compilation environment contains some number of inner environments (such as libraries) and each one can have a set of pragmas that apply to that inner environment. In the "worst case" there could be a different set of pragmas that apply to each and every separate compilation unit in an environment. The current interface asks this question: "What pragmas apply to all future compilation_units compiled into the Asis.Context?" This turns out to be a highly vendor specific question, and at least for Rational, it is a question without meaning. Returning a Nil_Element_List and returning the concatenation of all pragma sets everywhere both seem reasonable answers. Neither answer would seem actually useful. If the Configuration_Pragmas interface accepted a Compilation_Unit instead of a Context then ASIS would be able to answer the question "What pragmas applied to the compilation of this unit." ASIS would be able to do that independent of whatever scheme was used by each separate vendor. Any larger question would seem to be so vendor specific as to be meaningless for one or more vendors. (And hence not very useful to portable ASIS applications.) > >c) If so, any advice on what to return given a validated compilation system > > capable of having many different sets of configuration pragmas within a > > Context? (A Context may consist of nothing but a collection of libraries > > and have no obvious component that is "the main program", so determining > > the set affecting the main program may not be possible. Any other choice > > seems reminiscent of flipping a coin.) > > In multiple library systems there should be one library in the environment > that is the default location for compilations. That is the one I would > suggest be used to determine the set of config pragmas that apply. There should be? Why do you say that? When our system kicks off, it compiles anything anywhere in any library that needs compiling in order to satisfy whatever compilation request has been made by the user. The user may request that one unit be compiled. If that unit WITH's units in other libraries then compiling that one unit may cause all of those various library units to compile if they are not already compiled. Each library affected by the compilation has its own independent set of configuration pragmas. The user an also "point at" any number of specific units, in any number of libraries and kick off a compilation of those units. The compiler does whatever is necessary. The libraries do not even have to have any relationship (in terms of WITH's and such) to each other. When talking about compiling one unit, it makes sense that an Ada environment would have one deterministic algorithm for locating the pragmas that affect that compilation unit. When talking about multiple units scattered across multiple libraries, but all within a single Asis.Context, there is no reason to expect there to be a single pragma set used across all of those libraries (or even within a single library). Gary