J3/02-276
Date: 23 Sep 2002
To: J3
From: Richard Maine
Subject: Editor's comments on edits from meeting 162
This paper has the editor's comments on edits passed at
meeting 162. Nothing was done about any of these comments;
the documentation of edits made is in a separate paper.
The comments range from editorial trivia and style preferences up
to matters that I believe reflect substantiative technical errors.
paper 02-217
Note my first comment about paper 02-241r4.
paper 02-219r2
I don't understand the rationale behind the dtio-related
changes. Whether this is a shortcoming in the rationale or
in my understanding is unclear. I don't see that PASS is
even meaningful for dtio since PASS affects only how the
invocation is written, but the invocation of a dtio procedure
is not written explicitly in Fortran at all. I'm having
trouble seeing how PASS vs NOPASS for dtio would actually make
any difference at all in how any code would be written or
interpreted. This same question applies to assignment.
paper 02-220r1
Seems odd to make this fix here, but then not make comparable
fixes in the immediately following para. Indeed, grep reveals
that there are no occurences of the words "starting" and
"ending" anywhere in section 6 other than these two paras. A
quick read of these paras reveals that every usage of the
terms is actually referring to the values. Seems like a better
fix would have been to just include the word "value" in the
definitions of "starting point" and "ending point".
Though as noted elsewhere, we confuse syntax terms and values
so much as to be largely hopless to consistently fix anyway
(though not as often as we confuse entities and their names).
paper 02-221r2
[397:2,5,8] I'm dubious of these edits.
If a component is itself of derived type, I'd say that "its"
derived type definition could be misinterpreted as the one that
defines the derived type of the component. Of course, that
would be ludicrous as a scope, so the odds of anyone getting it
wrong are about the same as the odds of anyone getting the original
wrong.
397:23 It isn't new, but I still have trouble parsing this
sentence (and the similar one in the preceding para). I keep
parsing "an argument keyword of the scoping unit" as though
the "of" phrase modified "keyword". (Instead it is intended to
modify "scope" from earlier in the sentence).
398:11-12 I find the resulting wording confusing. We have both
"within a FORALL construct" and "a containing FORALL construct",
which makes it sound like we are talking about some FORALL that
contains the one that the "within" refers to. We'd probably be
better to change the "a containing" to "any containing" and then
omit the "within" phrase as redundant (if we aren't within one then
there is no containing one).
400:13,16 I can't tell whether these edits make sense or not because
I can't parse the sentences they are in (as I suspect I mentioned
when these sentences were last abused). Since the sentences talk
about multiple "accessed vias" (both host and use association, for
example), I'm suspicious that these edits still don't always tell us
which scoping unit is meant. If I could read the sentences at all,
maybe I'd know.
paper 02-223r1
I'd have said "the function" instead of "a function" in the second
edit. Everything else in the area is using "the" and the "a" seems
out of place as though it were changing the subject.
I'd also have said "that of" instead of repeating "the value of",
though that's pretty trivial. It would follow the style of the
"those of" in the previous sentence.
paper 02-224r2
[82:0+] Darned if I can figure out what is misleading about the
note, but I agree that the note didn't add anything useful
anyway.
paper 02-230r3
[382:17-25] I don't know why the result characteristics para
was omitted from the revised text. I almost wonder whether
this was accidental. Seems to me like the old result
charactersitics para was appropriate unchanged. Nothing now
says what the old para said.
I find the whole result section to be written with inadequate
preciseness. The first sentence is pretty much
incomprehensible. What is this PX thing? How does it
determine a result anyway? Not until reading the subsequent
paras can one even guess what the first one is trying to say.
It never does really say it. There is an awful lot of vague
hand-waving here without actually defining things. I'm not
convinced this is any better than just saying "you know what
this function should do". As it is, we are just asking the
reader to guess what we are trying to say.
If there is an actual term for the C "base" address, we should
use the term (perhaps just address?). If "base address"
happens to be the corect term, then we shouldn't quote the
"base". The quotes imply that we don't mean the term
literally.
[383:14-17] The result description here is less comprehensible
than that of C_LOC. IN addition to problems simillar to those
of C_LOC, it has expositional problems in confusing
requirements with conditions and the like. For example, we
have a statement that "The association status of PX has not
chamged". What does that mean? I think it is still part of
the "as if" condition, but it sure doesn't say that - it just
comes out and states it as a fact. Since PX is a fiction in
the first place, I don't know how one can state such facts
about it. Then we switch into stating what is apparently a
requirement (that's what "shall" means) on the target of PX.
Is this actually intended to be a requirement? If so, that
means it is illegal to use C_F_POINTER in such circumstances.
Or is it intended that the call be legal but give an undefined
result (much like a pointer assignment to an undefined pointer
would)? If this is a requirement on C_PTR, why isn't it stated
in the para about C_PTR?
There must be a bunch of "if"s or other conditionals missing
in the two cases. Such conditionals are not implied by just
writing case(something). Headings are just organizational
help; they don't get you out of writing the English. For
example, the requirement that "FPTR shall be scalar" is
clearly nonsense, since a few paras above we talk about
its shape. This probably means that FPTR shall be scalar
under some condition, but it doesn't say that. This needs
complete rewriting, which I'm afraid its not going to get
from me.
I am surprised that we have no requirements at all on C_PTR
except that it be a scalar of type C_PTR. Even if I assume
that the now-dangling cases are rewritten to something that
have "if"s in them somewhere, nothing anywhere says that
CPTR has to fit in either case. We just don't
say what happens if it doesn't fit.
[471:22+] I didn't even read the code in the samples. I just
inserted it with a few cut and paste operations. Assume it
was ok. The comma in the first sentence is inappropriate as
it stands; I'd have written it as ",which are" or perhaps
better (since the C processor might support them) ", which
might not be".
One or two of the code sample didn't actually have a lead-in.
For example, one just says "This may be done using C_LOC..."
and then just shows some code, without having anything like
"as follows" as a connector.
I don't think a definition in a comment in sample code is
sufficient to support using an acronym like URNG in the text,
as is done in one place.
paper 02-238r2
[81:14-17]
I wouldn't have used "also" here because I find it unclear
what it is in addition to. I'd have just given the complete
list, including a instead of implying
it with "also".
Of more consequence, I don't at all understand the bit about
"an interface body that is not in an interface block". I
don't see that we allow any such interface bodies. Seems to
me that this ought to be an interface body that is not in an
abstract interface block. The omission of "abstract" might
also be a typo, but that goes beyond what I think I can
justify on my own.
[253:25]
I thought we had some material that depended on making the
distinction that a procedure pointer was not classified as a
procedure. Alas, I forget where it was. Perhaps it is gone
by now. Perhaps it is fixed by this paper. It was a subtle
basis for distinction anyway and would probably be better
expressed explicitly. I just wish I were sure that it is gone
and that this change doesn't break it...wherever it may be.
Guess we can fix it if still needed.
paper 02-240r1
There is substantial duplication between sections 2.4.6 and
5.1.2.11. I'm not sure what criteria were used to decide
what is duplicated and what is not. I'm suspicious that
nobody noticed; there are no xrefs in either section to the
other. Particularly jarring to me was...
The first sentence of the new para in 5.1.2.11 defines the
pointer attribute, which seems appropriate, considering that's
what the section is about. But then the next 2 sentences talk
about pointers, failing to mention the relationship of such a
thing to the pointer attribute. You have to go back to
2.4.6 to see that relationship. That might be reasonable, as
the things in section 2 tend to be fundamental enough that
they get used all over without xrefs (otherwise, the number
of xrefs would be unreasonable). But as long as you have to
check 2.4.6 to understand the terminology of the second sentence,
you'll find the whole sentence duplicated, word for word.
[254:8+] I think you mean "local variable" instead of "local
entity" at the end of this edit. A dummy argument is a local
entity, so saying "dummy argument or local entity" doesn't
make much sense. See the definition in 16.0 (and in the
glossary). I once proposed defining the term "local entity"
in a way similar to the way that "local variable" is defined
in 2.4.3.1.1 (then using some other term for what we now call
a "local entity"). But I didn't get my wish on that.
[262:39-40] Although it seems reasonable to say essentially this
up front, I don't like the way that this now refers to the
bnf term before its definition. I'd have
used English instead (perhaps "a list of procedure entities")
like we do in many other similar statements.
paper 02-241r4
The edit at 16:32 seems inconsistent with paper 02-217, which
removed similar wording from 6.1.2 because it was vague and
confusing. I find it even more vague and confusing here,
where there is less context.
Note that 12.4.1.6(5) uses the term "subobject selector",
which is now undefined after the edit at 19:4. But I did it
as specified. Also, the "and" should probably now be an "or"
(likewise in the glossary).
While doing the 19:21-22 edit, I noticed that "may be" appears
to be used incorrectly (twice) in that para of the existing
text; this is supposed to be a definition (as evidenced by the
use of the tdef macro, which bolds and ads an index entry),
not permission for anything.
While doing the 20:12 edit, I noticed what appears to be an
error in the existing text. I suspect that "as an actual
argument" would be more appropriate than "in an actual
argument list". If the expression x+y appears as an actual
argument, then it seems to me that it constitutes a reference
to x and y, even though they are "in" the actual argument
list. I think this sentence is about cases where the
designator in question is the actual argument.
I also found myself at loss to figure out what the
exception is about, but I'll assume this is just my failing.
paper 02-242r2
[41:7] This doesn't look at all like a definition to me.
This uses the term but doesn't do anything
to define it. The only places that I can now find anything
even vaguely close to a definition of "component" are in
6.1.2 - defines "structure component".
First sentence of note 4.43 - but that's a pretty obscure
place and isn't normative.
2.4.3.1 - defines it parenthetically.
glossary - not normative.
[41:19+] I'm not sure why we have an isolated sentence about
accessibility of type-bound procs here. We don't talk about
accessibility of anything else in this area. Also, the "when"
is inappropriate and possibly wrong. Finally, this sentence
appears to contradict what is said in 4.5.1.8.
[47:20] I find the result hard
to parse. In particular, it is ambiguous what the ", and"
connects to. I could read it as "a subcomponent is
default-initialized...and the subcomponent is not a
subobject...". The strange comma in a 2-item list contributes
to this misreading (but removing the comma makes for other
confusions).
[47:20-22] Argh. Perhaps unnecessary for some, but it was my
only hope of understanding what the previous sentence was trying
to say. Oh well.
[56:6] This appears to me to be an unintentional technical
change. Hope I'm wrong. A nongeneric binding may be either a
specific binding or a final binding. I think this change just
eliminated overrides of final bindings.
[58:37-39] I find "for which... or that has..." to be a bit
awkward, contributing to confusion about what the "or" goes
with, but I suppose it's not wrong.
[61:11-] I have no idea how this sentence constitutes a
definition of the term "finalized". Bold is supposed to indicate
definition, not just first use (though the two are often the
same).
[61:33,35,38] I disagree that these qualifications are
unnecessary. Without these qualifications the section is
internally contradictory. These sentences now say that the
entity in question is finalized without qualification. The
new first sentence in the section doesn't qualify these
sentences; it just contradicts them. John's original, which
said "Finalization of a nonfinalizable entity has no effect"
would say what is evidently intended, but the current version
doesn't.
[74:33-34] I believe the edit done here (if I interpreted it
correctly) to be the inappropriate edit, but I did it as I
think was directed anyway. To my knowledge, the bnf
is used only in an obsolecent syntax (the one in
the line above). It is therefore appropriate to put its
definition in obs font. I do think there was a typography
error on these lines in that they were only partially in obs
font, but I think the correct form is to put the whole lines in
obs font rather than to put the whole lines in normal font.
Perhaps that fix was intended, but I can't deduce that from the
comment as phrased.
[116:13] Not new to this paper, but some of the "an"s in this
area should be "any"s. The current wording says that this
happens to exactly one argument. If there is more than one
argument meeting the conditions, then it is unspecified which
one this happens to. If no arguments meet the condition, then
apparently the code is illegal. I'm sure this is not the
intent.
paper 02-244r2
261:7 I don't see the point of including abstract interfaces
here (or at the cited 81:13-14). I think this might be a
remnant of a prior iteration of abstract interfaces. The
paper does say "Or don't have 'an abstract interface' in
either place", which seems to imply it is my choice which way
to do it, but I don't understand why the choice was left to
me. This isn't an editorial matter, as it changes the
definition of what code is legal. I suspect that the choice
was intended to be J3's, but that it accidentally was left
open. I personally suspect that the choice of omitting 'an
abstract interface' from both places would be better.
266:15-18 I think this sentence was supposed to cover a
different case than the preceding sentence. The preceeding
sentence was for type-bound procedures; I think this one was
supposed to be for procedure pointer components. So deleting
this may loose something. However, I agree that the sentence
is so awkwardly constructed that its point probably was all
but undecipherable anyway unless one previously guessed what
it must have been trying to say (and it still takes slow and
careful reading to verify that, yes, it could be interpreted
to say what was guessed).
paper 02-245r2
[88] Since here is required to be the name of a
variable, I wonder why we don't use . Is this
a remnant of a time when someone thought that other things
were allowed here, or is there an actual reason for this bnf
terminology?
paper 02-247r1
[46:3-4] I think that deletion of the last sentence of the para
leaves a hole in that we don't say what the kind is if it
isn't specified. Even though we now do require the INTEGER
specification, we don't require the kind to be explicitly
specified (and I suspect that explicit specification of
it will be relatively rare). The words in 5.1.1.1 don't
cover us because those are about the INTEGER type specifier
and this isn't an integer type specifier according to the
bnf - it just happens to look identical to one. Perhaps the
bnf should say that this is an integer type specifier, but it
doesn't.
paper 02-249r1
I also see similar cases in 9.10.4, but I did nothing about them.
(Might be more elsewhere; I didn't search).
paper 02-250r1
[257:18-19] Seems to me that another edit is needed here.
As is now, an interface block with "ABSTRACT INTERFACE" is
both an abstract interface block and a specific interface
block (since it has no generic spec).
[257:23] I'd have preferred "explicit or abstract interface"
instead of "explicit interface or abstract interface", but
that's minor.
[257:30-31] I'm dubious that "used in any way" is sufficiently
precise for normative text. The reader of the standard won't
have Malcolm's explanation of the meaning. I could imagine
"used" being incorrectly interpreted as "referenced". The "in
any way" is presumably intended to fix this, but I see it as
just extra words with no extra content. Is the procedure
"used" if it is goven the public attribute? I bet the intent
is that it not be, but without Malcom's explanation I have no
clue as to the answer to this. Even with the explanation, I'm
not entirely sure because I don't know enough about
implementation to know whether this might cause some
implementation sto generate a linkage.
Should we allow "END ABSTRACT INTERFACE"? I'm not sure of
the answer. Also not sure whether the question was thought of.
paper 02-252r2
[397:1-] The use of "may" here is inappropriate; no permission
is involved.
I didn't try to actually read the new section; I just pasted
it in and applied the formatting markup.
A phrasing something like "The itemized rules..." in the first
sentence of the new section might help people make the
connection between the rules and the numbers used in the annex
and the. Without the word "itemized", it is less clear to me.
Entered as is.
paper 02-253r2
[61:8] I think the comma grammatically incorrect. I see the
problem it is trying to fix, but adding an otherwise
inappropriate comma is a last resort for such things. This
one would have been pretty easy to fix without resorting to
such.
paper 02-254r1
[66:5-7] The wording seems unnecessarily roundabout compared
to what we use for similar restrictions elsewhere, but it is
neither new nor wrong.
paper 02-255r1
[191:14-18] I'd find this to read more smoothly with
"any part of which" instead of "of which any part".
paper 02-258r1
I'd have deleted what is now the first sentence in the second
para of PENDING= section. The sentence is purely about ID=
and is now duplicated word for word in the ID= section.
By the way, I asked about how to handle this alphabetization
quandry then this section was alphabeticized. Oh well, J3 is
free to change its mind; I've done so before.
paper 02-259r1
[163:22] I don't understand the point of this edit. (How can
a selector have those attributes without being a variable?)
[287:10] I think this edit makes the sentence both confusing
and grammatically questionable. Confusing because the reader
might think that "unallocated" modifies "pointer".
Grammatically questionable because it links nonparallel forms
of speech with an "or". ("Unallocated" is an adjective; the
phrase after the "or" is a noun phrase). These seem to me
like more serious flaws than the abuse of "allocatable" as a
noun. Note that the same use of the phrase "unallocated
allocatable" appears 11 times (by my count), and I am not
counting places where it is used as a modifier. Why change it
only this once? (Though perhaps I shouldn't ask, or all 11
might get changed to be confusing).
[196:25] I believe this to be technically incorrect.
Statements may have specifiers; operations do not. See, for
example the usage of "identifier" in the penultimate para of
9.6.1, and in 9.9.1.12, which would be pretty incomprehensible
if "identifier" were similarly replaced by "ID= specifier".
The second sentence of 9.5.1.8 specifically says we refer to
this as the identifier, which this edit then belies.
[231:29,232:1] I find the replacements harder to read than the
originals.
[232:26] I believe this edit to be technically incorrect. The
r is not a rounded value of anything. It is a number relating
to rounding, and thus might plausibly be called a rounding
value, but it is not a rounded value. It is, by definition,
either 0, 1, .5, or -.5, depending solely on the I/O rounding
mode and not on any numeric value.
[233:1] The list in this sentence is nonparallel, and I think
technically incorrect as a result. Three of the four items fit
appropriately. However the condition on w-n being positive
doesn't belong in the same sentence at all. It isn't a
definition of anything used in the table, and thus doesn't
belong introduced by "where". It is just plain a requirement
on the value of w. Indeed, as now phrased, one could argue
that it leaves a technical hole in the standard. With the
"where", it is no longer a requirement on the value of w.
Instead, it just defines conditions where the table applies.
Other conditions aren't now disallowed - they are just not
defined by this table. Also I note that the resulting sentence
is a little hard to parse because it has a 2-item "and" list
nested as one element of an outer "and" list.
[239:2] Although I agree the old sentence was hard to parse,
the revision leaves it unclear (to me anyway) whether or not
the "if" condition applies to the second clause. (It had
better apply).
[257:22] While entering this, I noticed that the antecedent
of the following "its" is unclear (could be "scoping unit"
or "interface body").
I'll just assume all the "only" fixes are correct; I can manage
to misread several of them, but then I often have trouble with
correct placement of "only" so I'm probably not a good judge.
Um...except for the one on [134:3].
I believe it constitutes a *MAJOR* unintentional techical
change. As reordered, this now *PROHBITS* the processor from
evaluating more than is necessary. The former wording left the
option to the processor. Seeing this case of what I am fairly
sure is an error in the placement of "only" makes me less
confident that the other similar changes are correct.
Umm...I also think the first two "only" changes on page 274 are
substantial technical errors. They changed this from talking
about being "only specfic" to being specific "only in a scoping
unit" (and nowhere else).
(another pair of "only" changes wasn't done because they
directly contradicted each other on where to put it).
This material on "only" can't have gotten a real review.
Perhaps J3 assumed that moving words like "only" around
can't change meaning, so it doesn't merit careful review.
I assure you that it is possible to majorly change the meaning
of a sentence by moving an "only" around. The original
paper 02-253 made a similar point, but then assumed that the
corrections were obvious. I had expressed concern in
pre-meeting email that such things were not always obvious.
My concerns appear to have been well-founded.
[275:11] This "only" change makes yet a different major
technical error in deleting the "only" entirely. It is very
diferent for something to be established to be specific
and for something to be established to be only specific. If
you miss that distinction, much of 12.4.4 becomes inconsistent
and incomprehensible. I've always found the section very
hard to read myself, but this would chnage it from hard to
impossible. Might I suggest that it is a bad idea for people
to try to make grammatical corrections to material that they
don't understand? I don't see how anyone who understood the
material could possibly have proposed this change....and I
also don't see how anyone who understood the material and
actually reviewed the edits could approve this one. See my
pre-meeting rant on the general subject of papers getting
approved without getting adequate review.
[441:9] I'm suspicious that the "only" placement here is
incorrect and also that there is a confusion of "can" and
"may". It is certainly possible (as in "can") to put
something inappropriate in a deallocate statement, but one
is not allowed (as in "may") to do so.
paper 02-263r1
[13:7]
I find the "also" in "may also be used" to be confusing.
Actually I found it confusing before because the referent for
the "also" had nothing to do with the preceeding sentence.
Now that the former referent ("may be used") is deleted, I
find the confusion worse. Did nothing about this.
I also find it strange to list the 3 kinds of interface blocks
and then say something about two of them. It leaves one
wondering what happened to the third.
[43:16+] I think you mean a bound in (rather than for) an
. I don't know what a bound for one
would be. Also, the sentence can be parsed to be referring
to a bound for a , which I doubt was
intended.
[251:1-2,4-5] I'm not entirely convinced that these sentences
still cover the issues of the interps that the originals came
from. This may be because I'm not sure exactly what does or
does not constitute being "declared in the scoping unit of a
module". Note also that, according to one of the other papers
passed at the same meeting, "explicitly" is redundant; there
is no way to implicitly get the EXTERNAL attribute.
paper 02-264
[141:18] This sentence now has a 4-element list of the form
"w, and x, y, and z", which isn't how such lists are supposed
to be punctuated. The fact that 3 of the elements of the list
are itemized doesn't actually change that. I'd have put the
first element as another itemized item instead of separating
it out like it is.
[164:11+] Apparently this now requires the => when the selector
is a named constant (since that's not a variable). Strange
requirement, but then selecting on a constant would be a strange
thing to do (but a legal one as far as I can tell).
paper 02-269r1
This paper made me wonder about the apparent inconsistency
between defined assignment and user-defined derived-type input.
Aren't the issues essentially identical for both? Shouldn't
the standard therefore treat them identically? The standard
says that defined assignment can use either intent(out) or
intent(inout), at the user's choice; I'd propose we say the same
thing here. Defined assignment was standardized in f90, so we
wouldn't want to change that without a lot better reason than
I see.
Note that the distinction between intent(out) and intent(inout)
has more consequences than just definition status. Consider
derived types that have final procedures. If I understand
correctly, a final procedure would be executed during intrinsic
input of a derived type. If I've got that straight (and I might
not - I'm still confused on several things about final procedures),
it seems odd to not even allow a final procedure in comparable
cases of user-defined derived-type input.
paper 02-270
[395:17] I don't think this edit makes any sense. If it makes
sense, then I'm more confused that usual. I presume that the
cited material at [57:3] is referring to the type-bound
specifics in the type-bound generics in question, so they are
still specifics. The new wording implies that they aren't.
Probably the words at [57:3] should be fixed instead.
[400:1] It must be me. I was having a horrible time figuring
out what this sentence was saying either before or after the
change. I almost gave up before I figured out what sense the
word "contains" was being used in. I think it would be clearer
as something like "is the host of". Since a scoping unit can
*BE* a subprogram or derived-type definition, I was thinking
that was the sense of "contains". Took me a while to
realize that this meant "contains" as in "is the host of"
instead of "contains" as in "is".