From owner-sigada-asis-tech@ACM.ORG Wed Nov 11 11:58:50 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (8.8.8+Sun/SMI-SVR4) id LAA29580; Wed, 11 Nov 1998 11:58:46 -0500 (EST) 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 LAA10977 for ; Wed, 11 Nov 1998 11:58:45 -0500 (EST) Received: from mail (mail.acm.org [199.222.69.4]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id LAA42794; Wed, 11 Nov 1998 11:56:31 -0500 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 68509 for SIGADA-ASIS-TECH@ACM.ORG; Wed, 11 Nov 1998 11:56:30 -0500 Received: from mailgw.rational.com (mailgw.rational.com [192.232.7.78]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id LAA16666 for ; Wed, 11 Nov 1998 11:56:28 -0500 Received: from fort-ext.rational.com (fort-ext.pureatria.com [192.232.7.130]) by mailgw.rational.com (8.9.1/8.9.1/RATIONAL-mailgw) with SMTP id IAA19588 for ; Wed, 11 Nov 1998 08:56:46 -0800 (PST) Received: from mailhub.rational.com by fort-ext.rational.com via smtpd (for [192.232.7.78]) with SMTP; 11 Nov 1998 16:56:46 UT Received: from cupmail0.rational.com (cupmail0.rational.com [172.19.8.250]) by mailhub.rational.com (8.8.7/8.8.7/RATIONAL-mailhub) with ESMTP id IAA13835 for ; Wed, 11 Nov 1998 08:56:45 -0800 (PST) Received: from snips.rational.com (snips.rational.com [172.19.130.60]) by cupmail0.rational.com (8.9.1/8.8.7/RATIONAL-cupmail0) with SMTP id IAA23817 for ; Wed, 11 Nov 1998 08:56:45 -0800 (PST) Received: by snips.rational.com (SMI-8.6/SMI-SVR4) id IAA22646; Wed, 11 Nov 1998 08:56:43 -0800 Message-ID: <199811111656.IAA22646@snips.rational.com> Date: Wed, 11 Nov 1998 08:56:43 -0800 Reply-To: geb@RATIONAL.COM Sender: ACM SIGADA ASIS Technical Discussion Group From: Gary Barnes Subject: Entries and Corresponding_Declaration/_Body To: SIGADA-ASIS-TECH@ACM.ORG Content-Length: 530 Status: OR Many declarations in Ada come in pairs, eg. a function declaration and a function body. Another example is entry declarations and entry bodies. For every declaration pair except for the entry/entry-body pair the Corresponding_Declaration and Corresponding_Body interfaces provide a way to jump from one declaration to the other within a pair. It is very odd that the entry declaration and entry body pairing was left out. Was this omission intentional or accidental? ASIS 1.1.1 included this pairing with the rest. Gary From owner-sigada-asis-tech@ACM.ORG Fri Nov 13 10:39:22 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (8.8.8+Sun/SMI-SVR4) id KAA02804; Fri, 13 Nov 1998 10:39:19 -0500 (EST) 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 KAA23897 for ; Fri, 13 Nov 1998 10:39:19 -0500 (EST) Received: from mail (mail.acm.org [199.222.69.4]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id KAA43446; Fri, 13 Nov 1998 10:37:02 -0500 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 75376 for SIGADA-ASIS-TECH@ACM.ORG; Fri, 13 Nov 1998 10:37:00 -0500 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 KAA17688 for ; Fri, 13 Nov 1998 10:26:52 -0500 Received: from srcc.UUCP (uucp@localhost) by logger.gamma.ru (8.8.8/8.8.8) with UUCP id SAA24457; Fri, 13 Nov 1998 18:27:30 +0300 (MSK) (envelope-from possum!possum.srcc.msu.su!rybin@gamma.srcc.msu.su) Received: by gamma.srcc.msu.su; Fri, 13 Nov 1998 18:26:14 +0300 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Fri, 13 Nov 1998 17:10:17 +0300 References: <199811111656.IAA22646@snips.rational.com> X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Lines: 22 Message-ID: Date: Fri, 13 Nov 1998 17:10:17 +0300 Reply-To: "Sergey I. Rybin" Sender: ACM SIGADA ASIS Technical Discussion Group From: "Sergey I. Rybin" Organization: Information Systems, SRCC, MSU Subject: Re: Entries and Corresponding_Declaration/_Body Comments: To: geb@ACM.ORG To: SIGADA-ASIS-TECH@ACM.ORG Content-Length: 1189 Status: OR > Many declarations in Ada come in pairs, eg. a function declaration and a > function body. Another example is entry declarations and entry bodies. For > every declaration pair except for the entry/entry-body pair the > Corresponding_Declaration and Corresponding_Body interfaces provide a way to > jump from one declaration to the other within a pair. It is very odd that > the entry declaration and entry body pairing was left out. Was this > omission intentional or accidental? It would be quite natural to have entry-declaration/entry-body pair as appropriate/returned kind for Corresponding_Body/Corresponding_Declaration, but the problem is that we have the same An_Entry_Declaration Element for protected entries (and here this approach would work fine) and for task entries (and here this approach would not work at all, or it can work only from accept statements to entry declarations, but not the other way around: Corresponding_Body can hardly make any general sense for entry declaration in tasks. Or should we return the list of all the accept statements for a given entry? This also would be nice, but I would classify this as a secondary query... Sergey From owner-sigada-asis-tech@ACM.ORG Fri Nov 13 15:11:54 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (8.8.8+Sun/SMI-SVR4) id PAA03088; Fri, 13 Nov 1998 15:11:53 -0500 (EST) 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 PAA04244 for ; Fri, 13 Nov 1998 15:11:52 -0500 (EST) Received: from mail (mail.acm.org [199.222.69.4]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id PAA34410; Fri, 13 Nov 1998 15:09:45 -0500 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 76175 for SIGADA-ASIS-TECH@ACM.ORG; Fri, 13 Nov 1998 15:09:44 -0500 Received: from mailgw.rational.com (mailgw.rational.com [192.232.7.78]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id PAA16950 for ; Fri, 13 Nov 1998 15:09:39 -0500 Received: from fort-ext.rational.com (fort-ext.pureatria.com [192.232.7.130]) by mailgw.rational.com (8.9.1/8.9.1/RATIONAL-mailgw) with SMTP id MAA26486; Fri, 13 Nov 1998 12:10:01 -0800 (PST) Received: from mailhub.rational.com by fort-ext.rational.com via smtpd (for [192.232.7.78]) with SMTP; 13 Nov 1998 20:10:01 UT Received: from cupmail0.rational.com (cupmail0.rational.com [172.19.8.250]) by mailhub.rational.com (8.8.7/8.8.7/RATIONAL-mailhub) with ESMTP id MAA18973; Fri, 13 Nov 1998 12:10:01 -0800 (PST) Received: from loapher2.rational.com (loapher2.rational.com [172.19.130.13]) by cupmail0.rational.com (8.9.1/8.8.7/RATIONAL-cupmail0) with ESMTP id MAA20851; Fri, 13 Nov 1998 12:10:00 -0800 (PST) Received: (from geb@localhost) by loapher2.rational.com (8.8.6/) id MAA03266; Fri, 13 Nov 1998 12:09:57 -0800 (PST) Message-ID: Date: Fri, 13 Nov 1998 12:09:56 PST Reply-To: geb@RATIONAL.COM Sender: ACM SIGADA ASIS Technical Discussion Group From: "Gary E. Barnes" Subject: Re: Entries and Corresponding_Declaration/_Body Comments: To: "Sergey I. Rybin" To: SIGADA-ASIS-TECH@ACM.ORG In-Reply-To: Your message of Fri, 13 Nov 98 17:10:17 +0300 Content-Length: 3719 Status: OR > > Many declarations in Ada come in pairs, eg. a function declaration and a > > function body. Another example is entry declarations and entry bodies. For > > every declaration pair except for the entry/entry-body pair the > > Corresponding_Declaration and Corresponding_Body interfaces provide a way to > > jump from one declaration to the other within a pair. It is very odd that > > the entry declaration and entry body pairing was left out. Was this > > omission intentional or accidental? > > It would be quite natural to have entry-declaration/entry-body pair > as appropriate/returned kind for > Corresponding_Body/Corresponding_Declaration, but the problem is that > we have the same An_Entry_Declaration Element for protected entries > (and here this approach would work fine) and for task entries (and > here this approach would not work at all, or it can work only > from accept statements to entry declarations, but not the > other way around: Corresponding_Body can hardly make any general sense > for entry declaration in tasks. Or should we return the > list of all the accept statements for a given entry? This > also would be nice, but I would classify this as a secondary > query... > > Sergey > My primary concern is that in RM 9.5.2(16) it says: 16 An entry_declaration of a protected unit requires a completion, which shall be an entry_body, and every entry_body shall be the completion of an entry_declaration of a protected unit. The profile of the entry_body shall conform fully to that of the corresponding declaration. And ASIS 2.0 has no way of jumping between these two parts of this multi-part declaration. It is the only multi-part declaration that does not have a way to navigate between the parts. (ASIS 1.1.1 did have a way to do it. It was part of the functioning of the Corresponding_Specification and Corresponding_Body interfaces. So this is actually a functionality regression on the part of ASIS 2.0 and not just an an ordinary omission.) So my goal is to provide an interface that can move between these two parts of entry declarations for protected units. With that said, my proposed means of achieving that goal is to modify the descriptions for Corresponding_Declaration and Corresponding_Body. I would add An_Entry_Declaration and An_Entry_Body_Declaration to the Accepted and Returns lists. There would also need to be a sentence added about these being restricted to protected entries. Corresponding_Body already has dual-personalities. That is, when given a procedure declaration it would normally return the procedure body declaration. However if the procedure is completed with a pragma then it returns a Nil_Element instead of something non-Nil, such as the pragma. The application then has to gather the related pragmas separately and sort through them in order to tell the difference between a procedure body that is missing from the library and a procedure that was merely completed by a pragma. Similarly it returns a declaration in one set of cases and it returns a Nil in another set of cases for functions, tasks, packages, etc. I don't think it would be much of a stretch to have Corresponding_Body return an entry_body in the case of an entry_declaration that was declared in a protected unit and to have it return a Nil_Element in the case of an entry_declaration that was declared in a task declaration. In one case the Enclosing_Element of the entry_declaration is a protected declaration and in the other it is a task declaration. Corresponding_Declaration is easier. Given an entry_body it simply returns an entry_declaration (assuming the declaration is present in the library). Gary From owner-sigada-asis-tech@ACM.ORG Sat Nov 14 09:37:37 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (8.8.8+Sun/SMI-SVR4) id JAA04283; Sat, 14 Nov 1998 09:37:37 -0500 (EST) 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 JAA17327 for ; Sat, 14 Nov 1998 09:37:36 -0500 (EST) Received: from mail (mail.acm.org [199.222.69.4]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id JAA52210; Sat, 14 Nov 1998 09:35:31 -0500 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 78179 for SIGADA-ASIS-TECH@ACM.ORG; Sat, 14 Nov 1998 09:35:30 -0500 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 JAA37914 for ; Sat, 14 Nov 1998 09:25:28 -0500 Received: from srcc.UUCP (uucp@localhost) by logger.gamma.ru (8.8.8/8.8.8) with UUCP id RAA09773; Sat, 14 Nov 1998 17:26:18 +0300 (MSK) (envelope-from possum!possum.srcc.msu.su!rybin@gamma.srcc.msu.su) Received: by gamma.srcc.msu.su; Sat, 14 Nov 1998 17:25:42 +0300 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Sat, 14 Nov 1998 17:27:05 +0300 References: X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Lines: 31 Message-ID: Date: Sat, 14 Nov 1998 17:27:04 +0300 Reply-To: "Sergey I. Rybin" Sender: ACM SIGADA ASIS Technical Discussion Group From: "Sergey I. Rybin" Organization: Information Systems, SRCC, MSU Subject: Re: Entries and Corresponding_Declaration/_Body Comments: To: geb@ACM.ORG To: SIGADA-ASIS-TECH@ACM.ORG Content-Length: 1623 Status: OR > Corresponding_Body already has dual-personalities. That is, when given a > procedure declaration it would normally return the procedure body > declaration. However if the procedure is completed with a pragma then it > returns a Nil_Element instead of something non-Nil, such as the pragma. The > application then has to gather the related pragmas separately and sort > through them in order to tell the difference between a procedure body that > is missing from the library and a procedure that was merely completed by a > pragma. Would you like to have Corresponding_Body returning A_Pragma Element in case if a subprogram declaration is completed by a pragma? I would say, that this would be quite natural. Do we have the possibility for adding such a change in the ASIS Draft? > Similarly it returns a declaration in one set of cases and it returns a Nil > in another set of cases for functions, tasks, packages, etc. > > I don't think it would be much of a stretch to have Corresponding_Body > return an entry_body in the case of an entry_declaration that was declared > in a protected unit and to have it return a Nil_Element in the case of an > entry_declaration that was declared in a task declaration. In one case the > Enclosing_Element of the entry_declaration is a protected declaration and in > the other it is a task declaration. > > Corresponding_Declaration is easier. Given an entry_body it simply returns > an entry_declaration (assuming the declaration is present in the library). I completely agree with this approach for entry declarations/bodies. Sergey From owner-sigada-asis-tech@ACM.ORG Sun Nov 15 10:25:19 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (8.8.8+Sun/SMI-SVR4) id KAA05179; Sun, 15 Nov 1998 10:25:19 -0500 (EST) 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 KAA23740 for ; Sun, 15 Nov 1998 10:25:18 -0500 (EST) Received: from mail (mail.acm.org [199.222.69.4]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id KAA46312; Sun, 15 Nov 1998 10:23:31 -0500 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 82685 for SIGADA-ASIS-TECH@ACM.ORG; Sun, 15 Nov 1998 10:23:30 -0500 Received: from gw.sd.aonix.com (gw.alsys.com [136.175.17.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id KAA46288 for ; Sun, 15 Nov 1998 10:23:28 -0500 Received: from rasht.sd.aonix.com (mailhub.sd.aonix.com [136.175.1.80]) by gw.sd.aonix.com (8.9.1a/8.9.1) with SMTP id HAA14813; Sun, 15 Nov 1998 07:22:35 -0800 (PST) Received: from puumba.telesoft by rasht.sd.aonix.com (4.1/TS-1.2c) id AA20403; Sun, 15 Nov 98 07:22:17 PST Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id HAA14598; Sun, 15 Nov 1998 07:22:42 -0800 Message-ID: <199811151522.HAA14598@puumba.telesoft> Date: Sun, 15 Nov 1998 07:22:42 -0800 Reply-To: "Steve Blake @pulsar" Sender: ACM SIGADA ASIS Technical Discussion Group From: "Steve Blake @pulsar" Subject: Re: Entries and Corresponding_Declaration/_Body Comments: To: rybin@ACM.ORG To: SIGADA-ASIS-TECH@ACM.ORG Content-Length: 47 Status: OR Gary's proposed changes are OK with me. Steve From owner-sigada-asis-tech@ACM.ORG Mon Nov 16 13:03:22 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (8.8.8+Sun/SMI-SVR4) id NAA07388; Mon, 16 Nov 1998 13:03:21 -0500 (EST) 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 NAA11133 for ; Mon, 16 Nov 1998 13:03:20 -0500 (EST) Received: from mail (mail.acm.org [199.222.69.4]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id NAA28370; Mon, 16 Nov 1998 13:01:01 -0500 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 88216 for SIGADA-ASIS-TECH@ACM.ORG; Mon, 16 Nov 1998 13:01:00 -0500 Received: from mailgw.rational.com (mailgw.rational.com [192.232.7.78]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id NAA52626 for ; Mon, 16 Nov 1998 13:00:55 -0500 Received: from fort-ext.rational.com (fort-ext.pureatria.com [192.232.7.130]) by mailgw.rational.com (8.9.1/8.9.1/RATIONAL-mailgw) with SMTP id KAA11613; Mon, 16 Nov 1998 10:01:14 -0800 (PST) Received: from mailhub.rational.com by fort-ext.rational.com via smtpd (for [192.232.7.78]) with SMTP; 16 Nov 1998 18:01:14 UT Received: from cupmail0.rational.com (cupmail0.rational.com [172.19.8.250]) by mailhub.rational.com (8.8.7/8.8.7/RATIONAL-mailhub) with ESMTP id KAA06361; Mon, 16 Nov 1998 10:01:13 -0800 (PST) Received: from loapher2.rational.com (loapher2.rational.com [172.19.130.13]) by cupmail0.rational.com (8.9.1/8.8.7/RATIONAL-cupmail0) with ESMTP id KAA27032; Mon, 16 Nov 1998 10:01:13 -0800 (PST) Received: (from geb@localhost) by loapher2.rational.com (8.8.6/) id KAA13439; Mon, 16 Nov 1998 10:00:41 -0800 (PST) Message-ID: Date: Mon, 16 Nov 1998 10:00:41 PST Reply-To: geb@RATIONAL.COM Sender: ACM SIGADA ASIS Technical Discussion Group From: "Gary E. Barnes" Subject: Re: Entries and Corresponding_Declaration/_Body Comments: To: "Sergey I. Rybin" To: SIGADA-ASIS-TECH@ACM.ORG In-Reply-To: Your message of Sat, 14 Nov 98 17:27:04 +0300 Content-Length: 1332 Status: OR > > Corresponding_Body already has dual-personalities. That is, when > > given a procedure declaration it would normally return the procedure > > body declaration. However if the procedure is completed with a pragma > > then it returns a Nil_Element instead of something non-Nil, such as > > the pragma. The application then has to gather the related pragmas > > separately and sort through them in order to tell the difference > > between a procedure body that is missing from the library and a > > procedure that was merely completed by a pragma. > > Would you like to have Corresponding_Body returning A_Pragma Element in > case if a subprogram declaration is completed by a pragma? I would say, > that this would be quite natural. That's what my implementation of ASIS 1.1.1 did. It seemed to work well for customers. > Do we have the possibility for adding such a change in the ASIS Draft? I don't know. Corresponding_Constant_Declaration says "will not return a pragma completion". Corresponding_Body doesn't say anything explicit but A_Pragma is not in the Returns list. I suppose changes of this sort could be treated as Errata. I would presume the ASIS standard would be as readily changeable as the Ada95 standard. It has had a fairly constant stream of clarifications and changes. Gary