From rybin@possum.srcc.msu.su Sat Jun 13 04:25:25 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id EAA21546; Sat, 13 Jun 1998 04:25:24 -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 EAA11096 for ; Sat, 13 Jun 1998 04:25:24 -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 EAA10122; Sat, 13 Jun 1998 04:16:45 -0400 Received: from wormhole.mtc.iitri.com (wormhole [192.104.146.110]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id EAA27159 for ; Sat, 13 Jun 1998 04:17:44 -0400 (EDT) Received: from logger.gamma.ru by mtc.iitri.com (4.1/3.1.090690-IITRI-MTC) id AA05822; Sat, 13 Jun 98 03:49:47 EDT Received: from srcc.UUCP (uucp@localhost) by logger.gamma.ru (8.8.8/8.8.8) with UUCP id LAA22762 for asis-comment@sw-eng.falls-church.va.us; Sat, 13 Jun 1998 11:44:27 +0400 (MSD) (envelope-from possum!possum.srcc.msu.su!rybin@gamma.srcc.msu.su) Received: by gamma.srcc.msu.su; Sat, 13 Jun 1998 11:44:04 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Sat, 13 Jun 1998 11:39:01 +0400 To: asis-comment@ns1.sw-eng.falls-church.va.us Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Sat, 13 Jun 98 11:39:01 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Normalized associations for call-as-dereference and dispatching calls Lines: 57 Content-Length: 2469 Status: ORr Another "interesting" ASIS question originated from some discussion with our ASIS customer working on ASIS tools. Suppose we have: type Acc_Subprogram is access procedure (I : Integer); Dynamic_Call : Acc_Subprogram; procedure P1 (J : Integer) is begin null; end P1; procedure Q1 (K : Integer) is begin null; end Q1; Var : Integer := 13; begin Dynamic_Call := P1'access; Dynamic_Call.all (Var); -<<-------------------------------------- ^^^^^^^^^^^^^^^^^^^^^^ | | Dynamic_Call := Q1'access; | Dynamic_Call.all (Var); -<<-------------------------------------+ ^^^^^^^^^^^^^^^^^^^^^^ | | And suppose we have got _NORMALIZED_ parameter associations from these calls. The question is - what should be the result of the Formal_Parameter query applied to such normalized associations? Clearly, it cannot be formal parameter defining names corresponding to the formal parameters of actually called procedures - this information is dynamically-determined in a general case. The only reasonable choice would be to return the defining name I from the declaration of the access-to-subprogram type Acc_Subprogram. The questions are: 1. Is it really what should be returned in this case (we've discussed this with Alain, and both of us think,that it is. 2. Should this be clarified in the ASIS definition? I'm pretty sure, that it should, because as it stands now, ASIS just reuses the old Ada83-based approch for normalized subprogram associations, without taking into account call-as-dereference and dispatching calls. Dispatching calls was the next question, and I'm afraid, it is not so easy to resolve. Suppose we've got a normalized subprogram association from a dispatching call (quite a syntactic action). And what in this case should be the result of the Formal_Parameter query applied to such an association? Alain's suggestion is to return a formal parameter defining name from the subprogram declaration corresponding to the root of the type hierarchy. Any comments? And this also should be documented in the ASIS definition. Sorry for raising this issue _after_ WG9 meeting, but before yesterday evening I myself was not avare of this problem :(( Sergey From roby Fri Jun 19 15:47:23 1998 Return-Path: Received: by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA10294; Fri, 19 Jun 1998 15:47:21 -0400 From: roby (Clyde Roby) Message-Id: <199806191947.PAA10294@cronus.csed.ida.org> Subject: Re: Normalized associations for call-as-dereference and dispatching calls To: rybin@possum.srcc.msu.su (Sergey I. Rybin) Date: Fri, 19 Jun 1998 15:47:21 -0400 (EDT) Cc: asis-comment@ns1.sw-eng.falls-church.va.us, roby (Clyde Roby), Colket@ACM.Org (Currie Colket at ACM) In-Reply-To: from "Sergey I. Rybin" at Jun 13, 1998 11:39:01 AM X-Mailer: ELM [version 2.5 PL0b2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2602 Status: OR Sergey, Concerning your recent ASIS question, we would like for you to make specific suggested changes to the specification to address it. Clyde and Currie > Another "interesting" ASIS question originated from some > discussion with our ASIS customer working on ASIS tools. > > Suppose we have: > > type Acc_Subprogram is access procedure (I : Integer); > Dynamic_Call : Acc_Subprogram; > > procedure P1 (J : Integer) is begin null; end P1; > procedure Q1 (K : Integer) is begin null; end Q1; > > Var : Integer := 13; > begin > Dynamic_Call := P1'access; > Dynamic_Call.all (Var); -<<-------------------------------------- > ^^^^^^^^^^^^^^^^^^^^^^ | > | > Dynamic_Call := Q1'access; | > Dynamic_Call.all (Var); -<<-------------------------------------+ > ^^^^^^^^^^^^^^^^^^^^^^ | > | > And suppose we have got _NORMALIZED_ parameter associations from these > calls. The question is - what should be the result of the > Formal_Parameter query applied to such normalized associations? > Clearly, it cannot be formal parameter defining names corresponding > to the formal parameters of actually called procedures - this > information is dynamically-determined in a general case. > > The only reasonable choice would be to return the defining name > I from the declaration of the access-to-subprogram type > Acc_Subprogram. The questions are: > > 1. Is it really what should be returned in this case (we've > discussed this with Alain, and both of us think,that > it is. > > 2. Should this be clarified in the ASIS definition? I'm pretty > sure, that it should, because as it stands now, ASIS just > reuses the old Ada83-based approch for normalized subprogram > associations, without taking into account call-as-dereference > and dispatching calls. > > Dispatching calls was the next question, and I'm afraid, it is > not so easy to resolve. Suppose we've got a normalized subprogram > association from a dispatching call (quite a syntactic action). > And what in this case should be the result of the Formal_Parameter > query applied to such an association? > > Alain's suggestion is to return a formal parameter defining > name from the subprogram declaration corresponding to the > root of the type hierarchy. Any comments? And this also should > be documented in the ASIS definition. From rybin@possum.srcc.msu.su Mon Jun 22 14:20:04 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id OAA14524; Mon, 22 Jun 1998 14:19:58 -0400 Received: from logger.gamma.ru (logger.gamma.ru [194.186.254.23]) by cs.ida.org (8.8.7/8.8.7) with ESMTP id OAA15018 for ; Mon, 22 Jun 1998 14:19:56 -0400 (EDT) Received: from srcc.UUCP (uucp@localhost) by logger.gamma.ru (8.8.8/8.8.8) with UUCP id WAA18241; Mon, 22 Jun 1998 22:19:27 +0400 (MSD) (envelope-from possum!possum.srcc.msu.su!rybin@gamma.srcc.msu.su) Received: by gamma.srcc.msu.su; Mon, 22 Jun 1998 22:17:01 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Mon, 22 Jun 1998 22:02:50 +0400 To: roby@ida.org Cc: asis-comment@ns1.sw-eng.falls-church.va.us, Colket@ACM.Org References: <199806191947.PAA10294@cronus.csed.ida.org> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Mon, 22 Jun 98 22:02:50 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: Normalized associations for call-as-dereference and dispatching calls Lines: 79 Content-Length: 3507 Status: OR > Sergey, > > Concerning your recent ASIS question, we would like for > you to make specific suggested changes to the specification to > address it. > > Clyde and Currie I'm not feeling myself completely ready to propose specific changes. I can see two possibilities for normalized associations in case when the called subprogram can be determined only dinamically (calls as dereferences and dispatching calls): 1. To return nil association list as an indication of the fact, that we cannot produce any meaningful result in this case; 2. To return the "closest" statically determinable result (that is, based on the definition of the corresponding access-to-subprogram type in case of call-as-dereference and based on ... I do not know what... in case of a dispatching call I really do not know what would be better.... Sergey > > Another "interesting" ASIS question originated from some > > discussion with our ASIS customer working on ASIS tools. > > > > Suppose we have: > > > > type Acc_Subprogram is access procedure (I : Integer); > > Dynamic_Call : Acc_Subprogram; > > > > procedure P1 (J : Integer) is begin null; end P1; > > procedure Q1 (K : Integer) is begin null; end Q1; > > > > Var : Integer := 13; > > begin > > Dynamic_Call := P1'access; > > Dynamic_Call.all (Var); -<<-------------------------------------- > > ^^^^^^^^^^^^^^^^^^^^^^ | > > | > > Dynamic_Call := Q1'access; | > > Dynamic_Call.all (Var); -<<-------------------------------------+ > > ^^^^^^^^^^^^^^^^^^^^^^ | > > | > > And suppose we have got _NORMALIZED_ parameter associations from these > > calls. The question is - what should be the result of the > > Formal_Parameter query applied to such normalized associations? > > Clearly, it cannot be formal parameter defining names corresponding > > to the formal parameters of actually called procedures - this > > information is dynamically-determined in a general case. > > > > The only reasonable choice would be to return the defining name > > I from the declaration of the access-to-subprogram type > > Acc_Subprogram. The questions are: > > > > 1. Is it really what should be returned in this case (we've > > discussed this with Alain, and both of us think,that > > it is. > > > > 2. Should this be clarified in the ASIS definition? I'm pretty > > sure, that it should, because as it stands now, ASIS just > > reuses the old Ada83-based approch for normalized subprogram > > associations, without taking into account call-as-dereference > > and dispatching calls. > > > > Dispatching calls was the next question, and I'm afraid, it is > > not so easy to resolve. Suppose we've got a normalized subprogram > > association from a dispatching call (quite a syntactic action). > > And what in this case should be the result of the Formal_Parameter > > query applied to such an association? > > > > Alain's suggestion is to return a formal parameter defining > > name from the subprogram declaration corresponding to the > > root of the type hierarchy. Any comments? And this also should > > be documented in the ASIS definition. > From roby Thu Jul 2 16:44:16 1998 Return-Path: Received: by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id QAA05465; Thu, 2 Jul 1998 16:44:15 -0400 From: roby (Clyde Roby) Message-Id: <199807022044.QAA05465@cronus.csed.ida.org> Subject: proposed solution for Issue #096 To: SBlake@Aonix.Com (Steve Blake) Date: Thu, 2 Jul 1998 16:44:14 -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: 2987 Status: OR Steve, Please review this proposed solution to Issue #096. Clyde ------- !ASIS Issue #096 !topic Normalized associations for call-as-dereference and dispatching calls !reference ASIS 95 !from Sergey Rybin 98-06-13 !keywords normalized associations dispatching calls dereference calls !discussion Suppose we have: type Acc_Subprogram is access procedure (I : Integer); Dynamic_Call : Acc_Subprogram; procedure P1 (J : Integer) is begin null; end P1; procedure Q1 (K : Integer) is begin null; end Q1; Var : Integer := 13; begin Dynamic_Call := P1'access; Dynamic_Call.all (Var); -<<-------------------------------------- ^^^^^^^^^^^^^^^^^^^^^^ | | Dynamic_Call := Q1'access; | Dynamic_Call.all (Var); -<<-------------------------------------+ ^^^^^^^^^^^^^^^^^^^^^^ | | And suppose we have got _NORMALIZED_ parameter associations from these calls. The question is - what should be the result of the Formal_Parameter query applied to such normalized associations? Clearly, it cannot be formal parameter defining names corresponding to the formal parameters of actually called procedures - this information is dynamically-determined in a general case. The only reasonable choice would be to return the defining name I from the declaration of the access-to-subprogram type Acc_Subprogram. The questions are: 1. Is it really what should be returned in this case (we've discussed this with Alain, and both of us think, that it is. 2. Should this be clarified in the ASIS definition? I'm pretty sure, that it should, because as it stands now, ASIS just reuses the old Ada83-based approach for normalized subprogram associations, without taking into account call-as-dereference and dispatching calls. Dispatching calls was the next question, and I'm afraid, it is not so easy to resolve. Suppose we've got a normalized subprogram association from a dispatching call (quite a syntactic action). And what in this case should be the result of the Formal_Parameter query applied to such an association? Alain's suggestion is to return a formal parameter defining name from the subprogram declaration corresponding to the root of the type hierarchy. Any comments? And this also should be documented in the ASIS definition. !resolution Open !date 98-07-02 Proposed Resolution: To Clause 17.21, Formal_Parameter, add the following as the third item in the "If the Association argument is from a Normalized list" section: -- - Returns Nil_Element for normalized associations in the case where -- the called subprogram can be determined only dynamically (dispatching calls -- and calls as dereference). ASIS cannot produce any meaningful -- result in this case. ------- From sblake@sd.aonix.com Mon Jul 6 19:48:14 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id TAA08511; Mon, 6 Jul 1998 19:48:14 -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 TAA10188 for ; Mon, 6 Jul 1998 19:48:12 -0400 (EDT) Received: from rasht.sd.aonix.com (mailhub.alsys.com) by gw.sd.aonix.com (4.1/SMI-4.1.1) id AA12934; Mon, 6 Jul 98 16:46:06 PDT Received: from sd.aonix.com ([136.175.2.180]) by rasht.sd.aonix.com (4.1/TS-1.2c) id AA01908; Mon, 6 Jul 98 16:42:33 PDT Message-Id: <35A159E9.4CC5F089@sd.aonix.com> Date: Mon, 06 Jul 1998 16:12:42 -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 #096 References: <199807022044.QAA05465@cronus.csed.ida.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3786 Status: OR Clyde Roby wrote: > Steve, > > Please review this proposed solution to Issue #096. > > Clyde > ------- > > !ASIS Issue #096 > !topic Normalized associations for call-as-dereference and dispatching calls > !reference ASIS 95 > !from Sergey Rybin 98-06-13 > !keywords normalized associations dispatching calls dereference calls > !discussion > > Suppose we have: > > type Acc_Subprogram is access procedure (I : Integer); > Dynamic_Call : Acc_Subprogram; > > procedure P1 (J : Integer) is begin null; end P1; > procedure Q1 (K : Integer) is begin null; end Q1; > > Var : Integer := 13; > begin > Dynamic_Call := P1'access; > Dynamic_Call.all (Var); -<<-------------------------------------- > ^^^^^^^^^^^^^^^^^^^^^^ | > | > Dynamic_Call := Q1'access; | > Dynamic_Call.all (Var); -<<-------------------------------------+ > ^^^^^^^^^^^^^^^^^^^^^^ | > | > And suppose we have got _NORMALIZED_ parameter associations from these > calls. The question is - what should be the result of the > Formal_Parameter query applied to such normalized associations? > Clearly, it cannot be formal parameter defining names corresponding > to the formal parameters of actually called procedures - this > information is dynamically-determined in a general case. > > The only reasonable choice would be to return the defining name > I from the declaration of the access-to-subprogram type > Acc_Subprogram. The questions are: > > 1. Is it really what should be returned in this case (we've > discussed this with Alain, and both of us think, that > it is. > I agree with Sergey and Alain. In fact, this is the way my ASIS implementation works now. > 2. Should this be clarified in the ASIS definition? I'm pretty > sure, that it should, because as it stands now, ASIS just > reuses the old Ada83-based approach for normalized subprogram > associations, without taking into account call-as-dereference > and dispatching calls. > Yes, it should be clarified. > Dispatching calls was the next question, and I'm afraid, it is > not so easy to resolve. Suppose we've got a normalized subprogram > association from a dispatching call (quite a syntactic action). > And what in this case should be the result of the Formal_Parameter > query applied to such an association? > > Alain's suggestion is to return a formal parameter defining > name from the subprogram declaration corresponding to the > root of the type hierarchy. Any comments? And this also should > be documented in the ASIS definition. > I agree here too. The subprogram of the root type is the only choice for return from Corresponding_Name_Definition or Corresponding_Called_Entity or Corresponding_Called_Function as well, so it follows that the normalized formal parameter should be the one from the root subprogram. > !resolution Open > !date 98-07-02 > > Proposed Resolution: > > To Clause 17.21, Formal_Parameter, add the following as the third item in the "If the Association argument is from a Normalized list" section: > > -- - Returns Nil_Element for normalized associations in the case where > -- the called subprogram can be determined only dynamically (dispatching calls > -- and calls as dereference). ASIS cannot produce any meaningful > -- result in this case. > > ------- This does not need to be the case. The formal parameter from the access to subprogram definition or the subprogram of the root type should be meaningful if we just clarify the expected results suggested above. Steve From sblake@sd.aonix.com Mon Jul 6 19:56:38 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id TAA08516; Mon, 6 Jul 1998 19:56:38 -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 TAA10446 for ; Mon, 6 Jul 1998 19:56:36 -0400 (EDT) Received: from rasht.sd.aonix.com (mailhub.alsys.com) by gw.sd.aonix.com (4.1/SMI-4.1.1) id AA13249; Mon, 6 Jul 98 16:54:30 PDT Received: from sd.aonix.com ([136.175.2.180]) by rasht.sd.aonix.com (4.1/TS-1.2c) id AA02375; Mon, 6 Jul 98 16:50:56 PDT Message-Id: <35A15BE1.EA9A494F@sd.aonix.com> Date: Mon, 06 Jul 1998 16:21:06 -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 #096 References: <199807022044.QAA05465@cronus.csed.ida.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3368 Status: OR A further look shows that we return a nil element for the semantic queries Corresponding_Name_Definition, Corresponding_Called_Entity/Function, so I guess it makes sense to accept this nil element solution. Steve Clyde Roby wrote: > Steve, > > Please review this proposed solution to Issue #096. > > Clyde > ------- > > !ASIS Issue #096 > !topic Normalized associations for call-as-dereference and dispatching calls > !reference ASIS 95 > !from Sergey Rybin 98-06-13 > !keywords normalized associations dispatching calls dereference calls > !discussion > > Suppose we have: > > type Acc_Subprogram is access procedure (I : Integer); > Dynamic_Call : Acc_Subprogram; > > procedure P1 (J : Integer) is begin null; end P1; > procedure Q1 (K : Integer) is begin null; end Q1; > > Var : Integer := 13; > begin > Dynamic_Call := P1'access; > Dynamic_Call.all (Var); -<<-------------------------------------- > ^^^^^^^^^^^^^^^^^^^^^^ | > | > Dynamic_Call := Q1'access; | > Dynamic_Call.all (Var); -<<-------------------------------------+ > ^^^^^^^^^^^^^^^^^^^^^^ | > | > And suppose we have got _NORMALIZED_ parameter associations from these > calls. The question is - what should be the result of the > Formal_Parameter query applied to such normalized associations? > Clearly, it cannot be formal parameter defining names corresponding > to the formal parameters of actually called procedures - this > information is dynamically-determined in a general case. > > The only reasonable choice would be to return the defining name > I from the declaration of the access-to-subprogram type > Acc_Subprogram. The questions are: > > 1. Is it really what should be returned in this case (we've > discussed this with Alain, and both of us think, that > it is. > > 2. Should this be clarified in the ASIS definition? I'm pretty > sure, that it should, because as it stands now, ASIS just > reuses the old Ada83-based approach for normalized subprogram > associations, without taking into account call-as-dereference > and dispatching calls. > > Dispatching calls was the next question, and I'm afraid, it is > not so easy to resolve. Suppose we've got a normalized subprogram > association from a dispatching call (quite a syntactic action). > And what in this case should be the result of the Formal_Parameter > query applied to such an association? > > Alain's suggestion is to return a formal parameter defining > name from the subprogram declaration corresponding to the > root of the type hierarchy. Any comments? And this also should > be documented in the ASIS definition. > > !resolution Open > !date 98-07-02 > > Proposed Resolution: > > To Clause 17.21, Formal_Parameter, add the following as the third item in the "If the Association argument is from a Normalized list" section: > > -- - Returns Nil_Element for normalized associations in the case where > -- the called subprogram can be determined only dynamically (dispatching calls > -- and calls as dereference). ASIS cannot produce any meaningful > -- result in this case. > > ------- From colket@colket.org Tue Jul 7 12:05:27 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id MAA09605; Tue, 7 Jul 1998 12:05:26 -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 MAA24677 for ; Tue, 7 Jul 1998 12:05:26 -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 MAA11638; Tue, 7 Jul 1998 12:05:24 -0400 (EDT) Message-ID: <35A24702.695391F9@colket.org> Date: Tue, 07 Jul 1998 12:04:18 -0400 From: Currie Colket Reply-To: colket@colket.org X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ASIS Technical CC: Clyde Roby Subject: Propose Resolution for ASIS Issue #096 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3331 Status: OR Dear ASIS Technical, Only 2 issues are in need of resolution, that for Issue #95 and Issue #96. Attached is Issue #096 with its proposed resolution. Email on this issue is posted to => http://www.acm.org/sigada/WG/asiswg/issues/issue096.txt Comments suggesting alternative resolutions should be sent to => SIGAda-ASIS-Tech@acm.org as soon as possible. v/r Currie Colket Chair ASISWG/Chair ASISRG ------- !ASIS Issue #096 !topic Normalized associations for call-as-dereference and dispatching calls !reference ASIS 95 !from Sergey Rybin 98-06-13 !keywords normalized associations dispatching calls dereference calls !discussion Suppose we have: type Acc_Subprogram is access procedure (I : Integer); Dynamic_Call : Acc_Subprogram; procedure P1 (J : Integer) is begin null; end P1; procedure Q1 (K : Integer) is begin null; end Q1; Var : Integer := 13; begin Dynamic_Call := P1'access; Dynamic_Call.all (Var); -<<-------------------------------------- ^^^^^^^^^^^^^^^^^^^^^^ | | Dynamic_Call := Q1'access; | Dynamic_Call.all (Var); -<<-------------------------------------+ ^^^^^^^^^^^^^^^^^^^^^^ | | And suppose we have got _NORMALIZED_ parameter associations from these calls. The question is - what should be the result of the Formal_Parameter query applied to such normalized associations? Clearly, it cannot be formal parameter defining names corresponding to the formal parameters of actually called procedures - this information is dynamically-determined in a general case. The only reasonable choice would be to return the defining name I from the declaration of the access-to-subprogram type Acc_Subprogram. The questions are: 1. Is it really what should be returned in this case (we've discussed this with Alain, and both of us think, that it is. 2. Should this be clarified in the ASIS definition? I'm pretty sure, that it should, because as it stands now, ASIS just reuses the old Ada83-based approach for normalized subprogram associations, without taking into account call-as-dereference and dispatching calls. Dispatching calls was the next question, and I'm afraid, it is not so easy to resolve. Suppose we've got a normalized subprogram association from a dispatching call (quite a syntactic action). And what in this case should be the result of the Formal_Parameter query applied to such an association? Alain's suggestion is to return a formal parameter defining name from the subprogram declaration corresponding to the root of the type hierarchy. Any comments? And this also should be documented in the ASIS definition. !resolution Open !date 98-07-02 Proposed Resolution: To Clause 17.21, Formal_Parameter, add the following as the third item in the "If the Association argument is from a Normalized list" section: -- - Returns Nil_Element for normalized associations in the case where -- the called subprogram can be determined only dynamically (dispatching calls -- and calls as dereference). ASIS cannot produce any meaningful -- result in this case. ------- From rybin@POSSUM.SRCC.MSU.SU Wed Jul 8 08:07:44 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA12019; Wed, 8 Jul 1998 08:07:43 -0400 Received: from mail.acm.org ([199.222.69.4]) by cs.ida.org (8.8.7/8.8.7) with ESMTP id HAA16135 for ; Wed, 8 Jul 1998 07:15:12 -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 HAA17498; Wed, 8 Jul 1998 07:07:20 -0400 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 1021316 for SIGADA-ASIS-TECH@ACM.ORG; Wed, 8 Jul 1998 07:07:19 -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 GAA140286 for ; Wed, 8 Jul 1998 06:57:16 -0400 Received: from srcc.UUCP (uucp@localhost) by logger.gamma.ru (8.8.8/8.8.8) with UUCP id PAA12063; Wed, 8 Jul 1998 15:04:05 +0400 (MSD) (envelope-from possum!possum.srcc.msu.su!rybin@gamma.srcc.msu.su) Received: by gamma.srcc.msu.su; Wed, 8 Jul 1998 15:02:37 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Wed, 8 Jul 1998 14:31:37 +0400 References: X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Lines: 60 Message-ID: Date: Wed, 8 Jul 1998 14:31:37 +0400 Reply-To: "Sergey I. Rybin" Sender: ACM SIGADA ASIS Technical Discussion Group From: "Sergey I. Rybin" Organization: Information Systems, SRCC, MSU Subject: Re: Propose Resolution for ASIS Issue #096 Comments: To: Alain.Le_Guennec@ACM.ORG To: SIGADA-ASIS-TECH@ACM.ORG Content-Length: 2104 Status: OR > For profile of dereferences, the relevant RM paragraphs is 4.10 (10) > (and the note following it, in the AARM): It is not 4.10 (10), but 4.1(10). Alain told me a while ago, that there was a place in RM which explicitly resolved this problem, but I failed to find it by that time. Now we have an exact reference to RM and AARM, and I have to agree with Alain, that RM gives enough proof for returning non-nil components of normalized associations in case of calls as dereferences. Sergey > > << > 10 {profile [associated with a dereference]} If the type of the name in a > dereference is some access-to-subprogram type S, then the dereference denotes > a view of a subprogram, the profile of the view being the designated profile > of S. > > 10.a Ramification: This means that the formal parameter names and > default expressions to be used in a call whose name or prefix is a > dereference are those of the designated profile, which need not be > the same as those of the subprogram designated by the access value, > since 'Access requires only subtype conformance, not full > conformance. > >> > > > !resolution Open > > !date 98-07-02 > > > > Proposed Resolution: > > > > To Clause 17.21, Formal_Parameter, add the following as the third item > > in the "If the > > Association argument is from a Normalized list" section: > > > > -- - Returns Nil_Element for normalized associations in the case where > > -- the called subprogram can be determined only dynamically > > (dispatching calls > > -- and calls as dereference). ASIS cannot produce any meaningful > ^^^^^^^^^^^^^^^^^^^^ > > So I do not agree with this proposition of resolution. > > > -- result in this case. > > > > ------- > > > > > > Alain Le Guennec, not speaking for IRISA. > > -- > -- Office C301, IRISA, Campus de Beaulieu, 35042 Rennes, FRANCE > -- Phone: +33 2 99 84 25 41 ---- Fax: +33 2 99 84 71 71 > -- Email: Alain.Le_Guennec@irisa.fr -- PAMPA Research Group > From Alain.Le_Guennec@IRISA.FR Wed Jul 8 08:51:56 1998 Return-Path: Received: from metropolis.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id IAA12114; Wed, 8 Jul 1998 08:51:55 -0400 Received: from mail.acm.org ([199.222.69.4]) by metropolis.ida.org (8.8.7/8.8.7) with ESMTP id FAA04050 for ; Wed, 8 Jul 1998 05:51:56 -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 FAA172396; Wed, 8 Jul 1998 05:35:16 -0400 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 1021244 for SIGADA-ASIS-TECH@ACM.ORG; Wed, 8 Jul 1998 05:35:16 -0400 Received: from ulla.irisa.fr (ulla.irisa.fr [131.254.43.50]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id FAA161684 for ; Wed, 8 Jul 1998 05:25:13 -0400 Received: from myrtille.irisa.fr (myrtille.irisa.fr [131.254.43.44]) by ulla.irisa.fr (8.8.7/8.8.7) with ESMTP id LAA05804; Wed, 8 Jul 1998 11:32:14 +0200 (MET DST) References: <35A24702.695391F9@colket.org> Lines: 86 X-Mailer: Gnus v5.3/Emacs 19.34 Message-ID: Date: Wed, 8 Jul 1998 11:32:13 +0200 Reply-To: Alain.Le_Guennec@IRISA.FR Sender: ACM SIGADA ASIS Technical Discussion Group From: Alain Le Guennec Subject: Re: Propose Resolution for ASIS Issue #096 Comments: To: colket@ACM.ORG To: SIGADA-ASIS-TECH@ACM.ORG In-Reply-To: Currie Colket's message of Tue, 7 Jul 1998 12:04:18 -0400 Content-Length: 3358 Status: OR Currie Colket writes: > type Acc_Subprogram is access procedure (I : Integer); > Dynamic_Call : Acc_Subprogram; > > procedure P1 (J : Integer) is begin null; end P1; > procedure Q1 (K : Integer) is begin null; end Q1; > > Var : Integer := 13; > begin > Dynamic_Call := P1'access; > Dynamic_Call.all (Var); -<<-------------------------------------- > ^^^^^^^^^^^^^^^^^^^^^^ | > | > Dynamic_Call := Q1'access; | > Dynamic_Call.all (Var); -<<-------------------------------------+ > ^^^^^^^^^^^^^^^^^^^^^^ | > | > And suppose we have got _NORMALIZED_ parameter associations from these > calls. The question is - what should be the result of the > Formal_Parameter query applied to such normalized associations? > Clearly, it cannot be formal parameter defining names corresponding > to the formal parameters of actually called procedures - this > information is dynamically-determined in a general case. > > The only reasonable choice would be to return the defining name > I from the declaration of the access-to-subprogram type > Acc_Subprogram. The questions are: > > 1. Is it really what should be returned in this case (we've > discussed this with Alain, and both of us think, that > it is. > > 2. Should this be clarified in the ASIS definition? I'm pretty > sure, that it should, because as it stands now, ASIS just > reuses the old Ada83-based approach for normalized subprogram > associations, without taking into account call-as-dereference > and dispatching calls. For profile of dereferences, the relevant RM paragraphs is 4.10 (10) (and the note following it, in the AARM): << 10 {profile [associated with a dereference]} If the type of the name in a dereference is some access-to-subprogram type S, then the dereference denotes a view of a subprogram, the profile of the view being the designated profile of S. 10.a Ramification: This means that the formal parameter names and default expressions to be used in a call whose name or prefix is a dereference are those of the designated profile, which need not be the same as those of the subprogram designated by the access value, since 'Access requires only subtype conformance, not full conformance. >> > !resolution Open > !date 98-07-02 > > Proposed Resolution: > > To Clause 17.21, Formal_Parameter, add the following as the third item > in the "If the > Association argument is from a Normalized list" section: > > -- - Returns Nil_Element for normalized associations in the case where > -- the called subprogram can be determined only dynamically > (dispatching calls > -- and calls as dereference). ASIS cannot produce any meaningful ^^^^^^^^^^^^^^^^^^^^ So I do not agree with this proposition of resolution. > -- result in this case. > > ------- > > Alain Le Guennec, not speaking for IRISA. -- -- Office C301, IRISA, Campus de Beaulieu, 35042 Rennes, FRANCE -- Phone: +33 2 99 84 25 41 ---- Fax: +33 2 99 84 71 71 -- Email: Alain.Le_Guennec@irisa.fr -- PAMPA Research Group From rybin@POSSUM.SRCC.MSU.SU Wed Jul 8 09:00:16 1998 Return-Path: Received: from metropolis.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id JAA12135; Wed, 8 Jul 1998 09:00:15 -0400 Received: from mail.acm.org ([199.222.69.4]) by metropolis.ida.org (8.8.7/8.8.7) with ESMTP id CAA03490 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 CAA144284; Wed, 8 Jul 1998 02:18:42 -0400 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 1021093 for SIGADA-ASIS-TECH@ACM.ORG; Wed, 8 Jul 1998 02:18:41 -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 CAA143834 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 KAA07638; Wed, 8 Jul 1998 10:15:34 +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:13:43 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Tue, 7 Jul 1998 23:27:20 +0400 References: <35A24702.695391F9@colket.org> X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Lines: 104 Message-ID: Date: Tue, 7 Jul 1998 23:27:20 +0400 Reply-To: "Sergey I. Rybin" Sender: ACM SIGADA ASIS Technical Discussion Group From: "Sergey I. Rybin" Organization: Information Systems, SRCC, MSU Subject: Re: Propose Resolution for ASIS Issue #096 Comments: To: colket@ACM.ORG To: SIGADA-ASIS-TECH@ACM.ORG Content-Length: 3898 Status: OR I like the idea to return Nil_Element in case if a called subprogram can be determined only dynamically. The only comment: do not you think, that this note about returning Nil_Element in this case should be returned to Actual_Parameter also? Sergey > Dear ASIS Technical, > > Only 2 issues are in need of resolution, that for Issue #95 and Issue > #96. > > Attached is Issue #096 with its proposed resolution. Email on this issue > is posted to => > > http://www.acm.org/sigada/WG/asiswg/issues/issue096.txt > > Comments suggesting alternative resolutions should be sent to => > > SIGAda-ASIS-Tech@acm.org > > as soon as possible. > > v/r > Currie Colket > Chair ASISWG/Chair ASISRG > > ------- > > !ASIS Issue #096 > !topic Normalized associations for call-as-dereference and dispatching > calls > !reference ASIS 95 > !from Sergey Rybin 98-06-13 > !keywords normalized associations dispatching calls dereference calls > !discussion > > Suppose we have: > > type Acc_Subprogram is access procedure (I : Integer); > Dynamic_Call : Acc_Subprogram; > > procedure P1 (J : Integer) is begin null; end P1; > procedure Q1 (K : Integer) is begin null; end Q1; > > Var : Integer := 13; > begin > Dynamic_Call := P1'access; > Dynamic_Call.all (Var); -<<-------------------------------------- > ^^^^^^^^^^^^^^^^^^^^^^ | > | > Dynamic_Call := Q1'access; | > Dynamic_Call.all (Var); -<<-------------------------------------+ > ^^^^^^^^^^^^^^^^^^^^^^ | > | > And suppose we have got _NORMALIZED_ parameter associations from these > calls. The question is - what should be the result of the > Formal_Parameter query applied to such normalized associations? > Clearly, it cannot be formal parameter defining names corresponding > to the formal parameters of actually called procedures - this > information is dynamically-determined in a general case. > > The only reasonable choice would be to return the defining name > I from the declaration of the access-to-subprogram type > Acc_Subprogram. The questions are: > > 1. Is it really what should be returned in this case (we've > discussed this with Alain, and both of us think, that > it is. > > 2. Should this be clarified in the ASIS definition? I'm pretty > sure, that it should, because as it stands now, ASIS just > reuses the old Ada83-based approach for normalized subprogram > associations, without taking into account call-as-dereference > and dispatching calls. > > Dispatching calls was the next question, and I'm afraid, it is > not so easy to resolve. Suppose we've got a normalized subprogram > association from a dispatching call (quite a syntactic action). > And what in this case should be the result of the Formal_Parameter > query applied to such an association? > > Alain's suggestion is to return a formal parameter defining > name from the subprogram declaration corresponding to the > root of the type hierarchy. Any comments? And this also should > be documented in the ASIS definition. > > !resolution Open > !date 98-07-02 > > Proposed Resolution: > > To Clause 17.21, Formal_Parameter, add the following as the third item > in the "If the > Association argument is from a Normalized list" section: > > -- - Returns Nil_Element for normalized associations in the case where > -- the called subprogram can be determined only dynamically > (dispatching calls > -- and calls as dereference). ASIS cannot produce any meaningful > -- result in this case. > > ------- > From colket@colket.org Mon Jul 13 11:15:31 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id LAA20610; Mon, 13 Jul 1998 11:15: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 LAA10117 for ; Mon, 13 Jul 1998 11:15:30 -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 LAA31810; Mon, 13 Jul 1998 11:07:12 -0400 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 1035039 for SIGADA-ASIS-TECH@ACM.ORG; Mon, 13 Jul 1998 11:07:11 -0400 Received: from smtp1.erols.com (smtp1.erols.com [207.172.3.234]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id LAA24090 for ; Mon, 13 Jul 1998 11:07:05 -0400 Received: from colket.org (207-172-64-226.s226.tnt17.brd.erols.com [207.172.64.226]) by smtp1.erols.com (8.8.8/8.8.5) with ESMTP id LAA08643; Mon, 13 Jul 1998 11:12:30 -0400 (EDT) X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <35AA2398.5AF1C468@colket.org> Date: Mon, 13 Jul 1998 11:11:20 -0400 Reply-To: colket@colket.org Sender: ACM SIGADA ASIS Technical Discussion Group From: Currie Colket Subject: Re: Propose Resolution for ASIS Issue #096 Comments: To: "Sergey I. Rybin" To: SIGADA-ASIS-TECH@ACM.ORG Content-Length: 2427 Status: OR Sergey, Concur with this approach. Is it possible to write up a suggested replacement with Alain and circulate it amongst ASIS-Technical. This would be much appreciated. v/r Currie Sergey I. Rybin wrote: > > For profile of dereferences, the relevant RM paragraphs is 4.10 (10) > > (and the note following it, in the AARM): > > It is not 4.10 (10), but 4.1(10). > > Alain told me a while ago, that there was a place in RM which explicitly > resolved this problem, but I failed to find it by that time. > > Now we have an exact reference to RM and AARM, and I have to agree > with Alain, that RM gives enough proof for returning > non-nil components of normalized associations in case of > calls as dereferences. > > Sergey > > > > > << > > 10 {profile [associated with a dereference]} If the type of the name in a > > dereference is some access-to-subprogram type S, then the dereference denotes > > a view of a subprogram, the profile of the view being the designated profile > > of S. > > > > 10.a Ramification: This means that the formal parameter names and > > default expressions to be used in a call whose name or prefix is a > > dereference are those of the designated profile, which need not be > > the same as those of the subprogram designated by the access value, > > since 'Access requires only subtype conformance, not full > > conformance. > > >> > > > > > !resolution Open > > > !date 98-07-02 > > > > > > Proposed Resolution: > > > > > > To Clause 17.21, Formal_Parameter, add the following as the third item > > > in the "If the > > > Association argument is from a Normalized list" section: > > > > > > -- - Returns Nil_Element for normalized associations in the case where > > > -- the called subprogram can be determined only dynamically > > > (dispatching calls > > > -- and calls as dereference). ASIS cannot produce any meaningful > > ^^^^^^^^^^^^^^^^^^^^ > > > > So I do not agree with this proposition of resolution. > > > > > -- result in this case. > > > > > > ------- > > > > > > > > > > Alain Le Guennec, not speaking for IRISA. > > > > -- > > -- Office C301, IRISA, Campus de Beaulieu, 35042 Rennes, FRANCE > > -- Phone: +33 2 99 84 25 41 ---- Fax: +33 2 99 84 71 71 > > -- Email: Alain.Le_Guennec@irisa.fr -- PAMPA Research Group > > From rybin@POSSUM.SRCC.MSU.SU Mon Jul 13 14:15:31 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id OAA21044; Mon, 13 Jul 1998 14:15: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 OAA17678 for ; Mon, 13 Jul 1998 14:15:27 -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 OAA33050; Mon, 13 Jul 1998 14:07:26 -0400 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 1035511 for SIGADA-ASIS-TECH@ACM.ORG; Mon, 13 Jul 1998 14:07:24 -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 NAA06610 for ; Mon, 13 Jul 1998 13:57:20 -0400 Received: from srcc.UUCP (uucp@localhost) by logger.gamma.ru (8.8.8/8.8.8) with UUCP id WAA12457; Mon, 13 Jul 1998 22:04:28 +0400 (MSD) (envelope-from possum!possum.srcc.msu.su!rybin@gamma.srcc.msu.su) Received: by gamma.srcc.msu.su; Mon, 13 Jul 1998 22:02:59 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Mon, 13 Jul 1998 22:06:09 +0400 References: <35AA2398.5AF1C468@colket.org> X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Lines: 151 Message-ID: Date: Mon, 13 Jul 1998 22:06:09 +0400 Reply-To: "Sergey I. Rybin" Sender: ACM SIGADA ASIS Technical Discussion Group From: "Sergey I. Rybin" Organization: Information Systems, SRCC, MSU Subject: Re: Propose Resolution for ASIS Issue #096 Comments: To: colket@ACM.ORG To: SIGADA-ASIS-TECH@ACM.ORG Content-Length: 6199 Status: OR > Sergey, > > Concur with this approach. Is it possible to write up a suggested replacement with > Alain and circulate it amongst ASIS-Technical. This would be much appreciated. > > v/r > Currie Below is the proposed change based on our discussions. To speed up the ASIS revision process, I'm sending it directly to ASIS-Technical, without re-discussing with Alain (I think, now both of us have the same view on this problem). Note also a small proposed correction for the last paragraphs of 17.30 and 18.26. Sergey ================================================================= --------------------------------------------------------------------------------------- -- 17.30 function Function_Call_Parameters --------------------------------------------------------------------------------------- -- A normalized list contains artificial associations representing all -- explicit and default associations. It has a length equal to the number of -- parameter_specification elements of the formal_part of the -- parameter_and_result_profile. The order of normalized associations matches -- the order of parameter_specification elements. -- -- Each normalized association represents a one on one mapping of a -- parameter_specification elements to the explicit or default expression. -- A normalized association has one A_Defining_Name component that denotes the -- parameter_specification, and one An_Expression component that is either the -- explicit_actual_parameter or a default_expression. -- -->>> adding the following paragraph: -- -- If prefix of the call denotes an access to a function implicit or explicit -- dereference, normalized associations are constructed on the base of -- formal_part of the parameter_and_result_profile from the corresponding -- access_to_subprogrogram definition. -- --<<< end of the added papargaph -- -- The exception ASIS_Inappropriate_Element is raised when the function -- call is an attribute reference and Is_Normalized is True. ^^^^^^^^^^^^^^^^^^^^^^^^^^ I would add also this --------------------------------------------------------------------------------------- -- 18.26 function Call_Statement_Parameters --------------------------------------------------------------------------------------- ... -- A normalized list contains artificial associations representing all -- explicit and default associations. It has a length equal to the number of -- parameter_specification elements of the formal_part of the -- parameter_and_result_profile. The order of normalized associations matches -- the order of parameter_specification elements. -- -- Each normalized association represents a one on one mapping of a -- parameter_specification elements to the explicit or default expression. -- A normalized association has one A_Defining_Name component that denotes the -- parameter_specification, and one An_Expression component that is either the -- explicit_actual_parameter or a default_expression. -- -- -->>> adding the following paragraph: -- -- If prefix of the call denotes an access to a procedure implicit or explicit -- dereference, normalized associations are constructed on the base of -- formal_part of the parameter_profile from the corresponding -- access_to_subprogrogram definition. -- --<<< end of the added papargaph -- -- The exception ASIS_Inappropriate_Element is raised when the procedure -- call is an attribute reference and Is_Normalized is True. ^^^^^^^^^^^^^^^^^^^^^^^^^^ I would add also this ================================================================= > Sergey I. Rybin wrote: > > > > For profile of dereferences, the relevant RM paragraphs is 4.10 (10) > > > (and the note following it, in the AARM): > > > > It is not 4.10 (10), but 4.1(10). > > > > Alain told me a while ago, that there was a place in RM which explicitly > > resolved this problem, but I failed to find it by that time. > > > > Now we have an exact reference to RM and AARM, and I have to agree > > with Alain, that RM gives enough proof for returning > > non-nil components of normalized associations in case of > > calls as dereferences. > > > > Sergey > > > > > > > > << > > > 10 {profile [associated with a dereference]} If the type of the name in a > > > dereference is some access-to-subprogram type S, then the dereference denotes > > > a view of a subprogram, the profile of the view being the designated profile > > > of S. > > > > > > 10.a Ramification: This means that the formal parameter names and > > > default expressions to be used in a call whose name or prefix is a > > > dereference are those of the designated profile, which need not be > > > the same as those of the subprogram designated by the access value, > > > since 'Access requires only subtype conformance, not full > > > conformance. > > > >> > > > > > > > !resolution Open > > > > !date 98-07-02 > > > > > > > > Proposed Resolution: > > > > > > > > To Clause 17.21, Formal_Parameter, add the following as the third item > > > > in the "If the > > > > Association argument is from a Normalized list" section: > > > > > > > > -- - Returns Nil_Element for normalized associations in the case where > > > > -- the called subprogram can be determined only dynamically > > > > (dispatching calls > > > > -- and calls as dereference). ASIS cannot produce any meaningful > > > ^^^^^^^^^^^^^^^^^^^^ > > > > > > So I do not agree with this proposition of resolution. > > > > > > > -- result in this case. > > > > > > > > ------- > > > > > > > > > > > > > > Alain Le Guennec, not speaking for IRISA. > > > > > > -- > > > -- Office C301, IRISA, Campus de Beaulieu, 35042 Rennes, FRANCE > > > -- Phone: +33 2 99 84 25 41 ---- Fax: +33 2 99 84 71 71 > > > -- Email: Alain.Le_Guennec@irisa.fr -- PAMPA Research Group > > > > From rybin@POSSUM.SRCC.MSU.SU Tue Jul 21 03:55:26 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id DAA03103; Tue, 21 Jul 1998 03:55: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 DAA04105 for ; Tue, 21 Jul 1998 03:55:25 -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 DAA08972; Tue, 21 Jul 1998 03:46:59 -0400 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 1052429 for SIGADA-ASIS-TECH@ACM.ORG; Tue, 21 Jul 1998 03:46:58 -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 DAA31754 for ; Tue, 21 Jul 1998 03:36:28 -0400 Received: from srcc.UUCP (uucp@localhost) by logger.gamma.ru (8.8.8/8.8.8) with UUCP id LAA08679; Tue, 21 Jul 1998 11:34:29 +0400 (MSD) (envelope-from possum!possum.srcc.msu.su!rybin@gamma.srcc.msu.su) Received: by gamma.srcc.msu.su; Tue, 21 Jul 1998 11:31:49 +0400 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Tue, 21 Jul 1998 01:08:02 +0400 References: <199807162029.QAA26385@cronus.csed.ida.org> X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Lines: 156 Message-ID: Date: Tue, 21 Jul 1998 01:08:02 +0400 Reply-To: "Sergey I. Rybin" Sender: ACM SIGADA ASIS Technical Discussion Group From: "Sergey I. Rybin" Organization: Information Systems, SRCC, MSU Subject: Re: Issue #096 Revision Comments: To: roby@ACM.ORG To: SIGADA-ASIS-TECH@ACM.ORG Content-Length: 6365 Status: OR > All, > > This is the revised proposed solution for Issue #096. It > incorporates the wording to address dereferencing provided by Alain > and Sergey. If you have any further comments or suggestions, please > send them to SIGAda-ASIS-Tech@ACM.Org by 24 July. Thank you. > > Clyde and Currie > ------- The proposed change affects three queries: Function_Call_Parameters Call_Statement_Parameters and Formal_Parameter. I am afraid, some logic is missed here. From one side, adding proposed clarification to Formal_Parameter is redundant and not necessary: explanations added to Function_Call_Parameters and Call_Statement_Parameters are enough to "compute" the result of this query in case of a dispatching call or a call-a- dereference), From the other side,if we would like to clarify Formal parameter, we will have to clarify in the same way also Actual_Parameter, because the situations for formal and default actual parameters in a normalized association obtained from a dispatching call or from a call-as-dereference are quite similar. I would propose to add clarifications only to Function_Call_Parameters and to Call_Statement_Parameters. Sergey > > !ASIS Issue #096 > !topic Normalized associations for call-as-dereference and dispatching calls > !reference ASIS 95 > !from Sergey Rybin 98-06-13 > !keywords normalized associations dispatching calls dereference calls > !discussion > > Suppose we have: > > type Acc_Subprogram is access procedure (I : Integer); > Dynamic_Call : Acc_Subprogram; > > procedure P1 (J : Integer) is begin null; end P1; > procedure Q1 (K : Integer) is begin null; end Q1; > > Var : Integer := 13; > begin > Dynamic_Call := P1'access; > Dynamic_Call.all (Var); -<<-------------------------------------- > ^^^^^^^^^^^^^^^^^^^^^^ | > | > Dynamic_Call := Q1'access; | > Dynamic_Call.all (Var); -<<-------------------------------------+ > ^^^^^^^^^^^^^^^^^^^^^^ | > | > And suppose we have got _NORMALIZED_ parameter associations from these > calls. The question is - what should be the result of the > Formal_Parameter query applied to such normalized associations? > Clearly, it cannot be formal parameter defining names corresponding > to the formal parameters of actually called procedures - this > information is dynamically-determined in a general case. > > The only reasonable choice would be to return the defining name > I from the declaration of the access-to-subprogram type > Acc_Subprogram. The questions are: > > 1. Is it really what should be returned in this case (we've > discussed this with Alain, and both of us think, that > it is. > > 2. Should this be clarified in the ASIS definition? I'm pretty > sure, that it should, because as it stands now, ASIS just > reuses the old Ada83-based approach for normalized subprogram > associations, without taking into account call-as-dereference > and dispatching calls. > > Dispatching calls was the next question, and I'm afraid, it is > not so easy to resolve. Suppose we've got a normalized subprogram > association from a dispatching call (quite a syntactic action). > And what in this case should be the result of the Formal_Parameter > query applied to such an association? > > Alain's suggestion is to return a formal parameter defining > name from the subprogram declaration corresponding to the > root of the type hierarchy. Any comments? And this also should > be documented in the ASIS definition. > > !resolution Open > !date 98-07-16 > > Proposed Resolution: > > To Clause 17.21, Formal_Parameter, add the following as the third and > fourth items in the "If the Association argument is from a Normalized > list" section: > > -- - If the prefix of the call denotes an access to a subprogram implicit > -- or explicit deference, normalized associations are constructed on the > -- basis of the formal_part of the parameter_profile or > -- parameter_and_result_profile from the corresponding access_to_subprogram > -- definition. > > -- - Returns Nil_Element for normalized associations in the case where > -- the called subprogram can be determined only dynamically (dispatching > -- calls). ASIS cannot produce any meaningful result in this case. > > To Clause 17.30, Function_Call_Parameters, change the paragraph reading: > > -- The exception ASIS_Inappropriate_Element is raised when the function > -- call is an attribute reference. > > To: > > -- If the prefix of the call denotes an access to a function implicit or > -- explicit deference, normalized associations are constructed on the basis > -- of the formal_part of the parameter_and_result_profile from the > -- corresponding access_to_subprogram definition. > > -- Returns Nil_Element for normalized associations in the case where > -- the called function can be determined only dynamically (dispatching > -- calls). ASIS cannot produce any meaningful result in this case. > > -- The exception ASIS_Inappropriate_Element is raised when the function > -- call is an attribute reference and Is_Normalized is True. > > To Clause 18.26, Call_Statement_Parameters, change the paragraph reading: > > -- The exception ASIS_Inappropriate_Element is raised when the function > -- call is an attribute reference. > > To: > > -- If the prefix of the call denotes an access to a procedure implicit or > -- explicit deference, normalized associations are constructed on the basis > -- of the formal_part of the parameter_profile from the corresponding > -- access_to_subprogram definition. > > -- Returns Nil_Element for normalized associations in the case where > -- the called procedure can be determined only dynamically (dispatching > -- calls). ASIS cannot produce any meaningful result in this case. > > -- The exception ASIS_Inappropriate_Element is raised when the procedure > -- call is an attribute reference and Is_Normalized is True. > > ------- > From colket@colket.org Tue Jul 21 14:45:10 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id OAA03507; Tue, 21 Jul 1998 14:45: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 OAA20300 for ; Tue, 21 Jul 1998 14:45:09 -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 OAA58484; Tue, 21 Jul 1998 14:36:41 -0400 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 1054119 for SIGADA-ASIS-TECH@ACM.ORG; Tue, 21 Jul 1998 14:36:40 -0400 Received: from smtp1.erols.com (smtp1.erols.com [207.172.3.234]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id OAA51304 for ; Tue, 21 Jul 1998 14:36:39 -0400 Received: from colket.org (207-172-87-65.s65.tnt6.brd.erols.com [207.172.87.65]) by smtp1.erols.com (8.8.8/8.8.5) with ESMTP id OAA03458; Tue, 21 Jul 1998 14:41:31 -0400 (EDT) X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 References: <199807162029.QAA26385@cronus.csed.ida.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <35B4E090.46CCB89D@colket.org> Date: Tue, 21 Jul 1998 14:40:16 -0400 Reply-To: colket@colket.org Sender: ACM SIGADA ASIS Technical Discussion Group From: Currie Colket Subject: Re: Issue #096 Revision Comments: To: "Sergey I. Rybin" Comments: cc: Clyde Roby To: SIGADA-ASIS-TECH@ACM.ORG Content-Length: 6904 Status: OR Sergy, Thank you for getting back right away. Unless there is additional discussion, there will only be changes for Function_Call_Parameters and for Call_Statement_Parameters as requested by Sergey. v/r Currie Sergey I. Rybin wrote: > > All, > > > > This is the revised proposed solution for Issue #096. It > > incorporates the wording to address dereferencing provided by Alain > > and Sergey. If you have any further comments or suggestions, please > > send them to SIGAda-ASIS-Tech@ACM.Org by 24 July. Thank you. > > > > Clyde and Currie > > ------- > > The proposed change affects three queries: > > Function_Call_Parameters > Call_Statement_Parameters > > and > > Formal_Parameter. > > I am afraid, some logic is missed here. > > >From one side, adding proposed clarification to Formal_Parameter is > redundant and not necessary: explanations added to > Function_Call_Parameters and Call_Statement_Parameters are enough > to "compute" the result of this query in case of a dispatching call > or a call-a- dereference), > > >From the other side,if we would like to clarify Formal parameter, > we will have to clarify in the same way also Actual_Parameter, > because the situations for formal and default actual parameters > in a normalized association obtained from a dispatching call or from a > call-as-dereference are quite similar. > > I would propose to add clarifications only to Function_Call_Parameters > and to Call_Statement_Parameters. > > Sergey > > > > > !ASIS Issue #096 > > !topic Normalized associations for call-as-dereference and dispatching calls > > !reference ASIS 95 > > !from Sergey Rybin 98-06-13 > > !keywords normalized associations dispatching calls dereference calls > > !discussion > > > > Suppose we have: > > > > type Acc_Subprogram is access procedure (I : Integer); > > Dynamic_Call : Acc_Subprogram; > > > > procedure P1 (J : Integer) is begin null; end P1; > > procedure Q1 (K : Integer) is begin null; end Q1; > > > > Var : Integer := 13; > > begin > > Dynamic_Call := P1'access; > > Dynamic_Call.all (Var); -<<-------------------------------------- > > ^^^^^^^^^^^^^^^^^^^^^^ | > > | > > Dynamic_Call := Q1'access; | > > Dynamic_Call.all (Var); -<<-------------------------------------+ > > ^^^^^^^^^^^^^^^^^^^^^^ | > > | > > And suppose we have got _NORMALIZED_ parameter associations from these > > calls. The question is - what should be the result of the > > Formal_Parameter query applied to such normalized associations? > > Clearly, it cannot be formal parameter defining names corresponding > > to the formal parameters of actually called procedures - this > > information is dynamically-determined in a general case. > > > > The only reasonable choice would be to return the defining name > > I from the declaration of the access-to-subprogram type > > Acc_Subprogram. The questions are: > > > > 1. Is it really what should be returned in this case (we've > > discussed this with Alain, and both of us think, that > > it is. > > > > 2. Should this be clarified in the ASIS definition? I'm pretty > > sure, that it should, because as it stands now, ASIS just > > reuses the old Ada83-based approach for normalized subprogram > > associations, without taking into account call-as-dereference > > and dispatching calls. > > > > Dispatching calls was the next question, and I'm afraid, it is > > not so easy to resolve. Suppose we've got a normalized subprogram > > association from a dispatching call (quite a syntactic action). > > And what in this case should be the result of the Formal_Parameter > > query applied to such an association? > > > > Alain's suggestion is to return a formal parameter defining > > name from the subprogram declaration corresponding to the > > root of the type hierarchy. Any comments? And this also should > > be documented in the ASIS definition. > > > > !resolution Open > > !date 98-07-16 > > > > Proposed Resolution: > > > > To Clause 17.21, Formal_Parameter, add the following as the third and > > fourth items in the "If the Association argument is from a Normalized > > list" section: > > > > -- - If the prefix of the call denotes an access to a subprogram implicit > > -- or explicit deference, normalized associations are constructed on the > > -- basis of the formal_part of the parameter_profile or > > -- parameter_and_result_profile from the corresponding access_to_subprogram > > -- definition. > > > > -- - Returns Nil_Element for normalized associations in the case where > > -- the called subprogram can be determined only dynamically (dispatching > > -- calls). ASIS cannot produce any meaningful result in this case. > > > > To Clause 17.30, Function_Call_Parameters, change the paragraph reading: > > > > -- The exception ASIS_Inappropriate_Element is raised when the function > > -- call is an attribute reference. > > > > To: > > > > -- If the prefix of the call denotes an access to a function implicit or > > -- explicit deference, normalized associations are constructed on the basis > > -- of the formal_part of the parameter_and_result_profile from the > > -- corresponding access_to_subprogram definition. > > > > -- Returns Nil_Element for normalized associations in the case where > > -- the called function can be determined only dynamically (dispatching > > -- calls). ASIS cannot produce any meaningful result in this case. > > > > -- The exception ASIS_Inappropriate_Element is raised when the function > > -- call is an attribute reference and Is_Normalized is True. > > > > To Clause 18.26, Call_Statement_Parameters, change the paragraph reading: > > > > -- The exception ASIS_Inappropriate_Element is raised when the function > > -- call is an attribute reference. > > > > To: > > > > -- If the prefix of the call denotes an access to a procedure implicit or > > -- explicit deference, normalized associations are constructed on the basis > > -- of the formal_part of the parameter_profile from the corresponding > > -- access_to_subprogram definition. > > > > -- Returns Nil_Element for normalized associations in the case where > > -- the called procedure can be determined only dynamically (dispatching > > -- calls). ASIS cannot produce any meaningful result in this case. > > > > -- The exception ASIS_Inappropriate_Element is raised when the procedure > > -- call is an attribute reference and Is_Normalized is True. > > > > ------- > >