J3/14-271r1 To: J3 From: Malcolm Cohen Subject: Action items arising from 14-239 Date: 2014 October 17 1. Introduction This paper contains the dispositions for action items in 14-239. These are (1) edits needed (included), (2) no action required, or (3) action deferred to a future meeting. 2. Action (and rejection!) items in order of occurrence in 14-239 When context is needed it precedes the copy of the ACTION directive. The proposed disposition of the ACTION is listed in the RESULT directive. (1) ACTION: I wonder if "pending communication affector" and "pending input/output storage sequence affector" should be indexed. (These occur in c05, c09, c15 and maybe c16.) RESULT: Yes, as "pending affector"; edit below. (2) ACTION: If you want what was left of NOTE 5.25 reinstated, please ask. RESULT: No action. (3) 188r1 edit for [292:0+7-8] Entered as specified, but the paragraph still seems a bit hard to read. Perhaps this should be more substantially rewritten? ACTION: Review for possible further wordsmithing. RESULT: No action. (4) 188r1 edit for [525:25-27] p1 is still broken,... ACTION: Rewrite p1. RESULT: Yes; edit below. (5) ACTION: Review example code typesetting in Annex C, correct paragraph numbers that I did not fix this time, make all inline examples indented - none of those should be flush left - probably best to indent everything the same amount. RESULT: Yes; edit below. (7) 202: ACTION: Review this BNF for possible simplification or renaming. RESULT: Yes, rename to ; edit below. (8) 175r3: REJECTED. RESULT: This was addressed by paper 14-270. (9) 172: REJECTED. RESULT: This is being pursued through the interp process, see 14-241r1. No further action required here. (10) 179r2: ACTION: Check other keywords, in particular the prefix/suffix ones, and change all to the new keyword macros so they will be indexed and hyperlinked consistently. RESULT: Yes; edit below. (11) 198r1: ACTION: (1) We should require the exponent for zero to be zero. (2) We should explicitly state that the exponent shall be chosen so that the first hexadecimal shall be nonzero, but that there is no other constraint. (3) OR, we should decide on how to choose the exponent so that the output is completely portable. RESULT: Yes, do (1) and (2). (12) 198r1: ACTION: The example tables in other edit descriptors have inconsistent capitalisation. I suggest "First word only capitalised". RESULT: Yes. (13) 198r1: ACTION: We say "the form of the output field" (here and elsewhere) but do not say "without embedded blanks" (the form includes embedded blanks!). We should probably say it explicitly. Do we say somewhere that it can have leading blanks? I don't see it for e.g. EN editing. Also, we usually have blanks in between each syntax item in the form, except between the mantissa and exponent. The form for E and D has a blank between the optional sign and the optional leading zero, but nowhere else. We should change them all to have a blank in between each item. RESULT: (i) Yes, change E and D to have a blank in between each item. (ii) If reasonable words can be crafted, specify no embedded blanks. (14) ACTION: 14.10 Summary of the procedures, p4, states that the elemental functions are available for "all reals X and Y". This does not handle IEEE_QUIET_compare which has (A,B), nor IEEE_FMA which has (A,B,C). It also does not mention integers (IEEE_SCALE) or logicals or indeed subroutines (IEEE_GET_FLAG). Maybe, either delete the text (probably bad) or state that unless otherwise specified, arguments of intrinsic type are accepted regardless of their kind type parameter value? RESULT: Defer consideration to meeting 206 (15) NO UTI BUT ... "14.5 Underflow mode" is now described wrongly; the IEEE standard includes an "abrupt underflow" mode ("alternate exception handling"). RESULT: Yes, but defer edits to meeting 206. (16) ACTION: Consider rewriting 14.5 to reference IEEE section 8.2. RESULT: Defer consideration to meeting 206. (17) ACTION: Should "underflow mode" and "halting mode(s)" not be indexed? RESULT: Yes; edit below. (18) NO INTERP/UTI BUT ... "TYPE(IEEE_STATUS_TYPE)" is factually incorrect, the type is called "IEEE_STATUS_TYPE", the "TYPE()" stuff is just the syntax around *SOME* (not all) appearances of the type name! ACTION: Get rid of remaining extraneous "TYPE("...")" syntax in prose. RESULT: Yes; edit below. (19) EXTRA: [c14] - Changed some examples to have a space between the procedure name and the opening parenthesis, just like we do when we write function references in normative text, and hyperlinked the name to the function definition. - Used the deftype family on IEEE_ROUND_TYPE. - Changed some colons in examples to ellipses. END EXTRA ACTION: (1) Check other examples in c14 for inconsistent spacing. (2) Use \deftype macro family for all IEEE module types. (3) Change colons that should be ellipses to ellipses. RESULT: Yes; edit below. (20) NO INTERP/UTI BUT >>> 14.8 Exceptional values ... "inquiry functions ... are provided to determine whether these facilities are available": what facilities? Needs rewording, especially since we actually say what the inquiry functions mean twice already elsewhere (14.9 plus in the function desc). ACTION: Reword. RESULT: Yes, but defer edits to meeting 206. (21) DESPARATELY SEEKING WORDSMITH: The various functions are "provided to inquire whether the processor supports..." Why do we have this unnecessary and undesirable rationale here? Just say (1) what "support" means, and optionally (2) function IEEE_SUPPORT_XYZ "inquires" or "returns", don't try to say why we provided the function! ACTION: Remove unnecessary waffle, replace with requirements if needed, or with simple statements of fact if appropriate, or just delete if nothing is needed here anyway. (I think we generally want some statement of facts...) RESULT: Yes, but defer edits to meeting 206. (22) MISSING EDIT: 14.9p1 various bullets seem to be totally wrong. ACTION: Paragraph needs a complete rewrite. RESULT: Yes, but defer edits to meeting 206. (23) ACTION: If people think we should use the word not the symbol, this should be changed. If people like it we could consider using the symbol in other places. RESULT: Yes, continue to use the word in prose like "an IEEE infinity", but when referring to the mathematical value use the infinity sign; edit below. (24) ACTION: We variously say "shall be a scalar of type blah", "shall be a blah scalar", "shall be scalar and of type blah". for intrinsic blah, we should always use the second formulation; for derived blah, we should always use the first formulation. RESULT: Check for the third formulation and change it to one of the others; edit below. (25) 184r4: ACTION: Perhaps some more thought is required. RESULT: This is connected to UTI 010; deferred to meeting 206 (JOR and/or DATA and EDIT). (26) 191r3: REJECTED. RESULT: This was addressed by paper 14-243. (27) 191r3: ACTION: Raise an interp request for the apparent defects. RESULT: This was addressed by paper 14-242. (28) ACTION: Consider indexing "error termination" everywhere it appears, and maybe hyperlinking it back to clause 2? RESULT: Yes; edit below. (6) ACTION: Make SOURCE= a "proper" specifier (e.g. using \defspecifier), hyperlink all references to it, index significant refs to it. RESULT: Yes, also MOLD=; edit below. 3. Edits to 14-007r2 [throughout] Index "pending communication affector" and "pending input/output storage sequence affector" as "pending affector". {(1). These occur in c05, c09, c15 and maybe c16.} [throughout] "concurrent-triplet" -> "concurrent-control", including in concurrent-triplet-list. {(7).} [throughout] Check keywords, in particular the prefix/suffix ones, change all to the new keyword macros, and use those macros everywhere for automatic indexing and hyperlinking. {(10).} [throughout] Index "underflow mode" and "halting mode(s)" (the latter as singular. Hyperlink to their definition subclause in c14. {(17).} [throughout c14] Change "TYPE(derived-type-name)" to "derived-type-name" for e.g. IEEE_STATUS_TYPE, in prose (not code samples). {(18).} [throughout c14] (a) Check examples for space between the procedure name and the left parenthesis; (b) hyperlink those procedure names to the function definition, if they are not already; (c) use \deftype for all IEEE_ derived types; (d) change colons in examples that are intended to be ellipses to actual ellipses. {(19).} [throughout] "infinity" -> "$\infty$" when and only when talking about the value infinity. {(23).} [throughout] Change "shall be scalar and of type blah" to "shall be a scalar of type blah" for derived types, to "shall be a blah scalar" for intrinsic types. {(24).} [throughout] Index "error termination" everywhere it appears, and hyperlink back to clause 2. {(28).} [throughout Annex C] Check all code examples in Annex C, correct any broken paragraph numbering, indent all inline examples by 7 spaces, indent noninline examples the same if space permits. {(5).} [539:5-10] C.9.2 Procedures defined by means other than Fortran, p2, delete "Procedures defined by ... to be an external procedure." and join the remnant sentence "The means ... 1539." to p1. Append a new sentence "A procedure defined by means other than Fortran is considered to be an external procedure." {(4) Say nothing about global names as they are not necessary given the existence of C_FUNPTR.} ===END===