J3/08-102
To: J3
From: Malcolm Cohen
Subject: Editor's Report for 08-007
Date: 2008 January 15
1. Editorial Changes
Fixed a random "correspond with"->"correspond do".
Termified "unit" (with "input/output unit" as a synonym).
Indexed "edit descriptor" instead of "format descriptor", which latter is
a term we in fact never use even once in the text.
Indexed "scoping unit".
Finished indexing of "extensible type".
Indexed "program unit" and "block data program unit".
2. Meeting Paper Disposition Summary Table
Cut-and-pasted from the minutes and then updated as each paper was done.
07-280r1 0003 07-299 0104 07-313 DONE 07-327r2 DONE
07-281r2 0079 07-300 ~007 07-314 DONE 07-328r3 0108
07-282r2 0080 07-301r1 DONE 07-315 UTIGONE 07-329r2 DONE
07-287r2 DONE 07-302r1 0105 07-316 UTIGONE 07-330r1 DONE
07-288r1 DONE 07-303 ~007 07-317r1 DONE 07-331r1 DONE
07-289r1 s1DONE 07-304r2 DONE 07-318r1 ~007 07-332r1 DONE
07-290r2 DONE 07-305r3 DONE 07-319 DONE 07-333r1 REJ
07-292 DONE 07-306 UTIGONE 07-320r2 DONE 07-334 REJ
07-293r2 REJ 07-307 DONE 07-321r1 ???? 07-335r2 DONE
07-294r2 DONE 07-308r1 DONE 07-322r1 DONE 07-336r1 DONE
07-295r1 REJ 07-309r1 0106 07-323r1 DONE 07-337 0004
07-296r1 DONE 07-310 ~007 07-324r3 DONE 07-338 0109
07-297r2 0102 07-311 DONE 07-325r2 DONE 07-339 0099
07-298r2 0103 07-312r3 0107 07-326r1 DONE 07-340r1 0100
The 4-digit number after a paper number indicates an F03/ interp
number. "~edits" means the paper does not contain edits to the
current 007 other tha to remove a UTI. "~007" means the paper
does not pertain to the current 007 at all. "sect1" means only
section 1 passed.
???? = Malcolm thinks this has nothing to do with the 007.
3. Meeting Paper Details
07-287r2:
[7:5] Done, though this seems to have little to do with the topic.
EXTRA EDIT [14:31] Reworded to put the obsolescent items together and
obsolescent-fonted the lot ("ENTRY, or statement function").
Why is there no edit for page 14?
[27:28] We don't put "<>" into obsolescent font in this case.
[27:30] Ditto.
[27:43] Ditto.
[31:23] Which of these things is not like the others; the font usage in
this sentence is now completely impenetrable (for ENTRY it means
that ENTRY is obsolescent, for DATA it means the practice of
putting it in the executables is obsolescent).
[32] I didn't find "and ENRTY statements", so I just did "and ENTRY".
Statements includes FORMAT so would be inappropriate.
[32] I didn't find "ENTRY statements" here either, just did "ENTRY".
[116:30-31] Also did the following comma.
[119:18] Ditto.
[153:6] Done.
[153:23] Done.
[164:23] Done.
[288:15] Done.
[288] in Note 11.4 Done.
EXTRA EDIT: [292:6] \obs "an ,".
[295:8] Done.
[295:33] Not the initial comma.
[296:2-3] Done.
[298:26] Not the initial comma.
[298:28] Not the initial comma.
[299:37] Reworded to put the obsolescent things together.
[300:29-30] Done.
[326:9] Not the initial comma.
[327:14-15] Not the full stop.
EXTRA EDIT: [329:22] \obs "or ENTRY".
[330:30-332:13] Not the heading.
EXTRA EDIT: [338:4,11,14,17,18] \obs-fonted the constraint numbers; this
is in the "Statement function".
[475:10-13] Done.
[475:20] Not the trailing comma.
[478:35] Done.
[478:37] Done.
[485:6] Done.
[485:18] Done.
[485:26] Done.
[494:22+] Done.
[495:30+] "Entry Statements"->"ENTRY statements".
EXTRA EDIT: You are supposed to tell the user what to use instead, like
all the other ones do. If you cannot do that, it is NOT obsolescent.
I added a paragraph to do that.
07-288r1:
[225:8-10, 17-18] Retained "in the data transfer statement", otherwise
the incorrect syntax ref makes it meaningless since a single
can't contain both a namelist group and anything
else. (It's still a bad syntax ref, but at least the reader can figure
out what we meant.)
[225:22, 225:37-38] REJECTED.
The first sentence of the insertion duplicates part of C913.
The editor wonders why the EOR= and SIZE= requirements were not
combined, since they are identical.
[225:23,225:35-36] REJECTED ditto.
EXTRA EDIT: I combined C923 and C924, and paragraphs 2 and 3, with
wording of the latter similar to that in the rejected edits.
Hopefully this gets close to what subgroup were intending.
[229:1] Done.
[235:32] Done, but the editor wonders whether stating this in a more
positive form might read better, viz
"Unformatted data transfer is permitted only for a file that is
\termi{connected} for unformatted input/output."
[236:1] Done, but the editor wonders about the wording similarly.
[239:26-28] Retained the closing full stop.
The editor wonders why these three bullet items quote the character
value, and not with Fortran quotes either, in opposition to our
practice elsewhere in this clause and throughout the whole rest of
the standard.
07-289r1 section 1:
[260:18] Done.
[261:23-25] Done.
[261:36] Done.
[262:3] Done.
[262:20] Done.
07-290r2:
[230:19] Deleted "input/output list" instead, since I don't know what an
"effective list item" is (that was complaint UTI 141!).
[232:1-2,4] Done.
[263:14-18] Done.
Since UTI 141 said "Please review this" it might have been nice to say
whether you thought I got it right.
Deleted UTI 140 and 141.
07-292:
[64:13] Did the edit (the "definition" is wrong) but...
The commentary says "Objects are then covered by 4.5.1p5 at [64:15].",
and this is completely incorrect - 64:15 defined *components* of an
object, not *direct components*. The paper goes on further to say "The
intent is that the term is defined both for types and for objects."; if
so, it has failed in that intent. It further says "As is, 4.5.1p4 only
defines the term for objects." which is incorrect, it already defines
the term only for types, the "object" in the definition is being used
referentially not definitionally.
Since a quick grep reveals the only usage of direct components being in
relation to the type we are probably ok...
07-293r2:
REJECTED. If the definition of subcomponent is wrong for here, it must
be wrong for everywhere. Certainly in A%PTR%COMPONENT, COMPONENT is
***NOT*** intended to be a subcomponent of A (that just does not make
sense). It is a subcomponent of A%PTR but not of A. If the definition
of subcomponent gets that wrong, fix the definition. And direct
component is wrong here because we are talking about objects not types.
07-294r2:
[441:18] Also inserted "assigned the value" after later "is".
[442:10] Also changed "the value is" to "it is assigned the value".
[442:22] Done.
[442:25-26] Done, but this is ambiguous so the UTI is not yet resolved.
[443:5] Done.
[443:8] Done.
[443:19] Done.
[443:21-22] Done.
Modified UTI 133.
07-295r1:
REJECTED. Applying this edit results in a direct contradiction with line
6 on the same page instead of a lie. That's not enough of an
improvement to be worth doing.
07-296r1:
[11:22] REJECTED reference insertions. These are defined terms.
They are defined in clause 2, not clause 12. The references into
clause 12 are wrong anyway. Did the deletion.
[296:20-21] Done, though I still think it would be better as a note.
[297:9] Done.
Deleted UTI 139.
07-301r1:
[16:9-11+] Done.
[95:2-3] Done.
[459:7-8] Done.
[470:2] Done.
[470:4] Done.
[470:8] Done.
EXTRA EDIT: [471:2] Did the obvious edit.
[471:3-4] Done.
[471:11] Did "have a name that has external linkage" instead.
[471:34] Done.
[635] Instead, indexed it everywhere it occurred, and make p459 the
defining occurrence. I think we need to mention that we use
defined terms from C somewhere though.
Deleted UTI 143.
07-304r2:
[316:28+] Done. This is much better.
Deleted UTI 130.
07-305r3:
[317:3-] Done.
I note that after the previous paper, these two adjacent notes have very
similar examples and riff on very similar themes.
They probably ought to be combined into a single note with a single
example that makes all the points that need to be made.
Deleted UTI 131.
07-307:
[467:1] Done.
[467:7] Done.
07-306:
Now that the authors have explained (via those notes) what they really
mean by this I accept that this sentence I was complaining about is not,
strictly speaking, incorrect. I still think it is horribly misleading,
but I'm not going to spend time trying to come up with wording that
explains it better. Maybe the situation with dummy co-arrays should
actually be properly explained, or referred to, but enough for now.
Deleted UTI 125.
07-308r1:
[236:32-33] To get this to work properly, deleted "procedures",
"allow"->"allows", and deleted "process" in the insertion (I see
no process here, just a facility).
Also, I changed the procedures from "UDDTIO procedures" to
"defined input/output procedures" everywhere I found it, including
here. Seems to work best...
[164:20-21] Deleted definition of "defined elemental assignment
statement" because it was never ever used.
I did a reasonable job of indexing "defined assignment", but 90% of the
way through found some indexing for "assignment!defined". Do we really
want this? If so, it should be done that way everywhere (this is merely
a case of using a different macro).
I didn't bother to index "defined operation", partly because in some
places I happen to know we use "defined operator" instead. Grr.
07-311:
[449:2-3] Done.
07-313:
There seems to be a bit of "interesting" design here, quite unlike our
other intrinsic procedures in the way it uses the KIND argument. For
NEW_LINE, for example, we actually provide an argument of the right
kind instead of using a KIND argument to get the one we want. That
would seem to be eminently doable for MASKL and MASKR too; just have
them return a value with the same kind as I, no need for any optional
argument at all. It means if one has a default integer X with value
37 one probably wants MASKL(INT(X,int64)) but that's hardly much of an
imposition.
[345:LOGICAL+] Done.
[393:29+] I utterly reject "BIT_SIZE(M)" as being in any sense
appropriate for describing the requirement on I. What is it
supposed to mean in the context of IMPLICIT LOGICAL(A-Z)?
Rewrote to say what we mean, but it's a bit ugly. We don't
have these problems with other intrinsics because these use
KIND in a funny way (see above).
Done.
07-314:
[340:7-9] Done.
07-315:
It is depressing to have my main complaint about obtuse phrasing being
taken as a request for a technical change. It is ironic that I
complained about the obtuse phrasing being used instead of saying that
the operation is being applied elementally, the authors reject that
complaint and then in the very next paragraph talk about the "elemental"
nature of the collective subroutines!
The text at question is in Annex B; it is MEANT to be explanatory.
Well, I guess we don't want to explain it to the users in the same words
we use amongst ourselves then.
Deleted UTI 119.
07-316:
Thanks for the review.
Deleted UTI 137.
07-317r1:
[96:21+] Done.
[316:24-28] Done.
[317:2] Done.
Deleted UTI 129.
07-319:
[334: 13] Done.
[334:30] Done.
07-320r2:
[217:12-13] Also deleted "of a program" to make it read better.
07-322r1:
[339:18-] Done.
[339:19-20] Done with a slight wording change, but it is still a bit
complicated ... maybe something a bit more like
"On every image of the team, the ultimate arguments for each
corresponding co-array dummy argument shall correspond as described
in \ref{D2:Co-array}."
would be better? (I don't think that is quite there yet though.)
I made this sentence a separate paragraph.
Deleted UTIs 127 and 128.
07-323r1:
[12:6] Deleted "for data" (ungrammatical and incorrect).
Why incorrect? Because the cross-team reduction operates using data
that is not local to the image (otherwise the result would necessarily
be different on each image!).
[201:9-11] Done. Is there a competition for the longest sentence?
[222:8] Done.
[337:15-17] Deleted "for data" (same reasons).
[337:18] Done.
I'm not entirely convinced this yet has quite everything in the right
place, but it is a big enough improvement that I
Deleted UTI 138.
07-324r3:
[31:12] Inserted ", input/output units," instead (we normally just use
"unit" in a context where we are thinking about i/o, but in a few
places we use "input/output unit" for clarity; I think it is better
here too.
[209:12] This isn't a requirement the user has any means of satisfying.
Added UTI 144.
[215:5] I really don't like this blanket statement, but it's probably ok.
[217:16-19] Didn't delete "to the unit". "is of"->"has".
[222:14-17] This seems to make note 9.23 bad; inserted UTI 145.
Deleted UTI 142 (though without careful reading it is not quite clear how
you have gotten away without needing units to become image-associated
on OPEN with a connect team).
07-325r2:
[265:35] Done.
[265:37-38] Done. Thank you for giving the actual \ref!
[265:41-266:2] Done.
[266:3] Done.
[266:7-9] Done.
[266:9+] Done.
[266:10-11] Also deleted ", respectively".
[266:19-20] Done.
[271:1-] Done. Added UTI 146 because of the quiet change in the
semantics of BOZ editing for integers (they did it on the value before,
not on the internal representation). Deleted "denoting ..."; this is
either completely content-free or a contradiction. Anyway, what it is
that an output form "denotes" isn't something within the remit of the
standard. For all we know it might be denoting machine poetry.
07-326r1:
[56:15-57:9] Called the new subclause "Binary, octal, and hexadecimal
literal constants" instead. We don't ever use the made-up
word BOZ so used the syntax term instead. Reworded the
original sentence that implied only hexadecimal constants
were BOZ.
It is annoying that we have thrown away centuries of maths in favour
of reinventing the wheel, badly. There was absolutely nothing wrong
with the previous approach. A pity also that people insist on putting
philosophical garbage about having "no type" in the standard. No, the
fictions about subroutines and class(*) are fictions with a purpose,
and have a standard effect. This philosophical nonsense doesn't, and
is just false -- does noone know type theory? Inserting all this
counterfactual nonsense, reinventing positional arithmetic notation,
just makes us look like a bunch of ignorant dinosaurs.
[57:3] Did this very bad idea.
[57:5] Ditto.
[57:6-9] Done. The only edit in this paper that was actually useful.
07-327r2:
This is just so silly. A lot of work that achieves almost nothing apart
from obfuscation. I really resent working to make the standard worse
when there is no functionality being added.
[110:26] Done, the only useful edit in the paper.
[110:31-33] Done, a complete waste of time and energy. And why did you
ask me to delete the first sentence and type it in again? Perhaps
you think I have nothing better to do? Please DO NOT DO THIS AGAIN
in future. (Yes, I have to go through and convert J3-notation into
LaTeX, it is not a simple cut-and-paste, so this was an exercise that
could only result in errors not in any improvement.)
[386:26-28] We've just been through the ridiculous exercise of saying
that a bit pattern "has no type" (sic), so how can we use it now.
("If false" implies everything including other false statements.)
Furthermore, the interpretation of the value in F2003 is *NOT*
processor dependent. We do not have a mandate to remove F2003
facilities. Added UTI 149.
[411:25] Done.
07-329r2:
[342:Table 13.1] Done. Could we not have put these in with the other
functions that have special needs?
[358:26+] Slightly edited. Did by cut-and-paste, so I hope there were
no wording changes other than the conditions between these.
These are all missing (the required) examples. Added UTI 150.
07-330r1:
[382:18-21] Done.
[384:34-385:1] Done.
[386:33-36] Done.
[371:14-18] Called the shift argument SHIFT like it's supposed to be.
[371:27-31] Called the shift argument SHIFT like it's supposed to be.
[371:19] Done.
[371:32] Done.
[382:22] Done.
[385:2] Done.
[386:37] Done.
[371:21+] Done.
[371:34+] Done.
[397:34-398:2] Simplified MASK requirements. Why is this function not
3-way symmetric with regards to its type requirements?
[398:3] Greatly simplified conversion statements.
[417:9] Done.
07-331r1:
[229:27] Done. Hopefully this edit was chosen because we got the
definition of "variable" right, not because we want to read functions
from a unit (I didn't check).
Deleted UTI 132.
07-332r1:
[436:16] REJECTED. This repetitious repetition of the exactly phrasing
of the sentence before, which is what this is talking about, adds
nothing I can see other than ink and enhanced difficulty of
comprehension. Especially since we repeat that "kind of real" at
the end.
[436:17] Done.
[436:18-19] This rewording achieves precisely nothing. Done anyway.
[436:23] Achieves if not nothing then certainly only a subnormal (it
was implicit before). Done anyway.
[436:24-26] Done.
None of this has addressed the main topic of 135, and the text
remains contradictory.
Modified UTI 135.
07-333r1:
It seems to have passed by the authors of this paper that we are not
editing the IEEE standard and its terminology is not our own. It
doesn't help that they misquote it (hint - "add" is not an operation).
As for
Note to editor: The 1985 IEEE standard uses "", not
"between... and..." or a double-arrow symbol.
it is a complete irrelevance what typographical conventions the IEEE 754
standard used (they aren't going to be used in 754R even!).
REJECTED.
This paper contains technical changes which are certainly not mandated
by WG5 and which do not even make sense. I know there are some people
that think that NaN/Inf/subnormal values are the only ones of interest
(a few others include "negative zero") and that normal numbers do not
matter, but that is not a viewpoint I can agree with.
The inserted paragraph says that our intrinsic SQRT, ANINT, AINT, INT,
MOD functions all have to obey IEEE for the above special values. It
is ridiculous to allow SQRT(2.0) to return 1.4 (not a very accurate
result) but to require SQRT(2.0E-37) to return the EXACT IEEE square
root. Why did we bother to have IEEE_SUPPORT_SQRT then?
Since this paper does not call out this TECHNICAL CHANGE, and has no
passed specifications, I am assuming that this was inadvertant.
07-334:
This wasn't processed at m181 because the existing text, though
admittedly confusingly written, got things right in the presence
of ENTRY and internal procedures... and it was less than clear that
the suggested replacement did that. I would be more enthusiastic about
this change if there had been any mention of these concerns and whether
they were misfounded, or had been properly taken into account.
REJECTED.
I got as far as the third edit before finding it obviously incorrect.
(An ENTRY statement does not specify the name of a subprogram.)
This does not alleviate my fears about it breaking existing text.
Sorry, but I am sending this back to subgroup for further revision.
07-335r2:
[56:5] Done. This is somewhat redundantly worded, but since the whole
thing is completely silly (just using standard maths we only need
three sentences max to get the whole effect) I've not bothered to
wordsmith it.
[339:21+] Oh really. Couldn't a better title be thought of?
[340:3] Done.
[340:5+] Sure, but we already said we were talking about nonnegative.
[340:11+] Did some obvious fixups (like the broken list, extraneous
unnecessary words). Didn't fix all the bad wording though. And
what about DBLE and CMPLX - does this not apply there? Added UTI 148.
[465] Deleted Note 15.9 instead. BITS is never coming back with the
\bits LaTeX macro, since meeting 182 made incompatible changes to
some of the bits intrinsics. (Up until that point I had intended to
keep \bits in parallel, but with the incompatible changes I have
given up.)
[568:5+] REJECTED. This is already completely covered by line 5 (we
don't go into *ANY* detail on *ANY* of the intrinsic function stuff
here, we just punt the user to c13). If there is anything that is
not covered, I bet it doesn't just apply to negative integers.
07-336r1:
[342ff] Done.
[427:9] Done. This is inconsistent with the meaning of "intrinsic".
Added UTI 147.
[427:11] NO ONE THOUSAND TIMES NO. Presumably the whole point of making
this intrinsic module "nonintrinsic" (ha!) is to reduce its importance
and visibility. So you DON'T mention it first. Added as a second
sentence instead.
[430:27+] Did random editorial fixups. The proposed table title is
ridiculously long - shortened it to "functions with special needs".
===END===