From jkr@jkr.cc.rl.ac.uk Fri Jul 21 16:33:26 2000 Received: from nameserv.rl.ac.uk (nameserv.rl.ac.uk [130.246.135.129]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id QAA87838 for ; Fri, 21 Jul 2000 16:33:26 +0200 (CEST) (envelope-from jkr@jkr.cc.rl.ac.uk) Received: from jkr.cc.rl.ac.uk (jkr.cc.rl.ac.uk [130.246.8.20]) by nameserv.rl.ac.uk (8.8.8/8.8.8) with ESMTP id PAA29392 for ; Fri, 21 Jul 2000 15:33:25 +0100 Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id PAA17773 for SC22WG5@dkuug.dk; Fri, 21 Jul 2000 15:34:33 +0100 (BST) Date: Fri, 21 Jul 2000 15:34:33 +0100 (BST) From: John Reid Message-Id: <200007211434.PAA17773@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Interpretation 191 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In J3/00-165, I proposed replacements for the ANSWER and EDITS sections of 191. These were not accepted by J3. The interpretations subgroup indicated that it agreed with the general thrust of my response, but that they felt that the edits involved too much "hand waving" and not enough precise definition. My feeling now is that I would rather try a different, simpler, approach than attempt to clarify 00-165. I think we need rules that are easy for the user and the compiler writer to understand. This is a fresh attempt, based on the idea that everything about two sequence types must be the same if they are to be the same type. Here is my new proposal, including the question (which I have not changed). For your convenience, I attach the ANSWER and EDITS as now in 00-165 and 006. ............ NUMBER: F90/000191 TITLE: Interaction of SEQUENCE derived types and rename KEYWORDS: SEQUENCE, derived type, use association, derived type DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Consider the following: MODULE M TYPE T SEQUENCE TYPE (T), POINTER :: P END TYPE END MODULE USE M, T2=>T TYPE T SEQUENCE TYPE (T2), POINTER :: P END TYPE TYPE (T) X TYPE (T2) Y X = Y END Section 4.4.2, 'Determination of derived types', seems to indicate that types T and T2 in the main program refer to the same type. Note that both types have structure components that agree in order, name, and attributes. However, considering type T in the context of module M only, type T is a derived type that contains one component that is a pointer to itself. In the context of the main program, type T is a derived type that contains one component that is a pointer to a different derived type. Are types T and T2 considered to be the same type? ANSWER: No. The intention of the wording in 4.4.2 is to require the two derived-type definitions to have completely identical properties in order to define the same type. T and T2 are the not of same type since the local names of the types of their components differ. The first edit is provided to clarify this conclusion. Discussion: This example has drawn our attention to the fact that the present text does not address the problems that arise with recursive types. If two sequence types are the same, the attributes of corresponding components must match. The attributes include the type, so if a pair of corresponding types in a recursive set differ, so do all the types that have components of these differing types. Applying this argument recursively, we find that all pairs of corresponding types in a recursive set differ. Thus the pairs of corresponding types in a recursive set either all agree or all differ. In deciding which of these outcomes applies, we cannot take the types of the recursive compoents into account. We define them to be all different if any other diference is found in one or more of them. If there is no such difference, they all agree. Our second edit specifies this. EDITS: 1. Page 43, Section 4.4.2, lines 5-9 [43:26-30]. Change the sentences 'Data ... types.' to Data entities also have the same type if they are declared with reference to separate derived-type definitions that (1) Are in different scoping units, (2) Specify the same type name, (3) Have the SEQUENCE property, and (4) Have components that do not have PRIVATE accessibility and agree in order, name, type name, and attributes. Otherwise, they are of different derived types. If the type of a component is accessed by use association, the requirement in (4) that the type names agree applies to both the local names and the names in the original type definition. 2. Page 43, Section 4.4.2, before NOTE 4.30 [43:32+], add new paragraph: If the type of a component is a member of a set of sequence types in a recursion, the requirement in (4) that the types agree is waived, but the names are required to agree. If any pair of corresponding types involved in the recursion fails to satisfy the requirements (1) to (4), any pair of data entities declared with corresponding types of the recursion have different types. Otherwise, any pair of data entities declared with corresponding types of the recursion have the same type. SUBMITTED BY: Janice C. Shepherd HISTORY: 94-273 m130 submitted 94-377 m131 Response submitted, approved u.c. 95-034r1 m132 X3J3 ballot failed 15-5 00-165 m153 Alternative response rejected by subgroup -------------------------------------------------------------------------------- 2. ANSWER and EDITS in 00-165 ANSWER: Yes, T and T2 are the same type. This is because each type definition has a single component that is a scalar pointer of the type that is defined in the module. The sentence 'In the context of the main program, type T is a derived type that contains one component that is a pointer to a different derived type.' is incorrect since the main program has a use statement for the module. The same type definition is used for both components, so their types must be the same. The intention is that two data entities declared with reference to separate derived-type definitions of the same sequence type should always have the same type. The first edit makes this apparent. Unfortunately, if the example is altered to MODULE M TYPE T SEQUENCE TYPE (T), POINTER :: P END TYPE END MODULE USE M, T2=>T TYPE T SEQUENCE TYPE (T), POINTER :: P END TYPE TYPE (T) X TYPE (T2) Y X = Y END an ambiguity is exposed. If the types are the same, then their components have the same type, which is consistent. If the types are different, then their components have different types, which is again consistent. The intention was that the types be the same in this case, and the second edit specifies this. Similar problems occur with indirect recursions. Consider, for example, TYPE H SEQUENCE TYPE(E),POINTER :: F END TYPE TYPE E SEQUENCE TYPE(H),POINTER :: P END TYPE Now E and H stand or fall together. If the two Hs are different, the two Es must be different, and vice-versa. The compiler has to consider the two together. In general, if there is a set of k sequence types that are coupled in a mutual recursion, the compiler must consider them all together. EDITS: 1. Page 143, Section 4.4.2, lines 5-7 [43:26-28]. Change 'Data ... same name,' to 'Data entities also have the same type if they are declared with reference to separate derived-type definitions that are in different scoping units, have the same name,' 2. Page 44, end of Section 4.4.2 [44:31+], add new paragraphs: In the case of recursive data types with the SEQUENCE property, the rules of the previous paragraph do not always determine whether two entities have the same type. For example, suppose the type declaration TYPE T SEQUENCE TYPE (T), POINTER :: P END TYPE appears identically in two scoping units. If the components have the same type, any data entities declared with the two type definitions have the same type. On the other hand, were the components to have different types, any data entities declared with the two type definitions would have different types. Whenever such a situation occurs, any data entities declared with the two type definitions shall have the same type. Similar problems occur with indirect recursions. Suppose, for example, the type declarations TYPE H SEQUENCE TYPE(E),POINTER :: F END TYPE TYPE E SEQUENCE TYPE(H),POINTER :: P END TYPE appear identically in two scoping units. Now the types must be considered together. If the two components P have different types, entities declared with the two type H definitions have different types. In general, if there is a set of k sequence types that are coupled in a mutual recursion, all k must be considered together. If it is possible to interpret two entities declared with corresponding types to be of the same type, this shall be done. -------------------------------------------------------------------------------- 3. ANSWER and EDITS in 006 ANSWER: Yes, T and T2 are the same type. An edit is provided to clarify this conclusion. Discussion: The first sentence in section 4.4.2 states, "a particular type name may be defined at once in a scoping unit." However, by the use of rename, it's possible for a scoping to have access to two separately defined derived types, that were originally defined the same name, by two different local names. For derived types made accessible by use association, the derived type name referred to in section 4.4.2 is in the corresponding . Edits are provided to clarify this. EDITS: 1. In section 4.4.2, add the following to the end of the first paragraph: [35:39] "In addition, two derived types accessible in the same scope might be the same if one or both are accessible by use association." 2. In section 4.4.2, after the second paragraph, add the following independent paragraph: [35:46] "Note that the criterion that the two types have the same name applies to the of the respective ." --------------------------------------------------------------------------------