jlg@a.UUCP (Jim Giles) (03/03/88)
In the previous article in this series, I stated the criterion I would use to determine desirability of new features in Fortran 8x. This was: > The criterion for Fortran 8x features (in my opinion) should be to > certify existing practice or to extend the language in a significant > way. I will use this criterion throughout this discussion. To this criterion I would like to add the following reservation: If a new feature costs little to implement and doesn't negatively effect users who don't use the new feature, then I don't care whether the new feature is included or not. In this class of 'irrelevant' features are such things as the free source form, DO TIMES, DO WHILE, and REPEAT UNTIL. All these features can be implemented with minor changes to the 'frontend' part of a compiler, some even in the lexical scanner alone. Clearly, people who don't use these features won't be effected at all. The old fixed source form is not even deprecated, so continued use is not in future danger either. Some people have requested that the free source form be implemented only if a filter from the old for is a required environment utility. Why bother? The old source form will continue to work, there is not even a need to recode. (Besides, a week with yacc or shorter with a more powerful tool would suffice to write the required filter - in Fortran itself if you want.) If the free source form IS left in the language, it should include significant blanks (as inter-token delimiters) and it should allow the continuation mark (&) to appear either on the line to be continued or on the continuing line (with both places required for continued character constants of course). The other features (DOs and REPEATs) are just simple translations into the equivalent: DO 5 TIMES => DO IVAR=1,5 ! IVAR is a unique temporary integer ! or may be implemented in whatever ! way the compiler chooses. DO WHILE (COND) => 1234 IF (COND) THEN ... ... ! 1234 is a unique parse generated label END DO GOTO 1234 REPEAT 5678 CONTINUE ... ... ! 5678 is a unique parse generated label UNTIL (COND) IF (COND) GOTO 5678 Clearly, these feature don't add to the complexity of the compiler much, and they OBVIOUSLY don't handicap existing users any. J. Giles Los Alamos
reeder@ut-emx.UUCP (William P. Reeder) (03/04/88)
In article <501@a.UUCP>, jlg@a.UUCP (Jim Giles) writes: > > The old fixed source form is not even deprecated, so continued use is > not in future danger either. > Please see page B-5, lines 15-25 of S8.104, where it says: B.3.2 Redundant Functionality. The features identified below are deprecated simply because they are now completely redundant, ... ^^^^^^^^^^ ... (1) Fixed source form -- replaced by the free source form (3.3.1) ... Sounds to me like fixed source form is deprecated. Now look on page A-4, lines 75-90, and page A-5, lines 1-13: A.3.2 Rules for Supplementary Standards. Some rules governing the preparation of supplementary standards based on procedure and module libraries are: ... (4) Standard modules must not use obsolescent or deprecated features ... ^^^^^^^^^^^^^^^^^^^^^^^^^ ... Sounds like the use of fixed source form IS in danger -- if I want my package to be considered as a supplementary standard (perhaps for 2d or 3d graphics) then I had better not use fixed source form. -- William {Wills,Card,Weekly,Virtual} Reeder reeder@emx.utexas.edu The Looniversity of TexMex at Autism, Consternation Central, Austin TX 78712 DISCLAIMER: I speak only for myself, and usually only to myself.
jlg@a.UUCP (Jim Giles) (03/05/88)
In article <1066@ut-emx.UUCP>, reeder@ut-emx.UUCP (William P. Reeder) writes: > B.3.2 Redundant Functionality. The features identified below are > deprecated simply because they are now completely redundant, ... > (1) Fixed source form -- replaced by the free source form (3.3.1) > Oops, you're right. But what I said still applies with the following modification: Fixed source form should not be depricated. J. Giles Los Alamos