From rybin@possum.srcc.msu.su Sat Jan 11 12:19:51 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id MAA13975; Sat, 11 Jan 1997 12:19:51 -0500 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA09201; Sat, 11 Jan 97 12:20:05 EST Received: from crocus.gamma.ru by sw-eng.falls-church.va.us (8.7.1/) id QAA12456; Sat, 11 Jan 1997 16:45:01 GMT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.7.6/8.7.3) with UUCP id TAA27692 for asis-technical@sw-eng.falls-church.va.us; Sat, 11 Jan 1997 19:47:29 +0300 (MSK) Received: by gamma.srcc.msu.su; Sat, 11 Jan 1997 19:46:21 +0300 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Sat, 11 Jan 1997 19:37:39 +0300 To: asis-technical@sw-eng.falls-church.va.us Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Sat, 11 Jan 97 19:37:39 +0300 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Class-wide types in ASIS Lines: 140 Content-Length: 6247 Status: OR All, I have the following question/comment on ASIS 2.0.K. Consider the following example (taken from Ada 95 Rationale, page 4-6, the leading declarations are skipped): ... declare A_File : File'Class := Get_File_From_User; begin View (A_File); end; ^ | -------------------------------------------------- and consider the Element (let's call it El) representing this | construct. The corresponding Element is of An_Expression/An_Idenifier kind, it represents a variable, so the Corresponding_Expression_Type should not return a Nil_Element when applying to El (the definition of Corresponding_Expression_Type from 2.0.K is appended to this message) The question is - what kind should Corresponding_Expression_Type (El) have? The problem is that the result should represent (in some way) a *CLASS-WIDE* type, but ASIS has no position in its Element classification hierarchy for class-wide types. Moreover, the multi-file search for the expression "class-wide" or "class wide" gives a null result for ASIS 2.0.K My guess is that if we do not have a special position for classifying class-wide types, then the result of Corresponding_Expression_Type should be of the same ASIS type kind, as the root type of the class. Do you agree? Another problem is that RM95 3.4.1(3) says: Every type is either a specific type, a class-wide type, or a universal type. A specific type is one defined by a type_declaration, a formal_type_declaration, or a full type definition embedded in a declaration for an object. Class-wide and universal types are implicitly defined, to act as ^^^^^^^^^^^^^^^^^^ representatives for an entire class of types, as follows: So if Corresponding_Expression_Type (El) is not a Nil_Element, it is an *implicit* Element. Two questions arise here: 1. If an ASIS implementation does not support implicit Elements, there exists one more case (comparing with what is mentioned in ASIS 2.0.K) when Corresponding_Expression_Type may return a Nil_Element - this is the case when it should return the definition of some class-wide type, but when it cannot do it, because an ASIS implementation does not support implicit Elements. 2. As any other Element, the Element being the result of Corresponding_Expression_Type (El) has the Enclosing Element and it may be traversed by ASIS structural queries. I am afraid, both these aspects need additional explanations for the elements representing class-wide types. This is one more example, when RM is not enough to answer these questions (that is, what is the enclosing construct and what is the syntax structure of the (implicit) definition of a class-wide type) - the language definition simply does not need answers, but ASIS does! And, finally, what do you think about the alternative solutions which would eliminate any implicit elements when querying about expression types? 1. The idea is to add a special value to Type_Kinds (A_Class_Wide_Type) and to have the constant Class_Wide_Type_Element as the only Element value having this kind. Corresponding_Expression_Type should return Class_Wide_Type_Element for any argument of class-wide type, and then we have to add another query (Corresponding_Expression_Root_Type???) to get the *explicit* declaration of the root type of the class. The Class_Wide_Type_Element constant should have no child Elements and a Nil_Element as Enclosing Element, and no span and text image As a result, an application needs two steps to understand that it deals with an expression of a class-wide type, and both these steps deals with explicit Elements 2. Another idea is to add a boolean query Is_Of_Class_Wide type for expressions and to return in Corresponding_Expression_Type not the class-wide type, but its root type. Sergey Rybin ASIS-for-GNAT Project -------------------------------------------------------- ------------------------------------------------------------------------------ -- Section 17.1 function Corresponding_Expression_Type ------------------------------------------------------------------------------ function Corresponding_Expression_Type (Expression : in Asis.Expression) return Asis.Declaration; ------------------------------------------------------------------------------ -- Expression - Specifies the expression to query -- -- Returns the type_declaration for the type of the expression. This query -- does not "unwind" subtypes or derived types to get to the -- Corresponding_First_Subtype or Corresponding_Parent_Subtype declarations. -- -- Returns a Nil_Element for two classes of expressions that do not have a -- Corresponding_Expression_Type: -- -- - Naming expressions that name packages, subprograms, tasks, etc. These -- expressions do have a Corresponding_Name_Definition and a -- Corresponding_Name_Declaration. -- -- - The Actual_Parameter Expression from A_Pragma_Argument_Association for a -- Pragma may or may not have a Corresponding_Expression_Type. If the -- returned declaration is non-nil then the Expression is either a) an -- ordinary expression, or b) a naming expression that names a constant or -- variable object. -- -- If the returned declaration is Nil, Corresponding_Name_Definition and -- Corresponding_Name_Declaration can be used to determine whether the -- expression is a naming expression that specifies a subprogram, package, -- task, etc. If Corresponding_Name_Definition raises Asis_Failed (with a -- Status of Value_Error), the Actual_Parameter is not a normal Ada -- expression at all and does not follow normal Ada semantic rules. -- For example, "pragma Private_Part (Open => Yes);", the "Yes" expression -- may simply be a "keyword" that is specially recognized by the -- implementor's compilation system and may not actually refer to any -- declared object (Corresponding_Expression_Type = Nil_Element and -- Corresponding_Name_Declaration raises Asis_Failed). -- -- Appropriate Element_Kinds: -- An_Expression -- -- Returns Element_Kinds: -- Not_An_Element -- A_Declaration -- From Alfred.Strohmeier@di.epfl.ch Tue Jan 14 09:58:50 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id JAA18364; Tue, 14 Jan 1997 09:58:50 -0500 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA07880; Tue, 14 Jan 97 09:59:02 EST Received: from dimail.epfl.ch by sw-eng.falls-church.va.us (8.7.1/) id NAA14106; Tue, 14 Jan 1997 13:39:29 GMT Received: from lglsun1.epfl.ch by dimail.epfl.ch (SMI-8.6/EPFL-DI-5.1-S-MX) id OAA13706; Tue, 14 Jan 1997 14:42:01 +0100 Received: by lglsun1.epfl.ch (SMI-8.6/EPFL-DI-5.1-MX) id OAA03800; Tue, 14 Jan 1997 14:42:00 +0100 Date: Tue, 14 Jan 1997 14:42:00 +0100 From: Alfred.Strohmeier@di.epfl.ch (Alfred Strohmeier) Message-Id: <199701141342.OAA03800@lglsun1.epfl.ch> To: asis-technical@sw-eng.falls-church.va.us Subject: Re: Class-wide types in ASIS X-Sun-Charset: US-ASCII Content-Length: 1763 Status: OR > From rybin@gamma.srcc.msu.su@possum.srcc.msu.su Sat Jan 11 17:48 MET 1997 > To: asis-technical@sw-eng.falls-church.va.us > From: "Sergey I. Rybin" > Date: Sat, 11 Jan 97 19:37:39 +0300 > Subject: Class-wide types in ASIS > > All, > > I have the following question/comment on ASIS 2.0.K. > > Consider the following example (taken from Ada 95 Rationale, page 4-6, > the leading declarations are skipped): > > ... > declare > A_File : File'Class := Get_File_From_User; > begin > View (A_File); > end; ^ > | > -------------------------------------------------- > and consider the Element (let's call it El) representing this | construct. > I will just provide the thoughts of a naive "user". When querying about A_File, the answers I would expect are: a) it's a class-wide type (if you prefer syntactic sugar: it's of the type A_Class_Wide_Type, or something similar) b) its type, or more exactly the name of its type, is File. I think we have to be aware that in some way there are two types having the name File, a specific type and a class-wide type. Another approch would be to return File'Class, but in my mind this is not really a name. c) it is declared by the declaration A_File : File'Class := Get_File_From_User; d) when parsing this declaration, we would have to solve again the problem stated in b) e) if a semantic query is issued about the declaration of the class-wide type File, I would simply return the declaration of the specific type File. Clearly, it is useless here to construct some kind of "artificial" declaration. > .... > Sergey Rybin > > ASIS-for-GNAT Project > -------------------------------------------------------- -- Alfred Strohmeier From rybin@possum.srcc.msu.su Wed Jan 15 10:37:12 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id KAA20461; Wed, 15 Jan 1997 10:37:11 -0500 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA24670; Wed, 15 Jan 97 10:37:26 EST Received: from crocus.gamma.ru by sw-eng.falls-church.va.us (8.7.1/) id PAA28784; Wed, 15 Jan 1997 15:04:49 GMT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.7.6/8.7.3) with UUCP id SAA04546; Wed, 15 Jan 1997 18:03:12 +0300 (MSK) Received: by gamma.srcc.msu.su; Wed, 15 Jan 1997 18:02:25 +0300 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Wed, 15 Jan 1997 17:47:04 +0300 To: Alfred.Strohmeier@di.epfl.ch, asis-technical@sw-eng.falls-church.va.us References: <199701141342.OAA03800@lglsun1.epfl.ch> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Wed, 15 Jan 97 17:47:04 +0300 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: Class-wide types in ASIS Lines: 86 Content-Length: 3699 Status: OR > > Consider the following example (taken from Ada 95 Rationale, page 4-6, > > the leading declarations are skipped): > > > > ... > > declare > > A_File : File'Class := Get_File_From_User; > > begin > > View (A_File); > > end; ^ > > | > > -------------------------------------------------- > > and consider the Element (let's call it El) representing this | construct. > > > > > I will just provide the thoughts of a naive "user". When querying about > A_File, the answers I would expect are: I think that the viewpoint of "naive user" should be considered as an important test for any change in ASIS! > a) it's a class-wide type (if you prefer syntactic sugar: it's of the > type A_Class_Wide_Type, or something similar) I completely agree with this point! The problem is that now there is no means in ASIS to say that the type is class-wide (or that something is of class-wide type) > b) its type, or more exactly the name of its type, is File. I think we > have to be aware that in some way there are two types having the name > File, a specific type and a class-wide type. Another approch would be > to return File'Class, but in my mind this is not really a name. This is another example when ASIS has to say more, then what is said in RM95! If ASIS has a declaration of a type, it has to be able to return both the ASIS Element and the literal string representing (the name of) the type being declared. I do not know what is better (or worse) in this case - to return File or File'Class. From the point of view of minimizing changes needed to fix the problem File'Class looks as the worse solution... > c) it is declared by the declaration > > A_File : File'Class := Get_File_From_User; There is no problem with getting this information! This may be done by Corresponding_Name_Definition function, and this function has no problem with class-wide typed. > d) when parsing this declaration, we would have to solve again the > problem stated in b) I do not see any problem with parsing this declaration - it is enough for an application to realise, that the subtype mark is an attribute reference for the 'Class attribute. > e) if a semantic query is issued about the declaration of the > class-wide type File, I would simply return the declaration of the > specific type File. Clearly, it is useless here to construct some kind > of "artificial" declaration. There is one point here I agree with - that this is useless (or rather hard) to construct "artificial" stuff here. There is another point I cannot agree with - that it would be OK to return a specific type instead of the really needed class-wide type. Suppose some application traversing the Ada stuff and making some type-dependent analysis. The very natural thing for this application is to query about the types of expresions being traversed, and another natural thing is to use Traverse_Element-based algorythm. So the application should realize, that some expression is of class-wide type when querying about the type of the expression. My point is, that when applying the Corresponding_Expression_Type to *ANY* expression, it is important to understand *by the result returned by this query*, that the expression is of class-wide type. It is not very important to get the "declaration" of this class-wide type - an application may use another means to get the declaration of the root type of the class. The class-wide type itself is not really important. Two things are important - the fact that the type is clas-wide and its root type. (I am afraid I am starting to repeat myself). Any other opinions??? Sergey From sblake@alsys.com Wed Jan 15 12:20:20 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id MAA20752; Wed, 15 Jan 1997 12:20:20 -0500 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA26447; Wed, 15 Jan 97 12:20:32 EST Received: from gw.alsys.com by sw-eng.falls-church.va.us (8.7.1/) id QAA29878; Wed, 15 Jan 1997 16:43:49 GMT Received: from rasht.alsys.com (mailhub.alsys.com) by gw.alsys.com (4.1/SMI-4.1.1) id AA29360; Wed, 15 Jan 97 08:46:42 PST Received: from pulsar.telesoft by rasht.alsys.com (4.1/TS-1.2c) id AA07667; Wed, 15 Jan 97 08:45:50 PST Received: by pulsar.telesoft (5.x/SMI-SVR4) id AA02673; Wed, 15 Jan 1997 08:44:40 -0800 Date: Wed, 15 Jan 1997 08:44:40 -0800 From: sblake@alsys.com (Steve Blake @pulsar) Message-Id: <9701151644.AA02673@pulsar.telesoft> To: asis-technical@sw-eng.falls-church.va.us, rybin@possum.srcc.msu.su Subject: Re: Class-wide types in ASIS Content-Length: 5509 Status: OR >I have the following question/comment on ASIS 2.0.K. > >Consider the following example (taken from Ada 95 Rationale, page 4-6, >the leading declarations are skipped): > >... >declare > A_File : File'Class := Get_File_From_User; >begin > View (A_File); >end; ^ > | > -------------------------------------------------- >and consider the Element (let's call it El) representing this | construct. > >The corresponding Element is of An_Expression/An_Idenifier kind, it >represents a variable, so the Corresponding_Expression_Type should not >return a Nil_Element when applying to El (the definition of >Corresponding_Expression_Type from 2.0.K is appended to this message) > >The question is - what kind should Corresponding_Expression_Type (El) >have? The problem is that the result should represent (in some way) >a *CLASS-WIDE* type, but ASIS has no position in its Element >classification hierarchy for class-wide types. Moreover, the >multi-file search for the expression "class-wide" or "class wide" >gives a null result for ASIS 2.0.K > >My guess is that if we do not have a special position for classifying >class-wide types, then the result of Corresponding_Expression_Type >should be of the same ASIS type kind, as the root type of the class. >Do you agree? In this case, Corresponding_Expression_Type should return a nil element, and its commentary can be updated to explain it. Returning the root type is not a good solution because it is not really correct, and might be misleading. At least a nil value would likely prompt more investigation by the client tool. Some history on Corresponding_Expression_Type: It is one of the left-over queries from very early ASIS designs, and is wrought with implementation and design problems (as you point out). One reaon is because typically context information to determine the type of numeric literals and other expressions is just not kept in intermediate representations of many compilers. It would have to be recomputed by some ASIS implementations. I doubt if it is widely used in ASIS applications, and unless it is too late, I would be happy to see it removed from the spec. There are other ways to get the information provided by this query. >Another problem is that RM95 3.4.1(3) says: > > Every type is either a specific type, a class-wide type, or a > universal type. A specific type is one defined by a > type_declaration, a formal_type_declaration, or a full type > definition embedded in a declaration for an object. Class-wide > and universal types are implicitly defined, to act as > ^^^^^^^^^^^^^^^^^^ > representatives for an entire class of types, as follows: > > >So if Corresponding_Expression_Type (El) is not a Nil_Element, it is >an *implicit* Element. Two questions arise here: > >1. If an ASIS implementation does not support implicit Elements, > there exists one more case (comparing with what is mentioned in > ASIS 2.0.K) when Corresponding_Expression_Type may return > a Nil_Element - this is the case when it should return the > definition of some class-wide type, but when it cannot do it, > because an ASIS implementation does not support implicit Elements. > >2. As any other Element, the Element being the result of > Corresponding_Expression_Type (El) has the Enclosing Element > and it may be traversed by ASIS structural queries. I am afraid, > both these aspects need additional explanations for the elements > representing class-wide types. This is one more example, when > RM is not enough to answer these questions (that is, what is > the enclosing construct and what is the syntax structure of the > (implicit) definition of a class-wide type) - the language definition > simply does not need answers, but ASIS does! Take the simple approach, and return nil element. Let's avoid the extra complication. > >And, finally, what do you think about the alternative solutions which >would eliminate any implicit elements when querying about expression types? > >1. The idea is to add a special value to Type_Kinds (A_Class_Wide_Type) > and to have the constant Class_Wide_Type_Element as the only > Element value having this kind. Corresponding_Expression_Type should > return Class_Wide_Type_Element for any argument of class-wide type, > and then we have to add another query > (Corresponding_Expression_Root_Type???) to get the *explicit* declaration > of the root type of the class. > > The Class_Wide_Type_Element constant should have no child Elements and > a Nil_Element as Enclosing Element, and no span and text image > > As a result, an application needs two steps to understand that it > deals with an expression of a class-wide type, and both these steps > deals with explicit Elements > >2. Another idea is to add a boolean query Is_Of_Class_Wide type for > expressions and to return in Corresponding_Expression_Type not the > class-wide type, but its root type. This kind of query can be written generally using other ASIS queries. This eliminates the need for a limited and useless A_Class_Wide_Type kind and all the documentation and implementation effort it requires. The admirable ideas and alternatives presented are interesting and creative, and are fun to discuss. However, I'm not sure this query is vital enough to warrant anything other than a simple solution. Further, I don't think it would be missed if it were removed. Steve Blake From rybin@possum.srcc.msu.su Wed Jan 15 17:30:25 1997 Return-Path: Received: from ida.org by cronus.csed.ida.org (SMI-8.6/SMI-SVR4) id RAA21176; Wed, 15 Jan 1997 17:30:25 -0500 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us) by ida.org (4.1/SMI-4.1) id AA02122; Wed, 15 Jan 97 17:30:40 EST Received: from crocus.gamma.ru by sw-eng.falls-church.va.us (8.7.1/) id VAA03436; Wed, 15 Jan 1997 21:52:20 GMT Received: from srcc.UUCP (uucp@localhost) by crocus.gamma.ru (8.7.6/8.7.3) with UUCP id AAA08403; Thu, 16 Jan 1997 00:54:52 +0300 (MSK) Received: by gamma.srcc.msu.su; Thu, 16 Jan 1997 00:54:00 +0300 Received: by possum.srcc.msu.su (UUPC/@ v5.09gamma, 14Mar93); Thu, 16 Jan 1997 00:48:08 +0300 To: asis-technical@sw-eng.falls-church.va.us, sblake@alsys.com References: <9701151644.AA02673@pulsar.telesoft> Message-Id: Organization: Information Systems, SRCC, MSU From: "Sergey I. Rybin" Date: Thu, 16 Jan 97 00:48:08 +0300 X-Mailer: BML [MS/DOS Beauty Mail v.1.36] Subject: Re: Class-wide types in ASIS Lines: 9 Content-Length: 300 Status: OR > Take the simple approach, and return nil element. Let's avoid the extra > complication. I like the aproach suggested by Steve and I agree with Steve's arguments. Nil Element might be used as a way to tell an application that a given expression requires some special analysis. Sergey Rybin.