JOR Items on Deleting Archaic Features

                 by Craig T. Dedo
                  April 17, 1996

<FORTREQ>
<NUMBER>    102
<TITLE>        Delete Arithmetic IF
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  The Fortran 2000 standard should delete the arithmetic IF construct
(8.2.4, B.2(1)).
</REQUIREMENT>

<JUSTIFICATION>
  The arithmetic IF is a construct left over from the 1950s when Fortran
was designed to run on a particular machine, i.e., the IBM 704, which had
an instruction set which was particularly well suited to this form of
branching.  Continued use of this feature encourages the construction of
difficult to follow, spaghetti-style control flow.

  The arithmetic IF can be replaced by the block IF construct, which is an
easier to use and more generalized form of the IF control structure.  The
availability of sophisticated, highly reliable code restructuring tools means
that converting arithmetic IF constructs to block IF constructs can be done
automatically, efficiently, and economically.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  Delete section 8.2.4 from the standard.  Enter the text of 8.2.4 into
Annex B as part of section B.1 for the benefit of those vendors who wish to
continue supporting the arithmetic IF feature.  Most likely, the person who
does the work will have to find the other places in the standard where this
construct is mentioned.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.  As noted above, users of older codes can easily convert their
arithmetic IF constructs to block IF constructs.
</ESTIMATED IMPACT>

<SUBMITTED BY>
  Craig T. Dedo
  17130 W. Burleigh Place
  Brookfield, WI   53005
  (414) 783-5869
  E-mail: Craig.Dedo@mixcom.com
</SUBMITTED BY>

<REFERENCE>
  X3J3 / 96-007r0 8.2.4, B.2(1)
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-070
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>    103
<TITLE>        Delete Non-Block DO Constructs
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  The Fortran 2000 standard should delete the non-block form of the DO
construct (8.1.4.1.2, 8.1.4.2, B.2(2)).
</REQUIREMENT>

<JUSTIFICATION>
  The non-block form of the DO construct is a construct left over from the
1950s and 1960s when little was known about how to write code so that it
would be easy to follow.  The high cost of main memory and disk space in
those years also put a high premium on writing Fortran so that it would
occupy as little space as possible.  Continued use of this feature encourages
the construction of difficult to follow, spaghetti-style control flow.

  The non-block form of the DO construct can be replaced by the block
form of the DO construct, which is an easier to use form of the DO control
structure.  The availability of sophisticated, highly reliable code
restructuring tools means that converting non-block DO constructs to block
DO constructs can be done automatically, efficiently, and economically.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  Delete section 8.1.4.1.2 and the second paragraph of 8.1.4.2 from the
standard.  Move the text of both parts into Annex B as part of section B.1
for the benefit of those vendors who wish to continue supporting the non-block
DO construct.  Most likely, the person who does the work will have to
find the other places in the standard where this construct is mentioned.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.  As noted above, users of older codes can easily convert their
non-block DO constructs to block DO constructs.
</ESTIMATED IMPACT>

<SUBMITTED BY>
  Craig T. Dedo
  17130 W. Burleigh Place
  Brookfield, WI   53005
  (414) 783-5869
  E-mail: Craig.Dedo@mixcom.com
</SUBMITTED BY>

<REFERENCE>
  X3J3 / 96-007r0 8.1.4.1.2, 8.1.4.2, B.2(2)
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-070
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>    104
<TITLE>        Delete Computed GO TO Statements
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  The Fortran 2000 standard should delete the computed GO TO
statement (8.2.3, B.2.2).
</REQUIREMENT>

<JUSTIFICATION>
  The computed GO TO statement is a construct left over from the 1950s
and 1960s when little was known about how to write code so that it would
be easy to follow.  The high cost of main memory and disk space in those
years also put a high premium on writing Fortran so that it would occupy
as little space as possible.  Continued use of this feature encourages the
construction of difficult to follow, spaghetti-style control flow.

  The computed GO TO statement can be replaced by a CASE construct,
which is an easier to use and more generalized form of the same kind of
control structure.  The availability of sophisticated, highly reliable code
restructuring tools means that converting computed GO TO constructs to
CASE constructs can be done automatically, efficiently, and economically.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  Delete section 8.2.3 from the standard.  Move the text of section 8.2.3
into Annex B as part of section B.1 for the benefit of those vendors who
wish to continue supporting the computed GO TO construct.  Most likely,
the person who does the work will have to find the other places in the
standard where this construct is mentioned.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.  As noted above, users of older codes can easily convert their
computed GO TO constructs into CASE constructs.
</ESTIMATED IMPACT>

<SUBMITTED BY>
  Craig T. Dedo
  17130 W. Burleigh Place
  Brookfield, WI   53005
  (414) 783-5869
  E-mail: Craig.Dedo@mixcom.com
</SUBMITTED BY>

<REFERENCE>
  X3J3 / 96-007r0 8.2.3, B.2.2
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-070
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>    105
<TITLE>        Delete Fixed Form Source
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  The Fortran 2000 standard should delete fixed form source (3.3.2,
B.2.6).
</REQUIREMENT>

<JUSTIFICATION>
  Fixed form source was designed when the principal machine-readable
input medium for new programs was punched cards.  Now that new and
amended programs are generally entered via keyboards using text editing /
word processing software and stored on disk files, it is unnecessary
overhead and error prone, to have to locate positions 6, 7, and 72 on a line.
Free form source was designed expressly for this more modern technology.

  Fixed form source can be replaced free form source, which is an easier
to use and more generalized form of source code.  The availability of
sophisticated, highly reliable code restructuring tools means that converting
fixed form source to free form source can be done automatically, efficiently,
and economically.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  Delete section 3.3.2 from the standard.  Move the text of section 3.3.2
into Annex B as part of section B.1 for the benefit of those vendors who
wish to continue supporting fixed form source.  Most likely, the person who
does the work will have to find the other places in the standard where this
construct is mentioned.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal. As noted above, a software tool can easily convert from fixed
to free form source.
</ESTIMATED IMPACT>

<SUBMITTED BY>
  Craig T. Dedo
  17130 W. Burleigh Place
  Brookfield, WI   53005
  (414) 783-5869
  E-mail: Craig.Dedo@mixcom.com
</SUBMITTED BY>

<REFERENCE>
  X3J3 / 96-007r0 3.3.2, B.2.6
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-070
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>    106
<TITLE>        Delete Alternate Return
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  The Fortran 2000 standard should delete alternate return (12.4,
12.4.1.3, B.2.1).
</REQUIREMENT>

<JUSTIFICATION>
  Alternate return is a construct left over from the 1950s and 1960s when
little was known about how to write code so that it would be easy to follow.
The high cost of main memory and disk space in those years also put a high
premium on writing Fortran so that it would occupy as little space as
possible.  Continued use of this feature encourages the construction of
difficult to follow, spaghetti-style control flow.

  Alternate return specifiers can be replaced by a status variable which
indicates the completion status of the subroutine and what, if any problems
occurred during its execution.  The status variable can be evaluated by
either a CASE construct or block IF construct immediately after the call to
the subroutine.   Either of these block structures is an easier to use and
more structured method of evaluating a completion status.  The availability
of sophisticated, highly reliable code restructuring tools means that
converting alternate return constructs to CASE constructs or block IF
constructs can be done automatically, efficiently, and economically.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  Delete rule R1215 and the last constraint following R1215 from the
standard.  Delete section 12.4.1.3 from the standard.  Move this text into
Annex B as part of section B.1 for the benefit of those vendors who wish to
continue supporting alternate returns.  Most likely, the person who does the
work will have to find the other places in the standard where this construct
is mentioned.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal. As noted above, a software tool can easily convert alternate
return constructs to CASE or block IF constructs.
</ESTIMATED IMPACT>

<SUBMITTED BY>
  Craig T. Dedo
  17130 W. Burleigh Place
  Brookfield, WI   53005
  (414) 783-5869
  E-mail: Craig.Dedo@mixcom.com
</SUBMITTED BY>

<REFERENCE>
  X3J3 / 96-007r0 12.4, 12.4.1.3, B.2.1
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-070
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>    107
<TITLE>        Delete Statement Functions
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  The Fortran 2000 standard should delete statement functions (12.5.4,
B.2.3).
</REQUIREMENT>

<JUSTIFICATION>
  Statement functions are subject to a number of non-intuitive restrictions
and are a potential source of error since their syntax is easily confused with
that of an assignment statement.

  The internal function is a more generalized form of the statement
function and completely supersedes it.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  Delete section 12.5.4 from the standard.  Move this text into Annex B as
part of section B.1 for the benefit of those vendors who wish to continue
supporting statement functions.  Most likely, the person who does the work
will have to find the other places in the standard where statement functions
are mentioned.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.
</ESTIMATED IMPACT>

<SUBMITTED BY>
  Craig T. Dedo
  17130 W. Burleigh Place
  Brookfield, WI   53005
  (414) 783-5869
  E-mail: Craig.Dedo@mixcom.com
</SUBMITTED BY>

<REFERENCE>
  X3J3 / 96-007r0 12.5.4, B.2.3
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-070
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>    108
<TITLE>        Delete DATA Statements Among Executable Statements
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  The Fortran 2000 standard should delete the appearance of DATA
statements among executable statements (2.3.1, 2.3.2, Table 2.1, B.2.4).
</REQUIREMENT>

<JUSTIFICATION>
  The statement ordering rules of FORTRAN 66, FORTRAN 77, and
Fortran 90 allowed DATA statements to appear anywhere in a program
unit after the specification statements.  The ability to position DATA
statements among executable statements is very rarely used, is
unnecessary, and is a potential source of error.  It is generally considered
good programming practice to position specification statements such as
DATA statements, before the first executable statement.

  DATA statements which now occur among executable statements can
easily be moved into the declarations part of a program without any loss of
functionality or program effectiveness.  The availability of sophisticated,
highly reliable code restructuring tools means that moving DATA
statements can be done automatically, efficiently, and economically.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  Delete the references to DATA statements among executables in
sections 2.3.1 and 2.3.2 from the standard.  Delete the entry in Table 2.1
which shows "DATA statements" to the left of "Executable constructs".
Move this text into Annex B as part of section B.1 for the benefit of those
vendors who wish to continue supporting DATA statements among
executable statements.  Most likely, the person who does the work will have
to find the other places in the standard where statement functions are
mentioned.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.
</ESTIMATED IMPACT>

<SUBMITTED BY>
  Craig T. Dedo
  17130 W. Burleigh Place
  Brookfield, WI   53005
  (414) 783-5869
  E-mail: Craig.Dedo@mixcom.com
</SUBMITTED BY>

<REFERENCE>
  X3J3 / 96-007r0 2.3.1, 2.3.2, Table 2.1, B.2.4
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-070
</HISTORY>
</FORTREQ>