From owner-sigada-asis-tech@ACM.ORG Wed Dec 9 15:43:27 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (8.8.8+Sun/SMI-SVR4) id PAA06915; Wed, 9 Dec 1998 15:43:23 -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 PAA10337 for ; Wed, 9 Dec 1998 15:43:22 -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 PAA14690; Wed, 9 Dec 1998 15:43:02 -0500 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8d) with spool id 136270 for SIGADA-ASIS-TECH@ACM.ORG; Wed, 9 Dec 1998 15:43:01 -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 PAA21830 for ; Wed, 9 Dec 1998 15:42:57 -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 MAA12598 for ; Wed, 9 Dec 1998 12:42:26 -0800 (PST) Received: from mailhub.rational.com by fort-ext.rational.com via smtpd (for [192.232.7.78]) with SMTP; 9 Dec 1998 20:42:26 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 MAA24615 for ; Wed, 9 Dec 1998 12:42:25 -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 MAA11098; Wed, 9 Dec 1998 12:42:24 -0800 (PST) Received: (from geb@localhost) by loapher2.rational.com (8.8.6/) id MAA15987; Wed, 9 Dec 1998 12:42:23 -0800 (PST) Message-ID: <199812092042.MAA15987@loapher2.rational.com> Date: Wed, 9 Dec 1998 12:42:23 -0800 Reply-To: geb@RATIONAL.COM Sender: ACM SIGADA ASIS Technical Discussion Group From: Gary Barnes Subject: generic child units of generic parents, traversal questions To: SIGADA-ASIS-TECH@ACM.ORG Content-Length: 5807 Status: OR An interesting question for Enclosing_Element... Imagine a generic parent unit and a generic child unit. generic generic type Tp is (<>) type Tc is (<>); package Parent is package Parent.Child is end Parent; end Parent.Child; And an instance of that parent plus a WITH of the instance and a WITH of the child. package Instance is with Instance; new Parent (Integer); with Parent.Child; package Usage is generic package Aha renames Instance.Child; --<<==here end Usage; Let's say that an ASIS application traverses the Usage unit down to the renames reference to the Child identifier. And then it uses Asis.Expressions.Name_Declaration to jump to the implicit declaration of the Child interface that lurks within the Instance instantiation. This implicit declaration of Child is one that exists (or perhaps, "can be named") only in a context where a) there is an instantiation of the parent generic unit visible and b) the child generic unit is also visible. It is an implicit declaration. So therefore I suppose there will be ASIS implementations that don't implement it (or won't allow access to it, or whatever). They can stop reading at this point. For the ASIS implementations that do have it or that implement it... When the ASIS appliciation takes the A_Generic_Declaration element corresponding to that implicit Child generic declaration and passes it to Enclosing_Element, what is the result? There is no literal piece of text that caused the implicit Child to spring into existence so there is no obviousls correct answer. I can imagine at least three possibilities, 1) The result is the declaration for Usage. It is the context that allowed the implicit declaration to exist (or to be nameable). 2) The result is the declaration for Instance. It is the instantiation from which the implicit declaration can be named. It is also the instantiation of the parent that would determine those things that a Child instantation would inherit from its Parent instantiation. 3) The result is the declaration of Parent.Child itself. (1) would be workable. It would not always return A_Declaration---imagine the parent being instantiated in a declare/begin/end. The context would be the block and not some specific A_Declaration element. (2) could be useful. In order to predict the full properties of a Child instance it is necessary to know the associated Parent instance and this might be the only method of determining that instance short of an exhaustive search of the context. (Imagine an application that arrived at the implicit Child by calling Corresponding_Generic_Element for an element from an instantiation of Child. The application would not know ahead of time that it was working with a generic child of a generic parent.) (3) would be workable, but the application might be able to get the same information by invoking Corresponding_Generic_Element or something on the name of the Child (see the next topic). I tend to think that (2) would be the most useful to applications. This is the one level child case. There are also two level, three level, four level, ... cases to consider. (2) seems overall to be the most interesting. But, are there other candidates? ============================================================================== And here is a related interesting question for Corresponding_Generic_Element and for Is_Part_Of_Instance... The implicit Child declaration, is it Is_Part_Of_Instance? It is not a literal textual component of the Parent unit. However, it exists and is nameable only due to the existance of the Instance and it is named as if it were a subcomponent of the instance. So is it part of an instance for the purposes of Is_Part_Of_Instance? The obvious answer would seem to be No, but that might not be the best answer, see below. How does an ASIS application traverse from an implicit Child declaration to the actual Child generic declaration? This is an example of a multi-part declaration that I don't believe is presently covered by ASIS. There can be any number of implicit Child declarations in the library. We need to jump from one implicitly declared generic spec to the corresponding identical explicitly declared generic spec. One possibility that comes to mind is the Corresponding_Generic_Element interface. The implicit Child declaration acts as if it is part of the Instance instantiation. It exists because the Instance exists and it inherits generic formal values from the Instance just as if it were actually part of the Instance. If Corresponding_Generic_Element is invoked on a name from within the implicit Child declaration (either the name of the Child itself or the name of some subcomponent), what is the result? If the result is the corresponding element from the original Child generic declaration then the traversal problem is solved. But that then also needs to reflect back to the answer for the Is_Part_Of_Instance question for the implicit Child. It would then be appropriate to answer Is_Part_Of_Instance as Yes. Or, answer Is_Part_Of_Instance No and add implicit generic Child declarations to the list of things taken care of by a call to Corresponding_Declaration. Call it with the implicit generic declaration and it can return the explicit generic. Although, given that it is more customary for that interface to jump from explicit instance to implicit declaration, having it jump from implicit declaration to explicit declaration might seem odd. Other candidates? Gary From owner-sigada-asis-tech@ACM.ORG Thu Dec 10 13:09:48 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (8.8.8+Sun/SMI-SVR4) id NAA08553; Thu, 10 Dec 1998 13:09:47 -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 NAA02676 for ; Thu, 10 Dec 1998 13:09:46 -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 NAA37472; Thu, 10 Dec 1998 13:09:29 -0500 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8d) with spool id 139358 for SIGADA-ASIS-TECH@ACM.ORG; Thu, 10 Dec 1998 13:09:27 -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 NAA38198 for ; Thu, 10 Dec 1998 13:09:25 -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 KAA19131; Thu, 10 Dec 1998 10:07:41 -0800 (PST) Received: from puumba.telesoft by rasht.sd.aonix.com (4.1/TS-1.2c) id AA16873; Thu, 10 Dec 98 10:07:03 PST Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id KAA10755; Thu, 10 Dec 1998 10:07:23 -0800 Message-ID: <199812101807.KAA10755@puumba.telesoft> Date: Thu, 10 Dec 1998 10:07:23 -0800 Reply-To: "Steve Blake @pulsar" Sender: ACM SIGADA ASIS Technical Discussion Group From: "Steve Blake @pulsar" Subject: Re: generic child units of generic parents, traversal questions Comments: To: geb@ACM.ORG To: SIGADA-ASIS-TECH@ACM.ORG Content-Length: 7030 Status: OR >From owner-sigada-asis-tech@ACM.ORG Wed Dec 9 12:58:24 1998 >Subject: generic child units of generic parents, traversal questions >To: SIGADA-ASIS-TECH@ACM.ORG Indeed... > >An interesting question for Enclosing_Element... > >Imagine a generic parent unit and a generic child unit. > > generic generic > type Tp is (<>) type Tc is (<>); > package Parent is package Parent.Child is > end Parent; end Parent.Child; > >And an instance of that parent plus a WITH of the instance and a WITH of the >child. > > package Instance is with Instance; > new Parent (Integer); with Parent.Child; > package Usage is > generic package Aha > renames Instance.Child; --<<==here > end Usage; > >Let's say that an ASIS application traverses the Usage unit down to the >renames reference to the Child identifier. And then it uses >Asis.Expressions.Name_Declaration to jump to the implicit declaration of the >Child interface that lurks within the Instance instantiation. > >This implicit declaration of Child is one that exists (or perhaps, "can be >named") only in a context where a) there is an instantiation of the parent >generic unit visible and b) the child generic unit is also visible. > >It is an implicit declaration. So therefore I suppose there will be ASIS >implementations that don't implement it (or won't allow access to it, or >whatever). They can stop reading at this point. > >For the ASIS implementations that do have it or that implement it... When >the ASIS appliciation takes the A_Generic_Declaration element corresponding >to that implicit Child generic declaration and passes it to >Enclosing_Element, what is the result? There is no literal piece of text >that caused the implicit Child to spring into existence so there is no >obviousls correct answer. > >I can imagine at least three possibilities, > >1) The result is the declaration for Usage. It is the context that allowed > the implicit declaration to exist (or to be nameable). > >2) The result is the declaration for Instance. It is the instantiation > from which the implicit declaration can be named. It is also the > instantiation of the parent that would determine those things that a Child > instantation would inherit from its Parent instantiation. > >3) The result is the declaration of Parent.Child itself. > > >(1) would be workable. It would not always return A_Declaration---imagine >the parent being instantiated in a declare/begin/end. The context would be >the block and not some specific A_Declaration element. > >(2) could be useful. In order to predict the full properties of a Child >instance it is necessary to know the associated Parent instance and this >might be the only method of determining that instance short of an exhaustive >search of the context. (Imagine an application that arrived at the implicit >Child by calling Corresponding_Generic_Element for an element from an >instantiation of Child. The application would not know ahead of time that >it was working with a generic child of a generic parent.) > >(3) would be workable, but the application might be able to get the same >information by invoking Corresponding_Generic_Element or something on the >name of the Child (see the next topic). > >I tend to think that (2) would be the most useful to applications. >This is the one level child case. There are also two level, three level, four >level, ... cases to consider. (2) seems overall to be the most interesting. > >But, are there other candidates? > A 4th possibility would be to return a Nil_Element since the original explicit child generic declaration can be only at the library level, the implicit declaration could be considered library level also, especially if the instantiation is at the library level. Enclosing_Element of library level declaration elements is Nil_Element. If the instance is nested (not lib level) then the 2nd possibility seems the most reasonable and useful to me. The name of the implicit child generic declaration is "instance_name.child" so it should be easy for applications to get to the parent instance. In situations like this, I'd rather see a clear dead end (Nil_ELement) than a variety of semantically different choices for ASIS implementations. If an implementation chooses to return a non-nil element then the 2nd choice gets my vote. >============================================================================== > >And here is a related interesting question for Corresponding_Generic_Element >and for Is_Part_Of_Instance... > >The implicit Child declaration, is it Is_Part_Of_Instance? It is not a >literal textual component of the Parent unit. However, it exists and is >nameable only due to the existance of the Instance and it is named as if it >were a subcomponent of the instance. So is it part of an instance for the >purposes of Is_Part_Of_Instance? The obvious answer would seem to be No, >but that might not be the best answer, see below. > I agree that it should not be Is_Part_Of_Instance. >How does an ASIS application traverse from an implicit Child declaration to >the actual Child generic declaration? This is an example of a multi-part >declaration that I don't believe is presently covered by ASIS. There can be >any number of implicit Child declarations in the library. > >We need to jump from one implicitly declared generic spec to the >corresponding identical explicitly declared generic spec. One possibility >that comes to mind is the Corresponding_Generic_Element interface. > >The implicit Child declaration acts as if it is part of the Instance >instantiation. It exists because the Instance exists and it inherits >generic formal values from the Instance just as if it were actually part of >the Instance. If Corresponding_Generic_Element is invoked on a name from >within the implicit Child declaration (either the name of the Child itself >or the name of some subcomponent), what is the result? If the result is the >corresponding element from the original Child generic declaration then the >traversal problem is solved. But that then also needs to reflect back to >the answer for the Is_Part_Of_Instance question for the implicit Child. It >would then be appropriate to answer Is_Part_Of_Instance as Yes. > >Or, answer Is_Part_Of_Instance No and add implicit generic Child >declarations to the list of things taken care of by a call to >Corresponding_Declaration. Call it with the implicit generic declaration >and it can return the explicit generic. Although, given that it is more >customary for that interface to jump from explicit instance to implicit >declaration, having it jump from implicit declaration to explicit >declaration might seem odd. > This is my preference. Steve >Other candidates? > > Gary > From sblake@sd.aonix.com Thu Dec 17 17:10:57 1998 Return-Path: Received: from cs.ida.org by cronus.csed.ida.org (8.8.8+Sun/SMI-SVR4) id RAA23061; Thu, 17 Dec 1998 17:10:56 -0500 (EST) Received: from gw.sd.aonix.com (gw.sd.aonix.com [136.175.17.2]) by cs.ida.org (8.8.7/8.8.7) with ESMTP id RAA25394 for ; Thu, 17 Dec 1998 17:10:55 -0500 (EST) 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 OAA02714 for ; Thu, 17 Dec 1998 14:09:39 -0800 (PST) Received: from puumba.telesoft by rasht.sd.aonix.com (4.1/TS-1.2c) id AA03143; Thu, 17 Dec 98 14:08:57 PST Received: by puumba.telesoft (SMI-8.6/SMI-SVR4) id OAA25031; Thu, 17 Dec 1998 14:09:21 -0800 Date: Thu, 17 Dec 1998 14:09:21 -0800 From: sblake@sd.aonix.com (Steve Blake @pulsar) Message-Id: <199812172209.OAA25031@puumba.telesoft> To: roby@ida.org Subject: mods from Gary Content-Length: 2487 Status: OR ============================================================================== Enclosing_Element - What should it return when given the A_Declaration corresponding to the implicit redeclaration of a child generic for an instantiated parent generic? RM 10.1.1(19) Says "..., there is a corresponding declaration nested immediately within each instance of the parent." If we follow that then the Enclosing_Element of the implicit generic child must be the implicit generic instance of the instantiated parent. Since the RM literally states the location of the implicit child I don't see that we have any real choice. This is a place that neither one of us had put up as a candidate. I see all of the candidates as about equally hard to implement. Here's how I would phrase it. You'd probably want to change it to make it fit within the exact phraseology patterns of the standard. -- Returns the expanded generic specification template from the parent -- generic instantiation corresponding to any implicit generic child unit -- specification given as an argment, see Reference Manual 10.1.1(19). ============================================================================== Is_Part_Of_Instance - The implicit child would be Is_Part_Of_Implicit but not Is_Part_Of_Instance. -- Returns False for any implicit generic child unit specifications or -- their subcomponents, see Reference Manual 10.1.1(19). ============================================================================== Is_Part_Of_Implicit - The implicit child would be Is_Part_Of_Implicit. -- Returns True for any implicit generic child unit specifications or -- their subcomponents, see Reference Manual 10.1.1(19). ============================================================================== Corresponding_Declaration - When given the A_Declaration of the implicit child generic redeclaration it would return the A_Declaration specification of the child itself. -- Returns the declaration of the generic child unit corresponding to -- an implicit generic child unit specification, see Reference Manual -- 10.1.1(19). Corresponding_Body - Returns Nil_Element or returns the body of the child? Probably Nil_Element. -- Returns Nil_Element for an implicit generic child unit specification, -- see Reference Manual 10.1.1(19). ============================================================================== I think that's all of the parts. Gary