From JGPB@jbinfo.demon.co.uk Wed Jun 19 06:54:22 1996 Return-Path: Date: Wed, 19 Jun 1996 10:51:18 GMT From: JGPB@jbinfo.demon.co.uk (John Barnes) Reply-To: JGPB@jbinfo.demon.co.uk To: asis-technical@sw-eng.falls-church.va.us Cc: jgpb@jbinfo.demon.co.uk Subject: example in draft Lines: 21 Content-Length: 745 X-Lines: 21 Status: RO There seems to be a serious error in the example on pages viii to xx of the fragment of the draft (1996-06-01) distributed at the ISO meeting last week. It only has a with clause for Asis. It needs with clauses for lots of other things as well such as ASIS_Elements_Kinds and the child packages of Asis such as Asis.Elements. It is good to check such visible examples through a compiler. The question of whether it is good practice to mix a hierarchy of packages and a flat structure in the one standrad also needs to be considered. It might be better if everything were in Asis or a child of Asis. Of course, Asis could be empty apart from its children which is the case with some packages in 95 such as Ada.Characters. -- John Barnes From rybin@alex.srcc.msu.su Mon Aug 26 04:02:10 1996 Return-Path: Received: from ida.org by csed-115.csed.ida.org (SMI-8.6/SMI-SVR4) id EAA10831; Mon, 26 Aug 1996 04:02:07 -0400 Received: from crocus.gamma.ru by ida.org (4.1/SMI-4.1) id AA04025; Mon, 26 Aug 96 04:01:39 EDT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.7.5/8.7.3) with UUCP id LAA10356; Mon, 26 Aug 1996 11:51:38 +0400 (MSD) Received: by gamma.srcc.msu.su; Mon, 26 Aug 1996 11:50:43 +0400 Received: by vadik.srcc.msu.su; Mon, 26 Aug 1996 11:36:56 +0400 Received: by alex.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Mon, 26 Aug 1996 11:45:36 +0400 To: ASIS-Officers@sw-eng.falls-church.va.us, roby@ida.org Cc: Colket@SMTP-GW.SPAWAR.Navy.Mil References: <199608132251.SAA22922@csed-115.csed.ida.org> Message-Id: Organization: Research Computing Center, Moscow State University From: Rybin Sergey Igorevich Date: Mon, 26 Aug 96 11:45:36 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: new ASIS package structure Lines: 149 Content-Length: 5899 Status: OR Dear ASIS Officers, I hope I am not too late with my comments on the new ASIS packaging structure. 1. The first impression and the general comment: the new structure is better, then the old one. In our latest ASIS paper to be presented at TRI-Ada'96 we suggested, that the ASIS hierarchy should be rooted by the _empty_ umbrella package named Asis. From the other side, if the package Asis contains the definitions of the main ASIS types, all its children do not need to "with" any package containing type definitions. So it may make sense to use as a general prototype for the ASIS hierarchy not the predefined Ada hierarchy rooted by the empty Ada package, but the predefined hierarchy rooted by the non-empty package System. 2. A small technical remark: why does all the children of the Asis package contain the with clause for their parent? with Asis; package Asis.Declarations is ... etc. 3. And now the most important question - how to define the ASIS types in the root Asis package? Let me start from the small remark about Asis integer types and constants. ASIS 2.0.H says: ------------------------------------------------------------------------------ -- Section 3.1 type Asis_Integer ------------------------------------------------------------------------------ -- Asis_Integer -- -- A numeric subtype that allows each ASIS implementation to place constraints -- on the lower and upper bounds. Whenever possible, the range of this type -- should meet or exceed -(2**31-1) .. 2**31-1. -- ------------------------------------------------------------------------------ --******************* Implementation_Defined_Integer_Constant : constant := 10; subtype Implementation_Defined_Integer_Type is Integer; --******************* What about Implementation_Defined_Integer_Constant : constant := 2**31-1; instead of Implementation_Defined_Integer_Constant : constant := 10; And now - about the ASIS private types. ASIS 2.0.H says: -- ------------------------------------------------------------------------------ -- Context must be an undiscriminated limited private type, or, must be -- derived from an undiscriminated limited private type. It may be declared -- as a new type or as a subtype of an existing type. ------------------------------------------------------------------------------ type Context is (Implementation_Defined); Nil_Context : constant Context := Implementation_Defined; ------------------------------------------------------------------------------ That is, ASIS requires Context to be an undiscriminated limited private type, and in two lines below it formally defines it as an *enumeration* type. The intent is quite clear for all the people who has been involved in the ASIS process for a long time, moreover, we are going to have the ASIS specification compilable, but if I try to look on this from the standardization viewpoint, I must say, that I definitely do not like this. And I am expecting formal "external" objections concerning the definitions of the main ASIS abstractions as given in 2.0.H during the formal reviewing of ASIS. I would suggest the following way of defining the ASIS abstractions: package Asis is ... -- ------------------------------------------------------------------------------ -- Context must be an undiscriminated limited private type, or, must be -- derived from an undiscriminated limited private type. It may be declared -- as a new type or as a subtype of an existing type. ------------------------------------------------------------------------------ type Context is limited private; Nil_Context : constant Context; ------------------------------------------------------------------------------ ... private ... type Context is (Implementation_Defined); Nil_Context : constant Context := Implementation_Defined; ... end Asis; I would also suggest to simplify the requirements imposed by the ASIS definitions to the ASIS types, e.g. for the Context type I would prefer to say only: -- Context must be an undiscriminated limited private type. instead of -- Context must be an undiscriminated limited private type, or, must be -- derived from an undiscriminated limited private type. It may be declared -- as a new type or as a subtype of an existing type. May be, I am missing something important, but in my opinion the second part of the existing definition: -- ... or, must be -- derived from an undiscriminated limited private type. It may be declared -- as a new type or as a subtype of an existing type. is an implementation detail which does not have to be specified in the ASIS standard. 4. This comment does not have the direct relation to the latest changes in the ASIS package structure. I was going to present it more then a month ago - sorry for this hole in my memory. The question is - what is the semantics of and what is the purpose to have in the ASIS definition such notions as Nil_Context and Nil_Container? As for Nil_Context, it seems to be completely useless. The only occurrence of Nil_Context in ASIS 2.0.H is its definition in the Asis package, it is not used in the documentation of any ASIS query. Moreover, any ASIS Context, if it is a Context, should contain at least Ada predefined compilation units, therefore it cannot be empty. As for Nil_Container, the current ASIS definition uses it do define the semantics of two queries from Asis.Ada_Environments.Containers: Name and Enclosing_Context (ASIS defines what should happen if the argument is a Nil_Container). But ASIS says nothing about the situations when Nil_Container could or should be obtained, and in my opinion, the general semantics of the ASIS notion of a Container does not need Nil_Container at all. Sergey Rybin. From colket@smtp-gw.spawar.navy.mil Fri Sep 6 16:42:38 1996 Return-Path: Received: from ida.org by csed-115.csed.ida.org (SMI-8.6/SMI-SVR4) id QAA12130; Fri, 6 Sep 1996 16:42:37 -0400 Received: from opal.spawar.navy.mil by ida.org (4.1/SMI-4.1) id AA05405; Fri, 6 Sep 96 16:42:03 EDT Received: from smtp-gw.spawar.navy.mil by opal.spawar.navy.mil (5.x/SMI-SVR4) id AA29864; Fri, 6 Sep 1996 16:36:59 -0400 Received: from ccMail by smtp-gw.spawar.navy.mil (IMA Internet Exchange 1.04b) id 2308afa0; Fri, 6 Sep 96 16:35:06 -0400 Mime-Version: 1.0 Date: Fri, 6 Sep 1996 16:34:26 -0400 Message-Id: <2308afa0@smtp-gw.spawar.navy.mil> From: colket@smtp-gw.spawar.navy.mil (Currie Colket) Subject: Re[2]: new ASIS package structure To: ASIS-Officers@sw-eng.falls-church.va.us, roby@ida.org, Rybin Sergey Igorevich Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Length: 7756 Status: OR Sergey, Reference your email => >I hope I am not too late with my comments on the new ASIS packaging structure. Thank you for being the ONLY one to respond to the new package structure. I wish it were because all others on asis-officers have reviewed it thoroughly and found the new package to be perfect. Alas, I believe it is because most of us were gone in August. Hopefully your Email will encourage others to look at the new structure are respond soon!!! In regards to you comments => > 1. The first impression and the general comment: the new structure is > better, then the old one. In our latest ASIS paper to be presented at > TRI-Ada'96 we suggested, that the ASIS hierarchy should be rooted by > the _empty_ umbrella package named Asis. From the other side, > if the package Asis contains the definitions of the main ASIS types, > all its children do not need to "with" any package containing type > definitions. So it may make sense to use as a general prototype for > the ASIS hierarchy not the predefined Ada hierarchy rooted by the > empty Ada package, but the predefined hierarchy rooted by the > non-empty package System. Many of the types have already been pushed to lower levels. Certainly additional types can be pushed lower and we should strive to do this. There are several types used by more than one child package useful to have in package Asis. These probably should remain in package Asis so there will not be an empty package. >2. A small technical remark: why does all the children of the Asis > package contain the with clause for their parent? > > with Asis; > package Asis.Declarations is > ... > > etc. Good catch - this will be corrected. >3. And now the most important question - how to define the ASIS types > in the root Asis package? > > Let me start from the small remark about Asis integer types and constants. > > ASIS 2.0.H says: > >------------------------------------------------------------------------------ >-- Section 3.1 type Asis_Integer >------------------------------------------------------------------------------ >-- Asis_Integer >-- >-- A numeric subtype that allows each ASIS implementation to place constraints >-- on the lower and upper bounds. Whenever possible, the range of this type >-- should meet or exceed -(2**31-1) .. 2**31-1. >-- >------------------------------------------------------------------------------ > >--******************* >Implementation_Defined_Integer_Constant : constant := 10; >subtype Implementation_Defined_Integer_Type is Integer; >--******************* > >What about > > Implementation_Defined_Integer_Constant : constant := 2**31-1; > >instead of > > Implementation_Defined_Integer_Constant : constant := 10; Concur - Clearly this was done to make the specification compile. I like your approach of providing a realistic value for the constant. A comment should identify the implementation permissions to change this value. >And now - about the ASIS private types. ASIS 2.0.H says: > >-- >------------------------------------------------------------------------------ >-- Context must be an undiscriminated limited private type, or, must be >-- derived from an undiscriminated limited private type. It may be declared >-- as a new type or as a subtype of an existing type. >------------------------------------------------------------------------------ > > type Context is (Implementation_Defined); > Nil_Context : constant Context := Implementation_Defined; > >------------------------------------------------------------------------------ > >That is, ASIS requires Context to be an undiscriminated limited private type, >and in two lines below it formally defines it as an *enumeration* type. >The intent is quite clear for all the people who has been involved in the >ASIS process for a long time, moreover, we are going to have the >ASIS specification compilable, but if I try to look on this from >the standardization viewpoint, I must say, that I definitely do not >like this. And I am expecting formal "external" objections concerning the >definitions of the main ASIS abstractions as given in 2.0.H during the >formal reviewing of ASIS. > >I would suggest the following way of defining the ASIS abstractions: > >package Asis is > ... >-- >------------------------------------------------------------------------------ >-- Context must be an undiscriminated limited private type, or, must be >-- derived from an undiscriminated limited private type. It may be declared >-- as a new type or as a subtype of an existing type. >------------------------------------------------------------------------------ > > type Context is limited private; > Nil_Context : constant Context; > >------------------------------------------------------------------------------ >... >private > ... > type Context is (Implementation_Defined); > Nil_Context : constant Context := Implementation_Defined; > ... >end Asis; > > >I would also suggest to simplify the requirements imposed by the ASIS >definitions to the ASIS types, e.g. for the Context type I would prefer >to say only: > >-- Context must be an undiscriminated limited private type. > >instead of > >-- Context must be an undiscriminated limited private type, or, must be >-- derived from an undiscriminated limited private type. It may be declared >-- as a new type or as a subtype of an existing type. > >May be, I am missing something important, but in my opinion the second part >of the existing definition: > >-- ... or, must be >-- derived from an undiscriminated limited private type. It may be declared >-- as a new type or as a subtype of an existing type. > >is an implementation detail which does not have to be specified in the >ASIS standard. I tend to concur with you that the intent of each definition will be clearer to readers of the specification by identifying these types as private types. Do you think any vendor will have a problem if we limit such types to undiscriminated limit private types? Comments from other officers please!!! >4. This comment does not have the direct relation to the latest changes > in the ASIS package structure. I was going to present it more then a > month ago - sorry for this hole in my memory. > > The question is - what is the semantics of and what is the purpose to > have in the ASIS definition such notions as Nil_Context and Nil_Container? > > As for Nil_Context, it seems to be completely useless. The only occurrence > of Nil_Context in ASIS 2.0.H is its definition in the Asis package, > it is not used in the documentation of any ASIS query. Moreover, > any ASIS Context, if it is a Context, should contain at least Ada > predefined compilation units, therefore it cannot be empty. > > As for Nil_Container, the current ASIS definition uses it do define > the semantics of two queries from Asis.Ada_Environments.Containers: > Name and Enclosing_Context (ASIS defines what should happen if the > argument is a Nil_Container). But ASIS says nothing about the situations > when Nil_Container could or should be obtained, and in my opinion, > the general semantics of the ASIS notion of a Container does not need > Nil_Container at all. There is always the issue of what happens if Context or Container are empty? Hence they were added as a way to complete the possibilities. Implementations may have additional uses for these notions - perhaps Steve can provide some additional insight. Thank you again - hopefully we will have another version out within a week (or two). v/r Currie P.S. I also have been out of the office for the last month. Life will become more normal next Tuesday. From rybin@alex.srcc.msu.su Wed Sep 11 05:46:34 1996 Return-Path: Received: from ida.org by csed-115.csed.ida.org (SMI-8.6/SMI-SVR4) id FAA17281; Wed, 11 Sep 1996 05:46:26 -0400 Received: from gw.srcc.msu.su by ida.org (4.1/SMI-4.1) id AA16901; Wed, 11 Sep 96 05:45:17 EDT Received: from srcc.UUCP (uusrcc@localhost) by gw.srcc.msu.su (8.6.12/8.6.12) with UUCP id NAA05648; Wed, 11 Sep 1996 13:43:17 +0400 Received: by gamma.srcc.msu.su; Wed, 11 Sep 1996 13:36:18 +0400 Received: by vadik.srcc.msu.su; Wed, 11 Sep 1996 10:03:26 +0400 Received: by alex.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Wed, 11 Sep 1996 10:00:57 +0400 To: roby@ida.org Cc: colket@smtp-gw.spawar.navy.mil References: <199609101706.NAA16908@csed-115.csed.ida.org> Message-Id: Organization: Research Computing Center, Moscow State University From: Rybin Sergey Igorevich Date: Wed, 11 Sep 96 10:00:57 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: Re[2]: new ASIS package structure Lines: 17 Content-Length: 530 Status: OR > Sergey, > > Currie wanted to know if you received his reply > to your original response. Evidently, your email address > gave an error back to his mailer. > > Clyde I've got the reply. I've also got your last test message a few days ago. My current address is rybin@alex.srcc.msu.su, my address in Lausanne also works and forwards all the messages to Moscow. We had some local problems with our mail system in the beginning of this week - this might be the cause of the error responce you have got. Sergey From rybin@alex.srcc.msu.su Thu Sep 12 09:27:17 1996 Return-Path: Received: from ida.org by csed-115.csed.ida.org (SMI-8.6/SMI-SVR4) id JAA19325; Thu, 12 Sep 1996 09:27:10 -0400 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA05095; Thu, 12 Sep 96 09:20:21 EDT Received: from gw.srcc.msu.su by sw-eng.falls-church.va.us (8.7.1/) id MAA20880; Thu, 12 Sep 1996 12:30:24 GMT Received: from srcc.UUCP (uusrcc@localhost) by gw.srcc.msu.su (8.6.12/8.6.12) with UUCP id NAA18552; Thu, 12 Sep 1996 13:27:54 +0400 Received: by gamma.srcc.msu.su; Thu, 12 Sep 1996 13:27:23 +0400 Received: by vadik.srcc.msu.su; Thu, 12 Sep 1996 13:26:35 +0400 Received: by alex.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Thu, 12 Sep 1996 13:28:23 +0400 To: asis-officers@sw-eng.falls-church.va.us, colket@smtp-gw.spawar.navy.mil References: <2308afa0@smtp-gw.spawar.navy.mil> Message-Id: Organization: Research Computing Center, Moscow State University From: Rybin Sergey Igorevich Date: Thu, 12 Sep 96 13:28:22 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: Re[2]: new ASIS package structure Lines: 68 Content-Length: 3415 Status: OR > >4. This comment does not have the direct relation to the latest changes > > in the ASIS package structure. I was going to present it more then a > > month ago - sorry for this hole in my memory. > > > > The question is - what is the semantics of and what is the purpose to > > have in the ASIS definition such notions as Nil_Context and Nil_Container? > > > > As for Nil_Context, it seems to be completely useless. The only occurrence > > of Nil_Context in ASIS 2.0.H is its definition in the Asis package, > > it is not used in the documentation of any ASIS query. Moreover, > > any ASIS Context, if it is a Context, should contain at least Ada > > predefined compilation units, therefore it cannot be empty. > > > > As for Nil_Container, the current ASIS definition uses it do define > > the semantics of two queries from Asis.Ada_Environments.Containers: > > Name and Enclosing_Context (ASIS defines what should happen if the > > argument is a Nil_Container). But ASIS says nothing about the situations > > when Nil_Container could or should be obtained, and in my opinion, > > the general semantics of the ASIS notion of a Container does not need > > Nil_Container at all. > > There is always the issue of what happens if Context or Container are empty? > Hence they were added as a way to complete the possibilities. Implementations > may have additional uses for these notions - perhaps Steve can provide some > additional insight. As for Containers, I am ready to agree, that the notion of a Nil Container may be useful. If an ASIS implementation provides some "stable" approach for Containers, i.e. supports Containers for predefined and user-defined compilation units, a Nil Container may correspond to the Context containing no user-defined units. As for a Nil_Context, I have another question. Should ASIS say anything about what *predefined* Ada compilation units should be reachable from any Context? And if it should, what exactly should be said. Suppose we have only one user-defined compilation unity A belonging to a given Context, and this unit depends on no Ada predefined compilation unit (except Standard). The question is - what should be the result of the Asis.Compilation_Units.Compilation_Units query for such a Context? What is the right answer: 1. A only (this can hardly be possible, because we need an enclosing unit for such entities as Integer, Boolean, etc., but what about a unit like procedure A is begin null; end A; ) 2. A and Standard; 3. A, Standard and all the predefined units defined in RM95; 4. A, Standard and some implementation-defined (or implementation-dependent) subset of the predefined units defined in RM95 (should an empty subset be allowed in this case?). Another question - consider a Context containing no user-defined compilation units at all. What should Asis.Compilation_Units.Compilation_Units return for it: 1. Nil_Compilation_Unit_List; 2. Standard only; 3. Standard and all the predefined units defined in RM95; 4. Standard and some implementation-defined (or implementation-dependent) subset of the predefined units defined in RM95 (should an empty subset be allowed in this case?)? If *every* ASIS Context, when opening, *must* contain at least the package Standard, what may be the meaning of Nil_Context? Sergey From sblake@alsys.com Wed Sep 25 12:28:20 1996 Return-Path: Received: from ida.org by csed-115.csed.ida.org (SMI-8.6/SMI-SVR4) id MAA08628; Wed, 25 Sep 1996 12:28:19 -0400 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA11490; Wed, 25 Sep 96 12:27:31 EDT Received: from gw.alsys.com by sw-eng.falls-church.va.us (8.7.1/) id QAA06436; Wed, 25 Sep 1996 16:11:03 GMT Received: from rasht.alsys.com (mailhub.alsys.com) by gw.alsys.com (4.1/SMI-4.1.1) id AA29272; Wed, 25 Sep 96 09:13:16 PDT Received: from pulsar.telesoft by rasht.alsys.com (4.1/TS-1.2c) id AA29190; Wed, 25 Sep 96 09:12:40 PDT Received: by pulsar.telesoft (5.x/SMI-SVR4) id AA21299; Wed, 25 Sep 1996 09:12:16 -0700 Date: Wed, 25 Sep 1996 09:12:16 -0700 From: sblake@alsys.com (Steve Blake @pulsar) Message-Id: <9609251612.AA21299@pulsar.telesoft> To: asis-officers@sw-eng.falls-church.va.us Subject: Comments on new ASIS package structure Content-Length: 696 Status: OR My compliments go to Clyde and Currie for taking the ball and running with it, to ensure progress continues! I really appreciate your efforts. I agree with each of Sergey's comments (numbered 1, 2, and 3) on the new structure. Especially with the 3rd comment about specifying the types and the needed commentary modifications. I would suggest combining the Asis.Element_Kinds and Asis.Unit_Kinds packages into one; Asis.Kinds. This would provide a single capsule and avoid potential name collisions with the package name and the type names (i.e. Asis.Element_Kinds identifies both a package and a type). That's all I have at this time. I look forward to the meetings at TRI-Ada. Steve From rybin@alex.srcc.msu.su Fri Sep 27 04:49:42 1996 Return-Path: Received: from ida.org by csed-115.csed.ida.org (SMI-8.6/SMI-SVR4) id EAA12277; Fri, 27 Sep 1996 04:49:40 -0400 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA07722; Fri, 27 Sep 96 04:48:50 EDT Received: from gw.srcc.msu.su by sw-eng.falls-church.va.us (8.7.1/) id IAA26596; Fri, 27 Sep 1996 08:31:26 GMT Received: from srcc.UUCP (uusrcc@localhost) by gw.srcc.msu.su (8.7.6/8.7.3) with UUCP id KAA17637 for asis-officers@sw-eng.falls-church.va.us; Fri, 27 Sep 1996 10:51:28 +0400 (MSD) Received: by gamma.srcc.msu.su; Fri, 27 Sep 1996 10:51:12 +0400 Received: by vadik.srcc.msu.su; Fri, 27 Sep 1996 10:50:30 +0400 Received: by alex.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Fri, 27 Sep 1996 10:47:10 +0400 To: asis-officers@sw-eng.falls-church.va.us References: <9609251612.AA21299@pulsar.telesoft> Message-Id: Organization: Research Computing Center, Moscow State University From: Rybin Sergey Igorevich Date: Fri, 27 Sep 96 10:47:10 +0400 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: Comments on new ASIS package structure Lines: 8 Content-Length: 316 Status: OR > I would suggest combining the Asis.Element_Kinds and Asis.Unit_Kinds > packages into one; Asis.Kinds. This would provide a single capsule and > avoid potential name collisions with the package name and the type names > (i.e. Asis.Element_Kinds identifies both a package and a type). A good idea! Sergey