Date: Wed, 8 Sep 2021 19:30:23 -0400
My thanks to the author for addressing the feedback given on r0. I now have
feedback (below) on r1.
-- HT
I believe the author is already aware that the comment grammar should be
corrected to indicate a sequence of characters within the comment.
I believe similarly with regards to objections to using the grammar term in
prose.
As noted in the SG 16 meeting today, the paper removes the freedom for an
implementation to consider a preprocessing directive containing vertical
tab or form feed as being an error. This is a design decision that the
paper does not acknowledge as such. I believe that noting this change
clearly in the paper's design section is sufficient to remedy this.
I have the following additional concerns about the wording:
(1)
In [lex.phases],
"introducing new-line characters for end-of-line indicators"
is removed.
I do not believe that this is helpful. The presumed intent remains that
implementations may introduce line-breaks of one form or another for
end-of-line indicators that do not correspond particularly to any "physical
source file character".
Note that [cpp.line] contains a reference ("or introduced") to this text.
(2)
In the new [lex.whitespaces] subclause, the following is added:
whitespaces are ignored except as they serve to separate tokens
This seems to have come from the text being removed out of [lex.token]
(where it was excusable). Whitespace separation is significant in
[cpp.replace.general], etc. This sentence should at best be a note in
relation to phase 7 of translation.
feedback (below) on r1.
-- HT
I believe the author is already aware that the comment grammar should be
corrected to indicate a sequence of characters within the comment.
I believe similarly with regards to objections to using the grammar term in
prose.
As noted in the SG 16 meeting today, the paper removes the freedom for an
implementation to consider a preprocessing directive containing vertical
tab or form feed as being an error. This is a design decision that the
paper does not acknowledge as such. I believe that noting this change
clearly in the paper's design section is sufficient to remedy this.
I have the following additional concerns about the wording:
(1)
In [lex.phases],
"introducing new-line characters for end-of-line indicators"
is removed.
I do not believe that this is helpful. The presumed intent remains that
implementations may introduce line-breaks of one form or another for
end-of-line indicators that do not correspond particularly to any "physical
source file character".
Note that [cpp.line] contains a reference ("or introduced") to this text.
(2)
In the new [lex.whitespaces] subclause, the following is added:
whitespaces are ignored except as they serve to separate tokens
This seems to have come from the text being removed out of [lex.token]
(where it was excusable). Whitespace separation is significant in
[cpp.replace.general], etc. This sentence should at best be a note in
relation to phase 7 of translation.
Received on 2021-09-08 18:30:51