J3/14-192 To: J3 Members From: Stan Whitlock Subject: Results of the J3 Fortran interp letter ballot #30 Date: 2014 June 18 Here are the results of J3 letter ballot #30 on Fortran interpretations that officially closed 13-Jun-2014. The ballot is in J3 paper 14-146 for meeting #204. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep F08 F08 F08 F08 F08 F08 F08 F08 / interp 099 100 101 102 103 104 105 106 result of LB #30 Y Y Y Y Y C N Y Daniel Chen Y Y Y Y Y Y Y Y Malcolm Cohen Y Y Y C C C N Y Robert Corbett Y Y Y C N Y Y Y Bill Long Y Y Y Y Y C Y Y Toon Moene Y Y Y Y Y Y N Y Dan Nagle Y Y Y Y Y Y Y Y John Reid Y Y Y Y Y Y N Y Van Snyder Y Y Y Y Y Y Y Y Stan Whitlock Y Y Y Y Y Y Y Y where Y means "yes" C "yes with comment" N "no with comment" John Reid is a non-voting alternate for this J3 vote and Malcolm Cohen is not a member of J3 but their comments are welcome and recorded here. The comments for each interp are attached below in the same order as the table above. The comments for each interp are separated by a line of "*"s. The interps marked "C" pass with some minor fixes, as noted below. The interps marked "N" fail. The edited interps in their final form are attached and will appear in the next version 006A. /Stan ************************************************************************ F08/0099 VOLATILE in specification expressions All Yes votes, no Comments, and no No votes. Result for F08/0099: F08/0099 passed by J3 letter ballot. F08/0100 IMPORT statement and prior explicit declaration All Yes votes, no Comments, and no No votes. Result for F08/0100: F08/0100 passed by J3 letter ballot. F08/0101 NAMELIST and multiple occurrences of a variable All Yes votes, no Comments, and no No votes. Result for F08/0101: F08/0101 passed by J3 letter ballot. F08/0102 MERGE and polymorphism Malcolm Cohen's Yes vote with comment on F08/0102: I think it is clear that (E) is polymorphic. Being polymorphic is not something that depends on a runtime value or a dynamic type; the statement (E) is only not-standard-conforming if it is actually executed with Y and X having different dynamic types. We could fix the example (add a new allocatable W, and W=t2(), and change example E to do a merge between Y and W instead of Y and X) but it doesn't seem particularly important. Robert Corbett's Yes vote with comment on F08/0102: The answers given agree with what the text of the Fortran 2008 standard says. I think the language would be better if MERGE were defined differently, but such a change should not be done as part of an interpretation. I do not think the edit is necessary, but I agree to its inclusion for the sake of clarity. I am slightly bothered by answer A2. It states "Only MERGE invocation E is polymorphic." The code shown is not standard conforming, for reasons given in answer A3, and so it is questionable if it is polymorphic or not. Result for F08/0102: /INTERP believes that Malcolm's comments sufficiently address Robert's concerns. F08/0102 passed by J3 letter ballot. F08/0103 Pointers to internal procedures with different host instances Malcolm Cohen's Yes vote with comment on F08/0103: The current answer (the "right answer") is the only one that is at all useful to the user IMO. The optimisability of internal procedures *as actual arguments* when they only reference SAVEd variables (i.e. they are not thread-safe) is the wrong concern. The whole point of passing an internal procedure as an actual argument is to enable stuff like thread-safety otherwise the user can just pass a module procedure instead. Anyway, we took this straw vote, including both the options of making ASSOCIATED(x,y) when they refer to the "same" internal procedure either processor-dependent or prohibited. That straw vote was 5-1-1-1-1 (right answer - wrong answer - processor dependent - prohibited - undecided). If we're going to retake it, not that I think we should, I would prefer the current answer. Robert Corbett's No vote on F08/0103: The answer given prohibits certain optimizations for little gain. An internal procedure that does not reference any variables or procedures in the host scope that are bound to a particular host instance could be implemented more efficiently if the standard made the result of ASSOCIATED with two arguments that are procedures undefined if those procedures are different instances of an internal procedure. I see little use for the two argument form of ASSOCIATED where the arguments are procedures. I see even less use for it when the two arguments refer to the same internal procedure. Result for F08/0103: /INTERP believes that Malcolm's comments sufficiently address Robert's concerns. F08/0103 passed by J3 letter ballot. F08/0104 IEEE Inquiry Functions Malcolm Cohen's Yes vote with comment on F08/0104: In the edit for [150:28+], "ISO_C_BINDING (10)" should be "ISO_C_BINDING (15.2)". (15.2 is "The ISO_C_BINDING intrinsic module".) Bill Long's Yes vote with comment on F08/0104: The edit for [150:28+] includes "...ISO_C_BINDING (10)...". I suspect the "10" should be "15". If not, I don't understand why the "(10)" is there. Result for F08/0104: /INTERP accepts Malcolm's comment and will modify the edit as stated. F08/0104 passed as amended by J3 letter ballot. F08/0105 Is the ASYNCHRONOUS attribute allowed with the VALUE attribute? Malcolm Cohen's No vote on F08/0105: ASYNCHRONOUS dummy arguments have a bunch of constraints that, and I quote "are designed to avoid forcing a processor to use the so-called copy-in/copy-out argument passing mechanism" As currently written that is not true for ASYNCHRONOUS+VALUE because VALUE forces the copy-in part of that mechanism. Furthermore, those restrictions (C1238 to C1240) do not make sense for ASYNCHRONOUS+VALUE because the dummy is not associated with the actual argument but with a copy thereof. We fixed this for VOLATILE by prohibiting it to be combined with VALUE. That is by far the easiest and most sensible fix for ASYNCHRONOUS. Alternatively, rewrite those constraints to make sense e.g. "with/has the ASYNCHRONOUS" -> "without/does-not-have the VALUE attribute and with/has the ASYNCHRONOUS" several times, and fix the NOTE so it is not "at best misleading". Nick Maclaren's comment on F08/0105: It would be clearer if after "A dummy argument with the VALUE attribute can successfully take part in asynchronous operations" it added "started and completed within that procedure". Toon Moene's No vote on F08/0105: Allowing this would make the meaning of the program depend on when the processor decides to make the copy inherent in the VALUE attribute. This seems a dangerous introduction of non-determinism in the Standard to me. John Reid's No vote on F08/0105: Malcolm's argument convinces me to vote no on F08/0105. Result for F08/0105: /INTERP agrees with Malcolm's comments. F08/0105 failed the J3 letter ballot. F08/0106 MOVE_ALLOC for a remote array All Yes votes, no Comments, and no No votes. Result for F08/0106: F08/0106 passed by J3 letter ballot. ------------------------------------------------------------------------ NUMBER: F08/0099 TITLE: VOLATILE in specification expressions KEYWORD: VOLATILE, specification expression DEFECT TYPE: Interpretation. STATUS: Passed by J3 letter ballot QUESTION: Is the following subprogram required always to print "T T"? subroutine Wobbly ( N ) integer, volatile :: N integer :: A ( n, n ) integer :: B ( n * n ) print *, size(a) == size(b), size(a,1) == size(a,2) end subroutine Wobbly ANSWER: No. There are three specification expressions in the subroutine, and the volatile variable N appears in each of them. Since, being volatile, the variable N might have a different value each time it is referenced, these three specification expressions might receive different values for their references to N. If that happens, the array sizes might well be different. EDITS: None. SUBMITTED BY: Van Snyder HISTORY: 13-298r1 m202 F08/0099 submitted 13-298r2 m202 Revised answer - passed by J3 meeting 14-xxx m204 Passed by J3 letter ballot 14-146 ---------------------------------------------------------------------- NUMBER: F08/0100 TITLE: IMPORT statement and prior explicit declaration KEYWORD: IMPORT statement, prior explicit declaration DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Q1. Does the following program fragment conform to the 2008 standard? subroutine S ( P ) interface subroutine Q ( X ) real, intent(inout) :: X end subroutine Q end interface interface subroutine P ( A ) import procedure (R) :: A end subroutine P end interface procedure (Q) :: R end subroutine S 12.4.3.3p2 says "If an entity that is made accessible by this means is accessed by host association and is defined in the host scoping unit, it shall be explicitly declared prior to the interface body." However, although the procedure R is declared in the host scoping unit it is not defined in the host scoping unit, so this is ineffective. Q2. If the IMPORT statement were changed to "IMPORT R", would that be conforming? 12.4.3.3p1 says "An entity that is imported in this manner and is defined in the host scoping unit shall be explicitly declared prior to the interface body." Again, procedure R is declared but not defined in the host scoping unit, so this requirement is ineffective. ANSWER: These examples were not intended to conform to the Fortran standard. An edit is provided. EDITS: [282:7] 12.4.3.3p1, after "imported in this manner and is" change "defined" to "declared". [282:14] p2, after "is accessed by host association and is" change "defined" to "declared". SUBMITTED BY: Van Snyder HISTORY: 13-305 m202 F08/0100 submitted 13-305r1 m202 Revised answer & edits - passed by J3 meeting 14-xxx m204 Passed by J3 letter ballot 14-146 ---------------------------------------------------------------------- NUMBER: F08/0101 TITLE: NAMELIST and multiple occurrences of a variable KEYWORD: NAMELIST DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider Program p1 Real :: x = 3, y = 4 Namelist /n/ x, y Write (*,n) End Program According to 5.6, "The order in which the variables are specified in the NAMELIST statement determines the order in which the values appear on output." However, this stops short of saying that the order is the same, merely that it determines it. Perhaps it might be standard-conforming for a processor to always produce the values in reverse order, for example. 10.11.4 does not seem to address the issue of what the order is. Q1: Is the order meant to be the same? Consider Program p2 Real :: x = 3, y = 4 Namelist /n/ x, y, x Write (*,n) End Program This program did not conform to Fortran 90, but does conform to Fortran 2003 and later. The Fortran 2008 standard says (5.6p2): "The order in which the variables are specified in the NAMELIST statement determines the order in which the values appear on output." However, there are only two variables in the NAMELIST statement, X and Y. Therefore it seems to be ambiguous whether the output should be something like &N X=3 Y=4 / or &N Y=4 X=3 / Some compilers produce &N X=3 Y=4 X=3 / but this is not an ordering of the variables X and Y. Q2. Is this program intended to conform to the standard, and if so, what is the intended output? ANSWER: A1. Yes, the order is meant to be the same. An edit is supplied to clarify this. A2. The program was intended to conform to the standard, and the output was intended to be the third option. An edit is supplied to correct the text in 5.6. EDIT: [111:13-14] 5.6p2, replace entire paragraph with "The order in which the values appear on output is the same as the order of the s in the namelist group object list; if a variable appears more than once as a for the same namelist group, its value appears once for each occurrence". SUBMITTED BY: Malcolm Cohen HISTORY: 13-314 m202 F08/0101 submitted, first option selected by straw vote - passed by J3 meeting 14-xxx m204 Passed by J3 letter ballot 14-146 ---------------------------------------------------------------------- NUMBER: F08/0102 TITLE: MERGE and polymorphism KEYWORD: MERGE, polymorphic DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider Program test Type t End Type Type,Extends(t) :: t2 End Type Class(t),Allocatable :: x,y Type(t),Allocatable :: a x = t() y = t2() a = t() Do i=1,2 Select Type (z=>Merge(a,x,i==1)) ! A Type Is (t) Print *,'ok' Type Is (t2) Print *,'FAIL' End Select End Do Do i=1,2 Select Type (z=>Merge(x,a,i==1)) ! B Type Is (t) Print *,'ok' Type Is (t2) Print *,'FAIL' End Select End Do Do i=1,2 Select Type (z=>Merge(a,y,i==1)) ! C Type Is (t) Print *,'t' Type Is (t2) Print *,'t2' End Select End Do Do i=1,2 Select Type (z=>Merge(y,a,i==1)) ! D Type Is (t) Print *,'t' Type Is (t2) Print *,'t2' End Select End Do Do i=1,2 Select Type (z=>Merge(x,y,i==1)) ! E Type Is (t) Print *,'t' Type Is (t2) Print *,'t2' End Select End Do End Program According to the standard, the type of the result of MERGE is the same as the type of TSOURCE. One might imagine that this means that the result is polymorphic if and only if TSOURCE is polymorphic. This would be a slightly unusual and unexpected asymmetry. Also, the types of FSOURCE and TSOURCE have to be the same. If this means both the declared and dynamic types, one might imagine that this means that the result is polymorphic if and only if both FSOURCE and TSOURCE are polymorphic, since otherwise the non-polymorphic argument decides the type. On the other hand, if the type requirements are talking about the declared type only, one might imagine that the result is polymorphic if either TSOURCE or FSOURCE is polymorphic. However, in any case there would seem to be an error in the standard, since the result is specified to be the same as TSOURCE, rather than the same as whichever argument is chosen to be the result value; if this refers to the dynamic type, it is contradictory when FSOURCE is chosen as the result value. And if it does not refer to the dynamic type, there appears to be no statement which says what the dynamic type of the result is. Q1. Is the apparent asymmetry between the treatment of TSOURCE and FSOURCE intended? Q2. Which of the MERGE invocations A-E are polymorphic? Q3. When the result of MERGE is polymorphic, are the dynamic types of TSOURCE and FSOURCE permitted to be different? And if they are, is the dynamic type of the result the same as the chosen argument and not necessarily the same as TSOURCE? ANSWER: A1. There is no asymmetry between TSOURCE and FSOURCE, because they are required to have the same type and type parameters. This means that both the declared and dynamic types and type parameters must be the same. A2. Only MERGE invocation E is polymorphic. An edit is provided to clarify this. A3. No, the dynamic types and type parameters are required to be the same. Note that because MERGE is elemental, it needs the type and type parameters to be the same for both the declared and dynamic types, otherwise the principle that all elements of an array have the same (declared and dynamic) type and type parameters would be broken. EDITS: [368:26] 13.7.110p4 (Result Characteristics), "Same as TSOURCE." -> "Same type and type parameters as TSOURCE. Because TSOURCE and FSOURCE are required to have the same type and type parameters (for both the declared and dynamic types), the result is polymorphic if and only if both TSOURCE and FSOURCE are polymorphic." SUBMITTED BY: Malcolm Cohen HISTORY: 13-321 m202 F08/0102 submitted 13-321r1 m202 Revised example - passed by J3 meeting 14-xxx m204 Passed by J3 letter ballot 14-146 ---------------------------------------------------------------------- NUMBER: F08/0103 TITLE: Pointers to internal procedures with different host instances KEYWORD: internal procedure, procedure pointer, host instance DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider: MODULE TYPES ABSTRACT INTERFACE SUBROUTINE SUBROUTINE() END SUBROUTINE SUBROUTINE END INTERFACE TYPE PPS PROCEDURE(SUBROUTINE), POINTER, NOPASS :: SU_PTR END TYPE PPS END MODULE TYPES SUBROUTINE CPPS(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA INTEGER I, J, N N = SIZE(PPA) DO I = 1, N CALL PPA(I)%SU_PTR() END DO PRINT *,((ASSOCIATED(PPA(I)%SU_PTR,PPA(J)%SU_PTR),I=1,N),J=1,N) END SUBROUTINE CPPS RECURSIVE SUBROUTINE OUTER(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA INTERFACE SUBROUTINE CPPS(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA END SUBROUTINE CPPS END INTERFACE IF (SIZE(PPA) .EQ. 3) THEN CALL CPPS(PPA) ELSE CALL OUTER( (/ PPA, PPS(INNER) /) ) END IF CONTAINS SUBROUTINE INNER() WRITE (*,*) 'SIZE(PPA) =', SIZE(PPA) END SUBROUTINE INNER END SUBROUTINE OUTER PROGRAM MAIN USE TYPES INTERFACE RECURSIVE SUBROUTINE OUTER(PPA) USE TYPES TYPE(PPS), DIMENSION(:) :: PPA END SUBROUTINE OUTER END INTERFACE TYPE(PPS),DIMENSION(0) :: PPA CALL OUTER(PPA) END PROGRAM MAIN Does this program print all true values? The procedure pointers are all associated with the internal procedure INNER, which might lead one to believe that the answer is yes (that is, they are all associated with the same target), but each procedure pointer at each nesting level has a different host instance, which might lead one to believe that the answer is no (and that therefore only one of each of the 3-element sequences printed will be T). ANSWER: No, the program does not print all true values; two procedure pointers to the "same" internal procedure are only associated if the host instances are also the same. An edit is supplied to the standard to clarify this. EDITS: [330:20] 13.7.16p5 Case (ii), after "with TARGET" insert "and, if TARGET is an internal procedure, they have the same host instance". [330:22] Case (iii), after "same procedure" insert "and, if the procedure is an internal procedure, they have the same host instance". SUBMITTED BY: Robert Corbett HISTORY: 13-357 m202 F08/0103 submitted with four answers 13-357r1 m202 Selected answer, added edits - passed by J3 meeting 14-xxx m204 Passed by J3 letter ballot 14-146 ---------------------------------------------------------------------- NUMBER: F08/0104 TITLE: IEEE Inquiry Functions DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot All references are to Fortran 2008 10-007r1. On comp.lang.fortran Francis Coudert asked The Fortran 2008 standard defines an inquiry function as an "intrinsic function, or function in an intrinsic module, whose result depends on the properties of one or more of its arguments instead of their values". 10-007r1 section 1.3.89 [11:27-30] I wonder: by that definition, how can the IEEE_SUPPORT_HALTING(FLAG) function from the IEEE_EXCEPTIONS intrinsic module be an inquiry function? Its result depends on the value of FLAG, not its properties. QUESTIONS: Question 1. Are the functions IEEE_support_flag IEEE_support_halting IEEE_support_rounding c_associated c_funloc c_loc intended to be inquiry functions? Question 2. Are they consistent with the definition of inquiry functions? Question 3. Are they allowed in Specification expressions? Question 4. Are they allowed in Constant expressions? ANSWERS: Answer 1. No. These intrinsic module functions IEEE_support_flag IEEE_support_halting IEEE_support_rounding c_associated c_funloc c_loc are not inquiry functions because their results depend on other than the properties of their arguments. Edits are provided to correctly identify these functions as transformational: [18:35-37] section 1.3.146 transformational function intrinsic function, or function in an intrinsic module, that is neither elemental nor an inquiry function Answer 2. No. Their current classification is inconsistent with the definition of inquiry functions. Answer 3. They should be allowed in specification expressions. Edits are provided to correct this. Answer 4. No. Only the 3 IEEE_* functions should be allowed in constant expressions, not the 3 C_* functions. Edits are provided to correct this. EDITS to 10-007r1: [150:28+] section 7.1.11 Specification expression, paragraph 2, after bullet (10), insert a new bullet: "(nn) a reference to a transformational function from the intrinsic module IEEE_ARITHMETIC or IEEE_EXCEPTIONS (14) or the intrinsic module ISO_C_BINDING (15.2), where each argument is a restricted expression," [152:7-8] section 7.1.12 Constant expression, paragraph 1, replace bullet (8): "(8) a reference to the transformational function IEEE_SELECTED_REAL_KIND from the intrinsic module IEEE ARITHMETIC (14), where each argument is a constant expression," with: "(8) a reference to a transformational function from the intrinsic module IEEE_ARITHMETIC or IEEE_EXCEPTIONS (14), where each argument is a constant expression," [407-408:24+] section 14.10 Summary of the procedures, paragraph 3, in Table 14.1, for procedure IEEE_SUPPORT_ROUNDING: change the "Class" column entry from "I" to "T". [408:1-] section 14.10 Summary of the procedures, paragraph 3, in Table 14.2, for procedures IEEE_SUPPORT_FLAG and IEEE_SUPPORT_HALTING: change the "Class" column entries from "I" to "T". [418:16] section 14.11.27 IEEE_SUPPORT_FLAG (FLAG) or IEEE_SUPPORT_FLAG (FLAG, X), paragraph 2: "Inquiry function." -> "Transformational function." [418:32] section 14.11.28 IEEE SUPPORT HALTING (FLAG), paragraph 2: "Inquiry function." -> "Transformational function." [420:4] section 14.11.32 IEEE_SUPPORT_ROUNDING (ROUND_ VALUE) or IEEE_SUPPORT_ROUNDING (ROUND_VALUE, X), paragraph 2: "Inquiry function." -> "Transformational function." [426:19] section 15.2.3.2 C_ASSOCIATED (C_PTR_1 [, C_PTR_2]), paragraph 2: "Inquiry function." -> "Transformational function." [428:9] section 15.2.3.5 C_FUNLOC (X), paragraph 2: "Inquiry function." -> "Transformational function." [428:21] section 15.2.3.6 C_LOC (X), paragraph 2: "Inquiry function." -> "Transformational function." SUBMITTED BY: Dick Hendrickson HISTORY: 14-100 m203 F08/0104 submitted 14-100r1 m203 Answer proposed 14-100r2 m203 Passed by J3 meeting 14-xxx m204 Passed as amended by J3 letter ballot 14-146 ---------------------------------------------------------------------- NUMBER: F08/0105 TITLE: Is the ASYNCHRONOUS attribute allowed with the VALUE attribute? KEYWORDS: ASYNCHRONOUS, VALUE DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: In the description of the VALUE attribute, [101:23-24] section 5.3.18p1, constraint C558 disallows the VOLATILE attribute with the VALUE attribute: "C558 An entity with the VALUE attribute shall not have the ALLOCATABLE, INTENT (INOUT), INTENT (OUT), POINTER, or VOLATILE attributes." But there is no prohibition of the ASYNCHRONOUS attribute with the VALUE attribute. Should this combination also be disallowed? ANSWER: No, the combination of VALUE and ASYNCHRONOUS attributes should not be disallowed. That is, the combination of VALUE and ASYNCHRONOUS attributes should continue to be allowed. A dummy argument with the VALUE attribute can successfully take part in asynchronous operations. ASYNCHRONOUS is different from VOLATILE so there is no compelling reason to treat the two with respect to VALUE the same. Disallowing ASYNCHRONOUS with VALUE would introduce an incompatibility between F2003 and F2008. Users would be surprised to have currently working programs suddenly give errors. EDITS to 10-007r1: none SUBMITTED BY: Stan Whitlock HISTORY: 14-109 m203 F08/0105 submitted - disallow failed 14-109r1 m203 try allow - passed by J3 meeting 14-xxx m204 Failed J3 letter ballot 14-146 Malcolm Cohen's No vote on F08/0105: ASYNCHRONOUS dummy arguments have a bunch of constraints that, and I quote "are designed to avoid forcing a processor to use the so-called copy-in/copy-out argument passing mechanism" As currently written that is not true for ASYNCHRONOUS+VALUE because VALUE forces the copy-in part of that mechanism. Furthermore, those restrictions (C1238 to C1240) do not make sense for ASYNCHRONOUS+VALUE because the dummy is not associated with the actual argument but with a copy thereof. We fixed this for VOLATILE by prohibiting it to be combined with VALUE. That is by far the easiest and most sensible fix for ASYNCHRONOUS. Alternatively, rewrite those constraints to make sense e.g. "with/has the ASYNCHRONOUS" -> "without/does-not-have the VALUE attribute and with/has the ASYNCHRONOUS" several times, and fix the NOTE so it is not "at best misleading". Toon Moene's No vote on F08/0105: Allowing this would make the meaning of the program depend on when the processor decides to make the copy inherent in the VALUE attribute. This seems a dangerous introduction of non-determinism in the Standard to me. ---------------------------------------------------------------------- NUMBER: F08/0106 TITLE: MOVE_ALLOC for a remote array KEYWORDS: allocation, coindexed DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Was it intended that MOVE_ALLOC can affect the allocation status of an array on an image other than the executing image? An example is CALL MOVE_ALLOC(A,B[I]%A) ANSWER: No, it was not intended that the executing image can affect the allocation status of an array on an image other than the executing image. Edits are provided to correct this. EDITS to 10-007r1: 13.7.118 MOVE_ALLOC(FROM,TO), para 3: [372:18] In the description of FROM, after "It shall be allocatable", add "and shall not be a coindexed object". [372:19] In the description of TO, after "It shall be allocatable", add "and shall not be a coindexed object". SUBMITTED BY: John Reid HISTORY: 14-119 m203 F08/0106 submitted - passed by J3 meeting 14-xxx m204 Passed by J3 letter ballot 14-146 ----------------------------------------------------------------------