From WPRITCHE@dcscorp.com Wed Dec 31 12:48:04 1997 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id MAA03492; Wed, 31 Dec 1997 12:48:04 -0500 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 MAA12532 for ; Wed, 31 Dec 1997 12:49:18 -0500 (EST) Received: from 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 MAA51422; Wed, 31 Dec 1997 12:50:00 -0500 Received: from bp_exchange.dcscorp.com by sw-eng.falls-church.va.us (8.8.8/) id RAA23732; Wed, 31 Dec 1997 17:45:12 GMT Received: by smtp.gw.dcscorp.com with Internet Mail Service (5.0.1457.3) id ; Wed, 31 Dec 1997 12:51:01 -0500 Message-ID: <518ED0C5DB40D111BDB00060B06C73F8065947@smtp.gw.dcscorp.com> From: "Pritchett, William" To: "'asis-technical@sw-eng.falls-church.va.us'" Subject: ASIS Question Date: Wed, 31 Dec 1997 12:50:59 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Content-Length: 1260 Status: OR Consider the following code type Color_Type is ( Red, Blue, Green ); begin for Index in Color_Type'range loop null; end loop; end; I want to get to the declaration of Color_Type from the for_loop_statement. I have been able to get the Loop_Parameter_Specification by calling For_Loop_Parameter_Specification and from that I can call Specification_Subtype_Definition which gets me the "color_type'range" part. I now want to somehow get to the declaration of color_type. When I call Subtype_Mark (using ASIS-for-GNAT) I get and ASIS_Inappropriate_Element exception even though the description for the function Subtype_Mark says that A_Discrete_Subtype_Definition (which is the definition_kind for the "color_type'range" part) is an appropriate element kind. Is this an ASIS-for-GNAT bug or am I really doing something wrong? Thanks in advance, Bill Pritchett ------------------------------------------------------ | DCS Corporation | Voice: 703.683.8430 x726 | | 1330 Braddock Place | Fax: 703.836.6509 | | Alexandria, VA 22314 | mailto:wpritche@dcscorp.com | | http://www.dcscorp.com | | ------------------------------------------------------ From david.c.hoos.sr@ada95.com Wed Dec 31 13:17:37 1997 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id NAA03562; Wed, 31 Dec 1997 13:17:37 -0500 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 NAA13019 for ; Wed, 31 Dec 1997 13:18:50 -0500 (EST) Received: from 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 NAA68210; Wed, 31 Dec 1997 13:19:15 -0500 Received: from ada95.com by sw-eng.falls-church.va.us (8.8.8/) id SAA24410; Wed, 31 Dec 1997 18:14:48 GMT Received: from dhoos ([165.113.136.146]) by ada95.com (8.8.5) id LAA25443; Wed, 31 Dec 1997 11:18:08 -0700 (MST) X-Authentication-Warning: ada95.com: Host [165.113.136.146] claimed to be dhoos From: "David C. Hoos, Sr." To: "Pritchett, William" , Subject: Re: ASIS Question Date: Wed, 31 Dec 1997 12:17:53 -0600 Message-ID: <01bd1618$6919da10$928871a5@dhoos> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Content-Length: 1708 Status: OR I know this doesn't really answer your question, but what if the discrete_subtype_definition of your iteration_scheme were "Color_Type" instead of "Color_Type'range"? David C. Hoos, Sr. -----Original Message----- From: Pritchett, William To: 'asis-technical@sw-eng.falls-church.va.us' Date: Wednesday, December 31, 1997 12:02 PM Subject: ASIS Question >Consider the following code > > type Color_Type is ( Red, Blue, Green ); > > begin > for Index in Color_Type'range loop > null; > end loop; > end; > >I want to get to the declaration of Color_Type from the >for_loop_statement. I have been able to get the >Loop_Parameter_Specification by calling For_Loop_Parameter_Specification >and from that I can call Specification_Subtype_Definition which gets me >the "color_type'range" part. I now want to somehow get to the >declaration of color_type. When I call Subtype_Mark (using >ASIS-for-GNAT) I get and ASIS_Inappropriate_Element exception even >though the description for the function Subtype_Mark says that >A_Discrete_Subtype_Definition (which is the definition_kind for the >"color_type'range" part) is an appropriate element kind. Is this an >ASIS-for-GNAT bug or am I really doing something wrong? > >Thanks in advance, >Bill Pritchett > ------------------------------------------------------ >| DCS Corporation | Voice: 703.683.8430 x726 | >| 1330 Braddock Place | Fax: 703.836.6509 | >| Alexandria, VA 22314 | mailto:wpritche@dcscorp.com | >| http://www.dcscorp.com | | > ------------------------------------------------------ From rybin@possum.srcc.msu.su Thu Jan 1 18:06:15 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id SAA05159; Thu, 1 Jan 1998 18:06:14 -0500 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 SAA24536 for ; Thu, 1 Jan 1998 18:07:09 -0500 (EST) Received: from 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 GAA71912; Thu, 1 Jan 1998 06:49:45 -0500 Received: from crocus.gamma.ru by sw-eng.falls-church.va.us (8.8.8/) id LAA14847; Thu, 1 Jan 1998 11:45:20 GMT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id OAA12214; Thu, 1 Jan 1998 14:48:45 +0300 (MSK) Received: by gamma.srcc.msu.su; Thu, 1 Jan 1998 14:47:48 +0300 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Thu, 1 Jan 1998 14:48:35 +0300 To: asis-technical@sw-eng.falls-church.va.us, WPRITCHE@dcscorp.com References: <518ED0C5DB40D111BDB00060B06C73F8065947@smtp.gw.dcscorp.com> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Thu, 1 Jan 98 14:48:35 +0300 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: ASIS Question Lines: 59 Content-Length: 2171 Status: OR Bill, this time the bug is yours, but not mine :) When you get the "color_type'range" part, it is of A_Discrete_Range_Attribute_Reference kind, therefore the way to decompose it is to apply Asis.Definitions.Range_Attribute query, but not Subtype_Mark (see Asis.Definitions, --|ER and --|CR comments: --|ER---------------------------------------------------------------------------------- --|ER A_Discrete_Subtype_Definition - 3.6 --|ER A_Discrete_Range - 3.6.1 --|ER --|ER A_Discrete_Subtype_Indication --|CR --|CR Child elements returned by: --|CR function Subtype_Mark --|CR function Subtype_Constraint --|CR --|CR A_Discrete_Simple_Expression_Range --|CR --|CR Child elements returned by: --|CR function Lower_Bound --|CR function Upper_Bound --|ER --|ER---------------------------------------------------------------------------------- --|ER A_Discrete_Range_Attribute_Reference - 3.5 --|CR --|CR Child elements returned by: --|CR function Range_Attribute By the way, do you know, that now ACT suggests the full support for ASIS-for-GNAT, including providing new ASIS versions for new versions of the compiler, fixing bugs and consulting in ASIS and developing ASIS applications? Sergey Rybin > Consider the following code > > type Color_Type is ( Red, Blue, Green ); > > begin > for Index in Color_Type'range loop > null; > end loop; > end; > > I want to get to the declaration of Color_Type from the > for_loop_statement. I have been able to get the > Loop_Parameter_Specification by calling For_Loop_Parameter_Specification > and from that I can call Specification_Subtype_Definition which gets me > the "color_type'range" part. I now want to somehow get to the > declaration of color_type. When I call Subtype_Mark (using > ASIS-for-GNAT) I get and ASIS_Inappropriate_Element exception even > though the description for the function Subtype_Mark says that > A_Discrete_Subtype_Definition (which is the definition_kind for the > "color_type'range" part) is an appropriate element kind. Is this an > ASIS-for-GNAT bug or am I really doing something wrong? From rybin@possum.srcc.msu.su Thu Jan 1 18:06:16 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id SAA05161; Thu, 1 Jan 1998 18:06:15 -0500 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 SAA24558 for ; Thu, 1 Jan 1998 18:07:30 -0500 (EST) Received: from 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 GAA71708; Thu, 1 Jan 1998 06:22:44 -0500 Received: from crocus.gamma.ru by sw-eng.falls-church.va.us (8.8.8/) id LAA14351; Thu, 1 Jan 1998 11:18:06 GMT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.5/8.7.3) with UUCP id OAA11988; Thu, 1 Jan 1998 14:21:31 +0300 (MSK) Received: by gamma.srcc.msu.su; Thu, 1 Jan 1998 14:20:24 +0300 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Thu, 1 Jan 1998 14:20:07 +0300 To: ASIS-Technical@sw-eng.falls-church.va.us, WPRITCHE@dcscorp.com References: <518ED0C5DB40D111BDB00060B06C73F8065942@smtp.gw.dcscorp.com> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Thu, 1 Jan 98 14:20:07 +0300 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: ASIS Question Lines: 116 Content-Length: 4690 Status: OR Bill, > My question is this: Should a call to > ASIS.Statements.Corresponding_Called_Entity passing in the statement > corresponding to P1.Proc1( Foo ) return a Nil_Element? Yes, it should - ASIS 95 18.25 says: --------------------------------------------------------------------------------------- -- 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, > Under > ASIS-For-GNAT it returns the declaration corresponding to P1.Proc1. > Proc1 is a dispatching call and, according to the description, the > procedure Corresponding_Called_Entity should return a Nil_Element. It looks like a bug in ASIS-for-GNAT, I'll fix it. Thanks for reporting this bug :) > The > call to ASIS.Extensions.Is_Dispatching_Call (ASIS-for-GNAT extension) > returns True for this statement. I'm basically trying to determine if > an operation is potentially dispatching without using a vendor-specific > extension. ASIS 95 does not provide any query which could give you an answer in one step. So, the only way for an application is to try to compute this. The first step is to get Nil_Element as a result of Corresponding_Called_Entity/Function. Then, the application may try to analyse the called name and parameters. The next step may be to check if Corresponding_Called_Entity also returns Nil_Element for the prefix of the call (may be, some additional decomposition may be needed here). But this may be rather hard, if an ASIS implementation does not support implicitly declared predefined operations - you may have Nil_Element returned for dispatching calls and for calls to predefined operations... That's why we have Is_Dispatching_Call in ASIS-for-GNAT. (in my opinion, it looks like a hole in the ASIS functionality. Almost for sure every Ada compiler has in its internal structures used by an ASIS implementation some flag indicating if a given call is a dispatching call, so the implementation of this ASIS extension should be trivial, and the extension itself seems to be very useful. But to compute if a given call is a dispatching call using only ASIS primary queries looks like a real pain) Sergey Rybin > Consider the following code: > > package P1 is > type Obj is tagged abstract null record; > type Ref is access all Obj'class; > procedure Proc1( This : access Obj ) is abstract; > end P1; > > package P2 is > type Obj is new P1.Obj with null record; > type Ref is access all Obj'class; > procedure Proc1( This : access Obj ); > end P2; > > package P3 is > type Obj is new P1.Obj with null record; > type Ref is access all Obj'class; > procedure Proc1( This : access Obj ); > end P3; > > with P1, P2, P3; > procedure Driver; > Foo : P1.Ref := new P2.Obj; > begin > P1.Proc1( Foo ); -- P2.Proc1 called > Foo := new P3.Obj; > P1.Proc1( Foo ); -- P3.Proc1 called > end Driver; > > My question is this: Should a call to > ASIS.Statements.Corresponding_Called_Entity passing in the statement > corresponding to P1.Proc1( Foo ) return a Nil_Element? Under > ASIS-For-GNAT it returns the declaration corresponding to P1.Proc1. > Proc1 is a dispatching call and, according to the description, the > procedure Corresponding_Called_Entity should return a Nil_Element. The > call to ASIS.Extensions.Is_Dispatching_Call (ASIS-for-GNAT extension) > returns True for this statement. I'm basically trying to determine if > an operation is potentially dispatching without using a vendor-specific > extension. > > Thanks in advance, > Bill Pritchett > ------------------------------------------------------ > | DCS Corporation | Voice: 703.683.8430 x726 | > | 1330 Braddock Place | Fax: 703.836.6509 | > | Alexandria, VA 22314 | mailto:wpritche@dcscorp.com | > | http://www.dcscorp.com | | > ------------------------------------------------------ From roby Wed Jan 14 16:02:59 1998 Return-Path: Received: by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id QAA10386; Wed, 14 Jan 1998 16:02:58 -0500 From: roby (Clyde Roby) Message-Id: <199801142102.QAA10386@cronus.csed.ida.org> Subject: Re: ASIS Question To: rybin@possum.srcc.msu.su (Sergey I. Rybin) Date: Wed, 14 Jan 1998 16:02:58 -0500 (EST) Cc: roby (me), Colket@ACM.Org (Currie Colket) In-Reply-To: from "Sergey I. Rybin" at Jan 1, 98 02:20:07 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: 2132 Status: OR Sergey, In your reply sent back to Bill Pritchett, you said: > ASIS 95 does not provide any query which could give you an answer in one > step. So, the only way for an application is to try to compute this. > The first step is to get Nil_Element as a result of > Corresponding_Called_Entity/Function. Then, the application may try to > analyse the called name and parameters. The next step may be to check if > Corresponding_Called_Entity also returns Nil_Element for the prefix of the > call (may be, some additional decomposition may be needed here). But this > may be rather hard, if an ASIS implementation does not support implicitly > declared predefined operations - you may have Nil_Element returned for > dispatching calls and for calls to predefined operations... > > That's why we have Is_Dispatching_Call in ASIS-for-GNAT. (in my opinion, > it looks like a hole in the ASIS functionality. Almost for sure every > Ada compiler has in its internal structures used by an ASIS > implementation some flag indicating if a given call is a dispatching call, > so the implementation of this ASIS extension should be trivial, and > the extension itself seems to be very useful. But to compute if a given > call is a dispatching call using only ASIS primary queries looks like > a real pain) As you noted, it looks like a real pain to determine if a given call is a dispatching call using only ASIS primary queries. Should there be an Is_Dispatching_Call query in the ASIS standard, as you have implemented in ASIS-for-GNAT? Also note that there is much functionality not included in ASIS because there were discussions indicating that these could be included in a secondary layer, computed using primary ASIS queries and interfaces. Is the Is_Dispatching_Call query primitive enough to be included in the ASIS interface? Or, should it be included in the secondary layer, implemented from existing primitive ASIS interfaces as you have done? If you think it should be in the ASIS specification, this is the time to identify the interface. Such a call can easily be added to Clause 17 (Asis.Expressions). Clyde and Currie From rybin@possum.srcc.msu.su Thu Jan 15 02:09:29 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id CAA11109; Thu, 15 Jan 1998 02:09:28 -0500 Received: from crocus.gamma.ru (crocus.gamma.ru [193.124.255.1]) by cs.ida.org (8.8.7/8.8.7) with ESMTP id CAA22082 for ; Thu, 15 Jan 1998 02:10:34 -0500 (EST) Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.8.7/8.7.3) with UUCP id KAA05421; Thu, 15 Jan 1998 10:10:20 +0300 (MSK) Received: by gamma.srcc.msu.su; Thu, 15 Jan 1998 10:09:04 +0300 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Thu, 15 Jan 1998 10:09:06 +0300 To: roby@ida.org, rybin@possum.srcc.msu.su Cc: Colket@ACM.Org References: <199801142102.QAA10386@cronus.csed.ida.org> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Thu, 15 Jan 98 10:09:06 +0300 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: ASIS Question Lines: 60 Content-Length: 2717 Status: OR > Also note that there is much functionality not included in ASIS > because there were discussions indicating that these could be included > in a secondary layer, computed using primary ASIS queries and > interfaces. There are two important questions conserning this issue we still do not have answers for: 1. Is a given secondary query of primary importance for many of the (potential) real-life applications? 2. Is it really hard (and/or expensive) to implement a given secondary query as a combination of primary ASIS queries comparing with its implementation directly from the internal compiler data structures ised by an ASIS implementation? If both answers are "yes", the given query is a real candidat for including into a set of primary ASIS queries. But we do not really have these answers for most of the potential secondary queries - we just have not got enough experience yet, or the experience which has already been obtained exists as some local knowlege in separate groups of ASIS application developers. As for Is_Dispatching_Call, we realised, that this query was of primary importance for gnatelim (the tool which eliminates the unused subprograms in a whole program), and that it was a real pain to implement it as a secondary query, whereas its implementation on the base of the GNAT tree is trivial - just reading the corresponding flag. The situation is very similar for many queries from the ASIS-for-GNAT package Asis.Extensions - these queries look like secondary (and may be implemented as secondary), but in fact they are implemented just in the same way as primary queries - they traverse the GNAT tree without using ASIS primary queries. > Is the Is_Dispatching_Call query primitive enough to be included in > the ASIS interface? Or, should it be included in the secondary layer, > implemented from existing primitive ASIS interfaces as you have done? > If you think it should be in the ASIS specification, this is the time > to identify the interface. Such a call can easily be added to Clause > 17 (Asis.Expressions). I would add it to Asis.Exceptions, but not because of its primitivity - for sure, formally it is _not_ a primitive query, but because of the reasons described above - this query: 1. is very important in practice; 2. is relatively hard to implement as a "pure" secondary query; 3. for most of the Ada compilers should be implementable in one step from the internal compuler data structures But this way of moving secondary queries into ASIS is really dangerous - we do not really have any well-defined formal rules to make a decision... Sorry for this long discussion instead of a shord and clear answer :( :) Sergey From colket@colket.org Fri Jan 16 11:51:24 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id LAA14724; Fri, 16 Jan 1998 11:51:22 -0500 Received: from smtp2.erols.com (smtp2.erols.com [205.252.116.102]) by cs.ida.org (8.8.7/8.8.7) with ESMTP id LAA24551 for ; Fri, 16 Jan 1998 11:52:37 -0500 (EST) Received: from default (spg-tnt18s202.erols.com [207.172.52.202]) by smtp2.erols.com (8.8.8/8.8.5) with SMTP id LAA27274; Fri, 16 Jan 1998 11:49:28 -0500 (EST) Message-ID: <34BF8F01.65DB@colket.org> Date: Fri, 16 Jan 1998 11:46:57 -0500 From: Currie Colket Reply-To: colket@colket.org X-Mailer: Mozilla 3.01C-KIT (Win95; I) MIME-Version: 1.0 To: "Sergey I. Rybin" CC: roby@ida.org, Colket@ACM.Org Subject: Re: ASIS Question References: <199801142102.QAA10386@cronus.csed.ida.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3208 Status: OR Sergey, Thank you for your advise. I like the idea of including such queries into the ASIS specification. But at this time, there is danger in that it could adversely affect the standardization process by opening up the Pandora's Box for many other secondary queries. I will ponder your advice over the weekend. Thank you again for your detailed answer. v/r Currie > > > Also note that there is much functionality not included in ASIS > > because there were discussions indicating that these could be included > > in a secondary layer, computed using primary ASIS queries and > > interfaces. > > There are two important questions conserning this issue we still do > not have answers for: > > 1. Is a given secondary query of primary importance for many of the > (potential) real-life applications? > > 2. Is it really hard (and/or expensive) to implement a given secondary > query as a combination of primary ASIS queries comparing with its > implementation directly from the internal compiler data structures > ised by an ASIS implementation? > > If both answers are "yes", the given query is a real candidat for > including into a set of primary ASIS queries. > > But we do not really have these answers for most of the potential > secondary queries - we just have not got enough experience yet, or > the experience which has already been obtained exists as some local > knowlege in separate groups of ASIS application developers. > > As for Is_Dispatching_Call, we realised, that this query was of primary > importance for gnatelim (the tool which eliminates the unused > subprograms in a whole program), and that it was a real pain > to implement it as a secondary query, whereas its implementation > on the base of the GNAT tree is trivial - just reading the > corresponding flag. > > The situation is very similar for many queries from the ASIS-for-GNAT > package Asis.Extensions - these queries look like secondary (and > may be implemented as secondary), but in fact they are implemented > just in the same way as primary queries - they traverse the GNAT > tree without using ASIS primary queries. > > > Is the Is_Dispatching_Call query primitive enough to be included in > > the ASIS interface? Or, should it be included in the secondary layer, > > implemented from existing primitive ASIS interfaces as you have done? > > If you think it should be in the ASIS specification, this is the time > > to identify the interface. Such a call can easily be added to Clause > > 17 (Asis.Expressions). > > I would add it to Asis.Exceptions, but not because of its primitivity - > for sure, formally it is _not_ a primitive query, but because of > the reasons described above - this query: > > 1. is very important in practice; > 2. is relatively hard to implement as a "pure" secondary query; > 3. for most of the Ada compilers should be implementable in one step > from the internal compuler data structures > > But this way of moving secondary queries into ASIS is really dangerous - > we do not really have any well-defined formal rules to make a decision... > > Sorry for this long discussion instead of a shord and clear answer :( :) > > Sergey From roby Thu Feb 12 14:53:01 1998 Return-Path: Received: by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id OAA21704; Thu, 12 Feb 1998 14:52:59 -0500 From: roby (Clyde Roby) Message-Id: <199802121952.OAA21704@cronus.csed.ida.org> Subject: Re: ASIS Question To: rybin@possum.srcc.msu.su (Sergey I. Rybin) Date: Thu, 12 Feb 1998 14:52:59 -0500 (EST) Cc: roby (Clyde Roby), Colket@ACM.Org (Currie Colket) In-Reply-To: from "Sergey I. Rybin" at Jan 15, 98 10:09:06 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3642 Status: OR Sergey, Thank you for your discussion (see below). We are seriously considering including comments for the ASIS standardization ballot which would allow additional queries such as Is_Dispatching_Call. Are there any other queries besides Is_Dispatching_Call which you believe should be included in the ASIS interface? Since we don't have a current copy of the ASIS-for-GNAT package Asis.Extensions, can you provide us a copy of this package with the queries than are contained in it? Should all of these queries be included in the ASIS interface; or, should only some of them be included? In your write-up below, you indicated that you would add Is_Dispatching_Call to Asis.Exceptions. Do you really mean Asis.Expressions? It seems very inappropriate to put this query in Asis.Exceptions. Clyde and Currie > > Also note that there is much functionality not included in ASIS > > because there were discussions indicating that these could be included > > in a secondary layer, computed using primary ASIS queries and > > interfaces. > > There are two important questions conserning this issue we still do > not have answers for: > > 1. Is a given secondary query of primary importance for many of the > (potential) real-life applications? > > 2. Is it really hard (and/or expensive) to implement a given secondary > query as a combination of primary ASIS queries comparing with its > implementation directly from the internal compiler data structures > ised by an ASIS implementation? > > If both answers are "yes", the given query is a real candidat for > including into a set of primary ASIS queries. > > But we do not really have these answers for most of the potential > secondary queries - we just have not got enough experience yet, or > the experience which has already been obtained exists as some local > knowlege in separate groups of ASIS application developers. > > As for Is_Dispatching_Call, we realised, that this query was of primary > importance for gnatelim (the tool which eliminates the unused > subprograms in a whole program), and that it was a real pain > to implement it as a secondary query, whereas its implementation > on the base of the GNAT tree is trivial - just reading the > corresponding flag. > > The situation is very similar for many queries from the ASIS-for-GNAT > package Asis.Extensions - these queries look like secondary (and > may be implemented as secondary), but in fact they are implemented > just in the same way as primary queries - they traverse the GNAT > tree without using ASIS primary queries. > > > Is the Is_Dispatching_Call query primitive enough to be included in > > the ASIS interface? Or, should it be included in the secondary layer, > > implemented from existing primitive ASIS interfaces as you have done? > > If you think it should be in the ASIS specification, this is the time > > to identify the interface. Such a call can easily be added to Clause > > 17 (Asis.Expressions). > > I would add it to Asis.Exceptions, but not because of its primitivity - > for sure, formally it is _not_ a primitive query, but because of > the reasons described above - this query: > > 1. is very important in practice; > 2. is relatively hard to implement as a "pure" secondary query; > 3. for most of the Ada compilers should be implementable in one step > from the internal compuler data structures > > But this way of moving secondary queries into ASIS is really dangerous - > we do not really have any well-defined formal rules to make a decision... > > Sorry for this long discussion instead of a shord and clear answer :( :) From rybin@gnat.com Fri Feb 13 10:56:17 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id KAA24616; Fri, 13 Feb 1998 10:56:16 -0500 Received: from lglsun11.epfl.ch (root@lglsun11.epfl.ch [128.178.76.29]) by cs.ida.org (8.8.7/8.8.7) with ESMTP id KAA18201 for ; Fri, 13 Feb 1998 10:57:32 -0500 (EST) Received: from lglsun4.epfl.ch (lglsun4 [128.178.76.9]) by lglsun11.epfl.ch (8.8.X/EPFL-8.1a) with ESMTP id QAA12703; Fri, 13 Feb 1998 16:57:08 +0100 (MET) Received: from lglsun4 (localhost [127.0.0.1]) by lglsun4.epfl.ch (8.8.X/EPFL-8.1a) with SMTP id QAA04180; Fri, 13 Feb 1998 16:56:37 +0100 (MET) Sender: rybin@lglsun11.epfl.ch Message-ID: <34E46D17.55D1@gnat.com> Date: Fri, 13 Feb 1998 16:56:07 +0100 From: Sergey Rybin Organization: Ada Core Technologies X-Mailer: Mozilla 3.04Gold (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Clyde Roby CC: "Sergey I. Rybin" , Currie Colket Subject: Re: ASIS Question References: <199802121952.OAA21704@cronus.csed.ida.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 12319 Status: OR Clyde Roby wrote: > Are there any other queries besides Is_Dispatching_Call which > you believe should be included in the ASIS interface? I'm not sure... Unfortunately, we do not have enough feedback... I think, Is_Dispatching_Call definitely should be added, but I would not add any other qury till somebody would provide enough justification for that. > Since we don't have a current copy of the ASIS-for-GNAT > package Asis.Extensions, can you provide us a copy of this package > with the queries than are contained in it? The spec is appended. > Should all of these > queries be included in the ASIS interface; or, should only some of > them be included? See above - I think, this spec is now no more as a subject for possible discussions, but NOT a sughgestion to add something to the ASIS definition > > In your write-up below, you indicated that you would add > Is_Dispatching_Call to Asis.Exceptions. Do you really mean > Asis.Expressions? It seems very inappropriate to put this query in > Asis.Exceptions. Of course, Asis.Exceptions was a misprint, sorry about that. I'm not sure, that Expressions is the right place - Is_Dispatching_Call may also be applied to a procedure call, so Asis.Statements has just the same rights to contain this query. May be, Asis.Elements can be used as a compromise? Sergey ------------------------------------------------------------------------------ -- -- -- ASIS-for-GNAT IMPLEMENTATION COMPONENTS -- -- -- -- A S I S . E X T E N S I O N S -- -- -- -- S p e c -- -- -- -- Copyright (c) 1995-1997, Free Software Foundation, Inc. -- -- -- -- ASIS-for-GNAT is free software; you can redistribute it and/or modify it -- -- under terms of the GNU General Public License as published by the Free -- -- Software Foundation; either version 2, or (at your option) any later -- -- version. ASIS-for-GNAT is distributed in the hope that it will be use- -- -- ful, but WITHOUT ANY WARRANTY; without even the implied warranty of MER- -- -- CHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General -- -- Public License for more details. You should have received a copy of the -- -- GNU General Public License distributed with ASIS-for-GNAT; see file -- -- COPYING. If not, write to the Free Software Foundation, 59 Temple Place -- -- - Suite 330, Boston, MA 02111-1307, USA. -- -- -- -- As a special exception, if other files instantiate generics from this -- -- unit, or you link this unit with other files to produce an executable, -- -- this unit does not by itself cause the resulting executable to be -- -- covered by the GNU General Public License. This exception does not -- -- however invalidate any other reasons why the executable file might be -- -- covered by the GNU Public License. -- -- -- -- ASIS-for-GNAT was originally developed by the ASIS-for-GNAT team at the -- -- Software Engineering Laboratory of the Swiss Federal Institute of -- -- Technology (LGL-EPFL) in Lausanne, Switzerland, in cooperation with the -- -- Scientific Research Computer Center of Moscow State University (SRCC -- -- MSU), Russia, with funding partially provided by grants from the Swiss -- -- National Science Foundation and the Swiss Academy of Engineering -- -- Sciences. ASIS-for-GNAT is now maintained by Ada Core Technologies Inc -- -- (http://www.gnat.com). -- -- -- ------------------------------------------------------------------------------ -- This package contains some ASIS extensions which are neede by the ASIS -- implementation for GNAT itself, or which are considered to be useful for -- ASIS applications. -- -- Most of these extensions may be implemented as secondary ASIS queries, -- but we oftenly use some optimization based on direct traversing of the -- GNAT tree and obtaining the needed semantic information from it. -- In this package we follow the GNAT, but not ASIS coding and -- documentation style, but for some queries we use the ASIS-style lists -- of Appropriate, Expected and returned kinds. package Asis.Extensions is -------------------- -- Test functions -- -------------------- function Is_Dispatching_Call (Call : Asis.Element) return Boolean; -- Checks if its argument as a dispatching call. Returns False for -- a non-dispatching call and for any unexpected argument -- -- Expected Element_Kinds: -- A_Function_Call -- A_Procedure_Call_Statement function Is_Dispatching_Operation (Declaration : Asis.Element) return Boolean; -- Checks if its argument is a declaration of a dispatching subprogram. -- Returns False for a declaration of a non-dispatching subprogram -- and for any unexpected argument -- -- Expected Element_Kinds: -- A_Procedure_Declaration -- A_Function_Declaration -- A_Procedure_Renaming_Declaration -- A_Function_Renaming_Declaration function Acts_As_Spec (Declaration : Asis.Element) return Boolean; -- Checks if its argument is a subprogram body declaration for which no -- separate subprogram declaration exists. Returns False for any -- unexpected argument -- -- Expected Element_Kinds: -- A_Procedure_Body_Declaration -- A_Function_Body_Declaration -- A_Procedure_Body_Stub -- A_Function_Body_Stub function Is_Renaming_As_Body (Declaration : Asis.Element) return Boolean; -- Checks if its argument is a reanming-as-body declaration. -- Returns False for any unexpected argument. -- -- Expected Element_Kinds: -- A_Procedure_Renaning_Declaration -- A_Function_Renaming_Declaration --------------------------------------- -- End of the test functions section -- --------------------------------------- ----------------------------------------------------- -- Modified versions of the "primary" ASIS queries -- ----------------------------------------------------- -- this section contains the modified versions of the queries defined -- in the standard ASIS packages. The names of these modified versions -- may or may not be the same as in the "core" ASIS ----------------------- -- Asis.Declarations -- ----------------------- function Formal_Subprogram_Default (Declaration : in Asis.Generic_Formal_Parameter) return Asis.Expression; -- This is a modified version of the Formal_Subprogram_Default query -- adjusted for using in the implementation of -- Asis.Elements.Traverse_Element generic procedure. As that ASIS query, -- it returns the name appearing after the reserved word IS in the -- given generic for A_Name_Default Element, but if its argument is -- of another kind from Default_Kinds, it returns Nil_Element instead -- of raising Asis_Inappropriate_Element. -- -- Appropriate Declaration_Kinds: -- A_Formal_Function_Declaration -- A_Formal_Procedure_Declaration -- -- Returns Element_Kinds: -- An_Expression ---------------------- -- Asis.Expressions -- ---------------------- function Corresponding_Called_Function_Unwinded (Expression : in Asis.Expression) return Asis.Declaration; -- This is the modification of -- Asis.Expressions.Corresponding_Called_Function which unwinds all -- the renamings in case if the function name in the argument -- function call is defined by a renaming declaration. This -- function returns the declaration of the called function *entity*. -- -- 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 --------------------- -- Asis.Statements -- --------------------- function Corresponding_Called_Entity_Unwinded (Statement : in Asis.Statement) return Asis.Declaration; -- This is the modification of -- Asis.Statements.Corresponding_Called_Entity which unwinds all -- the renamings in case if the procedure or entry name in the argument -- call is defined by a renaming declaration. This function returns -- the declaration of the callable *entity*. -- -- 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 ---------------------------------------------------------------------- -- End of section "Modified versions of the "primary" ASIS queries" -- ---------------------------------------------------------------------- --------------------------------------- -- Extensions of ASIS functionality -- --------------------------------------- ------------------------------------- -- Extensions to Asis.Declarations -- ------------------------------------- -- function Corresponding_Overriden_Declaration -- (Declaration : Asis.Declaration) -- return Asis.Declaration; -- -- If Declaration overrides any primitive operation of a type, returns the -- -- overriden declaration (implicit or explicit). -- -- -- -- Returns Nil_Element if applied to an implicit declaration or when -- -- an argument does not override any declaration, or if Declaration is -- -- a subprogram body declaration for which an explicit separate -- -- specification presents -- -- -- -- The current implementation limitation is that Nil_Element is also -- -- returned in case of overridding of a predefined operator -- -- -- -- ??? How renaming-as-declaration should be processed??? -- -- -- -- Appropriate Declaration_Kinds -- -- A_Procedure_Declaration -- -- A_Function_Declaration -- -- A_Procedure_Body_Declaration -- -- A_Function_Body_Declaration -- -- A_Procedure_Renaming_Declaration -- -- A_Function_Renaming_Declaration -- -- A_Procedure_Body_Stub -- -- A_Function_Body_Stub -- -- A_Procedure_Instantiation -- -- A_Function_Instantiation -- -- -- -- Returns Declaration_Kinds -------------------------------- -- General_Purpose Extensions -- -------------------------------- function Get_Last_Component (E : Asis.Element) return Asis.Element; -- Returns the right-most direct component of its argument. Returns -- Nil_Element if its argument has no components. It is an error to -- call this functon for Nil_Element function Components (E : Asis.Element) return Asis.Element_List; -- Returns the list of all the first-level components of its argument. -- Nil_Element is returned for a terminal component. The implementation -- of this function is not very effective - we do not use any dynamic -- element lists, we simply compute the components twice - first time -- to get to know the overall number of components, and second -- time to fill in the result Element_List end Asis.Extensions; From roby Mon Apr 6 17:11:40 1998 Return-Path: Received: by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id RAA28454; Mon, 6 Apr 1998 17:11:38 -0400 From: roby (Clyde Roby) Message-Id: <199804062111.RAA28454@cronus.csed.ida.org> Subject: Issue #091, additional OOP interfaces To: SBlake@Aonix.Com (Steve Blake), Rybin@GNAT.Com (Sergey Rybin) Date: Mon, 6 Apr 1998 17:11:38 -0400 (EDT) Cc: Colket@ACM.Org (Currie Colket at ACM), roby (Clyde Roby) X-Mailer: ELM [version 2.5 PL0b2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 7077 Status: OR Steve and Sergey, Please find enclosed new function calls for Issue 091, "Add additional OOP interfaces to ASIS." The four new interfaces are: -- 17.30 function Corresponding_Called_Function_Unwound -- 17.41 function Is_Dispatching_Operation -- 18.26 function Corresponding_Called_Entity_Unwound -- 18.43 function Is_Dispatching_Call It is the intent that existing clauses 17.30 - 17.39 would be renumbered as 17.31 - 17.40 and existing clauses 18.26 - 18.41 would be renumbered as 18.27 - 18.42. Is_Dispatching_Operation would be placed at the end of Clause 17; Is_Dispatching_Call would be placed at the end of Clause 18. Please look over these new functions and identify any needed changes. You will need to look closely at Corresponding_Called_Function (Clause 17.29) and Corresponding_Called_Entity (Clause 18.25). These queries are largely based on Sergey's ASIS for GNAT implementation. After these queries have your blessing, we will circulate them to asis-technical for comment. Thank you! V/r Clyde and Currie --------------------------------------------------------------------------------------- -- 17.30 function Corresponding_Called_Function_Unwound --------------------------------------------------------------------------------------- function Corresponding_Called_Function_Unwound (Expression : in Asis.Expression) return Asis.Declaration; --------------------------------------------------------------------------------------- -- Expression - Specifies the Expression to query. -- -- This function recursively unwinds renamings to return the declaration that -- defines the first declaration of this called function. -- -- This is similar to Asis.Expressions.Corresponding_Called_Function but unwinds all -- the renamings to return the declaration that defines the first declaration of this -- 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. -- -- If function_prefix denotes an attribute_reference, and if the corresponding -- attribute is (re)defined by an attribute definition clause, an implementation -- is encouraged, but not required, to return the definition of the corresponding -- subprogram whose 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 an 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_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. -- --------------------------------------------------------------------------------------- -- 17.41 function Is_Dispatching_Operation --------------------------------------------------------------------------------------- function Is_Dispatching_Operation (Declaration : Asis.Element) return Boolean; --------------------------------------------------------------------------------------- -- Declaration - Specifies the declaration to query. -- -- Function checks if its argument is a declaration of a dispatching subprogram. -- -- Returns True for a declaration of a dispatching subprogram. -- -- Returns False for a declaration of a non-dispatching subprogram -- and for any unexpected argument. -- -- Expected Element_Kinds: -- A_Procedure_Declaration -- A_Function_Declaration -- A_Procedure_Renaming_Declaration -- A_Function_Renaming_Declaration -- --------------------------------------------------------------------------------------- -- 18.26 function Corresponding_Called_Entity_Unwound --------------------------------------------------------------------------------------- function Corresponding_Called_Entity_Unwound (Statement : in Asis.Statement) return Asis.Declaration; --------------------------------------------------------------------------------------- -- Statement - Specifies the procedure_call_statement or -- entry_call_statement to query -- -- This function recursively unwinds renamings to return the first declaration -- of the procedure or entry denoted by the call. -- -- This is similar to Asis.Statements.Corresponding_Called_Entity but unwinds all -- the renamings to return the declaration that defines the first 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 an attribute definition clause, an implementation -- is encouraged, but not required, to return the definition of the corresponding -- subprogram whose 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 an 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_Instantiation -- A_Formal_Procedure_Declaration -- An_Entry_Declaration -- A_Generic_Procedure_Declaration -- --------------------------------------------------------------------------------------- -- 18.43 function Is_Dispatching_Call --------------------------------------------------------------------------------------- function Is_Dispatching_Call (Call : Asis.Element) return Boolean; --------------------------------------------------------------------------------------- -- Element - Specifies the element to query. -- -- This function checks if its argument as a dispatching call. -- -- Returns True for a dispatching call. -- -- Returns False for a non-dispatching call and for any unexpected argument. -- -- Expected Element_Kinds: -- A_Function_Call -- A_Procedure_Call_Statement -- From sblake@sd.aonix.com Tue Apr 14 13:44:39 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id NAA14631; Tue, 14 Apr 1998 13:44: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 NAA23406 for ; Tue, 14 Apr 1998 13:45:56 -0400 (EDT) Received: from rasht.sd.aonix.com (mailhub.alsys.com) by gw.sd.aonix.com (4.1/SMI-4.1.1) id AA02719; Tue, 14 Apr 98 10:44:19 PDT Received: from puumba.telesoft by rasht.sd.aonix.com (4.1/TS-1.2c) id AA06824; Tue, 14 Apr 98 10:42:00 PDT Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id KAA20586; Tue, 14 Apr 1998 10:41:58 -0700 Date: Tue, 14 Apr 1998 10:41:58 -0700 From: sblake@sd.aonix.com (Steve Blake @pulsar) Message-Id: <199804141741.KAA20586@puumba.telesoft> To: Rybin@GNAT.Com, SBlake@aonix.com, roby@ida.org Subject: Re: Issue #091, additional OOP interfaces Cc: Colket@ACM.Org Content-Length: 4826 Status: OR Here are some questions and comments. Steve >From roby@ida.org Mon Apr 6 14:15:23 1998 >Subject: Issue #091, additional OOP interfaces >To: SBlake@aonix.com (Steve Blake), Rybin@GNAT.Com (Sergey Rybin) >Cc: Colket@ACM.Org (Currie Colket at ACM), roby@ida.org (Clyde Roby) >Mime-Version: 1.0 >Content-Transfer-Encoding: 7bit > >Steve and Sergey, > >Please find enclosed new function calls for Issue 091, "Add additional >OOP interfaces to ASIS." > >The four new interfaces are: > >-- 17.30 function Corresponding_Called_Function_Unwound >-- 17.41 function Is_Dispatching_Operation >-- 18.26 function Corresponding_Called_Entity_Unwound >-- 18.43 function Is_Dispatching_Call > > >It is the intent that existing clauses 17.30 - 17.39 would be >renumbered as 17.31 - 17.40 and existing clauses 18.26 - 18.41 would >be renumbered as 18.27 - 18.42. Is_Dispatching_Operation would be >placed at the end of Clause 17; Is_Dispatching_Call would be placed at >the end of Clause 18. > >Please look over these new functions and identify any needed >changes. You will need to look closely at >Corresponding_Called_Function (Clause 17.29) and >Corresponding_Called_Entity (Clause 18.25). > >These queries are largely based on Sergey's ASIS for GNAT >implementation. > >After these queries have your blessing, we will circulate them to >asis-technical for comment. Thank you! > >V/r >Clyde and Currie Regarding: -- 17.30 function Corresponding_Called_Function_Unwound -- 18.26 function Corresponding_Called_Entity_Unwound I'm not sure I understand why these have anything to do with OOP. As I see them, they are just secondary queries implemented (simplistically) like this: Func_Dec := Corresponding_Called_Function(The_Call); if Func_Dec is a renaming declaration then return Corresponding_Name_Declaration(Corresponding_Base_Entity(Func_Dec); else return Func_Dec; end if; Are we really adding OOP value here? Do we really need these? Regarding: -- 17.41 function Is_Dispatching_Operation This is pretty clear: True for primitive subprograms of a tagged type. 3.9.2. I think the comments for the query should use this terminology. -- 18.43 function Is_Dispatching_Call Does this distinguish between a dispatching call and a call on a dispatching operation? I think it should, in which case there should be another query: -- function Is_Call_On_Dispatching_Operation Is_Dispatching_Call is only true if the controlling tag is dynamically determined (3.9.2(1)). Is_Call_On_Dispatching_Operation is true if the call name or prefix denotes the declaration of a primitive operation of a tagged type. --------------------------------------------------------------------------------------- -- 17.41 function Is_Dispatching_Operation --------------------------------------------------------------------------------------- function Is_Dispatching_Operation (Declaration : Asis.Element) return Boolean; --------------------------------------------------------------------------------------- -- Declaration - Specifies the declaration to query. -- -- Returns True if the declaration is a primitive subprogram of a tagged type. -- -- Returns False for any unexpected argument. -- -- Expected Element_Kinds: -- A_Procedure_Declaration -- A_Function_Declaration -- A_Procedure_Renaming_Declaration -- A_Function_Renaming_Declaration -- What about generics and instantiations? --------------------------------------------------------------------------------------- -- 18.43 function Is_Dispatching_Call --------------------------------------------------------------------------------------- function Is_Dispatching_Call (Call : Asis.Element) return Boolean; --------------------------------------------------------------------------------------- -- Call - Specifies the element to query. -- -- Returns True if the controlling tag of Call is dynamically determined. -- -- Returns False for any unexpected Element. -- -- Expected Element_Kinds: -- A_Function_Call -- A_Procedure_Call_Statement --------------------------------------------------------------------------------------- -- ??.?? function Is_Dispatching_Call --------------------------------------------------------------------------------------- function Is_Call_On_Dispatching_Operation (Call : Asis.Element) return Boolean; --------------------------------------------------------------------------------------- -- Call - Specifies the element to query. -- -- Returns True if the name or prefix of Call denotes the declaration of a -- primitive operation of a tagged type. -- -- Returns False for any unexpected Element. -- -- Expected Element_Kinds: -- A_Function_Call -- A_Procedure_Call_Statement From sblake@sd.aonix.com Mon Apr 13 19:13:01 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id TAA12283; Mon, 13 Apr 1998 19:13:01 -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 TAA06508 for ; Mon, 13 Apr 1998 19:14:18 -0400 (EDT) Received: from rasht.sd.aonix.com (mailhub.alsys.com) by gw.sd.aonix.com (4.1/SMI-4.1.1) id AA09857; Mon, 13 Apr 98 16:12:37 PDT Received: from puumba.telesoft by rasht.sd.aonix.com (4.1/TS-1.2c) id AA25555; Mon, 13 Apr 98 16:10:19 PDT Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id QAA10025; Mon, 13 Apr 1998 16:10:18 -0700 Date: Mon, 13 Apr 1998 16:10:18 -0700 From: sblake@sd.aonix.com (Steve Blake @pulsar) Message-Id: <199804132310.QAA10025@puumba.telesoft> To: Rybin@GNAT.Com, SBlake@aonix.com, roby@ida.org Subject: Re: Issue #091, additional OOP interfaces Cc: Colket@ACM.Org Content-Length: 184 Status: ORr Folks, Please don't let my silence the past vacation week be construed as my approval. I have some questions and comments I'll forward ASAP. I just did not get to it today... Steve From roby@cronus.csed.ida.org Tue Apr 14 07:05:50 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id HAA12792; Tue, 14 Apr 1998 07:05:49 -0400 Received: from cronus.csed.ida.org (cronus.csed.ida.org [129.246.83.36]) by cs.ida.org (8.8.7/8.8.7) with SMTP id HAA12320; Tue, 14 Apr 1998 07:07:04 -0400 (EDT) Received: by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id HAA12789; Tue, 14 Apr 1998 07:05:43 -0400 From: roby@cronus.csed.ida.org (Clyde Roby) Message-Id: <199804141105.HAA12789@cronus.csed.ida.org> Subject: Re: Issue #091, additional OOP interfaces To: sblake@sd.aonix.com (Steve Blake @pulsar) Date: Tue, 14 Apr 1998 07:05:43 -0400 (EDT) Cc: Rybin@GNAT.Com, SBlake@aonix.com, roby@ida.org, Colket@ACM.Org In-Reply-To: <199804132310.QAA10025@puumba.telesoft> from "Steve Blake @pulsar" at Apr 13, 1998 04:10:18 PM X-Mailer: ELM [version 2.5 PL0b2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 307 Status: OR Steve, > Please don't let my silence the past vacation week be construed as my approval. > I have some questions and comments I'll forward ASAP. I just did not get > to it today... We figured something like that. We'll be looking forward to your inputs. Hope your vacation was an enjoyable one! Clyde From colket@colket.org Sun May 10 21:41:29 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id VAA03304; Sun, 10 May 1998 21:41:29 -0400 Received: from smtp2.erols.com (smtp2.erols.com [207.172.3.235]) by cs.ida.org (8.8.7/8.8.7) with ESMTP id VAA18545 for ; Sun, 10 May 1998 21:42:51 -0400 (EDT) Received: from colket.org (207-172-41-159.s159.tnt10.brd.erols.com [207.172.41.159]) by smtp2.erols.com (8.8.8/8.8.5) with ESMTP id VAA23183; Sun, 10 May 1998 21:42:49 -0400 (EDT) Message-ID: <35565784.C4FE6085@colket.org> Date: Sun, 10 May 1998 21:42:28 -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 , Clyde Roby Subject: Issue #091 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3376 Status: OR Dear asis-technical, Attached is Issue #091 with a proposed resolution of ACCEPT and the proposed solution. The solution was developed with input from Sergey Rybin and Steve Blake. This solution will be made part of the ASIS DIS if there are no negative comments addressed to asis-technical by 15 May. Please send concerns to the asis-technical mailing list with Issue #091 in the subject line. v/r Currie Colket !ASIS Issue #091 !topic Add additional OOP interfaces to ASIS !reference ASIS 95-17 and 18 !from Bill Pritchett !keywords dispatching operations OO object-oriented !discussion Add Is_Dispatching_Operation and Corresponding_Called_Function_Unwound to Clause 17 (package Asis.Expressions). Add Is_Dispatching_Call and Corresponding_Called_Entity_Unwound to Clause 18 (package Asis.Statements). These are necessary to support OOP queries. !resolution Accept, with Modification. !date 98-05-06 !Notes Functions Corresponding_Called_Function_Unwound and Corresponding_Called_Entity_Unwound have nothing to do with OOP; they are best implemented as secondary queries. The following three interfaces were added to ASIS 2.0.Q to support OOP: --------------------------------------------------------------------------------------- -- 17.40 function Is_Dispatching_Operation --------------------------------------------------------------------------------------- function Is_Dispatching_Operation (Declaration : in Asis.Element) return Boolean; --------------------------------------------------------------------------------------- -- Declaration - Specifies the declaration to query. -- -- Returns True if the declaration is a primitive subprogram of a tagged type. -- -- Returns False for any unexpected argument. -- -- Expected Element_Kinds: -- A_Procedure_Declaration -- A_Function_Declaration -- A_Procedure_Renaming_Declaration -- A_Function_Renaming_Declaration -- --------------------------------------------------------------------------------------- -- 18.42 function Is_Dispatching_Call --------------------------------------------------------------------------------------- function Is_Dispatching_Call (Call : in Asis.Element) return Boolean; --------------------------------------------------------------------------------------- -- Call - Specifies the element to query. -- -- Returns True if the controlling tag of Call is dynamically determined. -- -- Returns False for any unexpected Element. -- -- Expected Element_Kinds: -- A_Function_Call -- A_Procedure_Call_Statement --------------------------------------------------------------------------------------- -- 18.43 function Is_Call_On_Dispatching_Operation --------------------------------------------------------------------------------------- function Is_Call_On_Dispatching_Operation (Call : in Asis.Element) return Boolean; --------------------------------------------------------------------------------------- -- Call - Specifies the element to query. -- -- Returns True if the name or prefix of Call denotes the declaration of a -- primitive operation of a tagged type. -- -- Returns False for any unexpected Element. -- -- Expected Element_Kinds: -- A_Function_Call -- A_Procedure_Call_Statement From dan@flash.irvine.com Mon May 11 15:19:38 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA04111; Mon, 11 May 1998 15:19:38 -0400 Received: from irvine.com (flash.irvine.com [192.160.8.4]) by cs.ida.org (8.8.7/8.8.7) with SMTP id PAA07305 for ; Mon, 11 May 1998 15:20:58 -0400 (EDT) Received: from flash.irvine.com by flash.irvine.com id aa20959; 11 May 98 12:19 PDT To: colket@colket.org cc: ASIS-Technical@ns1.sw-eng.falls-church.va.us, roby@ida.org, ClydeRoby@acm.org, dan@flash.irvine.com Subject: Re: Issue #091 Date: Mon, 11 May 1998 12:19:06 PDT From: Dan Eilers Message-ID: <9805111219.aa20959@flash.irvine.com> Content-Length: 693 Status: OR > -- 17.40 function Is_Dispatching_Operation > -- Returns True if the declaration is a primitive subprogram of a tagged > -- type > -- 18.42 function Is_Dispatching_Call > -- Returns True if the controlling tag of Call is dynamically determined. > -- 18.43 function Is_Call_On_Dispatching_Operation > -- Returns True if the name or prefix of Call denotes the declaration of > -- a primitive operation of a tagged type. I think the commentary for these function should consider the possibility that pragma restrictions(no_dispatch) and similar compiler optimizations can cause primitive subprograms to be implemented with non-dispatching calls. -- Dan Eilers From sblake@sd.aonix.com Tue May 12 15:32:43 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id PAA07609; Tue, 12 May 1998 15:32:42 -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 PAA05210 for ; Tue, 12 May 1998 15:34:03 -0400 (EDT) Received: from rasht.sd.aonix.com (mailhub.alsys.com) by gw.sd.aonix.com (4.1/SMI-4.1.1) id AA19625; Tue, 12 May 98 11:58:39 PDT Received: from puumba.telesoft by rasht.sd.aonix.com (4.1/TS-1.2c) id AA28299; Tue, 12 May 98 11:55:58 PDT Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id LAA06803; Tue, 12 May 1998 11:55:43 -0700 Date: Tue, 12 May 1998 11:55:43 -0700 From: sblake@sd.aonix.com (Steve Blake @pulsar) Message-Id: <199805121855.LAA06803@puumba.telesoft> To: colket@colket.org, dan@flash.irvine.com Subject: Re: Issue #091 Cc: ASIS-Technical@ns1.sw-eng.falls-church.va.us, ClydeRoby@ACM.Org, roby@ida.org Content-Length: 1783 Status: OR >From dan@flash.irvine.com Mon May 11 12:26:16 1998 >To: colket@colket.org >Cc: ASIS-Technical@ns1.sw-eng.falls-church.va.us, roby@ida.org, > ClydeRoby@ACM.Org, dan@flash.irvine.com >Subject: Re: Issue #091 > > >> -- 17.40 function Is_Dispatching_Operation >> -- Returns True if the declaration is a primitive subprogram of a tagged >> -- type > >> -- 18.42 function Is_Dispatching_Call >> -- Returns True if the controlling tag of Call is dynamically determined. > > >> -- 18.43 function Is_Call_On_Dispatching_Operation >> -- Returns True if the name or prefix of Call denotes the declaration of >> -- a primitive operation of a tagged type. > >I think the commentary for these function should consider the possibility >that pragma restrictions(no_dispatch) and similar compiler optimizations >can cause primitive subprograms to be implemented with non-dispatching calls. > > -- Dan Eilers This is a good point that I think just need clarification. I believe only -- 18.42 function Is_Dispatching_Call would be affected. Certainly if an optimization affects whether or not a call will dispatch, then we want this reflected in the result of the query. I suggest we add something to that effect. I'm not sure how pragma restrictions(no_dispatch) needs to be involved in the commentary. If it is obeyed, then occurrences of T'Class are not allowed and thus Is_Dispatching_Call would always just return False. We could add something about this also. But neither this pragma nor optimizations it seems would have an affect on Is_Dispatching_Operation or Is_Call_On_Dispatching_Operation; a primitive subprogram of a tagged type is defined to be a dispatching operation regardless of whether calls to it dispatch or not. Steve From cooper@longshot.ds.boeing.com Wed May 13 16:30:47 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id QAA10318; Wed, 13 May 1998 16:30:47 -0400 Received: from mailgate2.boeing.com (mailgate2.boeing.com [199.238.248.100]) by cs.ida.org (8.8.7/8.8.7) with ESMTP id QAA06582 for ; Wed, 13 May 1998 16:32:07 -0400 (EDT) Received: from splinter.boeing.com ([130.42.28.12]) by mailgate2.boeing.com (8.8.5/8.8.5) with ESMTP id NAA11759; Wed, 13 May 1998 13:31:57 -0700 (PDT) Received: from longshot.ds.boeing.com by splinter.boeing.com with ESMTP (1.37.109.16/16.2) id AA124751518; Wed, 13 May 1998 13:31:58 -0700 Received: (from cooper@localhost) by longshot.ds.boeing.com (SMI-8.6/RDS-1.0) id NAA00563; Wed, 13 May 1998 13:31:54 -0700 Date: Wed, 13 May 1998 13:31:54 -0700 From: cooper@longshot.ds.boeing.com (C. Daniel Cooper) Message-Id: <199805132031.NAA00563@longshot.ds.boeing.com> To: Colket@ACM.org Subject: Re: Issue #091 Cc: Roby@ida.org X-Sun-Charset: US-ASCII Content-Length: 1445 Status: OR Currie, > !ASIS Issue #091 > !topic Add additional OOP interfaces to ASIS > !reference ASIS 95-17 and 18 > !from Bill Pritchett > !keywords dispatching operations OO object-oriented > !discussion > > Add Is_Dispatching_Operation and Corresponding_Called_Function_Unwound > to Clause 17 (package Asis.Expressions). Add Is_Dispatching_Call and > Corresponding_Called_Entity_Unwound to Clause 18 (package > Asis.Statements). These are necessary to support OOP queries. > > !resolution Accept, with Modification. > !date 98-05-06 > !Notes > > Functions Corresponding_Called_Function_Unwound and > Corresponding_Called_Entity_Unwound have nothing to do with OOP; they > are best implemented as secondary queries. The following three > interfaces were added to ASIS 2.0.Q to support OOP: When you were here, I read the above too hastily. I agree with your modified proposal, plus the additional commentary suggested by Dan Eilers and Steve Blake. What I wanted to point out was that your 3 proposed queries not only support OOP but also help with performance analysis in general (even more justification). The 2 you've omitted are indeed best implemented as secondaries. -- C. Daniel Cooper =========v=======================v Engineer at Software | All opinions are mine | 206-655-3519 | and may not represent | CDaniel.Cooper@Boeing.com | those of my employer. | ==========================^=======================^ From colket@colket.org Tue May 19 13:13:24 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id NAA08084; Tue, 19 May 1998 13:13:24 -0400 Received: from smtp3.erols.com (smtp3.erols.com [207.172.3.236]) by cs.ida.org (8.8.7/8.8.7) with ESMTP id NAA00056 for ; Tue, 19 May 1998 13:14:48 -0400 (EDT) Received: from colket.org (207-172-44-196.s196.tnt3.brd.erols.com [207.172.44.196]) by smtp3.erols.com (8.8.8/8.8.5) with ESMTP id NAA25725; Tue, 19 May 1998 13:14:42 -0400 (EDT) Message-ID: <3561BDE8.75164713@colket.org> Date: Tue, 19 May 1998 13:14:16 -0400 From: Currie Colket Reply-To: colket@colket.org X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: "C. Daniel Cooper" CC: Colket@acm.org, Roby@ida.org Subject: Re: Issue #091 References: <199805132031.NAA00563@longshot.ds.boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1599 Status: OR Dan: > Currie, > > > !ASIS Issue #091 > > !topic Add additional OOP interfaces to ASIS > > !reference ASIS 95-17 and 18 > > !from Bill Pritchett > > !keywords dispatching operations OO object-oriented > > !discussion > > > > Add Is_Dispatching_Operation and Corresponding_Called_Function_Unwound > > to Clause 17 (package Asis.Expressions). Add Is_Dispatching_Call and > > Corresponding_Called_Entity_Unwound to Clause 18 (package > > Asis.Statements). These are necessary to support OOP queries. > > > > !resolution Accept, with Modification. > > !date 98-05-06 > > !Notes > > > > Functions Corresponding_Called_Function_Unwound and > > Corresponding_Called_Entity_Unwound have nothing to do with OOP; they > > are best implemented as secondary queries. The following three > > interfaces were added to ASIS 2.0.Q to support OOP: > > When you were here, I read the above too hastily. I agree with your > modified proposal, plus the additional commentary suggested by Dan > Eilers and Steve Blake. What I wanted to point out was that your 3 > proposed queries not only support OOP but also help with performance > analysis in general (even more justification). The 2 you've omitted > are indeed best implemented as secondaries. It was great to see you again! I am glad you concur with the proposed solutions. I would prefer not going back to add the other two functions at this time. Hopefully I will have a section for you to look at by COB today (or early tomorrow) for the write-up on the notional ASIS application. v/r Currie P.S. Thank you for your comments on the ABL meeting. From colket@colket.org Wed May 27 01:09:42 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id BAA21953; Wed, 27 May 1998 01:09:42 -0400 Received: from smtp2.erols.com (smtp2.erols.com [207.172.3.235]) by cs.ida.org (8.8.7/8.8.7) with ESMTP id BAA26659 for ; Wed, 27 May 1998 01:11:07 -0400 (EDT) Received: from colket.org (207-172-45-96.s96.tnt5.brd.erols.com [207.172.45.96]) by smtp2.erols.com (8.8.8/8.8.5) with ESMTP id BAA00919; Wed, 27 May 1998 01:10:26 -0400 (EDT) Message-ID: <356BA022.1746AADE@colket.org> Date: Wed, 27 May 1998 01:09:54 -0400 From: Currie Colket Reply-To: colket@colket.org X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Dan Eilers , ASIS Technical CC: roby@ida.org Subject: Issue #095 (was Re: Please Review ASIS 20Q) References: <9805221743.aa02647@flash.irvine.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1627 Status: OR Dear ASIS Technical: Dan Eilers raises two excellent points which I have separated into 2 separate emails, the first on I#091 and the second on I#095. This email is for I#095: Dan Eilers wrote: > > I#091 reflects Dan Eiler's concern when pragma Restrictions(No_Dispatch) > > applies. > > The commentary for this issue still needs clarification: > > # function Is_Dispatching_Call (Call : in Asis.Element) return Boolean; > # > #------------------------------------------------------------------------ > #-- Call - Specifies the element to query. > #-- > #-- Returns True if the controlling tag of Call is dynamically determined. > #-- > #-- This function shall always return False when > #-- pragma Restrictions(No_Dispatch) applies. > > Does "dynamically determined" refer to a determination by a compiler? > If so, what should a stand-alone ASIS implementation return for this query? > > What is meant by "pragma Restrictions(No_Dispatch) applies"? > Does this mean that the pragma simply exists in the source code? > Or does it mean that a compiler took advantage of the pragma to > statically determine the tag? > > What should an ASIS implementation return in the absence of > this pragma, but in the presence of a compiler optimization > that statically determines the tag, based on noticing a lack > of any references to T'Class. You raise some interesting issues pertaining to a stand-alone ASIS implementation. I would be interested in seeing alternative proposals to address your concerns. Perhaps you would like to propose a solution that is clearer? Discussion from ASIS-technical is requested. v/r Currie From eachus@mitre.org Wed May 27 09:55:42 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id JAA22534; Wed, 27 May 1998 09:55:41 -0400 Received: from mail.acm.org (mail.acm.org [199.222.69.4]) by cs.ida.org (8.8.7/8.8.7) with ESMTP id JAA03087 for ; Wed, 27 May 1998 09:57:06 -0400 (EDT) Received: from ns1.sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id JAA46790; Wed, 27 May 1998 09:50:20 -0400 Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with ESMTP id JAA24171 for ; Wed, 27 May 1998 09:35:25 -0400 (EDT) Received: from spectre.mitre.org (spectre.mitre.org [129.83.61.124]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with ESMTP id JAA21698; Wed, 27 May 1998 09:38:27 -0400 (EDT) Received: from blofeld (blofeld.mitre.org [129.83.41.77]) by spectre.mitre.org (8.8.5/8.8.5) with SMTP id JAA06865; Wed, 27 May 1998 09:38:26 -0400 (EDT) Message-Id: <3.0.1.32.19980527094151.00c2f980@spectre.mitre.org> X-Sender: eachus@spectre.mitre.org X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 27 May 1998 09:41:51 -0400 To: ASIS-Technical@ns1.sw-eng.falls-church.va.us From: "Robert I. Eachus" Subject: Re: Issue #095 (was Re: Please Review ASIS 20Q) Cc: Dan Eilers In-Reply-To: <356BA022.1746AADE@colket.org> References: <9805221743.aa02647@flash.irvine.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Length: 3208 Status: OR This is clearly an Ada language issue, and should be easy to resolve. >Dan Eilers wrote: >> # function Is_Dispatching_Call (Call : in Asis.Element) return Boolean; >> # >> #------------------------------------------------------------------------ >> #-- Call - Specifies the element to query. >> #-- >> #-- Returns True if the controlling tag of Call is dynamically determined. >> #-- >> #-- This function shall always return False when >> #-- pragma Restrictions(No_Dispatch) applies. If pragma Restrictions(No_Dispatch) applies, then "Occurances of T'Class are not allowed for any (tagged) subtype T." RM H.4(19). Implementors should be able to treat this requirement as a comment. If 'Class does not appear in the program/partition, then dispatching cannot occur. >> Does "dynamically determined" refer to a determination by a compiler? >> If so, what should a stand-alone ASIS implementation return for this query? Not a compiler determined trait at all. Dynamically determined refers, I would hope, to RM 3.9.2(5): "The name or expression is dynamically tagged if it is of a class-wide type, or it is a call with a controlling result and at least one dynamically tagged controlling operand." (You also need to read 3.9.2(7) which determines when type conversions and actual parameters are dynamically tagged.) So this is language defined and (relatively) easy to determine. It is more difficult to determine whether a particular _tag_indeterminate_ 3.9.2(6) construct is dispatching. For some functions, overload resolution at the point of the call will decide whether dispatching is or is not required. That resolution uses the rules at 3.9.2(8 and9). But a conforming ASIS implementation must be able to do overload resolution, so each instance of a call on a tag indeterminate function can be determined by language rules to be dynamically or statically dispatching. >> What is meant by "pragma Restrictions(No_Dispatch) applies"? >> Does this mean that the pragma simply exists in the source code? >> Or does it mean that a compiler took advantage of the pragma to >> statically determine the tag? As indicated above, the compiler should reject any unit containing 'Class if pragma Restrictions(No_Dispatch) is in force. There are no cases where you have to determine whether or not a tag is static--there is no dispatching, not just there is no dynamic dispatching. >> What should an ASIS implementation return in the absence of >> this pragma, but in the presence of a compiler optimization >> that statically determines the tag, based on noticing a lack >> of any references to T'Class. Uh, this is not an optimization, the tag IS static. But note that you have to be pretty wide ranging in that hunt for T'Class. You can have a subtype of a class wide type, or a class wide type can be the actual corresponding to a generic formal type. Pragma Restrictions(No_Dispatch) allows you (Dan as an implementor) to eliminate dispatching tables, since they can never be used. Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... From dan@flash.irvine.com Wed May 27 19:41:17 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id TAA01509; Wed, 27 May 1998 19:41:16 -0400 Received: from mail.acm.org (mail.acm.org [199.222.69.4]) by cs.ida.org (8.8.7/8.8.7) with ESMTP id TAA18432 for ; Wed, 27 May 1998 19:42:42 -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 TAA1844910; Wed, 27 May 1998 19:35:44 -0400 Received: from irvine.com (flash.irvine.com [192.160.8.4]) by ns1.sw-eng.falls-church.va.us (8.8.8/8.8.8) with SMTP id TAA12088 for ; Wed, 27 May 1998 19:35:16 -0400 (EDT) Received: from flash.irvine.com by flash.irvine.com id aa09920; 27 May 98 16:37 PDT To: eachus@MITRE.Org cc: ASIS-Technical@ns1.sw-eng.falls-church.va.us, dan@flash.irvine.com Subject: Re: Issue #095 (was Re: Please Review ASIS 20Q) Date: Wed, 27 May 1998 16:37:46 PDT From: Dan Eilers Message-ID: <9805271637.aa09920@flash.irvine.com> Content-Length: 662 Status: OR Robert Eachus wrote: >> Does "dynamically determined" refer to a determination by a compiler? >> If so, what should a stand-alone ASIS implementation return for this query? > This is clearly an Ada language issue, and should be easy to resolve. ... > Not a compiler determined trait at all. Dynamically determined refers, > I would hope, to RM 3.9.2(5): "The name or expression is dynamically ... Thanks, the RM reference clears things up that these are language-defined terms, not compiler implementation issues, and consequently there is no need to worry about stand-alone ASIS implementations or even pragma restrictions(no_dispatch). -- Dan From dan@flash.irvine.com Fri May 22 20:43:17 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id UAA16965; Fri, 22 May 1998 20:43:17 -0400 Received: from irvine.com (flash.irvine.com [192.160.8.4]) by cs.ida.org (8.8.7/8.8.7) with SMTP id UAA07967 for ; Fri, 22 May 1998 20:44:41 -0400 (EDT) Received: from flash.irvine.com by flash.irvine.com id aa02647; 22 May 98 17:43 PDT To: colket@colket.org cc: ASIS-Technical@ns1.sw-eng.falls-church.va.us, roby@ida.org, dan@flash.irvine.com Subject: Re: Please Review ASIS 20Q Date: Fri, 22 May 1998 17:43:46 PDT From: Dan Eilers Message-ID: <9805221743.aa02647@flash.irvine.com> Content-Length: 1514 Status: OR > The asis20q980521.doc contains all the updates from the ISO Balloting > process. In addition, the following Editorial Comments and Technical > Issues have been incorporated: > >... > I#095 Semantic queries for multi-part declarations S. Rybin I am surprised to see that I#095 was incorporated, since the email discussion has not reached any sort of consensus, as far as I can tell. > I#091 reflects Dan Eiler's concern when pragma Restrictions(No_Dispatch) > applies. The commentary for this issue still needs clarification: # function Is_Dispatching_Call (Call : in Asis.Element) return Boolean; # #------------------------------------------------------------------------ #-- Call - Specifies the element to query. #-- #-- Returns True if the controlling tag of Call is dynamically determined. #-- #-- This function shall always return False when #-- pragma Restrictions(No_Dispatch) applies. Does "dynamically determined" refer to a determination by a compiler? If so, what should a stand-alone ASIS implementation return for this query? What is meant by "pragma Restrictions(No_Dispatch) applies"? Does this mean that the pragma simply exists in the source code? Or does it mean that a compiler took advantage of the pragma to statically determine the tag? What should an ASIS implementation return in the absence of this pragma, but in the presence of a compiler optimization that statically determines the tag, based on noticing a lack of any references to T'Class. -- Dan Eilers