From alainlg@student.DoCS.UU.SE Fri Apr 25 08:17:54 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA25399; Fri, 25 Apr 1997 08:17:53 -0400 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA01419; Fri, 25 Apr 97 08:18:26 EDT Received: from Veda.DoCS.UU.SE by sw-eng.falls-church.va.us (8.7.1/) id LAA22835; Fri, 25 Apr 1997 11:51:00 GMT Received: from Xantia.DoCS.UU.SE (Xantia.DoCS.UU.SE [130.238.8.76]) by Veda.DoCS.UU.SE (8.6.12/8.6.12) with ESMTP id NAA02004 for ; Fri, 25 Apr 1997 13:53:56 +0200 Received: (alainlg@localhost) by Xantia.DoCS.UU.SE (8.6.12/8.6.12) id NAA14483; Fri, 25 Apr 1997 13:53:54 +0200 Date: Fri, 25 Apr 1997 13:53:54 +0200 Message-Id: <199704251153.NAA14483@Xantia.DoCS.UU.SE> From: Alain Le Guennec To: asis-technical@sw-eng.falls-church.va.us Subject: Corresponding_Called_Entity and stream oriented attribute references. Content-Length: 1213 Status: OR As currently specified, Corresponding_Called_Entity and Corresponding_Called_Function have to return a Nil_Element for a prefix that denotes an attribute reference. I think there is a case in Ada95 where these queries could yield a more usefull result, namely for stream oriented attributes which have an attribute representation clause. Please consider the following example: - ----------------------------------- with Ada.Streams; procedure Sample32 is package My_Package is type TR is null record; procedure Write_TR (Stream : access Ada.Streams.Root_Stream_Type'Class; Item : in TR); for TR'Write use Write_TR; end My_Package; package body My_Package is procedure Write_TR (Stream : access Ada.Streams.Root_Stream_Type'Class; Item : in TR) is begin null; end Write_TR; end My_Package; use My_Package; type SA is access Ada.Streams.Root_Stream_Type'Class; R : TR; S : SA; begin TR'Write (S, R); end Sample32; It is determined statically that this call is actually pointing to My_Package.Write_TR, so why not return this subprogram declaration instead of a Nil_Element ? Any comment ? -- Alain Le Guennec. From rybin@possum.srcc.msu.su Tue May 13 14:19:49 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id OAA16008; Tue, 13 May 1997 14:19:48 -0400 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA27207; Tue, 13 May 97 14:20:24 EDT Received: from crocus.gamma.ru by sw-eng.falls-church.va.us (8.7.1/) id RAA24272; Tue, 13 May 1997 17:53:10 GMT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id VAA29332; Tue, 13 May 1997 21:55:45 +0400 (MSD) Received: by gamma.srcc.msu.su; Tue, 13 May 1997 21:55:03 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Tue, 13 May 1997 21:52:58 +0400 To: Alain.LeGuennec@enst-bretagne.fr Cc: asis-technical@sw-eng.falls-church.va.us, sblake@alsys.com References: Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Tue, 13 May 97 21:52:58 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: renaming-as-... in ASIS Lines: 89 Content-Length: 4227 Status: OR Alain, I'm sending this message as "Cc:" to Steve and to asis-technical. Some time ago Steve and myself discussed this problem, but - shame on me! - I cannot find this discussion in my mail archive. And I am sure, that here we have a hole in the ASIS defrinition which should be fixed (in any case, independently on who is right - you or me). > > Another thing is that Corresponding_Called_Function and > > Corresponding_Called_Entity both unwind renamings. Does this > > help? > > I think they should NOT, since A_Procedure_Renaming_Declaration > (resp. A_Function_Renaming_Declaration) are part of the possible > returned declaration kinds, in the case of renaming as declaration > (the incomplete declaration should be returned instead in the case > of renaming as body.) Well, let me justify my position. First, the definition of Corresponding_Called_Entity says: "Returns the declaration of the *procedure or entry* denoted by the call". That is, the declaration of some *entity* should be returned. But a renaming declaration *does not* define and *entity*, it defines a new *name* for some *previously declared* *entity*. Second, there is another query in ASIS - Corresponding_Name_Definition, related to *names* but not *entities*. Name can be defined by a renaming declaration, entity - cannot. So Corresponding_Name_Definition does not unwind any renaming. So, if you would like to know, what subprogram or entry *entity* is called - use Corresponding_Caleed_Entity/Corresponding_Called_Function. But if you would like to know the "naming history" (I'm not sure, that this is the best term, but I hope you see, what I mean) - select the prefix from the call, and then analyze it (may be, along with doing some additional decomposition of the prefix) by applying Corresponding_Name_Definition. Third, renaming-as-body makes a somewhat special case for ASIS. From one side, it is a completion of some subprogram declaration, but, formally speaking, any subprogram declaration declares an entity. But from the other side, no *new* subprogram is declared by this declaration. So I would unwind renamings only for a renaming-as-declaration, but not for renaming-as-body. And, finally, I think, that the definition of these two queries: Corresponding_Called_Function and Corresponding_Called_Entity should be clarified. First, it should be said explicitly whether or not unwinding of renamings should take place. Second, if these queries should unwing renamings, A_Procedure_Renaming_Declaration and A_Function_Renaming_Declaration should be removed from the lists of returned kinds. > The declaration of the procedure/function is not the same > as the declaration of the renamed entity, so I think no unwinding > should be done at all (otherwise you could as well go directly > to the proper body instead of returning a body stub for subunits.) > Why not simply return the "real (first)" subprogram declaration ? I think the rule should be - to return the declaration defining the corresponding callable *entity*. > And there are cases (renaming an enumeration literal or an > access dereference as a function for example) where there is > a valid subprogram declaration to return only if you do not unwind. ^^^^^^^^^^^^^^^^^^^^^^ "Subprogram" or *renaming* declaration? But, for sure, you are right - there are cases when it is impossible to return the *declaration* of the called entity, and not all of them are mentioned in the definition of these queries. If you use an access dereference "directly", but not through renaming, you will have the same problem. > Moreover, it may be interesting to know whether a given renaming > is used or not (not only the based entity), for example to get rid > of the "dummy" bodies that GNAT generates for renamings as body. > This is harder to do if you unwind renamings autmatically. I'm afraid, a static code analysis tool has to make difference between the use of subprograms and the use of names to access subprograms. And it has to use Corresponding_Called_Function/Entity for the first kind of analysis, and it has to use Corresponding_Name_Definition as the basis for the second kind of analysis. Sergey From roby Fri May 23 16:45:24 1997 Return-Path: Received: by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id QAA05871; Fri, 23 May 1997 16:42:06 -0400 From: roby (Clyde Roby) Message-Id: <199705232042.QAA05871@cronus.csed.ida.org> Subject: new issue #079 To: alainlg@student.DoCS.UU.SE (Alain Le Guennec), SBlake@Aonix.Com (Steve Blake), rybin@alex.srcc.msu.su (Rybin) Date: Fri, 23 May 1997 16:42:06 -0400 (EDT) Cc: roby (me), ASIS-Officers@SW-Eng.Falls-Church.Va.US (asis-officers) In-Reply-To: <199705061455.QAA26702@Xantia.DoCS.UU.SE> from "Alain Le Guennec" at May 6, 97 04:55:34 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 701 Status: OR All, Alain send an email message with Subject "Corresponding_Called_Entity and stream oriented attribute references". We have not seen any replies with this Subject. However, Sergey sent an email message on 13 May to Alain with Subject "Re: renaming-as-... in ASIS" was cc'ed to ASIS-Technical and which appears to reply to private email between Sergey and Alain for this topic and new issue #077's email. Please suggest appropriate changes (exact wording if possible) to the appropriate interfaces. Again, we need to have this information by COB Tuesday, 27 May, because Currie and Clyde are meeting on Wednesday to finalize ASIS for the WG9 meeting on 2 June. Thank you. Clyde (and Currie) From rybin@possum.srcc.msu.su Sun May 25 14:12:36 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id OAA07693; Sun, 25 May 1997 14:12:36 -0400 Received: from crocus.gamma.ru by ida.org (4.1/SMI-4.1) id AA11243; Sun, 25 May 97 14:09:33 EDT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id WAA28396; Sun, 25 May 1997 22:08:46 +0400 (MSD) Received: by gamma.srcc.msu.su; Sun, 25 May 1997 22:08:33 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Sat, 24 May 1997 23:30:46 +0400 To: alainlg@Minsk.DoCS.UU.SE, roby@ida.org, SBlake@Aonix.Com Cc: ASIS-Officers@SW-Eng.Falls-Church.Va.US References: <199705232042.QAA05871@cronus.csed.ida.org> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Sat, 24 May 97 23:30:46 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: new issue #079 Lines: 126 Content-Length: 5359 Status: OR > Alain send an email message with Subject > "Corresponding_Called_Entity and stream oriented attribute > references". We have not seen any replies with this Subject. > However, Sergey sent an email message on 13 May to Alain with Subject > "Re: renaming-as-... in ASIS" was cc'ed to ASIS-Technical and which > appears to reply to private email between Sergey and Alain for this > topic and new issue #077's email. I think, Alain has pointed out the partial case of attributes-subprograms which is of real importance for real-life Ada code to be analyzed by ASIS applications. From the other side, for some ASIS implementations may be too hard to return the declaration of a function which is really called in place of the given call of a subprogram-attribute. So I would suggest to encourage, but not to require an ASIS implementation to return a subprogram declaration of a really called subprogram for a call to attribute-subprogram. (If chosen, this correction should be applied to both Corresponding_Called_Entity and Corresponding_Called_Function, to take care about possible implementation-specific (re)definable attribute-functions). Below is my version. I'm far from being happy about it - I am afraid, that both wording and English require corrections :( Sergey --------------------------------------------------------------------------------------- -- Subclause 18.25 function Corresponding_Called_Entity --------------------------------------------------------------------------------------- function Corresponding_Called_Entity (Statement : in Asis.Statement) return Asis.Declaration; --------------------------------------------------------------------------------------- -- Statement - Specifies the procedure_call_statement or -- entry_call_statement to query -- -- Returns the declaration of the procedure or entry denoted by the call. -- -- Returns a Nil_Element if the: -- -- - prefix of the call denotes an access to a procedure implicit -- or explicit dereference, -- -- - argument is a dispatching call, -- -- - argument is a call to a dispatching operation of a tagged type which -- is not statically determined. -- -- If procedure_prefix denotes an attribute_reference, and if the -- corresponding attribute is (re)defined by attribute definition clause, an -- implementation is encouraged, but not required to return the definition of -- the corresponding subprogram which name is used after "use" in this -- attribute definition clause, if an implementation cannot return such a -- subprogram definition, a Nil_Element should be returned. For an attribute -- reference which is not (re)defined by attribute definition clause, a -- Nil_Element should be returned. -- -- Appropriate Statement_Kinds: -- An_Entry_Call_Statement -- A_Procedure_Call_Statement -- -- Returns Declaration_Kinds: -- Not_A_Declaration -- A_Procedure_Declaration -- A_Procedure_Body_Declaration -- A_Procedure_Body_Stub -- A_Procedure_Renaming_Declaration -- A_Procedure_Instantiation -- A_Formal_Procedure_Declaration -- An_Entry_Declaration -- --------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------- -- Subclause 17.29 function Corresponding_Called_Function --------------------------------------------------------------------------------------- function Corresponding_Called_Function (Expression : in Asis.Expression) return Asis.Declaration; --------------------------------------------------------------------------------------- -- Expression - Specifies the function_call to query -- -- Returns the declaration of the called function. -- -- Returns a Nil_Element if the: -- -- - function_prefix denotes a predefined operator for which the implementation -- does not provide an artificial function declaration, -- -- - prefix of the call denotes an access to a function implicit or explicit -- dereference, -- -- - argument is a dispatching call, or -- -- - argument is a call to a dispatching operation of a tagged type which -- is not statically determined. -- -- If function_prefix denotes an attribute_reference, and if the -- corresponding attribute is (re)defined by attribute definition clause, an -- implementation is encouraged, but not required to return the definition of -- the corresponding subprogram which name is used after "use" in this -- attribute definition clause, if an implementation cannot return such a -- subprogram definition, a Nil_Element should be returned. For an attribute -- reference which is not (re)defined by attribute definition clause, a -- Nil_Element should be returned. -- -- Appropriate Expression_Kinds: -- A_Function_Call -- -- Returns Declaration_Kinds: -- Not_A_Declaration -- A_Function_Declaration -- A_Function_Body_Declaration -- A_Function_Body_Stub -- A_Function_Renaming_Declaration -- A_Function_Instantiation -- A_Formal_Function_Declaration -- --|IP Implementation Permissions: --|IP --|IP An implementation can choose whether or not to construct and provide --|IP artificial implicit declarations for predefined operators. -- From sblake@sd.aonix.com Sun May 25 15:10:06 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA07729; Sun, 25 May 1997 15:10:06 -0400 Received: from gw.alsys.com by ida.org (4.1/SMI-4.1) id AA11542; Sun, 25 May 97 15:10:46 EDT Received: from rasht.sd.aonix.com (mailhub.alsys.com) by gw.alsys.com (4.1/SMI-4.1.1) id AA03381; Sun, 25 May 97 11:48:48 PDT Received: from puumba.telesoft by rasht.sd.aonix.com (4.1/TS-1.2c) id AA19624; Sun, 25 May 97 11:47:09 PDT Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id LAA14685; Sun, 25 May 1997 11:47:08 -0700 Date: Sun, 25 May 1997 11:47:08 -0700 From: sblake@sd.aonix.com (Steve Blake @pulsar) Message-Id: <199705251847.LAA14685@puumba.telesoft> To: SBlake@aonix.com, alainlg@Minsk.DoCS.UU.SE, roby@ida.org, rybin@possum.srcc.msu.su Subject: Re: new issue #079 Cc: ASIS-Officers@sw-eng.falls-church.va.us Content-Length: 774 Status: OR I like Sergey's revised commentary for the two queries in question. One minor thing to point out in both: I think only one of the two cases is really needed. Isn't it true that the second line is redundant since if the argument is a dipatching call, it is by definition dynamically determined? -- -- - argument is a dispatching call, -- -- - argument is a call to a dispatching operation of a tagged type which -- is not statically determined. -- The same applies to this pair in the second query: -- -- - argument is a dispatching call, or -- -- - argument is a call to a dispatching operation of a tagged type which -- is not statically determined. -- If you agree, then each pair can be replaced with: -- - argument is a dispatching call. Steve From rybin@possum.srcc.msu.su Mon May 26 02:21:59 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id CAA08152; Mon, 26 May 1997 02:21:58 -0400 Received: from crocus.gamma.ru by ida.org (4.1/SMI-4.1) id AA14436; Mon, 26 May 97 02:21:08 EDT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id KAA03779; Mon, 26 May 1997 10:20:48 +0400 (MSD) Received: by gamma.srcc.msu.su; Mon, 26 May 1997 10:19:58 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Mon, 26 May 1997 10:16:08 +0400 To: alainlg@Minsk.DoCS.UU.SE, roby@ida.org, SBlake@aonix.com, sblake@sd.aonix.com Cc: ASIS-Officers@sw-eng.falls-church.va.us References: <199705251847.LAA14685@puumba.telesoft> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Mon, 26 May 97 10:16:08 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: new issue #079 Lines: 35 Content-Length: 1134 Status: OR > I like Sergey's revised commentary for the two queries in question. One > minor thing to point out in both: > > I think only one of the two cases is really needed. Isn't it true that > the second line is redundant since if the argument is a dipatching call, it > is by definition dynamically determined? It would be nice to get some comment from Ada 95 OO specialist, but I also think, that the second line is redundant (and somewhat confusing, when follows the first one - a reader may start to look for some difference between these two situations). I agree with Steve's suggestion. > -- > -- - argument is a dispatching call, > -- > -- - argument is a call to a dispatching operation of a tagged type which > -- is not statically determined. > -- > > > The same applies to this pair in the second query: > > -- > -- - argument is a dispatching call, or > -- > -- - argument is a call to a dispatching operation of a tagged type which > -- is not statically determined. > -- > > If you agree, then each pair can be replaced with: > > > -- - argument is a dispatching call.