Re: A few syntax questions

Gary L. Scott wrote:
Joe Krahn wrote:

Richard E Maine wrote:

Joe Krahn <krahn@xxxxxxxxxxxxx> wrote:


So, it seems that they are included due to the presence of an implicit
RETURN, if reached, even though they are themselves not really an action
statement. Still, I think putting them in the 'action-stmt' syntax rule
is an unneeded complication. Maybe a note about implicit returns would
be better.




I'm afraid I am not interested in discussing how to optimize the bnf of
the standard. If I were to redo the bnf from scratch, I'd do many things
differently. Some of them evenhave technical impact instead of just
editorial. There are a few annoying "features" that have, in my opinion,
no real technical justification, but it would have made the bnf messier
to make them "right". (High on that list is the mess whereby -32768 is
always parsed as a unary minus operating on a positive 32768, with the
result that it overflows in 16 bits. I'm sure that can be solved; heck,
some compilers do so; it is just messier to write bnf for doing it
"right".)


It wasn't just a case of making the BNF better, but because I assumed there was a reason for it, and as *** H. pointed out, there is a reason: the END statements can have labels and ar GOTO-able.

As for the -32768 example, I guess that means that a standard conforming compiler is supposed to overflow. But, surely nodoby intends that to be the case, it's just a side-effect of how the BNF was written. To me, it makes sense just to get rid of the low-level BNF and replace it with rules.



Because it is for backwards compatibility, it seems that it would be realitvely easy to restrict newer constructs to being used only
in case sensitive (free-form) source code.




I tried suggesting that once. Actually more than once. There are a few
cases where f90 syntax is uglier than it would "need" to be if it were
restricted to free source form. And there are some inherited f77 syntax
items like that also, such as the parens in the parameter statement.

But to say that I got no interest would be an overstatement. What I got
was much more along the lines of "even if it comes out of the standard,
vendors will keep supporting fixed source form and will object to new
features that won't work in it...because their users will object."

That's the longer, polite version of the responses I got. :-)


That is a very sad stance. Did they complain about long lines for people who still have 80-column punch cards? Why not modernize the standard, and just support the new syntax in fixed format as an extension? The only sensible way to move forward is to declare things as deprecated or obsoleted and have a transition period. I am hoping that F2003 features will regain some respect for Fortran in CS departments,, and not just be coinsidered an old archaic language for old programs, but such strong support of archaic Fortran standards is a major reason why Fortran popularity continues to dwindle. Surely it is beneficial to make Fortran more respectable to new users in exchange for annoying a few people into learning 'modern' Fortran. It's hard to know if Standards members really want to modernize Fortran, or just continue to kill it slowly.

Joe

In only a very few cases does maintaining backward compatibility hinder the "improvement" process. Breaking billions of lines of old code is absolutely unacceptable.

The point is that they aren't even willing to limit fixed-format to old code, but want to continue supporting F95/F2003/etc. constructs in fixed format. Keeping old code functional is good, and being able to maintain it according to the language spec in which it was written is good. But, why even consider fixed format compatibility for F2003 features?

Joe
.