From rybin@possum.srcc.msu.su Fri May 15 12:45:09 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id MAA01142; Fri, 15 May 1998 12:44:54 -0400 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 MAA25165 for ; Fri, 15 May 1998 12:46:16 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id MAA116836; Fri, 15 May 1998 12:39:32 -0400 Received: from logger.gamma.ru (logger.gamma.ru [194.186.254.23]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with ESMTP id MAA21095; Fri, 15 May 1998 12:39:28 -0400 (EDT) Received: from srcc.UUCP (uucp@localhost) by logger.gamma.ru (8.8.7/8.8.7) with UUCP id UAA18668; Fri, 15 May 1998 20:43:00 +0400 (MSD) Received: by gamma.srcc.msu.su; Fri, 15 May 1998 20:42:15 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Fri, 15 May 1998 20:41:32 +0400 To: asis-comment@ns1.sw-eng.falls-church.va.us Cc: asis-technical@ns1.sw-eng.falls-church.va.us Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Fri, 15 May 98 20:41:32 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: "Double-defined" names - what should be returned by semantic queries? Lines: 39 Content-Length: 1403 Status: OR I remember, that this problem was discussed some time ago, but I do not remember if the discussion had any impact on ASIS 95 standardization/revision process. Consider the following example: package Pkg1 is procedure Foo ( A: in out integer ); ^^^ <----------------- ???? <--------- end Pkg1; | | package body Pkg1 is | | procedure Foo ( A: in out integer ) is | begin ^^^ <------------------ ???? <------- A := 5; | ^^^ >-----------> Corresponding_Name_Definition >--> end Foo; end Pkg1; Which definition of the formal parameter A should be returned by Correspponding_Name_Definition when applying to usage occurence of A in an assignment statement? This is not clarified now in the ASIS definition, and this makes a problem for tools - what should a tool expect in this case? (My message just originates from a real problem of this kind) I think, ASIS should clarify this. Note, that what is presented above is only an example. The same problem exists for Corresponding_Called_Function in case if a separate spec exists along with the body for a given function. Any comments? Sergey From cdaniel.cooper@Boeing.Com Fri May 15 15:57:27 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA01076; Fri, 15 May 1998 15:57:26 -0400 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 PAA00254 for ; Fri, 15 May 1998 15:58:49 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id PAA67272; Fri, 15 May 1998 15:52:28 -0400 Received: from mailgate2.boeing.com (mailgate2.boeing.com [199.238.248.100]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with ESMTP id PAA02770 for ; Fri, 15 May 1998 15:52:48 -0400 (EDT) Received: from mercury.boeing.com ([130.42.138.11]) by mailgate2.boeing.com (8.8.5/8.8.5) with SMTP id MAA22189 for ; Fri, 15 May 1998 12:56:33 -0700 (PDT) Received: from longshot.ds.boeing.com by mercury.boeing.com; Fri, 15 May 98 12:56:33 -0700 Received: (from cooper@localhost) by longshot.ds.boeing.com (SMI-8.6/RDS-1.0) id MAA03599 for ASIS-technical@SW-Eng.Falls-Church.VA.US; Fri, 15 May 1998 12:56:31 -0700 Date: Fri, 15 May 1998 12:56:31 -0700 From: cdaniel.cooper@Boeing.Com (C. Daniel Cooper) Message-Id: <199805151956.MAA03599@longshot.ds.boeing.com> To: ASIS-technical@ns1.sw-eng.falls-church.va.us Subject: Re: "Double-defined" names - what should be returned by semantic queries? X-Sun-Charset: US-ASCII Content-Length: 3455 Status: ORr Sergey wrote, > Consider the following example: > > package Pkg1 is > > procedure Foo ( A: in out integer ); > ^^^ <----------------- ???? <--------- > end Pkg1; | > | > package body Pkg1 is | > | > procedure Foo ( A: in out integer ) is | > begin ^^^ <------------------ ???? <------- > A := 5; | > ^^^ >-----------> Corresponding_Name_Definition >--> > end Foo; > > end Pkg1; Actually, it gets worse than that: consider package Pkg1 is procedure Foo ( A: in out integer ); end Pkg1; package body Pkg1 is procedure Foo ( A: in out integer ) is separate; end Pkg1; separate (Pkg1) procedure Foo ( A: in out integer ) is begin A := 5; end Foo; > Which definition of the formal parameter A should be returned by > Correspponding_Name_Definition when applying to usage occurence > of A in an assignment statement? Above, there are *three* to choose from. > I think, ASIS should clarify this. I agree it is important to specify this, for consistency. To a degree, the resolution can be arbitrary: since many applications will look to further decompose the parameter definition, and since Ada requires all the definitions to be identical, it won't really matter which one is chosen. But where it *does* matter is if the application wants to look outwards rather than inwards, ie, to the enclosing hierarchy; in this case, if the application really cares *which* definition is used, it can make appropriate further queries to navigate to one of the other definitions, as preferred. For simplicity, we could just default ASIS to choose the definition in the body, since (in the above example) the spec or subunit may not necessarily be present. But unfortunately, such a rule would be too simplistic. Consider a decomposition of the following statement within some program unit *other* than the subprogram itself: Pkg1.Foo (A => 5); In this case, the reference to A can compile if the spec is present but the body (and subunit) is/are missing; so ASIS cannot blindly choose the definition in the body. What we need is a precedence order specifying which to choose when more than one definition exists. Note that such precedence will not relieve an application from still needing to query where it has landed: regardless of any precedence, we could have ended up in the spec (if no body) or in the body (if no spec); the client won't be able to rely on a default. Thus, the following rule should always work, not only for parameter definitions, but also (as Sergey hinted) for subprogram declarations as well: RULE: Where Ada allows more than one declaration/definition for an element, the "Corresponding" query for references will return the one in the spec unit, if present; otherwise the one in the body. For subunits, if the spec is absent, the subunit stub is returned and never the subunit body. -- C. Daniel Cooper =========v=======================v Engineer at Software | All opinions are mine | 206-655-3519 | and may not represent | CDaniel.Cooper@Boeing.com | those of my employer. | ==========================^=======================^ From roby Fri May 15 16:56:29 1998 Return-Path: Received: by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id QAA01189; Fri, 15 May 1998 16:56:28 -0400 From: roby (Clyde Roby) Message-Id: <199805152056.QAA01189@cronus.csed.ida.org> Subject: Re: "Double-defined" names - what should be returned by semantic queries? To: cdaniel.cooper@Boeing.Com (C. Daniel Cooper) Date: Fri, 15 May 1998 16:56:28 -0400 (EDT) Cc: roby (Clyde Roby), Rybin@GNAT.Com (Sergey Rybin), ASIS-Technical@SW-Eng.Falls-Church.Va.US (ASIS-Technical) In-Reply-To: <199805151956.MAA03599@longshot.ds.boeing.com> from "C. Daniel Cooper" at May 15, 1998 12:56:31 PM X-Mailer: ELM [version 2.5 PL0b2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2542 Status: OR Sergey Rybin had asked: > > Which definition of the formal parameter A should be returned by > > Correspponding_Name_Definition when applying to usage occurence > > of A in an assignment statement? Dan Cooper replied: > Above, there are *three* to choose from. > > > I think, ASIS should clarify this. > > I agree it is important to specify this, for consistency. To a degree, > the resolution can be arbitrary: since many applications will look to > further decompose the parameter definition, and since Ada requires all > the definitions to be identical, it won't really matter which one is > chosen. But where it *does* matter is if the application wants to look > outwards rather than inwards, ie, to the enclosing hierarchy; in this > case, if the application really cares *which* definition is used, it > can make appropriate further queries to navigate to one of the other > definitions, as preferred. > > For simplicity, we could just default ASIS to choose the definition in > the body, since (in the above example) the spec or subunit may not > necessarily be present. But unfortunately, such a rule would be too > simplistic. Consider a decomposition of the following statement within > some program unit *other* than the subprogram itself: > > Pkg1.Foo (A => 5); > > In this case, the reference to A can compile if the spec is present but > the body (and subunit) is/are missing; so ASIS cannot blindly choose the > definition in the body. What we need is a precedence order specifying > which to choose when more than one definition exists. Note that such > precedence will not relieve an application from still needing to query > where it has landed: regardless of any precedence, we could have ended > up in the spec (if no body) or in the body (if no spec); the client > won't be able to rely on a default. Thus, the following rule should > always work, not only for parameter definitions, but also (as Sergey > hinted) for subprogram declarations as well: Thus, with the above rationale, Dan proposed the following: > RULE: Where Ada allows more than one declaration/definition for an > element, the "Corresponding" query for references will return the > one in the spec unit, if present; otherwise the one in the body. > For subunits, if the spec is absent, the subunit stub is returned > and never the subunit body. I think that this rule provides an excellent explanation and clarification of Sergey's original question and that appropriate wording should appear in the ASIS document. Clyde From cdaniel.cooper@boeing.com Fri May 15 17:22:20 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id RAA01297; Fri, 15 May 1998 17:22:20 -0400 Received: from mailgate2.boeing.com (mailgate2.boeing.com [199.238.248.100]) by cs.ida.org (8.8.7/8.8.7) with ESMTP id RAA02593 for ; Fri, 15 May 1998 17:23:42 -0400 (EDT) Received: from mercury.boeing.com ([130.42.138.11]) by mailgate2.boeing.com (8.8.5/8.8.5) with SMTP id OAA05721 for ; Fri, 15 May 1998 14:23:36 -0700 (PDT) Received: from longshot.ds.boeing.com by mercury.boeing.com; Fri, 15 May 98 14:21:37 -0700 Received: (from cooper@localhost) by longshot.ds.boeing.com (SMI-8.6/RDS-1.0) id OAA03705; Fri, 15 May 1998 14:21:33 -0700 Date: Fri, 15 May 1998 14:21:33 -0700 From: cdaniel.cooper@boeing.com (C. Daniel Cooper) Message-Id: <199805152121.OAA03705@longshot.ds.boeing.com> To: roby@ida.org Subject: Re: "Double-defined" names - what should be returned by semantic queries? Cc: Colket@ACM.org X-Sun-Charset: US-ASCII Content-Length: 2144 Status: ORr Clyde, > I think that this rule provides an excellent explanation and > clarification of Sergey's original question and that appropriate > wording should appear in the ASIS document. I'm sure some wordsmithing is needed. After I reread it, I thought I should have edited it as follows -- but certainly feel free to use your own words instead: > In this case, the reference to A can compile if the spec is present but > the body (and subunit) is/are missing; so ASIS cannot blindly choose the > definition in the body. What we need is a precedence order specifying > which to choose when more than one definition exists. Note that such > precedence will not relieve an application from still needing to query > where it has landed: regardless of any precedence, we could have ended make that "it could have ended" > up in the spec (if no body) or in the body (if no spec); the client > won't be able to rely on a default. Thus, the following rule should > always work, not only for parameter definitions, but also (as Sergey > hinted) for subprogram declarations as well: The last 4 lines would be better as: up in the spec (if no body) or in the body (if no spec); the application won't be able to rely on an ASIS default. For consistency, though, ASIS could specify the following precedence rule -- not only for parameter definitions, but also (as Sergey hinted) for subprogram declarations: > RULE: Where Ada allows more than one declaration/definition for an > element, the "Corresponding" query for references will return the > one in the spec unit, if present; otherwise the one in the body. > For subunits, if the spec is absent, the subunit stub is returned > and never the subunit body. The above works for Ada83 (where I had run into the problem). Can you think of additional Ada95 cases that need to be included (eg, for child packages, etc)? -- C. Daniel Cooper =========v=======================v Engineer at Software | All opinions are mine | 206-655-3519 | and may not represent | CDaniel.Cooper@Boeing.com | those of my employer. | ==========================^=======================^ From roby Fri May 15 17:33:20 1998 Return-Path: Received: by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id RAA01312; Fri, 15 May 1998 17:33:19 -0400 From: roby (Clyde Roby) Message-Id: <199805152133.RAA01312@cronus.csed.ida.org> Subject: Re: "Double-defined" names - what should be returned by semantic queries? To: cdaniel.cooper@boeing.com (C. Daniel Cooper) Date: Fri, 15 May 1998 17:33:19 -0400 (EDT) Cc: roby (Clyde Roby), Colket@ACM.Org (Currie Colket at ACM) In-Reply-To: <199805152121.OAA03705@longshot.ds.boeing.com> from "C. Daniel Cooper" at May 15, 1998 02:21:33 PM X-Mailer: ELM [version 2.5 PL0b2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2075 Status: OR Dan, > I'm sure some wordsmithing is needed. After I reread it, I thought > I should have edited it as follows -- but certainly feel free to > use your own words instead: Will do. > > In this case, the reference to A can compile if the spec is present but > > the body (and subunit) is/are missing; so ASIS cannot blindly choose the > > definition in the body. What we need is a precedence order specifying > > which to choose when more than one definition exists. Note that such > > precedence will not relieve an application from still needing to query > > where it has landed: regardless of any precedence, we could have ended > > make that "it could have ended" Right. > > up in the spec (if no body) or in the body (if no spec); the client > > won't be able to rely on a default. Thus, the following rule should > > always work, not only for parameter definitions, but also (as Sergey > > hinted) for subprogram declarations as well: > > The last 4 lines would be better as: > > up in the spec (if no body) or in the body (if no spec); the application > won't be able to rely on an ASIS default. For consistency, though, ASIS > could specify the following precedence rule -- not only for parameter > definitions, but also (as Sergey hinted) for subprogram declarations: Okay. > > RULE: Where Ada allows more than one declaration/definition for an > > element, the "Corresponding" query for references will return the > > one in the spec unit, if present; otherwise the one in the body. > > For subunits, if the spec is absent, the subunit stub is returned > > and never the subunit body. > > The above works for Ada83 (where I had run into the problem). Can you > think of additional Ada95 cases that need to be included (eg, for child > packages, etc)? For Ada95, I don't think there's anything new for child packages since a child package (spec or body) is still a package. A declaration/definition can only appear in one such package, whether it is a parent or a child package. I can't think of any other case for Ada95, either. Clyde From dewar@gnat.com Fri May 15 20:57:54 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id UAA01759; Fri, 15 May 1998 20:57:53 -0400 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 UAA05224 for ; Fri, 15 May 1998 20:59:16 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id UAA132604; Fri, 15 May 1998 20:52:59 -0400 Received: from nile.gnat.com (NILE.GNAT.COM [205.232.38.5]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id UAA12727; Fri, 15 May 1998 20:53:48 -0400 (EDT) Received: by nile.gnat.com (5.0/1.20) id AA28117; Fri, 15 May 98 20:54:24 EDT Date: Fri, 15 May 98 20:54:24 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9805160054.AA28117@nile.gnat.com> To: asis-comment@ns1.sw-eng.falls-church.va.us, rybin@possum.srcc.msu.su Subject: Re: "Double-defined" names - what should be returned by semantic queries? Cc: asis-technical@ns1.sw-eng.falls-church.va.us Content-Length: 91 Status: OR This spec should always be referenced, there is only one formal parameter entity, not two. From dewar@gnat.com Fri May 15 21:07:10 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id VAA01775; Fri, 15 May 1998 21:07:10 -0400 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 VAA05324 for ; Fri, 15 May 1998 21:08:32 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id VAA147380; Fri, 15 May 1998 21:02:21 -0400 Received: from nile.gnat.com (NILE.GNAT.COM [205.232.38.5]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id VAA12935 for ; Fri, 15 May 1998 21:03:20 -0400 (EDT) Received: by nile.gnat.com (5.0/1.20) id AA06719; Fri, 15 May 98 21:03:55 EDT Date: Fri, 15 May 98 21:03:55 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9805160103.AA06719@nile.gnat.com> To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com Subject: Re: "Double-defined" names - what should be returned by semantic queries? Content-Length: 170 Status: OR I strongly feel that the definition refernced should be the one in the declaration (either the spec or, in the case where a body serves as the declaration, in the body). From dewar@gnat.com Fri May 15 21:17:35 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id VAA01785; Fri, 15 May 1998 21:17:34 -0400 Received: from nile.gnat.com (NILE.GNAT.COM [205.232.38.5]) by cs.ida.org (8.8.7/8.8.7) with SMTP id VAA05465 for ; Fri, 15 May 1998 21:18:57 -0400 (EDT) Received: by nile.gnat.com (5.0/1.20) id AA18588; Fri, 15 May 98 21:15:13 EDT Date: Fri, 15 May 98 21:15:13 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9805160115.AA18588@nile.gnat.com> To: cdaniel.cooper@boeing.com, roby@ida.org Subject: Re: "Double-defined" names - what should be returned by semantic queries? Cc: ASIS-Technical@ns1.sw-eng.falls-church.va.us, Rybin@gnat.com Content-Length: 597 Status: OR < RULE: Where Ada allows more than one declaration/definition for an > element, the "Corresponding" query for references will return the > one in the spec unit, if present; otherwise the one in the body. > For subunits, if the spec is absent, the subunit stub is returned > and never the subunit body. I think that this rule provides an excellent explanation and clarification of Sergey's original question and that appropriate wording should appear in the ASIS document. >> I agree, this is exactly the right rule. From sblake@sd.aonix.com Mon May 18 13:36:08 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id NAA05507; Mon, 18 May 1998 13:36:08 -0400 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 NAA03743 for ; Mon, 18 May 1998 13:37:31 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id NAA39686; Mon, 18 May 1998 13:30:42 -0400 Received: from gw.sd.aonix.com (gw.alsys.com [136.175.17.2]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id NAA05257 for ; Mon, 18 May 1998 13:27:29 -0400 (EDT) Received: from rasht.sd.aonix.com (mailhub.alsys.com) by gw.sd.aonix.com (4.1/SMI-4.1.1) id AA05957; Mon, 18 May 98 10:30:24 PDT Received: from puumba.telesoft by rasht.sd.aonix.com (4.1/TS-1.2c) id AA03077; Mon, 18 May 98 10:27:37 PDT Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id KAA29941; Mon, 18 May 1998 10:27:33 -0700 Date: Mon, 18 May 1998 10:27:33 -0700 From: sblake@sd.aonix.com (Steve Blake @pulsar) Message-Id: <199805181727.KAA29941@puumba.telesoft> To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com Subject: Re: "Double-defined" names - what should be returned by semantic queries? Content-Length: 2899 Status: OR > RULE: Where Ada allows more than one declaration/definition for an > element, the "Corresponding" query for references will return the > one in the spec unit, if present; otherwise the one in the body. > For subunits, if the spec is absent, the subunit stub is returned > and never the subunit body. > I think this rule works to some extent for references outside the immediate scope of the subprogram declaration, such as a call from another unit as in the example: Pkg1.Foo (A => 5); But if I'm reading this right, then in this example, or in the subunit example, >> package Pkg1 is >> >> procedure Foo ( A: in out integer ); >> ^^^ <----------------- ???? <--------- >> end Pkg1; | >> | >> package body Pkg1 is | >> | >> procedure Foo ( A: in out integer ) is | >> begin ^^^ <------------------ ???? <------- >> A := 5; | >> ^^^ >-----------> Corresponding_Name_Definition >--> >> end Foo; >> >> end Pkg1; > The corresponding_name_definition of the reference of A in the statement A := 5 within the body of Foo, will be the definition of A in the procedure declaration. I don't believe this should be the case. When the reference is in the immediate scope, the corresponding_name_definition should return the immediately enclosing "visible" definition, which would be the A in the procedure body declaration. There is also the same question for all two part declarations that have completions. If we applied the same rule, then definitions of references to subtype_marks would always go the the incomplete type (if any) and references in the immediate scope of declarations that complete private type and deferred constant declarations would resolve to the private type and deferred constant definitions and not to the full type or constant declarations which hold the interesting information. References should simply resolve to the single visible declaration. There are two major concerns: 1. We should follow the rules of Ada. The visibility rules in 8.3(19) and 8.3(24) should be the primary rules on this issue. 2. If we force it to always go to the spec (if any) then we are possibly adding significant overhead for some implementations to perform this normalization. There are primitive ASIS queries available to client tools to do this by their choice. Perhaps a simpler rule can be added: RULE: For declarations that have two parts, the semantic queries for references to their defining names will return the visible declaration or defining name. See the visibility rules in 8.3(19) and 8.3(24). Steve From dewar@gnat.com Mon May 18 14:00:17 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id OAA05644; Mon, 18 May 1998 14:00:16 -0400 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 OAA04485 for ; Mon, 18 May 1998 14:01:36 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id NAA91804; Mon, 18 May 1998 13:55:02 -0400 Received: from nile.gnat.com (NILE.GNAT.COM [205.232.38.5]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id NAA07123 for ; Mon, 18 May 1998 13:56:06 -0400 (EDT) Received: by nile.gnat.com (5.0/1.20) id AA04703; Mon, 18 May 98 13:56:33 EDT Date: Mon, 18 May 98 13:56:33 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9805181756.AA04703@nile.gnat.com> To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com, sblake@sd.aonix.com Subject: Re: "Double-defined" names - what should be returned by semantic queries? Content-Length: 608 Status: OR <> I disaree, I think it is far cleaner, and much closer to the definition of ADa to always refer to a single entity. There is only one entity here. It is mentioned twice, but there is only one entity! From sblake@sd.aonix.com Mon May 18 15:44:32 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA06041; Mon, 18 May 1998 15:44:31 -0400 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 PAA08574 for ; Mon, 18 May 1998 15:45:54 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id PAA83468; Mon, 18 May 1998 15:38:00 -0400 Received: from gw.sd.aonix.com (gw.alsys.com [136.175.17.2]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id PAA13601 for ; Mon, 18 May 1998 15:38:47 -0400 (EDT) Received: from rasht.sd.aonix.com (mailhub.alsys.com) by gw.sd.aonix.com (4.1/SMI-4.1.1) id AA10846; Mon, 18 May 98 12:41:44 PDT Received: from puumba.telesoft by rasht.sd.aonix.com (4.1/TS-1.2c) id AA09362; Mon, 18 May 98 12:38:50 PDT Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id MAA05659; Mon, 18 May 1998 12:38:46 -0700 Date: Mon, 18 May 1998 12:38:46 -0700 From: sblake@sd.aonix.com (Steve Blake @pulsar) Message-Id: <199805181938.MAA05659@puumba.telesoft> To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com, dewar@GNAT.Com, sblake@sd.aonix.com Subject: Re: "Double-defined" names - what should be returned by semantic queries? Content-Length: 1582 Status: OR >From dewar@gnat.com Mon May 18 11:04:20 1998 >To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@boeing.com, > sblake@sd.aonix.com >Subject: Re: "Double-defined" names - what should be returned by semantic queries? > ><A := 5 within the body of Foo, will be the definition of A in the procedure >declaration. > >I don't believe this should be the case. When the reference is in the >immediate scope, the corresponding_name_definition should return the >immediately enclosing "visible" definition, which would be the A in the >procedure body declaration. >>> > >I disaree, I think it is far cleaner, and much closer to the definition >of ADa to always refer to a single entity. There is only one entity here. >It is mentioned twice, but there is only one entity! If we want to be close to the definition of Ada (which is an ASIS goal) then we should always refer to the single VISIBLE entity, which in this case is the enclosing definition of the body. This takes all the guesswork and additional rule invention out of it and provides exactly the same view of declarations as the compiler sees and enforces. If we circumvent the Ada visibility rules, our solution will be far from clean. Within the scope of the completion, references should resolve to the completion or its components (such as parameter specifications). Otherwise, all references resolve to the first declaration: ie the spec, incomplete type, private type, deferred constant declaration, etc. Steve Steve From cdaniel.cooper@Boeing.Com Mon May 18 15:50:05 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA06083; Mon, 18 May 1998 15:50:04 -0400 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 PAA08752 for ; Mon, 18 May 1998 15:51:27 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id PAA29622; Mon, 18 May 1998 15:44:47 -0400 Received: from mailgate2.boeing.com (mailgate2.boeing.com [199.238.248.100]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with ESMTP id PAA13888 for ; Mon, 18 May 1998 15:45:47 -0400 (EDT) Received: from mercury.boeing.com ([130.42.138.11]) by mailgate2.boeing.com (8.8.5/8.8.5) with SMTP id MAA09021 for ; Mon, 18 May 1998 12:49:26 -0700 (PDT) Received: from longshot.ds.boeing.com by mercury.boeing.com; Mon, 18 May 98 12:49:29 -0700 Received: (from cooper@localhost) by longshot.ds.boeing.com (SMI-8.6/RDS-1.0) id MAA05319 for ASIS-technical@SW-Eng.Falls-Church.VA.US; Mon, 18 May 1998 12:49:24 -0700 Date: Mon, 18 May 1998 12:49:24 -0700 From: cdaniel.cooper@Boeing.Com (C. Daniel Cooper) Message-Id: <199805181949.MAA05319@longshot.ds.boeing.com> To: ASIS-technical@ns1.sw-eng.falls-church.va.us Subject: Re: "Double-defined" names - what should be returned by semantic queries? X-Sun-Charset: US-ASCII Content-Length: 2748 Status: OR Steve, > There is also the same question for all two part declarations that have > completions. If we applied the same rule, then definitions of references to > subtype_marks would always go the the incomplete type (if any) and references > in the immediate scope of declarations that complete private type and deferred > constant declarations would resolve to the private type and deferred > constant definitions and not to the full type or constant declarations which > hold the interesting information. I had thought this issue might apply to other constructs as well; thanks for pointing these out. > References should simply resolve to the single visible declaration. > There are two major concerns: > > 1. We should follow the rules of Ada. The visibility rules in 8.3(19) and > 8.3(24) should be the primary rules on this issue. > > 2. If we force it to always go to the spec (if any) then we are possibly adding > significant overhead for some implementations to perform this normalization. > There are primitive ASIS queries available to client tools to do this by > their choice. > > Perhaps a simpler rule can be added: (I presume you mean "added instead of the other one", not "added to the other one".) > RULE: For declarations that have two parts, the semantic queries for > references to their defining names will return the visible declaration or > defining name. See the visibility rules in 8.3(19) and 8.3(24). As I pointed out before, the rule that ASIS implements, from a client tool perspective, can largely be arbitrary. We're talking about which definition to land on when there's more than one "corresponding" one to choose from; however, because some of these are optional, the existence of the rule (regardless of what it states) does not free the client from needing to query where it has in fact landed: there may only have been a choice of one since another possibility happened to be missing (in which case the rule won't apply anyway). However, I'll vote for Steve's rule, since he offers more justification than I did, and in particular since it affords a (potential) performance benefit for client tools. Robert Dewar writes, > I disaree, I think it is far cleaner, and much closer to the definition > of ADa to always refer to a single entity. There is only one entity here. > It is mentioned twice, but there is only one entity! Sure, but which "mention" do we choose to be "corresponding", and why? -- C. Daniel Cooper =========v=======================v Engineer at Software | All opinions are mine | 206-655-3519 | and may not represent | CDaniel.Cooper@Boeing.com | those of my employer. | ==========================^=======================^ From rybin@possum.srcc.msu.su Mon May 18 16:57:35 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id QAA06227; Mon, 18 May 1998 16:57:33 -0400 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 QAA10503 for ; Mon, 18 May 1998 16:58:56 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id QAA97156; Mon, 18 May 1998 16:52:16 -0400 Received: from logger.gamma.ru (logger.gamma.ru [194.186.254.23]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with ESMTP id QAA17866 for ; Mon, 18 May 1998 16:52:57 -0400 (EDT) Received: from srcc.UUCP (uucp@localhost) by logger.gamma.ru (8.8.7/8.8.7) with UUCP id AAA06739; Tue, 19 May 1998 00:56:37 +0400 (MSD) Received: by gamma.srcc.msu.su; Tue, 19 May 1998 00:55:30 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Tue, 19 May 1998 00:54:47 +0400 To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com References: <199805181949.MAA05319@longshot.ds.boeing.com> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Tue, 19 May 98 00:54:47 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: "Double-defined" names - what should be returned by semantic queries? Lines: 108 Content-Length: 5485 Status: OR > Steve, > > > There is also the same question for all two part declarations that have > > completions. If we applied the same rule, then definitions of references to > > subtype_marks would always go the the incomplete type (if any) and references > > in the immediate scope of declarations that complete private type and deferred > > constant declarations would resolve to the private type and deferred > > constant definitions and not to the full type or constant declarations which > > hold the interesting information. > > I had thought this issue might apply to other constructs as well; > thanks for pointing these out. But this case of incomplete/private and the corresponding full type declarations is quite another story! In this case, it IS important to return DIFFERENT defining names when querying from inside the package being after the full definition and when querying from outside the package (in case of a private type). Private (incomplete) type declaration and the corresponding full type declaration defines two DIFFERENT VIEWS on the same type, and the difference is important for applications. But in case of a defining unit name or a formal parameter name we have exactly the same view on the same entity. And to return one name in one case and another name in another case just means to confuse an application! Who on earth will keep in mind this non-trivial visibility stuff defined in RM 95 section 8 when writing tools? > > References should simply resolve to the single visible declaration. > > There are two major concerns: > > > > 1. We should follow the rules of Ada. The visibility rules in 8.3(19) and > > 8.3(24) should be the primary rules on this issue. > > > > 2. If we force it to always go to the spec (if any) then we are possibly adding > > significant overhead for some implementations to perform this normalization. > > There are primitive ASIS queries available to client tools to do this by > > their choice. I'm afraid, here Steve contradicts to himself - if there are _primitive_ ASIS queries (not so hard, really, I've already added an extension of this kind to ASIS-for-GNAT :), how can the implementation overheads be _significant_? Just incorporate these _primitive_ queries into your implementation! I have two other concerns in defence of Dan's original suggestion: 1. For an _application_, it would be much more safe and comfortable to have a "normalized" result of semantic queries in case of "multiple-defined" names (private/incomplete and the corresponding full type declarations are NOT the case of multiple-defined names!). Consider and application dealing with a symbol/name table - if we have two (or even more, consider entry formal parameters in accept statements) "versions" for a defining name for a formal parameter, maintaning such a table would be a real pain. (Note, this discussion originated from the practical problem of this kind :) 2. ASIS already contains enough deviations from RM95, and all of them are justified by application's benefits ("terminate" statement, naming _expressions_ instead of the Ada notion of a name, an attribute reference as a component of an attribute definition clause, all this nice business with implicit label definitions which are attached to statements instead of being appended to the end of the corresponding declarative part etc). Are we really afraid of adding one more situation when ASIS does not _literally_ follow RM95, moreover, application benefits are obvious in this case? > > Perhaps a simpler rule can be added: > > (I presume you mean "added instead of the other one", not "added to the > other one".) > > > RULE: For declarations that have two parts, the semantic queries for > > references to their defining names will return the visible declaration or > > defining name. See the visibility rules in 8.3(19) and 8.3(24). > > As I pointed out before, the rule that ASIS implements, from a client > tool perspective, can largely be arbitrary. We're talking about which > definition to land on when there's more than one "corresponding" one to > choose from; however, because some of these are optional, the existence > of the rule (regardless of what it states) does not free the client from > needing to query where it has in fact landed: there may only have been a > choice of one since another possibility happened to be missing (in which > case the rule won't apply anyway). > > However, I'll vote for Steve's rule, since he offers more justification > than I did, and in particular since it affords a (potential) performance > benefit for client tools. > > Robert Dewar writes, > > > I disaree, I think it is far cleaner, and much closer to the definition > > of ADa to always refer to a single entity. There is only one entity here. > > It is mentioned twice, but there is only one entity! > > Sure, but which "mention" do we choose to be "corresponding", and why? I think, the question is: what is more important - application needs (of course, if applications really want "normalized to the first occurence" defining names) or formal conformance of ASIS to RM 95. I agree, that from language lawyer's viewpoint Steve's position is better justified. What is the tool developers viewpoint??? Sergey P.S. Sorry for terrible English - Moscow local time is 1.00 in the morning @:-\ From dewar@gnat.com Mon May 18 17:07:29 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id RAA06312; Mon, 18 May 1998 17:07:28 -0400 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 RAA10774 for ; Mon, 18 May 1998 17:08:51 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id RAA107988; Mon, 18 May 1998 17:02:21 -0400 Received: from nile.gnat.com (NILE.GNAT.COM [205.232.38.5]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id RAA18464 for ; Mon, 18 May 1998 17:03:17 -0400 (EDT) Received: by nile.gnat.com (5.0/1.20) id AA09923; Mon, 18 May 98 17:03:48 EDT Date: Mon, 18 May 98 17:03:48 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9805182103.AA09923@nile.gnat.com> To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com, dewar@gnat.com, sblake@sd.aonix.com Subject: Re: "Double-defined" names - what should be returned by semantic queries? Content-Length: 648 Status: OR <> YOu talk as though there is more than one entity in the Ada semantics, there is not, these are the same entity, there is no concept semantically of a separate spec entity and body entity, and your suggestion that somehow the body entity hides the spec entity in the body seems quite bogus to me. From dewar@gnat.com Mon May 18 17:09:46 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id RAA06349; Mon, 18 May 1998 17:09:45 -0400 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 RAA10848 for ; Mon, 18 May 1998 17:11:09 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id RAA78538; Mon, 18 May 1998 17:04:45 -0400 Received: from nile.gnat.com (NILE.GNAT.COM [205.232.38.5]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id RAA18576 for ; Mon, 18 May 1998 17:05:48 -0400 (EDT) Received: by nile.gnat.com (5.0/1.20) id AA09972; Mon, 18 May 98 17:06:19 EDT Date: Mon, 18 May 98 17:06:19 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9805182106.AA09972@nile.gnat.com> To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com Subject: Re: "Double-defined" names - what should be returned by semantic queries? Content-Length: 534 Status: OR <<> I disaree, I think it is far cleaner, and much closer to the definition > of ADa to always refer to a single entity. There is only one entity here. > It is mentioned twice, but there is only one entity! Sure, but which "mention" do we choose to be "corresponding", and why? >> We shoud be consistent. If there is only one entity, and apparently you agree with it, then ASIS should return the same single entity, and clearly the spec entity is the better choice once you agree that this desirable consistency rule should hold. From dewar@gnat.com Mon May 18 17:14:19 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id RAA06369; Mon, 18 May 1998 17:14:19 -0400 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 RAA10933 for ; Mon, 18 May 1998 17:15:43 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id RAA23290; Mon, 18 May 1998 17:09:11 -0400 Received: from nile.gnat.com (NILE.GNAT.COM [205.232.38.5]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id RAA18926 for ; Mon, 18 May 1998 17:10:12 -0400 (EDT) Received: by nile.gnat.com (5.0/1.20) id AA10072; Mon, 18 May 98 17:10:43 EDT Date: Mon, 18 May 98 17:10:43 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9805182110.AA10072@nile.gnat.com> To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com, rybin@possum.srcc.msu.su Subject: Re: "Double-defined" names - what should be returned by semantic queries? Content-Length: 1016 Status: OR <> I completely agree, the incomplete private case is totally different, here there definitely ARE two entities, and it is definitely meaningful to talk about which of them is visible where. From sblake@sd.aonix.com Mon May 18 18:58:22 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id SAA06558; Mon, 18 May 1998 18:58:22 -0400 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 SAA12885 for ; Mon, 18 May 1998 18:59:45 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id SAA157150; Mon, 18 May 1998 18:53:16 -0400 Received: from gw.sd.aonix.com (gw.alsys.com [136.175.17.2]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id SAA24846 for ; Mon, 18 May 1998 18:54:07 -0400 (EDT) Received: from rasht.sd.aonix.com (mailhub.alsys.com) by gw.sd.aonix.com (4.1/SMI-4.1.1) id AA18303; Mon, 18 May 98 15:57:04 PDT Received: from puumba.telesoft by rasht.sd.aonix.com (4.1/TS-1.2c) id AA17499; Mon, 18 May 98 15:54:17 PDT Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id PAA18583; Mon, 18 May 1998 15:54:00 -0700 Date: Mon, 18 May 1998 15:54:00 -0700 From: sblake@sd.aonix.com (Steve Blake @pulsar) Message-Id: <199805182254.PAA18583@puumba.telesoft> To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com, dewar@GNAT.Com, rybin@possum.srcc.msu.su Subject: Re: "Double-defined" names - what should be returned by semantic queries? Content-Length: 3323 Status: OR >From dewar@gnat.com Mon May 18 14:10:28 1998 > ><then we should always refer to the single VISIBLE entity, which in this >case is the enclosing definition of the body. This takes all the guesswork >and additional rule invention out of it and provides exactly the same view >of declarations as the compiler sees and enforces. >>> > >YOu talk as though there is more than one entity in the Ada semantics, there >is not, these are the same entity, there is no concept semantically of a >separate spec entity and body entity, and your suggestion that somehow >the body entity hides the spec entity in the body seems quite bogus to me. > ><<> I disaree, I think it is far cleaner, and much closer to the definition >> of ADa to always refer to a single entity. There is only one entity here. >> It is mentioned twice, but there is only one entity! > >Sure, but which "mention" do we choose to be "corresponding", and why? >>> > > > >We shoud be consistent. If there is only one entity, and apparently you >agree with it, then ASIS should return the same single entity, and >clearly the spec entity is the better choice once you agree that >this desirable consistency rule should hold. No, I don't agree that there is only one entity. Read 8.3(19) below and see what I mean. "If the completion of a declaration is a declaration, then within the scope of the completion, the first declaration is hidden from all visibility. Similarly, a discriminant_specification or parameter_specification is hidden within the scope of a corresponding discriminant_specification or parameter_specification of a corresponding completion, or of a corresponding accept statement." According to this, the ARM defines the parameter_specification of the completion (the body) to hide the corresponding parameter_specification of the first declaration (the spec). There are even conformance rules to ensure that profiles conform and we can have: procedure conform(a : integer); procedure conform(A : STANDARD.INTEGER) is begin null; end; which further suggests to me that the two parameter_specifications are unique entities. In the case of accept statements where there can be multiple accepts for a single entry, it would seem doubly important for the corresponding queries to take me to the enclosing visible parameter_specification. The visibility rules are very simple here. package Pack is function Foo (A : integer) return Boolean; Bool : Boolean := Foo(A => 2); -- corresponding_name_dec of A resolves to the -- visible parameter_spec of the spec of Foo end Pack; package body Pack is function Foo (A : integer) return Boolean is begin return Foo(A => 2); -- corresponding_name_dec of A resolves to the -- visible parameter_spec of the body of Foo end; Bool2 : Boolean := Foo(A => 2); -- corresponding_name_dec of A resolves to the -- visible parameter_spec of the body of Foo end Pack; with Pack; package FooPack is Fool : Boolean := Pack.Foo(A => 3); -- corresponding_name_dec of A resolves to -- the visible parameter_spec of the spec of Foo end; These are exactly the same rules for incomplete/private types which to me means consistency. Steve From sblake@sd.aonix.com Mon May 18 19:29:59 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id TAA06580; Mon, 18 May 1998 19:29:59 -0400 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 TAA13248 for ; Mon, 18 May 1998 19:31:22 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id TAA29580; Mon, 18 May 1998 19:24:56 -0400 Received: from gw.sd.aonix.com (gw.alsys.com [136.175.17.2]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id TAA25594 for ; Mon, 18 May 1998 19:26:00 -0400 (EDT) Received: from rasht.sd.aonix.com (mailhub.alsys.com) by gw.sd.aonix.com (4.1/SMI-4.1.1) id AA18817; Mon, 18 May 98 16:28:57 PDT Received: from puumba.telesoft by rasht.sd.aonix.com (4.1/TS-1.2c) id AA18878; Mon, 18 May 98 16:26:09 PDT Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id QAA21552; Mon, 18 May 1998 16:26:02 -0700 Date: Mon, 18 May 1998 16:26:02 -0700 From: sblake@sd.aonix.com (Steve Blake @pulsar) Message-Id: <199805182326.QAA21552@puumba.telesoft> To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com, rybin@possum.srcc.msu.su Subject: Re: "Double-defined" names - what should be returned by semantic queries? Content-Length: 7647 Status: OR >>From rybin@possum.srcc.msu.su Mon May 18 13:59:49 1998 >> >> > There is also the same question for all two part declarations that have >> > completions. If we applied the same rule, then definitions of references to >> > subtype_marks would always go the the incomplete type (if any) and references >> > in the immediate scope of declarations that complete private type and deferred >> > constant declarations would resolve to the private type and deferred >> > constant definitions and not to the full type or constant declarations which >> > hold the interesting information. >> >> I had thought this issue might apply to other constructs as well; >> thanks for pointing these out. > >But this case of incomplete/private and the corresponding full type >declarations is quite another story! In this case, it IS important to >return DIFFERENT defining names when querying from inside the package >being after the full definition and when querying from outside >the package (in case of a private type). Private (incomplete) type >declaration and the corresponding full type declaration defines >two DIFFERENT VIEWS on the same type, and the difference is important >for applications. But in case of a defining unit name or a >formal parameter name we have exactly the same view on the same entity. >And to return one name in one case and another name in another case >just means to confuse an application! Who on earth will keep in mind >this non-trivial visibility stuff defined in RM 95 section 8 when >writing tools? I guess I don't understand what is so confusing to the application. The rules I'm suggesting for unit and parameter names are exactly the same as for incomplete/private types, which we both agree is important to differentiate. Can you help me know more about the confused application? >> > References should simply resolve to the single visible declaration. >> > There are two major concerns: >> > >> > 1. We should follow the rules of Ada. The visibility rules in 8.3(19) and >> > 8.3(24) should be the primary rules on this issue. >> > >> > 2. If we force it to always go to the spec (if any) then we are possibly adding >> > significant overhead for some implementations to perform this normalization. >> > There are primitive ASIS queries available to client tools to do this by >> > their choice. > >I'm afraid, here Steve contradicts to himself - if there are _primitive_ >ASIS queries (not so hard, really, I've already added an extension >of this kind to ASIS-for-GNAT :), how can the implementation overheads >be _significant_? Just incorporate these _primitive_ queries into >your implementation! There are primitive queries, but the implementation overhead can be quite significant. Consider this: 1. It is generally efficient to get from a body to it corresponding spec because the implementation can keep a reference symbol/pointer with the body. It can be far more expensive to go from a spec to a body because when the spec is compiled, the body does not exist and hence there can be no link to the body. A search is then required to locate the body. 2. If the implementation does not keep a link with the body, then a search must also be made for the spec. If ASIS always normalizes the result of the semantic queries to resolve to the spec, then we are potentially forcing this type of overhead on any tools that want to resolve to the body. Extensions or normalization queries of this kind are perfect for the secondary toolkit layer but should not be made part of ASIS. >I have two other concerns in defence of Dan's original suggestion: > >1. For an _application_, it would be much more safe and comfortable > to have a "normalized" result of semantic queries in case of > "multiple-defined" names (private/incomplete and the corresponding > full type declarations are NOT the case of multiple-defined names!). > Consider and application dealing with a symbol/name table - > if we have two (or even more, consider entry formal parameters in > accept statements) "versions" for a defining name for a formal > parameter, maintaning such a table would be a real pain. > (Note, this discussion originated from the practical problem of > this kind :) The management of the symbol table should be done by toolkit secondary functions. It is not the responsibility of ASIS. The normalization from the body to the spec is likely effient, as I explained above. In either case, we are allowing the tool to make the choice. >2. ASIS already contains enough deviations from RM95, and all of them > are justified by application's benefits ("terminate" statement, > naming _expressions_ instead of the Ada notion of a name, an > attribute reference as a component of an attribute definition > clause, all this nice business with implicit label definitions > which are attached to statements instead of being appended to > the end of the corresponding declarative part etc). Are we > really afraid of adding one more situation when ASIS does not > _literally_ follow RM95, moreover, application benefits are > obvious in this case? > >> > Perhaps a simpler rule can be added: >> >> (I presume you mean "added instead of the other one", not "added to the >> other one".) >> >> > RULE: For declarations that have two parts, the semantic queries for >> > references to their defining names will return the visible declaration or >> > defining name. See the visibility rules in 8.3(19) and 8.3(24). >> >> As I pointed out before, the rule that ASIS implements, from a client >> tool perspective, can largely be arbitrary. We're talking about which >> definition to land on when there's more than one "corresponding" one to >> choose from; however, because some of these are optional, the existence >> of the rule (regardless of what it states) does not free the client from >> needing to query where it has in fact landed: there may only have been a >> choice of one since another possibility happened to be missing (in which >> case the rule won't apply anyway). >> >> However, I'll vote for Steve's rule, since he offers more justification >> than I did, and in particular since it affords a (potential) performance >> benefit for client tools. >> >> Robert Dewar writes, >> >> > I disaree, I think it is far cleaner, and much closer to the definition >> > of ADa to always refer to a single entity. There is only one entity here. >> > It is mentioned twice, but there is only one entity! >> >> Sure, but which "mention" do we choose to be "corresponding", and why? > >I think, the question is: what is more important - application needs (of >course, if applications really want "normalized to the first occurence" >defining names) or formal conformance of ASIS to RM 95. I agree, that >from language lawyer's viewpoint Steve's position is better justified. >What is the tool developers viewpoint??? > >Sergey If applications really want "normalized to the first occurence" then they can get that simply by performing the simple (and efficient) normalization themselves. If they don't, then ASIS hasn't forced them to do an expensive "unnormalization" to get back to the body. Lawyer stuff aside, ASIS should simply be consistent, and in the case of two part declarations, that means resolving to the declaration visible from the point of the reference. Steve >P.S. Sorry for terrible English - Moscow local time is 1.00 in the morning > @:-\ Can you spell ZZZZZZZZZZZZZZZZZZZ? *As in "get some sleep!/catch some Z's" From dewar@gnat.com Tue May 19 01:44:46 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id BAA06834; Tue, 19 May 1998 01:44:41 -0400 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 BAA16439 for ; Tue, 19 May 1998 01:46:05 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id BAA77632; Tue, 19 May 1998 01:39:37 -0400 Received: from nile.gnat.com (NILE.GNAT.COM [205.232.38.5]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id BAA02649 for ; Tue, 19 May 1998 01:40:26 -0400 (EDT) Received: by nile.gnat.com (5.0/1.20) id AA06877; Tue, 19 May 98 01:40:56 EDT Date: Tue, 19 May 98 01:40:56 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9805190540.AA06877@nile.gnat.com> To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com, dewar@gnat.com, rybin@possum.srcc.msu.su, sblake@sd.aonix.com Subject: Re: "Double-defined" names - what should be returned by semantic queries? Content-Length: 302 Status: OR <> In what sense is the parameter in the body a completion of the parameter in the spec, that doesn't make sense to me! From rybin@possum.srcc.msu.su Tue May 19 02:30:43 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id CAA06868; Tue, 19 May 1998 02:30:36 -0400 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 CAA16729 for ; Tue, 19 May 1998 02:31:58 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id CAA98854; Tue, 19 May 1998 02:25:29 -0400 Received: from logger.gamma.ru (logger.gamma.ru [194.186.254.23]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with ESMTP id CAA03368 for ; Tue, 19 May 1998 02:26:22 -0400 (EDT) Received: from srcc.UUCP (uucp@localhost) by logger.gamma.ru (8.8.7/8.8.7) with UUCP id KAA12285; Tue, 19 May 1998 10:30:01 +0400 (MSD) Received: by gamma.srcc.msu.su; Tue, 19 May 1998 10:28:16 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Tue, 19 May 1998 09:57:16 +0400 To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com, rybin@possum.srcc.msu.su, sblake@sd.aonix.com References: <199805182326.QAA21552@puumba.telesoft> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Tue, 19 May 98 09:57:16 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: "Double-defined" names - what should be returned by semantic queries? Lines: 123 Content-Length: 6073 Status: OR > >But in case of a defining unit name or a > >formal parameter name we have exactly the same view on the same entity. > >And to return one name in one case and another name in another case > >just means to confuse an application! Who on earth will keep in mind > >this non-trivial visibility stuff defined in RM 95 section 8 when > >writing tools? > > I guess I don't understand what is so confusing to the application. The > rules I'm suggesting for unit and parameter names are exactly the same > as for incomplete/private types, which we both agree is important to > differentiate. > > Can you help me know more about the confused application? Consider an application which collects information about variable definitions and variable usage to prove some program properties. Such an application may be completely disoriented when analyzing formal parameters of subprograms having separate spec and body. But I agree, that if an application is aware of these problems with "double-defined" names and if it has appropriate secondary queries, it becomes just a question of application design and implementation not to get messed up with this. > >I'm afraid, here Steve contradicts to himself - if there are _primitive_ > >ASIS queries (not so hard, really, I've already added an extension > >of this kind to ASIS-for-GNAT :), how can the implementation overheads > >be _significant_? Just incorporate these _primitive_ queries into > >your implementation! > > There are primitive queries, but the implementation overhead can be quite > significant. Consider this: > > 1. It is generally efficient to get from a body to it corresponding spec > because the implementation can keep a reference symbol/pointer with the > body. It can be far more expensive to go from a spec to a body because > when the spec is compiled, the body does not exist and hence there can > be no link to the body. A search is then required to locate the body. > > 2. If the implementation does not keep a link with the body, then a search > must also be made for the spec. This also is "implementation-specific". Consider a compiler which itself does "normalization-to-first-occurence" in its internal data structures (it may be quite reasonable for a compiler, and it does not lead to any Ada rule violation in the compiler behaviour). In this case, for ASIS providing "normalized" defining occurences may be very cheap, but trying to follow exactly RM-defined visibility rules may need searches and be therefore expensive. > > If ASIS always normalizes the result of the semantic queries to resolve to > the spec, then we are potentially forcing this type of overhead on any tools > that want to resolve to the body. > > Extensions or normalization queries of this kind are perfect for the > secondary toolkit layer but should not be made part of ASIS. Are not you afraid, that this may be a real problem for portability? If many (I still would be very interested to know HOW many) applications need such queries, some unification would definitely be helpful. But, of course, we are not able to unify everything... :( > >I have two other concerns in defence of Dan's original suggestion: > > > >1. For an _application_, it would be much more safe and comfortable > > to have a "normalized" result of semantic queries in case of > > "multiple-defined" names (private/incomplete and the corresponding > > full type declarations are NOT the case of multiple-defined names!). > > Consider and application dealing with a symbol/name table - > > if we have two (or even more, consider entry formal parameters in > > accept statements) "versions" for a defining name for a formal > > parameter, maintaning such a table would be a real pain. > > (Note, this discussion originated from the practical problem of > > this kind :) > > The management of the symbol table should be done by toolkit secondary > functions. It is not the responsibility of ASIS. The normalization from > the body to the spec is likely effient, as I explained above. In either > case, we are allowing the tool to make the choice. Technically, it looks like I have to agree with this point, and the discussion is starting to be a matter of tastes :) > >> > RULE: For declarations that have two parts, the semantic queries for > >> > references to their defining names will return the visible declaration or > >> > defining name. See the visibility rules in 8.3(19) and 8.3(24). > >> > > If applications really want "normalized to the first occurence" then they > can get that simply by performing the simple (and efficient) normalization > themselves. If they don't, then ASIS hasn't forced them to do an expensive > "unnormalization" to get back to the body. > > Lawyer stuff aside, ASIS should simply be consistent, and in the case of > two part declarations, that means resolving to the declaration visible from > the point of the reference. The only thing I'm not completely agree with is an efficiency issue. It definitely is implementation-specific and depends on whether or not the underlying Ada compiler does the normalization itself. But I must confess, that all the rest in Steve's approach is better justified indeed. ASIS works with defining names of entities, but not with entities themselves. If an entity has more then one defining name associating with it, then ASIS, when asking about the corresponding name (not entity!) definition, should return those name which corresponds to the Ada visibility rules. And mapping names on entities should be the application responsibility. I cannot see anything wrong in this approach > >P.S. Sorry for terrible English - Moscow local time is 1.00 in the morning > > @:-\ > > Can you spell ZZZZZZZZZZZZZZZZZZZ? *As in "get some sleep!/catch some Z's" In Russian we usially use some other sound in this situation. It's hard to write it down, something like HRRRHRRRHRRRHRRR ;) From rybin@possum.srcc.msu.su Tue May 19 02:30:44 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id CAA06870; Tue, 19 May 1998 02:30:43 -0400 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 CAA16734 for ; Tue, 19 May 1998 02:32:06 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id CAA99388; Tue, 19 May 1998 02:25:35 -0400 Received: from logger.gamma.ru (logger.gamma.ru [194.186.254.23]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with ESMTP id CAA03365 for ; Tue, 19 May 1998 02:26:17 -0400 (EDT) Received: from srcc.UUCP (uucp@localhost) by logger.gamma.ru (8.8.7/8.8.7) with UUCP id KAA12291; Tue, 19 May 1998 10:30:02 +0400 (MSD) Received: by gamma.srcc.msu.su; Tue, 19 May 1998 10:28:25 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Tue, 19 May 1998 10:26:58 +0400 To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com, dewar@GNAT.Com, rybin@possum.srcc.msu.su, sblake@sd.aonix.com References: <199805182254.PAA18583@puumba.telesoft> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Tue, 19 May 98 10:26:58 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: "Double-defined" names - what should be returned by semantic queries? Lines: 65 Content-Length: 3309 Status: OR > >From dewar@gnat.com Mon May 18 14:10:28 1998 > > > ><<> I disaree, I think it is far cleaner, and much closer to the definition > >> of ADa to always refer to a single entity. There is only one entity here. > >> It is mentioned twice, but there is only one entity! > > > >Sure, but which "mention" do we choose to be "corresponding", and why? > >>> > > > >We shoud be consistent. If there is only one entity, and apparently you > >agree with it, then ASIS should return the same single entity, and > >clearly the spec entity is the better choice once you agree that > >this desirable consistency rule should hold. > > > No, I don't agree that there is only one entity. Read 8.3(19) below and see > what I mean. > > "If the completion of a declaration is a declaration, then within the scope > of the completion, the first declaration is hidden from all visibility. > Similarly, a discriminant_specification or parameter_specification is hidden > within the scope of a corresponding discriminant_specification or > parameter_specification of a corresponding completion, or of a corresponding > accept statement." Let's turn this discussion another way. ASIS is an interface to an Ada environment, and it has ASIS Element as a primary means to express Ada syntaxt and semantics. Element is a syntaxt notion, but entity you are discussing about is not a syntaxt notion. ASIS is a "syntax-based" interface. It can return defining names of entities, but it cannot return entities themselves. In Ada one entity may have more then one corresponding defining name, sometimes they correspond to significantly different views on the entity (private <-> full views of a type). If in ASIS we ask about the Corresponding_Name_Definition for some usage name, Ada visibility rules should define the result just because of the very narure of the query (we are asking the visibility question, are not we?). Corresponding_Name_Definition is the query about names, but not about entities, and this probably was the real origin of the application problem from which this discussion started. If in ASIS we ask about the Corresponding_Called_Function for some function call, the situation is somewhat ill-defined already in ASIS. What are we asking about - about the name of the called entity visible at the point of the call or about the called entity itself? In former case the visibility rules should work, in latter the "normalized-to-first-definition" approach seems to have more sense. ASIS cannot ask queries about entities (it just does not have the corresponding abstraction), but the impression making by the Corresponding_Called_Function/Corresponding_Called_Entity queries is that the _intent_ of these queries is to ask for a called _entity_ (look at the names of these queries!). The visibility issue seems to be of no interest when processing calls, but normalization of the results (to be sure if the same or different subbrograms are called) looks much more important. I have to agree with Steve's approach for Corresponding_Name_Definition, but I'm not so sure for Corresponding_Called_Function and Corresponding_Called_Entity. I cannot see enough formal reasons to apply rules from RM95 8.3 to choose what should be returned - a spec, a body or a stub. Sergey From dan@flash.irvine.com Tue May 19 04:18:10 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id EAA06937; Tue, 19 May 1998 04:18:10 -0400 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 EAA17479 for ; Tue, 19 May 1998 04:19:33 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id EAA58536; Tue, 19 May 1998 04:13:08 -0400 Received: from irvine.com (flash.irvine.com [192.160.8.4]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id EAA05430 for ; Tue, 19 May 1998 04:14:06 -0400 (EDT) Received: from flash.irvine.com by flash.irvine.com id aa07607; 19 May 98 1:17 PDT To: rybin@possum.srcc.msu.su cc: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com, dewar@GNAT.Com, sblake@sd.aonix.com, dan@flash.irvine.com Subject: Re: "Double-defined" names - what should be returned by semantic queries? Date: Tue, 19 May 1998 01:16:52 PDT From: Dan Eilers Message-ID: <9805190117.aa07607@flash.irvine.com> Content-Length: 794 Status: OR Sergey wrote: > Let's turn this discussion another way. ASIS is an interface to an Ada > environment, and it has ASIS Element as a primary means to express Ada > syntaxt and semantics. Element is a syntaxt notion, but entity you are > discussing about is not a syntaxt notion. > ... This claim that "ASIS is an interface to an Ada environment" is not true enough to draw any inferences from it. An "Ada environment" by RM 10.1.4(1) "is a conceptual declarative_part that forms the outermost declarative region of the context of any compilation." But one cannot for example infer from this that ASIS elements are restricted to the visible declarative items of library units. Indeed, they are neither restricted to declarative items, nor to previously compiled units. -- Dan Eilers From roby Fri May 22 09:55:11 1998 Return-Path: Received: by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id JAA14623; Fri, 22 May 1998 09:55:10 -0400 Date: Fri, 22 May 1998 09:55:10 -0400 From: roby (Clyde Roby) Message-Id: <199805221355.JAA14623@cronus.csed.ida.org> To: Colket@ACM.Org Cc: croby Subject: Issue #095, semantic queries on multi-part declarations Content-Length: 1673 Status: OR !ASIS Issue #095 !topic Semantic queries for multi-part declarations !reference ASIS 95 !from Sergey Rybin 98-05-15 !keywords semantic queries declarations multi-part !discussion Consider the following example: package Pkg1 is procedure Foo ( A: in out integer ); ^^^ <----------------- ???? <--------- end Pkg1; | | package body Pkg1 is | | procedure Foo ( A: in out integer ) is | begin ^^^ <------------------ ???? <------- A := 5; | ^^^ >-----------> Corresponding_Name_Definition >--> end Foo; end Pkg1; Which definition of the formal parameter A should be returned by Corresponding_Name_Definition when applying to usage occurence of A in an assignment statement? This is not clarified now in the ASIS definition, and this makes a problem for tools - what should a tool expect in this case? (My message just originates from a real problem of this kind) I think ASIS should clarify this. Note, that what is presented above is only an example. The same problem exists for Corresponding_Called_Function in case if a separate spec exists along with the body for a given function. !resolution Accept. !date 98-05-21 Add the following statement as a clarification to section 2.2.3.5, (Semantic References): Semantic queries that return declaration or defining names of multi-part declarations always return the single visible declaration. From dan@flash.irvine.com Fri May 22 20:43:17 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id UAA16965; Fri, 22 May 1998 20:43:17 -0400 Received: from irvine.com (flash.irvine.com [192.160.8.4]) by cs.ida.org (8.8.7/8.8.7) with SMTP id UAA07967 for ; Fri, 22 May 1998 20:44:41 -0400 (EDT) Received: from flash.irvine.com by flash.irvine.com id aa02647; 22 May 98 17:43 PDT To: colket@colket.org cc: ASIS-Technical@ns1.sw-eng.falls-church.va.us, roby@ida.org, dan@flash.irvine.com Subject: Re: Please Review ASIS 20Q Date: Fri, 22 May 1998 17:43:46 PDT From: Dan Eilers Message-ID: <9805221743.aa02647@flash.irvine.com> Content-Length: 1514 Status: OR > The asis20q980521.doc contains all the updates from the ISO Balloting > process. In addition, the following Editorial Comments and Technical > Issues have been incorporated: > >... > I#095 Semantic queries for multi-part declarations S. Rybin I am surprised to see that I#095 was incorporated, since the email discussion has not reached any sort of consensus, as far as I can tell. > I#091 reflects Dan Eiler's concern when pragma Restrictions(No_Dispatch) > applies. The commentary for this issue still needs clarification: # function Is_Dispatching_Call (Call : in Asis.Element) return Boolean; # #------------------------------------------------------------------------ #-- Call - Specifies the element to query. #-- #-- Returns True if the controlling tag of Call is dynamically determined. #-- #-- This function shall always return False when #-- pragma Restrictions(No_Dispatch) applies. Does "dynamically determined" refer to a determination by a compiler? If so, what should a stand-alone ASIS implementation return for this query? What is meant by "pragma Restrictions(No_Dispatch) applies"? Does this mean that the pragma simply exists in the source code? Or does it mean that a compiler took advantage of the pragma to statically determine the tag? What should an ASIS implementation return in the absence of this pragma, but in the presence of a compiler optimization that statically determines the tag, based on noticing a lack of any references to T'Class. -- Dan Eilers From colket@colket.org Wed May 27 00:45:58 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id AAA21931; Wed, 27 May 1998 00:45:58 -0400 Received: from smtp2.erols.com (smtp2.erols.com [207.172.3.235]) by cs.ida.org (8.8.7/8.8.7) with ESMTP id AAA26556 for ; Wed, 27 May 1998 00:47:23 -0400 (EDT) Received: from colket.org (207-172-45-96.s96.tnt5.brd.erols.com [207.172.45.96]) by smtp2.erols.com (8.8.8/8.8.5) with ESMTP id AAA26928; Wed, 27 May 1998 00:46:32 -0400 (EDT) Message-ID: <356B9A88.7DBD7035@colket.org> Date: Wed, 27 May 1998 00:46:00 -0400 From: Currie Colket Reply-To: colket@colket.org X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Dan Eilers , ASIS Technical CC: roby@ida.org Subject: Issue #091 (was Re: Please Review ASIS 20Q) References: <9805221743.aa02647@flash.irvine.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1579 Status: OR Dear ASIS-Technical: Dan Eilers raises two excellent points which I have separated into 2 separate emails, the first on I#091 and the second on I#095. This email is for I#091: > > The asis20q980521.doc contains all the updates from the ISO Balloting > > process. In addition, the following Editorial Comments and Technical > > Issues have been incorporated: > > > >... > > I#095 Semantic queries for multi-part declarations S. Rybin > > I am surprised to see that I#095 was incorporated, since the email > discussion has not reached any sort of consensus, as far as I can tell. You are right, I may have been a bit premature in providing a solution for this issue; I apologize. Please view the following as a proposed solution to Issue#095: !resolution Accept. !date 98-05-21 Add the following statement as a clarification to clause 2.2.3.5, (Semantic References): Semantic queries that return declaration or defining names of multi-part declarations always return the single visible declaration. Steve Blake was instrumental in this proposed solution through a telephone call which unfortunately was not available to the net. The solution provides a consistent approach to the entire specification without the need to specifically identify the ASIS interfaces where multi-part declarations are problemmatic. Please view the above as a proposed solution. Those disagreeing with the proposed solution should comment by 2 June to ASIS technical. Sorry for the deviation in procedure which caused the need of Dan's email. v/r Currie From dan@flash.irvine.com Wed May 27 19:53:39 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id TAA01516; Wed, 27 May 1998 19:53:39 -0400 Received: from irvine.com (flash.irvine.com [192.160.8.4]) by cs.ida.org (8.8.7/8.8.7) with SMTP id TAA18533 for ; Wed, 27 May 1998 19:55:04 -0400 (EDT) Received: from flash.irvine.com by flash.irvine.com id aa11037; 27 May 98 16:53 PDT To: colket@colket.org cc: ASIS-Technical@sw-eng.falls-church.va.us, roby@ida.org, dan@flash.irvine.com Subject: Re: Issue #091 (was Re: Please Review ASIS 20Q) Date: Wed, 27 May 1998 16:53:17 PDT From: Dan Eilers Message-ID: <9805271653.aa11037@flash.irvine.com> Content-Length: 1772 Status: OR > You are right, I may have been a bit premature in providing a solution for this > issue; I apologize. Please view the following as a proposed solution to > Issue#095: > > !resolution Accept. > !date 98-05-21 > > Add the following statement as a clarification to clause 2.2.3.5, > (Semantic References): > > Semantic queries that return declaration or defining names of > multi-part declarations always return the single visible > declaration. > > Steve Blake was instrumental in this proposed solution through a telephone call > which unfortunately was not available to the net. The solution provides a > consistent approach to the entire specification without the need to > specifically identify the ASIS interfaces where multi-part declarations are > problemmatic. Please view the above as a proposed solution. Those disagreeing > with the proposed solution should comment by 2 June to ASIS technical. > > Sorry for the deviation in procedure which caused the need of Dan's email. > > v/r > Currie I disagree with this proposed solution. It seems to have a surface consistency with private types, in that the declaration returned depends on the location of the reference. However, the situation for subprograms/parameters is very different than for private types. With private types, the semantics of a reference to a type depend on the location of the reference. But the semantics of a subprogram call and/or parameter association does _not_ depend on the location of the call. I cannot imagine any ASIS client tool benefiting from the proposed distinction between references before and after the declaration of a subprogram body. But I can imagine an ASIS client tool getting confused by the distinction. -- Dan Eilers From dan@flash.irvine.com Wed May 27 20:37:21 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id UAA01562; Wed, 27 May 1998 20:37:21 -0400 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 UAA19180 for ; Wed, 27 May 1998 20:38:47 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id UAA1801474; Wed, 27 May 1998 20:32:03 -0400 Received: from irvine.com (flash.irvine.com [192.160.8.4]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id UAA13291 for ; Wed, 27 May 1998 20:33:24 -0400 (EDT) Received: from flash.irvine.com by flash.irvine.com id aa14747; 27 May 98 17:36 PDT To: colket@colket.org cc: ASIS-Technical@ns1.sw-eng.falls-church.va.us Subject: Re: Issue #091 (was Re: Please Review ASIS 20Q) Date: Wed, 27 May 1998 17:36:22 PDT From: Dan Eilers Message-ID: <9805271736.aa14747@flash.irvine.com> Content-Length: 815 Status: OR There is currently an inconsistency in the handling of multi-part declarations, which perhaps should be remedied. For subprograms, packages, and tasks, there are distinct ASIS queries for returning the spec, given the body, and vice versa: -- 15.26 function Corresponding_Declaration -- 15.27 function Corresponding_Body However, for private types and deferred constants, there is only a single query, whose behavior varies depending on whether its parameter is a complete or incomplete declaration. -- 15.11 function Corresponding_Constant_Declaration -- 15.13 function Corresponding_Type_Declaration This seems error prone, since an ASIS client always has to check which kind of type declaration it is holding in order to know which kind will be returned. -- Dan Eilers From cdaniel.cooper@boeing.com Fri May 29 16:34:12 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id QAA05947; Fri, 29 May 1998 16:34:11 -0400 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 QAA06007 for ; Fri, 29 May 1998 16:35:37 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id QAA51504; Fri, 29 May 1998 16:25:51 -0400 Received: from mailgate2.boeing.com (mailgate2.boeing.com [199.238.248.100]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with ESMTP id KAA05872 for ; Fri, 29 May 1998 10:45:09 -0400 (EDT) Received: from mercury.boeing.com ([130.42.138.11]) by mailgate2.boeing.com (8.8.5/8.8.5) with SMTP id HAA01209 for ; Fri, 29 May 1998 07:48:51 -0700 (PDT) Received: from longshot.ds.boeing.com by mercury.boeing.com; Fri, 29 May 98 07:48:18 -0700 Received: (from cooper@localhost) by longshot.ds.boeing.com (SMI-8.6/RDS-1.0) id HAA10346; Fri, 29 May 1998 07:48:15 -0700 Date: Fri, 29 May 1998 07:48:15 -0700 From: cdaniel.cooper@boeing.com (C. Daniel Cooper) Message-Id: <199805291448.HAA10346@longshot.ds.boeing.com> To: ASIS-technical@ns1.sw-eng.falls-church.va.us Subject: Re: Issue #091 Cc: tom@longshot.ds.boeing.com X-Sun-Charset: US-ASCII Content-Length: 1902 Status: OR Dan Eilers wrote, > I cannot imagine any ASIS client tool benefiting from the proposed > distinction between references before and after the declaration > of a subprogram body. But I can imagine an ASIS client tool > getting confused by the distinction. It's more basic than that. As I pointed out before, from a tool perspective, the rule that ASIS implements can largely be arbitrary, ie, no rule will be more "beneficial" than any another. We're talking about which definition to land on when there's more than one "corresponding" one to choose from; this leads to two scenarios: 1) the tool doesn't care: Many applications will look to further decompose the definition, and since Ada requires all the definitions to be identical, it won't really matter which one is chosen. In this case, the rule is irrelevant. 2) the tool does care: Where it *does* matter is if the application wants to look outwards rather than inwards, ie, to the enclosing hierarchy. But in this case, the tool can't depend on the rule anyway, to know for certain which definition was chosen. This is because one or more of the definitions may be absent, and the existence of the rule (regardless of what it states) does not free the client from needing to query where it has in fact landed. So why does ASIS need such a rule at all? Answer: for consistency. How shall we pick the rule? From a tool perspective, the only consideration would be: performance. In that regard, Steve's rule seemed best :-) however, Sergey seemed not so sure that that approach indeed offered the best performance :-( On that point, I'll let the ASIS implementors decide. -- C. Daniel Cooper =========v=======================v Engineer at Software | All opinions are mine | 206-655-3519 | and may not represent | CDaniel.Cooper@Boeing.com | those of my employer. | ==========================^=======================^ From dewar@gnat.com Fri May 29 23:40:23 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id XAA06415; Fri, 29 May 1998 23:40:22 -0400 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 XAA10065 for ; Fri, 29 May 1998 23:41:48 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id XAA53762; Fri, 29 May 1998 23:31:54 -0400 Received: from nile.gnat.com (NILE.GNAT.COM [205.232.38.5]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id VAA24461 for ; Fri, 29 May 1998 21:56:46 -0400 (EDT) Received: by nile.gnat.com (5.0/1.20) id AA00665; Fri, 29 May 98 21:56:55 EDT Date: Fri, 29 May 98 21:56:55 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9805300156.AA00665@nile.gnat.com> To: colket@colket.org, dan@flash.irvine.com, sblake@sd.aonix.com Subject: Re: Issue #091 (was Re: Please Review ASIS 20Q) Cc: ASIS-Technical@ns1.sw-eng.falls-church.va.us Content-Length: 331 Status: OR <> I strongly agree with this. From dewar@gnat.com Fri May 29 23:40:42 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id XAA06420; Fri, 29 May 1998 23:40:41 -0400 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 XAA10068 for ; Fri, 29 May 1998 23:42:07 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id XAA26642; Fri, 29 May 1998 23:28:39 -0400 Received: from nile.gnat.com (NILE.GNAT.COM [205.232.38.5]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id VAA24455 for ; Fri, 29 May 1998 21:56:06 -0400 (EDT) Received: by nile.gnat.com (5.0/1.20) id AA00654; Fri, 29 May 98 21:56:15 EDT Date: Fri, 29 May 98 21:56:15 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9805300156.AA00654@nile.gnat.com> To: dan@flash.irvine.com, sblake@sd.aonix.com Subject: Re: Issue #091 (actually Issue #095) Cc: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@boeing.com, tom@longshot.ds.boeing.com Content-Length: 139 Status: OR I am having trouble understanding why anyone things it makes ASIS applications *easier* to return different entities at differtent points. From dan@flash.irvine.com Fri May 29 23:47:33 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id XAA06480; Fri, 29 May 1998 23:47:32 -0400 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 XAA10174 for ; Fri, 29 May 1998 23:48:58 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id XAA11696; Fri, 29 May 1998 23:34:13 -0400 Received: from irvine.com (flash.irvine.com [192.160.8.4]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id UAA23344 for ; Fri, 29 May 1998 20:59:23 -0400 (EDT) Received: from flash.irvine.com by flash.irvine.com id aa09989; 29 May 98 18:01 PDT To: sblake@sd.aonix.com cc: colket@colket.org, ASIS-Technical@ns1.sw-eng.falls-church.va.us, dan@flash.irvine.com Subject: Re: Issue #091 (was Re: Please Review ASIS 20Q) Date: Fri, 29 May 1998 18:01:38 PDT From: Dan Eilers Message-ID: <9805291801.aa09989@flash.irvine.com> Content-Length: 511 Status: OR > It is hard to defend consistency in this light, and I won't try. I agree > with Dan's point in that regard. But I don't believe either of these should > be changed at this time because they are no more prone to errors than are any > other queries. It is not difficult to write error free applications that > use these queries. > > > Steve Again, I don't buy the argument that since other ASIS queries are error-prone, we shouldn't attempt to minimize error-proneness where we easily can. -- Dan From sblake@sd.aonix.com Sat May 30 04:39:08 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id EAA06668; Sat, 30 May 1998 04:39:07 -0400 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 EAA11264 for ; Sat, 30 May 1998 04:40:34 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id EAA111502; Sat, 30 May 1998 04:28:12 -0400 Received: from gw.sd.aonix.com (gw.alsys.com [136.175.17.2]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id UAA22683 for ; Fri, 29 May 1998 20:17:29 -0400 (EDT) Received: from rasht.sd.aonix.com (mailhub.alsys.com) by gw.sd.aonix.com (4.1/SMI-4.1.1) id AA24211; Fri, 29 May 98 17:20:30 PDT Received: from puumba.telesoft by rasht.sd.aonix.com (4.1/TS-1.2c) id AA02143; Fri, 29 May 98 17:17:32 PDT Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id RAA00874; Fri, 29 May 1998 17:17:29 -0700 Date: Fri, 29 May 1998 17:17:29 -0700 From: sblake@sd.aonix.com (Steve Blake @pulsar) Message-Id: <199805300017.RAA00874@puumba.telesoft> To: colket@colket.org, dan@flash.irvine.com Subject: Re: Issue #091 (was Re: Please Review ASIS 20Q) Cc: ASIS-Technical@ns1.sw-eng.falls-church.va.us Content-Length: 2012 Status: OR >From dan@flash.irvine.com Wed May 27 17:38:49 1998 >To: colket@colket.org >Cc: ASIS-Technical@ns1.sw-eng.falls-church.va.us >Subject: Re: Issue #091 (was Re: Please Review ASIS 20Q) > > >There is currently an inconsistency in the handling of multi-part >declarations, which perhaps should be remedied. > >For subprograms, packages, and tasks, there are distinct ASIS queries >for returning the spec, given the body, and vice versa: > >-- 15.26 function Corresponding_Declaration >-- 15.27 function Corresponding_Body > >However, for private types and deferred constants, there is only >a single query, whose behavior varies depending on whether its >parameter is a complete or incomplete declaration. > >-- 15.11 function Corresponding_Constant_Declaration >-- 15.13 function Corresponding_Type_Declaration > >This seems error prone, since an ASIS client always has to >check which kind of type declaration it is holding in order to >know which kind will be returned. > > -- Dan Eilers > ASIS clients always do have to check the kind of element they hold. As recently discussed, this is the way ASIS tools must operate to avoid errors or wrong results. This fact is equally true for both sets. Most of these can return a Nil_Element, so it is especially prudent to classify results before passing them along. The semantics of these operations are significantly different for somewhat historical reasons. The first set returns the identity element if asking for the corresponding_declaration of a declaration. It was decided in ASISWG meetings to retain this functionality inherant in ASIS 1.1. The second set is different as stated. It is hard to defend consistency in this light, and I won't try. I agree with Dan's point in that regard. But I don't believe either of these should be changed at this time because they are no more prone to errors than are any other queries. It is not difficult to write error free applications that use these queries. Steve From cdaniel.cooper@Boeing.Com Sat May 30 07:18:56 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id HAA06743; Sat, 30 May 1998 07:18:55 -0400 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 HAA12775 for ; Sat, 30 May 1998 07:20:22 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id HAA125650; Sat, 30 May 1998 07:06:52 -0400 Received: from mailgate2.boeing.com (mailgate2.boeing.com [199.238.248.100]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with ESMTP id HAA03189 for ; Sat, 30 May 1998 07:05:12 -0400 (EDT) Received: from mercury.boeing.com ([130.42.138.11]) by mailgate2.boeing.com (8.8.5/8.8.5) with SMTP id EAA23835 for ; Sat, 30 May 1998 04:09:00 -0700 (PDT) Received: from longshot.ds.boeing.com by mercury.boeing.com; Sat, 30 May 98 04:09:02 -0700 Received: (from cooper@localhost) by longshot.ds.boeing.com (SMI-8.6/RDS-1.0) id EAA10833 for ASIS-technical@SW-Eng.Falls-Church.VA.US; Sat, 30 May 1998 04:08:59 -0700 Date: Sat, 30 May 1998 04:08:59 -0700 From: cdaniel.cooper@Boeing.Com (C. Daniel Cooper) Message-Id: <199805301108.EAA10833@longshot.ds.boeing.com> To: ASIS-technical@ns1.sw-eng.falls-church.va.us Subject: Re: Issue #091 (actually Issue #095) X-Sun-Charset: US-ASCII Content-Length: 1063 Status: OR Rober Dewar wrote, > I am having trouble understanding why anyone things it makes ASIS > applications *easier* to return different entities at differtent points. I can see where it *would* affect performance, however. And it's not "easier" to have a rule that says to always return the same definition, since the rule can't always be obeyed: that definition might be absent, such that another (identical) definition gets returned, and the ASIS tool can't avoid checking to find out which one it got (if it matters to the analysis -- otherwise, by definition, it won't matter). From a tool perspective, neither of the proposed rules is "easier." For those of you who think otherwise, I'd like to hear a defense rather than claims. If there is a "less error-prone" rule, let's hear *why* it is. -- C. Daniel Cooper =========v=======================v Engineer at Software | All opinions are mine | 206-655-3519 | and may not represent | CDaniel.Cooper@Boeing.com | those of my employer. | ==========================^=======================^ From dewar@gnat.com Sat May 30 08:43:38 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA06781; Sat, 30 May 1998 08:43:38 -0400 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 IAA13555 for ; Sat, 30 May 1998 08:45:01 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id IAA166122; Sat, 30 May 1998 08:30:59 -0400 Received: from nile.gnat.com (NILE.GNAT.COM [205.232.38.5]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id HAA03938 for ; Sat, 30 May 1998 07:44:40 -0400 (EDT) Received: by nile.gnat.com (5.0/1.20) id AA13964; Sat, 30 May 98 07:44:54 EDT Date: Sat, 30 May 98 07:44:54 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9805301144.AA13964@nile.gnat.com> To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@boeing.com Subject: Re: Issue #091 (actually Issue #095) Content-Length: 4142 Status: OR <> First of all, I cannot see any inherent performance problem if you are talking about performance of the underlying implementaiton problem. Indeed, changing GNAT to give inconsistent results depending on the context of the search would complicate the implementation and slow it down, since it would require machinery that is not present now. No big deal, and the slow down is probably negligible, but to make the contrary decision on the basis that there is some fundamental problem in implementation would be a heavy burden. If you are talking about performance of the application code, I simply can't see that. If anything the additional complexity that comes from the fact that different entities are returned in different situations would seem likely to me to complicate things. I am not sure about "the rule can't always be obeyed". The rule is that all instances of the same entity always return a consistent result. This rule can always be obeyed. How useful it is to applications is unclear, but again it is a heavy burden to try to make the point that it is *more* useful to applications to return inconsistent results. Consider for example a cross-reference application. Certainly a typical user considers "references to the spec" and "references to the body" to be identical (in fact typical users would not be aware of the idea of separate kinds of references in the case say of a subprogram body). So it would seem that a simple cross-reference utility would be much easier to write if the entity identities corresponded. In order to make the case that it is more valuable to have what I am callling here "inconsistent" results, some definite argument needs to be given that this helps either the ASIS implementation at a fundamental non-implementation specific level, or that it helps applications in a fundamental non-implementation specific manner. I do not see that either case has been made. It does seem that existing implementations are currently inconsistent with one another. Certainly GNAT always returns a consistent result (e.g. the spec in the case of a subprogram -- where of course, as in the RM the body can serve as a spec if there is none). From what I can understand other implementations take the other model. This means that trying to standardize at this stage on one or the other model can cause disruption to existing implementations. Certainly in the case of GNAT, we very deliberately considered this issue, and very deliberately chose what we considered to be the obviously desirable approach. It is not a huge amount of work to change, but from our point of view it seems (a) a waste of time and (b) to produce a less desirable result. Before we can be convinced to spend the time changing our implementation, we most certainly have to be convinced that it is worthwhile to do so. So far, nothing that has been said convincingly makes the case. Here is a question: it seems to me that a typical application that was written to deal with "different" entities being returned would also work with the "consistent" entity model. Is this the case? If so, then perhaps we are stuck with leaving this as implementation defined, and people who want to write portable ASIS applications have to be careful to deal with both cases. Probably this is something that has to be discussed at the next ASIS meeting. I doubt we will make much more progress in email. As is often the case, email is useful in delineating the issues, but poor as a medium for resolving them! From dewar@gnat.com Sat May 30 09:31:18 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id JAA06814; Sat, 30 May 1998 09:31:18 -0400 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 JAA13985 for ; Sat, 30 May 1998 09:32:44 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id JAA77764; Sat, 30 May 1998 09:25:52 -0400 Received: from nile.gnat.com (NILE.GNAT.COM [205.232.38.5]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id IAA04822 for ; Sat, 30 May 1998 08:33:16 -0400 (EDT) Received: by nile.gnat.com (5.0/1.20) id AA27917; Sat, 30 May 98 08:33:22 EDT Date: Sat, 30 May 98 08:33:22 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9805301233.AA27917@nile.gnat.com> To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@boeing.com, sblake@sd.aonix.com Subject: Re: Issue #091 Cc: tom@longshot.ds.boeing.com Content-Length: 1059 Status: OR <> I don't see this at all, can you explain more clearly why this is the case? Sure, it is the case when an ASIS application first picks up a reference to an entity, that it myust look at what it has found, but subsequent references could simply record as equal to one that it had already located and put in its table, and no check is necessary. It is this paradigm that seems so much more straightforward with the "one entity" approach. At best the above argument says that it is no LESS convenient to have the multiple-entity approach (and even that is dubious, as I note above), but completely missing seems a positive argument that it is MORE convenient. From rybin@possum.srcc.msu.su Sat May 30 10:35:29 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id KAA06864; Sat, 30 May 1998 10:35:29 -0400 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 KAA14357 for ; Sat, 30 May 1998 10:36:49 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id KAA25716; Sat, 30 May 1998 10:29:56 -0400 Received: from logger.gamma.ru (logger.gamma.ru [194.186.254.23]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with ESMTP id KAA06933 for ; Sat, 30 May 1998 10:31:14 -0400 (EDT) Received: from srcc.UUCP (uucp@localhost) by logger.gamma.ru (8.8.8/8.8.8) with UUCP id SAA00466; Sat, 30 May 1998 18:34:54 +0400 (MSD) (envelope-from possum!possum.srcc.msu.su!rybin@gamma.srcc.msu.su) Received: by gamma.srcc.msu.su; Sat, 30 May 1998 16:38:22 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Sat, 30 May 1998 16:34:35 +0400 To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com, dewar@GNAT.Com References: <9805301144.AA13964@nile.gnat.com> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Sat, 30 May 98 16:34:35 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: Issue #091 (actually Issue #095) Lines: 27 Content-Length: 982 Status: OR > Probably this is something that has to be discussed at the next ASIS > meeting. I doubt we will make much more progress in email. As is often > the case, email is useful in delineating the issues, but poor as a medium > for resolving them! I completely agree with this. An hour ago I started to write a respond to one of the previous messages in this discussion, but I was interrupted by my children, and when I came back to my computer, I saw Robert's message which says about the same I was going to say. It looks like we are stuck in this discussion. Efficiency is not the concern - different solutions may be more efficient in different Ada/ASIS implementations. Consistency with RM95 is not the concern either: RM95 is not about ASIS, and sometimes ASIS questions cannot be answered on the base of RM95 (or they may have more then one answer). Application benefits probably are the most important thing, but we cannot come to the common decision here. Sergey From dewar@gnat.com Sat May 30 10:40:30 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id KAA06869; Sat, 30 May 1998 10:40:29 -0400 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 KAA14396 for ; Sat, 30 May 1998 10:41:55 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id KAA155076; Sat, 30 May 1998 10:35:07 -0400 Received: from nile.gnat.com (NILE.GNAT.COM [205.232.38.5]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id KAA06941 for ; Sat, 30 May 1998 10:36:38 -0400 (EDT) Received: by nile.gnat.com (5.0/1.20) id AA02960; Sat, 30 May 98 10:36:48 EDT Date: Sat, 30 May 98 10:36:48 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9805301436.AA02960@nile.gnat.com> To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com, dewar@gnat.com, rybin@possum.srcc.msu.su Subject: Re: Issue #091 (actually Issue #095) Content-Length: 387 Status: OR <> No, but we can have a clearer delineation of the issues. I am so far completely missing the argument that having multiple identities for an entity would be helpful to applications, whereas it seems clear that for some applications, a consistent view would be advantageous. From cdaniel.cooper@Boeing.Com Sat May 30 17:27:36 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id RAA07157; Sat, 30 May 1998 17:27:35 -0400 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 RAA17043 for ; Sat, 30 May 1998 17:29:01 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id RAA172880; Sat, 30 May 1998 17:22:11 -0400 Received: from mailgate2.boeing.com (mailgate2.boeing.com [199.238.248.100]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with ESMTP id RAA14104 for ; Sat, 30 May 1998 17:23:08 -0400 (EDT) Received: from mercury.boeing.com ([130.42.138.11]) by mailgate2.boeing.com (8.8.5/8.8.5) with SMTP id OAA13675 for ; Sat, 30 May 1998 14:26:59 -0700 (PDT) Received: from longshot.ds.boeing.com by mercury.boeing.com; Sat, 30 May 98 14:26:58 -0700 Received: (from cooper@localhost) by longshot.ds.boeing.com (SMI-8.6/RDS-1.0) id OAA11064 for ASIS-technical@SW-Eng.Falls-Church.VA.US; Sat, 30 May 1998 14:26:55 -0700 Date: Sat, 30 May 1998 14:26:55 -0700 From: cdaniel.cooper@Boeing.Com (C. Daniel Cooper) Message-Id: <199805302126.OAA11064@longshot.ds.boeing.com> To: ASIS-technical@ns1.sw-eng.falls-church.va.us Subject: Re: Issue #091 (actually Issue #095) X-Sun-Charset: US-ASCII Content-Length: 5439 Status: OR Rober Dewar wrote, > First of all, I cannot see any inherent performance problem if you are > talking about performance of the underlying implementaiton problem. Indeed, > changing GNAT to give inconsistent results depending on the context of > the search would complicate the implementation and slow it down, since > it would require machinery that is not present now. No big deal, and the > slow down is probably negligible, but to make the contrary decision on > the basis that there is some fundamental problem in implementation would > be a heavy burden. > > If you are talking about performance of the application code, I simply can't > see that. If anything the additional complexity that comes from the fact that > different entities are returned in different situations would seem likely to > me to complicate things. I'm not claiming there's a performance "problem" (in the underlying ASIS implementations), but rather that ASIS performance might serve to help us decide on a rule. One rule is bound to support better performance than another, even if the difference is minor; however, if rule A performs better on ASIS implementation 1, but rule B performs better on ASIS implementation 2, then performance can't help us decide. > I am not sure about "the rule can't always be obeyed". The rule is that > all instances of the same entity always return a consistent result. This > rule can always be obeyed. How useful it is to applications is unclear, but > again it is a heavy burden to try to make the point that it is *more* useful > to applications to return inconsistent results. Consistency is an *attribute* of the rule. The rule would state whether to (consistently) traverse to a spec, a body, or a stub. But whatever it says, it can't be relied on (by the tool) because these are not always present. Finessing this by wording the rule such that the tool *can* depend on getting "the visible spec" or "the entity spec" doesn't change the issue: if the tool cares what definition it got, such rules won't help it to know. > Consider for example a cross-reference application. Certainly a typical > user considers "references to the spec" and "references to the body" to > be identical (in fact typical users would not be aware of the idea of > separate kinds of references in the case say of a subprogram body). So > it would seem that a simple cross-reference utility would be much easier > to write if the entity identities corresponded. This is an example of "the tool doesn't care" case, where the rule is irrelevant (ie, any of the definitions will do). How is this easier to write using one rule versus another? Did I miss something? > In order to make the case that it is more valuable to have what I am callling > here "inconsistent" results, some definite argument needs to be given that > this helps either the ASIS implementation at a fundamental > non-implementation specific level, or that it helps applications in > a fundamental non-implementation specific manner. > > I do not see that either case has been made. That is correct! Apparently no one (including me) can make a case. > It does seem that existing implementations are currently inconsistent > with one another. Certainly GNAT always returns a consistent result (e.g. > the spec in the case of a subprogram -- where of course, as in the RM the > body can serve as a spec if there is none). From what I can understand > other implementations take the other model. > > This means that trying to standardize at this stage on one or the other > model can cause disruption to existing implementations. Certainly in the > case of GNAT, we very deliberately considered this issue, and very > deliberately chose what we considered to be the obviously desirable > approach. It is not a huge amount of work to change, but from our > point of view it seems (a) a waste of time and (b) to produce a less > desirable result. Before we can be convinced to spend the time changing > our implementation, we most certainly have to be convinced that it is > worthwhile to do so. So far, nothing that has been said convincingly > makes the case. > > Here is a question: it seems to me that a typical application that was > written to deal with "different" entities being returned would also > work with the "consistent" entity model. Is this the case? In my opinion, yes. Either the tool doesn't care, or if it does, it cannot depend on the rule (whatever it says) to avoid making additional queries. > If so, then > perhaps we are stuck with leaving this as implementation defined, and > people who want to write portable ASIS applications have to be careful > to deal with both cases. So here's what we have: - probable impact to existing ASIS implementations - no winning rule that outperforms the others across all implementations - different ideas about what consistency means - no overriding ARM-based guidance At this point I have to ask, what problem are we solving? Can anyone make a case that ASIS should *not* let this be implementation defined? Sergey originally brought this up as a consistency issue across multiple implementations; but is this really a problem? -- C. Daniel Cooper =========v=======================v Engineer at Software | All opinions are mine | 206-655-3519 | and may not represent | CDaniel.Cooper@Boeing.com | those of my employer. | ==========================^=======================^ From rybin@possum.srcc.msu.su Sun May 31 07:18:27 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id HAA07618; Sun, 31 May 1998 07:18:25 -0400 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 HAA19806 for ; Sun, 31 May 1998 07:19:52 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id HAA32210; Sun, 31 May 1998 07:10:19 -0400 Received: from logger.gamma.ru (logger.gamma.ru [194.186.254.23]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with ESMTP id HAA01828 for ; Sun, 31 May 1998 07:11:06 -0400 (EDT) Received: from srcc.UUCP (uucp@localhost) by logger.gamma.ru (8.8.8/8.8.8) with UUCP id PAA10400; Sun, 31 May 1998 15:14:51 +0400 (MSD) (envelope-from possum!possum.srcc.msu.su!rybin@gamma.srcc.msu.su) Received: by gamma.srcc.msu.su; Sun, 31 May 1998 15:14:24 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Sun, 31 May 1998 15:02:37 +0400 To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com References: <199805302126.OAA11064@longshot.ds.boeing.com> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Sun, 31 May 98 15:02:37 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: Issue #091 (actually Issue #095) Lines: 32 Content-Length: 1553 Status: OR > So here's what we have: > - probable impact to existing ASIS implementations > - no winning rule that outperforms the others across all implementations > - different ideas about what consistency means > - no overriding ARM-based guidance > > At this point I have to ask, what problem are we solving? Can anyone > make a case that ASIS should *not* let this be implementation defined? > Sergey originally brought this up as a consistency issue across multiple > implementations; but is this really a problem? It is a problem, because in case of multi-defined names ASIS says nothing about the result of some important semantic queries in case when more then one candidate for the result may be considered. We cannot assume, that RM95-defined visibility rules shoudl be applied "by default" here, because there is enough other cases, when ASIS does not literally follow RM95-defined formal rules. This may confuse an application. And all this discussion originated from such a confused application, and the application developer was confused, because he was not aware of this problem with multi-defiend names. And this is not the first case, when an application developer was confused by multi-part declarations in ASIS. Now I have nothing against making the result of the corresponding semantic queries implementation defined. What else can we do, if we cannot come to some common viewpoint? But what should be done for sure is documenting this problem (as an Application Note or in some other way) in the ASIS definition. Sergey From dewar@gnat.com Sun May 31 07:32:22 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id HAA07626; Sun, 31 May 1998 07:32:21 -0400 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 HAA19833 for ; Sun, 31 May 1998 07:33:48 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id HAA115012; Sun, 31 May 1998 07:26:54 -0400 Received: from nile.gnat.com (NILE.GNAT.COM [205.232.38.5]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id HAA02002 for ; Sun, 31 May 1998 07:28:27 -0400 (EDT) Received: by nile.gnat.com (5.0/1.20) id AA11812; Sun, 31 May 98 07:28:40 EDT Date: Sun, 31 May 98 07:28:40 EDT From: dewar@gnat.com (Robert Dewar) Message-Id: <9805311128.AA11812@nile.gnat.com> To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com, rybin@possum.srcc.msu.su Subject: Re: Issue #091 (actually Issue #095) Content-Length: 634 Status: OR <> I see no evidence that we cannot come to a common viewpoint. No discussion of this issue has occurred yet. Do not confuse a series of miscellaneous email notes for a discussion :-) As I said earlier, the proper resolution of this is simply to note that this is an issue that needs discussing at the next ASIS meeting. If the ARG gave up on every language issue that could not be decided by email, then everything in Ada would be implementation dependent! From sblake@sd.aonix.com Mon Jun 1 12:07:53 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id MAA09327; Mon, 1 Jun 1998 12:07:52 -0400 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 MAA05616 for ; Mon, 1 Jun 1998 12:09:19 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id MAA15030; Mon, 1 Jun 1998 12:02:21 -0400 Received: from gw.sd.aonix.com (gw.alsys.com [136.175.17.2]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id MAA06508 for ; Mon, 1 Jun 1998 12:03:10 -0400 (EDT) Received: from rasht.sd.aonix.com (mailhub.alsys.com) by gw.sd.aonix.com (4.1/SMI-4.1.1) id AA18378; Mon, 1 Jun 98 09:06:11 PDT Received: from puumba.telesoft by rasht.sd.aonix.com (4.1/TS-1.2c) id AA08247; Mon, 1 Jun 98 09:03:11 PDT Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id JAA20864; Mon, 1 Jun 1998 09:03:04 -0700 Date: Mon, 1 Jun 1998 09:03:04 -0700 From: sblake@sd.aonix.com (Steve Blake @pulsar) Message-Id: <199806011603.JAA20864@puumba.telesoft> To: ASIS-technical@ns1.sw-eng.falls-church.va.us, cdaniel.cooper@Boeing.Com Subject: Re: Issue #091 (actually Issue #095) Content-Length: 96 Status: OR Let's agree to disagree, for now, and plan to reach some agreement at an ASISWG meeting. Steve From sblake@sd.aonix.com Mon Jul 6 19:02:18 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id TAA08461; Mon, 6 Jul 1998 19:02:17 -0400 Received: from gw.sd.aonix.com (gw.alsys.com [136.175.17.2]) by cs.ida.org (8.8.7/8.8.7) with SMTP id TAA09743 for ; Mon, 6 Jul 1998 19:02:12 -0400 (EDT) Received: from rasht.sd.aonix.com (mailhub.alsys.com) by gw.sd.aonix.com (4.1/SMI-4.1.1) id AA11602; Mon, 6 Jul 98 16:00:04 PDT Received: from sd.aonix.com ([136.175.2.180]) by rasht.sd.aonix.com (4.1/TS-1.2c) id AA29649; Mon, 6 Jul 98 15:56:31 PDT Message-Id: <35A14F1F.43C0FBFD@sd.aonix.com> Date: Mon, 06 Jul 1998 15:26:40 -0700 From: Steve Blake Reply-To: sblake@sd.aonix.com Organization: Aonix X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: Clyde Roby Cc: Steve Blake , Currie Colket at ACM Subject: Re: proposed solution for Issue #095 References: <199807022006.QAA05389@cronus.csed.ida.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 5953 Status: OR Currie, Clyde, I just returned from vacation so this is my first chance to reply. I feel there are problems with this solution. Is there no way we can defer this until we can obtain sufficient discussion? See my notes interspersed. I offer a simple solution at the end. Steve Clyde Roby wrote: > Steve, > > Please review this proposed solution that Currie has written > after having had discussions with Sergey at the recent Ada-Europe > conference. Please call us right away. > > Currie and Clyde > ------- > > !ASIS Issue #095 > !topic Semantic queries for multi-part declarations > !reference ASIS 95 > !from Sergey Rybin 98-05-15 > !keywords semantic queries declarations multi-part > !discussion > > Consider the following example: > > package Pkg1 is > > procedure Foo ( A: in out integer ); > ^^^ <----------------- ???? <--------- > end Pkg1; | > | > package body Pkg1 is | > | > procedure Foo ( A: in out integer ) is | > begin ^^^ <------------------ ???? <------- > A := 5; | > ^^^ >-----------> Corresponding_Name_Definition >--> > end Foo; > > end Pkg1; > > Which definition of the formal parameter A should be returned by > Corresponding_Name_Definition when applying to usage occurence > of A in an assignment statement? > > This is not clarified now in the ASIS definition, and this makes > a problem for tools - what should a tool expect in this case? > (My message just originates from a real problem of this kind) > > I think ASIS should clarify this. > > Note, that what is presented above is only an example. The same > problem exists for Corresponding_Called_Function in case if > a separate spec exists along with the body for a given function. > > !resolution Open > !date 98-07-02 > > Proposed Resolution: > > Add the following text to Clause 17.6, Corresponding_Name_Definition before the Appropriate Expression_Kinds list: > > -- Where multiple declarations denote the defining_identifier, defining_character_literal, > -- defining_operator_symbol, or defining_program_unit_name from the > -- declaration of the referenced entity, this function will normally return > -- the first instance of the name definition. For functions, procedures, or entries, this is > -- possibly a declaration in the package specification. In the case of a private type, > -- an incomplete type declaration, or a deferred constant, this query should return the > -- corresponding full type/constant declaration, if available. > If we are allowing implementations to choose which definition to return, then that is what we should state. To use wordslike "normally" and "possibly" just leaves the issue wide open. I would stay away from the term "first instance" to avoid confusion with generics. And the notion of "if available" for a declaration is unclear: does it mean visible or compiled, or something else? > Add the following text to Clause 17. 6, Corresponding_Name_Definition before the Implementation Permissions commentary: > > --|AN The use of this query could return either an Expression_Kinds or an Element_Kinds > --|AN in a package specification, package body, or other syntactic location. The application > --|AN should plan for this. > > Add the following text to Clause 17.29, Corresponding_Called_Function before the Appropriate Expression_Kinds list: > > -- Where multiple declarations denote the called function, this function returns > -- the first declaration of the function denoted by the call. This first > -- declaration is frequently found in the package specification vice the package body. > This assumes the implementation will always return the first declaration which contradicts the implementation permissions implied above. Same with the similar comment below. If ASIS forces this on each implementation, this will be a huge performance problem for some. We should leave this up to the implementation. The real question here seems to be howto provide notification to applications that either part of the definition can be returned and that they must be ready to handle such events. > Add the following text to Clause 17.29, Corresponding_Called_Function before the Implementation Permissions commentary: > > --|AN The use of this query could return a declaration in a package > --|AN specification, package body, or other syntactic location. The application > --|AN should plan for this. > > Add the following text to Clause 18.25, Corresponding_Called_Entity before the Appropriate Statement_Kinds list: > > -- Where multiple declarations denote the procedure or entry, this function returns > -- the first declaration of the procedure or entry denoted by the call. This first > -- declaration is frequently found in the package specification vice the package body. > > Add the following text to Clause 18.25, Corresponding_Called_Entity after the Returns Declaration_Kinds list: > > --|AN The use of this query could return a declaration in a package > --|AN specification, package body, or other syntactic location. The application > --|AN should plan for this. > > ------- I would like to offer the following which could be added to each of the three queries. I think this will provide the clarification that is desired. --|IP An implementation may choose to return any part of mult-part declarations and definitions. --|IP No guarantee is made that the element will be the first part or that the determination will be --|IP made due to any visibility rules. An application should make its own analysis for each case --|IP based on which part is returned. From roby Thu Jul 2 16:06:26 1998 Return-Path: Received: by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id QAA05389; Thu, 2 Jul 1998 16:06:25 -0400 From: roby (Clyde Roby) Message-Id: <199807022006.QAA05389@cronus.csed.ida.org> Subject: proposed solution for Issue #095 To: SBlake@Aonix.Com (Steve Blake) Date: Thu, 2 Jul 1998 16:06:24 -0400 (EDT) Cc: roby (Clyde Roby), Colket@ACM.Org (Currie Colket at ACM) X-Mailer: ELM [version 2.5 PL0b2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 4106 Status: OR Steve, Please review this proposed solution that Currie has written after having had discussions with Sergey at the recent Ada-Europe conference. Please call us right away. Currie and Clyde ------- !ASIS Issue #095 !topic Semantic queries for multi-part declarations !reference ASIS 95 !from Sergey Rybin 98-05-15 !keywords semantic queries declarations multi-part !discussion Consider the following example: package Pkg1 is procedure Foo ( A: in out integer ); ^^^ <----------------- ???? <--------- end Pkg1; | | package body Pkg1 is | | procedure Foo ( A: in out integer ) is | begin ^^^ <------------------ ???? <------- A := 5; | ^^^ >-----------> Corresponding_Name_Definition >--> end Foo; end Pkg1; Which definition of the formal parameter A should be returned by Corresponding_Name_Definition when applying to usage occurence of A in an assignment statement? This is not clarified now in the ASIS definition, and this makes a problem for tools - what should a tool expect in this case? (My message just originates from a real problem of this kind) I think ASIS should clarify this. Note, that what is presented above is only an example. The same problem exists for Corresponding_Called_Function in case if a separate spec exists along with the body for a given function. !resolution Open !date 98-07-02 Proposed Resolution: Add the following text to Clause 17.6, Corresponding_Name_Definition before the Appropriate Expression_Kinds list: -- Where multiple declarations denote the defining_identifier, defining_character_literal, -- defining_operator_symbol, or defining_program_unit_name from the -- declaration of the referenced entity, this function will normally return -- the first instance of the name definition. For functions, procedures, or entries, this is -- possibly a declaration in the package specification. In the case of a private type, -- an incomplete type declaration, or a deferred constant, this query should return the -- corresponding full type/constant declaration, if available. Add the following text to Clause 17. 6, Corresponding_Name_Definition before the Implementation Permissions commentary: --|AN The use of this query could return either an Expression_Kinds or an Element_Kinds --|AN in a package specification, package body, or other syntactic location. The application --|AN should plan for this. Add the following text to Clause 17.29, Corresponding_Called_Function before the Appropriate Expression_Kinds list: -- Where multiple declarations denote the called function, this function returns -- the first declaration of the function denoted by the call. This first -- declaration is frequently found in the package specification vice the package body. Add the following text to Clause 17.29, Corresponding_Called_Function before the Implementation Permissions commentary: --|AN The use of this query could return a declaration in a package --|AN specification, package body, or other syntactic location. The application --|AN should plan for this. Add the following text to Clause 18.25, Corresponding_Called_Entity before the Appropriate Statement_Kinds list: -- Where multiple declarations denote the procedure or entry, this function returns -- the first declaration of the procedure or entry denoted by the call. This first -- declaration is frequently found in the package specification vice the package body. Add the following text to Clause 18.25, Corresponding_Called_Entity after the Returns Declaration_Kinds list: --|AN The use of this query could return a declaration in a package --|AN specification, package body, or other syntactic location. The application --|AN should plan for this. ------- From colket@colket.org Tue Jul 7 12:00:36 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id MAA09467; Tue, 7 Jul 1998 12:00:17 -0400 Received: from smtp1.erols.com (smtp1.erols.com [207.172.3.234]) by cs.ida.org (8.8.7/8.8.7) with ESMTP id MAA24500 for ; Tue, 7 Jul 1998 12:00:17 -0400 (EDT) Received: from colket.org (207-172-118-117.s117.tnt13.brd.erols.com [207.172.118.117]) by smtp1.erols.com (8.8.8/8.8.5) with ESMTP id LAA07255; Tue, 7 Jul 1998 11:55:06 -0400 (EDT) Message-ID: <35A24498.41A20FE@colket.org> Date: Tue, 07 Jul 1998 11:54:01 -0400 From: Currie Colket Reply-To: colket@colket.org X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: sblake@sd.aonix.com, Sergey Rybin CC: Clyde Roby , Steve Blake , Currie Colket at ACM , ASIS Officers , Joyce Tokar , Joyce Tokar , Dan Eilers Subject: Re: Proposed Solution for Issue #095 References: <199807022006.QAA05389@cronus.csed.ida.org> <35A14F1F.43C0FBFD@sd.aonix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 10246 Status: OR Dear Sergey and Steve: (copy to ASIS Officers) Issue #095 needs concurrence from both of you. Sergey provided a potential solution which Clyde and I forwarded to Steve for comments. I have tried to incorporate Steve's and Sergey's concerns into the following 2 proposed alternatives. The first proposed solution is advocated by Steve; the second proposed resolution is advocated by Sergey (with minor modifications). The earlier proposed solution (attached with Steve's commentary) was used to better formulate Proposed resolution #2. This earlier resolution included application notes, which are deleted in the proposed resolution #2 as this solution should be deterministic. Steve's concern is that proposed resolution #2 will incur a performance hit. It should be noted that neither AONIX nor ASIS for GNAT have implemented this issue based on the proposed resolution #2 (ASIS for GNAT is perhaps implemented based on the earlier proposed solution). In this light, proposed resolution #1 might be a good compromise alternative. We have already heard from the user community. Basically they do not care how this issue is resolved as they must plan for landing in a variety of places anyway. (Except they might be concerned on the performance issues). Hence this is an issue where concurrence between the implementors is desired. It might be nice to get input from other implementors as well. v/r Currie Proposed resolutions are: *******************Proposed Resolution #1********************** !resolution Open !date 98-07-07 Proposed Resolution #1: To Clause 17. 6, Corresponding_Name_Definition in the Implementation Permissions commentary; Clause 17.29, Corresponding_Called_Function in the Implementation Permissions commentary; and Clause 18.25, Corresponding_Called_Entity after the Returns Declaration_Kinds list. Add the following text: --|IP An implementation may choose to return any part of multi-part --|IP declarations and definitions. No guarantee is made that the --|IP element will be the first part or that the determination will be --|IP made due to any visibility rules. An application should make its --|IP own analysis for each case based on which part is returned. *******************Proposed Resolution #2********************** !resolution Open !date 98-07-07 Proposed Resolution #2: Add the following text to Clause 17.6, Corresponding_Name_Definition before the Appropriate Expression_Kinds list: -- Where multiple declarations denote the defining_identifier, -- defining_character_literal, defining_operator_symbol, or -- defining_program_unit_name from the declaration of the -- referenced entity, this function will return: -- -- - For functions, procedures, or entries, the first -- declaration of the name definition. This is, for example, -- the declaration in the package specification vice the -- package body. -- - For a private type, an incomplete type declaration, -- or a deferred constant, this query should return -- the corresponding full type/constant declaration. Add the following text to Clause 17.29, Corresponding_Called_Function before the Appropriate Expression_Kinds list: -- Where multiple declarations denote the called function, -- this function returns the first declaration of the function -- denoted by the call. This is, for example, the declaration -- in the package specification vice the package body. Add the following text to Clause 18.25, Corresponding_Called_Entity before the Appropriate Statement_Kinds list: -- Where multiple declarations denote the procedure or entry, -- this function returns the first declaration of the procedure -- or entry denoted by the call. This is, for example, the declaration -- in the package specification vice the package body. +-----------------------------------------------------------------------------+ The original proposal, based on Sergey's input at Ada-Europe, is provided below with comments from Steve Blake. > Currie, Clyde, > > I just returned from vacation so this is my first chance to reply. > > I feel there are problems with this solution. Is there no way we can defer this until we > can obtain sufficient discussion? > > See my notes interspersed. > > I offer a simple solution at the end. > > Steve > > Clyde Roby wrote: > > > Steve, > > > > Please review this proposed solution that Currie has written > > after having had discussions with Sergey at the recent Ada-Europe > > conference. Please call us right away. > > > > Currie and Clyde > > ------- > > > > !ASIS Issue #095 > > !topic Semantic queries for multi-part declarations > > !reference ASIS 95 > > !from Sergey Rybin 98-05-15 > > !keywords semantic queries declarations multi-part > > !discussion > > > > Consider the following example: > > > > package Pkg1 is > > > > procedure Foo ( A: in out integer ); > > ^^^ <----------------- ???? <--------- > > end Pkg1; | > > | > > package body Pkg1 is | > > | > > procedure Foo ( A: in out integer ) is | > > begin ^^^ <------------------ ???? <------- > > A := 5; | > > ^^^ >-----------> Corresponding_Name_Definition >--> > > end Foo; > > > > end Pkg1; > > > > Which definition of the formal parameter A should be returned by > > Corresponding_Name_Definition when applying to usage occurence > > of A in an assignment statement? > > > > This is not clarified now in the ASIS definition, and this makes > > a problem for tools - what should a tool expect in this case? > > (My message just originates from a real problem of this kind) > > > > I think ASIS should clarify this. > > > > Note, that what is presented above is only an example. The same > > problem exists for Corresponding_Called_Function in case if > > a separate spec exists along with the body for a given function. > > > > !resolution Open > > !date 98-07-02 > > > > Proposed Resolution: > > > > Add the following text to Clause 17.6, Corresponding_Name_Definition before the Appropriate Expression_Kinds list: > > > > -- Where multiple declarations denote the defining_identifier, defining_character_literal, > > -- defining_operator_symbol, or defining_program_unit_name from the > > -- declaration of the referenced entity, this function will normally return > > -- the first instance of the name definition. For functions, procedures, or entries, this is > > -- possibly a declaration in the package specification. In the case of a private type, > > -- an incomplete type declaration, or a deferred constant, this query should return the > > -- corresponding full type/constant declaration, if available. > > > > If we are allowing implementations to choose which definition to return, then that is what we should state. To use > wordslike "normally" and "possibly" just leaves the issue wide open. I would stay away from the term "first instance" to > avoid confusion with generics. And the notion of "if available" for a declaration is unclear: does it mean visible or > compiled, or something else? > > > Add the following text to Clause 17. 6, Corresponding_Name_Definition before the Implementation Permissions commentary: > > > > --|AN The use of this query could return either an Expression_Kinds or an Element_Kinds > > --|AN in a package specification, package body, or other syntactic location. The application > > --|AN should plan for this. > > > > Add the following text to Clause 17.29, Corresponding_Called_Function before the Appropriate Expression_Kinds list: > > > > -- Where multiple declarations denote the called function, this function returns > > -- the first declaration of the function denoted by the call. This first > > -- declaration is frequently found in the package specification vice the package body. > > > > This assumes the implementation will always return the first declaration which contradicts the implementation permissions > implied above. Same with the similar comment below. If ASIS forces this on each implementation, this will be a huge > performance problem for some. We should leave this up to the implementation. The real question here seems to be howto > provide notification to applications that either part of the definition can be returned and that they must be ready to > handle such events. > > > Add the following text to Clause 17.29, Corresponding_Called_Function before the Implementation Permissions commentary: > > > > --|AN The use of this query could return a declaration in a package > > --|AN specification, package body, or other syntactic location. The application > > --|AN should plan for this. > > > > Add the following text to Clause 18.25, Corresponding_Called_Entity before the Appropriate Statement_Kinds list: > > > > -- Where multiple declarations denote the procedure or entry, this function returns > > -- the first declaration of the procedure or entry denoted by the call. This first > > -- declaration is frequently found in the package specification vice the package body. > > > > Add the following text to Clause 18.25, Corresponding_Called_Entity after the Returns Declaration_Kinds list: > > > > --|AN The use of this query could return a declaration in a package > > --|AN specification, package body, or other syntactic location. The application > > --|AN should plan for this. > > > > ------- > > I would like to offer the following which could be added to each of the three queries. I think this will provide the > clarification that is desired. > > --|IP An implementation may choose to return any part of mult-part declarations and definitions. > --|IP No guarantee is made that the element will be the first part or that the determination will be > --|IP made due to any visibility rules. An application should make its own analysis for each case > --|IP based on which part is returned. From dewar@GNAT.COM Wed Jul 8 08:20:12 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA12052; Wed, 8 Jul 1998 08:20:11 -0400 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 IAA01180 for ; Wed, 8 Jul 1998 08:20:11 -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 IAA173700; Wed, 8 Jul 1998 08:13:07 -0400 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 1021369 for SIGADA-ASIS-OFFICERS@ACM.ORG; Wed, 8 Jul 1998 08:13:06 -0400 Received: from nile.gnat.com (NILE.GNAT.COM [205.232.38.5]) by mail.acm.org (8.8.5/8.7.5) with SMTP id IAA71080 for ; Wed, 8 Jul 1998 08:03:05 -0400 Received: by nile.gnat.com (5.0/1.20) id AA29559; Wed, 8 Jul 98 08:05:22 EDT Message-ID: <9807081205.AA29559@nile.gnat.com> Date: Wed, 8 Jul 1998 08:05:22 EDT Reply-To: Robert Dewar Sender: ACM SIGADA ASIS Officers Mailing List From: Robert Dewar Subject: Re: Proposed Solution for Issue #095 Comments: To: rybin@ACM.ORG To: SIGADA-ASIS-OFFICERS@ACM.ORG Content-Length: 517 Status: OR <<> --|IP An implementation may choose to return any part of multi-part > --|IP declarations and definitions. No guarantee is made that the > --|IP element will be the first part or that the determination will be > --|IP made due to any visibility rules. An application should make its > --|IP own analysis for each case based on which part is returned. >> This is only clear if elsewhere there is a clear definition of what a multi-part declaration is, since this is not an Ada technical term. From rybin@POSSUM.SRCC.MSU.SU Wed Jul 8 08:59:06 1998 Return-Path: Received: from metropolis.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA12124; Wed, 8 Jul 1998 08:59:06 -0400 Received: from mail.acm.org ([199.222.69.4]) by metropolis.ida.org (8.8.7/8.8.7) with ESMTP id CAA03491 for ; Wed, 8 Jul 1998 02:34: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 CAA22662; Wed, 8 Jul 1998 02:18:40 -0400 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 1021092 for SIGADA-ASIS-OFFICERS@ACM.ORG; Wed, 8 Jul 1998 02:18:40 -0400 Received: from logger.gamma.ru (logger.gamma.ru [194.186.254.23]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id CAA91096 for ; Wed, 8 Jul 1998 02:08:37 -0400 Received: from srcc.UUCP (uucp@localhost) by logger.gamma.ru (8.8.8/8.8.8) with UUCP id KAA07632; Wed, 8 Jul 1998 10:15:32 +0400 (MSD) (envelope-from possum!possum.srcc.msu.su!rybin@gamma.srcc.msu.su) Received: by gamma.srcc.msu.su; Wed, 8 Jul 1998 10:12:51 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Tue, 7 Jul 1998 23:20:24 +0400 References: <35A24498.41A20FE@colket.org> X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Lines: 21 Message-ID: Date: Tue, 7 Jul 1998 23:20:24 +0400 Reply-To: "Sergey I. Rybin" Sender: ACM SIGADA ASIS Officers Mailing List From: "Sergey I. Rybin" Organization: Information Systems, SRCC, MSU Subject: Re: Proposed Solution for Issue #095 Comments: To: colket@ACM.ORG To: SIGADA-ASIS-OFFICERS@ACM.ORG Content-Length: 968 Status: OR Currie, Steve, > In this light, proposed resolution #1 might be a good compromise alternative. > > Proposed Resolution #1: > > To Clause 17. 6, Corresponding_Name_Definition in the Implementation Permissions commentary; > Clause 17.29, Corresponding_Called_Function in the Implementation Permissions commentary; and Clause 18.25, > Corresponding_Called_Entity after the Returns Declaration_Kinds list. Add the following text: > > --|IP An implementation may choose to return any part of multi-part > --|IP declarations and definitions. No guarantee is made that the > --|IP element will be the first part or that the determination will be > --|IP made due to any visibility rules. An application should make its > --|IP own analysis for each case based on which part is returned. I really like it: short and clear, and makes a clear warning for an application that the application should be careful with multi-part declarations. Sergey