(j3.2006) Multiple & on free-form continuation?

Malcolm Cohen malcolm
Thu Aug 28 19:41:35 EDT 2014


>I agree the first case should be an error, but I don't think the words in
>the standard say that.

Yes they do.

You wrote earlier
  "I can read the words in the standard as not disallowing this. "

However, the words in the standard ABSOLUTELY DO NOT support that.  To claim 
this you Need To Show The Syntax that accepts that example.  There is none.

> This is why I think an interp is needed. Bill's
>response supports this by noting Cray and PGI disagree as to which & is the
>sentinel.

Since there are no ampersands in the syntax (outside of character syntax which 
is not relevant), assuming that the first (noncharactercontext) ampersand you 
see is a "sentinel" seems to be a perfectly reasonable response.

As does assuming the last (ncc) ampersand you see is a "sentinel".

> PGI's error message for this case, " Non-comment character after a
>'&'", isn't supported by the standard.

It most certainly IS supported by the standard which says

  "The character "&" is used to indicate that the statement is continued on the 
next line that is not a comment line."

and

   "If a noncharacter context is to be continued, an "&" shall be the last 
nonblank character on the line, ...".

and this supports PGI perfectly.  In the case of
   A = B * & &
obviously the first ampersand does not satisfy the explicit requirement that it 
be the last nonblank (noncomment) character on the line!

You earlier wrote "An & is the last nonblank character, just not the only &. I 
don?t see any words that prohibit multiple ?&? characters at the end of a 
continued line."

but I think it is rather clear that in the case of multiple ampersands, they 
cannot all be the last nonblank character!

When you attempt to parse this you can get
(1) the first ampersand is a continuation, but it does not satisfy the rules, so 
error
or
(2) the last ampersand is a continuation, but the first ampersand does not 
appear anywhere else in the syntax rules, so error.

I don't see any need to choose between those two, since they are both true!

>I will write a paper for 205, outlining the possible approaches, and we can
>discuss it then.

In my opinion there is no possible doubt that
(a) the source text is not Fortran,
(b) saying "unexpected syntax" is a perfectly reasonable error message,
(c) saying "noncomment character after &" is a perfectly reasonable message.

I see no need for any wording change here.  There are no ampersands in the 
syntax outside of
(1) character context
(2) continuation
and the example is not character context and does not satisfy the requirements 
for noncharacter context continuation.

If you want to contend that the first ampersand is not a continuation ampersand 
(a perfectly reasonable theory!), you need to show where the result satisfies 
the syntax rules.

Otherwise the similar example

   A = B + #$ &
  & 3

would have to be considered acceptable since "we don't explicitly say you cannot 
have #$ before an &"!  Yes that's a silly example, but it underlines the fact 
that ***you need to show the syntax you claim the example is following*** before 
you can assume the standard is deficient.  Just as in "A = B + & 3", there is no 
such syntax for "A = B + #$ 3".

(Not to mention we already have a pile of unnecessary interps to wade through... 
so let's not raise any more).

Oh, and if the wording change did make one of the two possible error messages 
"incorrect", that would unnecessarily constrain the implementation (and create 
unnecessary work for some subset of the vendors).  This would not be an 
improvement.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo. 




More information about the J3 mailing list