I am surprised that Malcolm is confused about what Werner is trying
to accomplish by regularizing the syntax of the function header.

It was immediately clear to me that Werner was advocating to change
the syntax of function headers, _not_ the syntax of such things as
EXTERNAL and PROCEDURE declarations.

I advocated the same syntax as did Werner, in 1986, to avoid the
necessity for CONTAINS.

I have extensive experience teaching difficult material to adult
students.  Every irregularity contributes to the difficulty of
learning.  (Ponder the difficulty to memorize the irregular verbs
of French, as opposed to the near absolute -- almost theorem-like --
symmetry of Arabic.)  Difficulty of learning contributes to mistakes and
increased lifetime cost, and resistance to usage.  If one of our
goals is to preserve and encourage use of Fortran, irregularities
should be removed.

Fortran presently has the half-principle that the entity being declared
can have :: put before it, in which case a comma-separated list of
additional attributes or modifiers can precede the ::.  This is true
for object, type, and attribute declarations, but not true for procedure,
interface and module declarations.  That the latter all introduce blocks
is _not_ an intrinsic asymmetry that should be amplified by prohibiting ::
before the name of the entity being declared: notice that
  TYPE, PUBLIC :: MyType
introduces a block.

To make the symmetry more complete, every entity declaration should
allow :: before the entity, and every specifiable attribute of the
entity should be allowed in a comma-separated list before ::, viz.

  TYPE(MyType), RECURSIVE, ALLOCATABLE, DIMENSION(10), PUBLIC, &
    RESULT(MyResult), FUNCTION :: MyFunc ( ... ) ... END FUNCTION MyFunc
  MODULE :: MyModule ... END MODULE MyModule
  INTERFACE :: ASSIGNMENT(=) ... END INTERFACE
  INTERFACE :: OPERATOR(.MyOp.) ... END INTERFACE
  INTERFACE, PUBLIC :: GenericSet ... END INTERFACE GenericSet
  SUBROUTINE, RECURSIVE, PUBLIC :: MySub ( ... ) ... END SUBROUTINE MySub

Of course, the present (irregular) syntaxes should continue to be offered.

I would go a step further, and allow the attributes in any order, viz.
  SAVE, REAL :: X ! and
  FUNCTION, REAL :: AnotherFunc ( ... )
Allowing this would not _require_ it.  That is, one would still be
allowed to use
  REAL, SAVE :: X ! or
  REAL X; SAVE X
as a uniform personal style.  In any case the irregularity of
requiring the data type to be first if it's present is less severe
than prohibiting :: in half of the categories of entity declarations.

As Werner has pointed out, all of these changes are easy, from the
linguistic point of view, in that they have no semantic impact.
Implementing the changes in the standard would be tedious, but, once
the concept is agreed the doing of it should not be controversial.

Allowing to specify attributes in any order would substantially simplify
the exposition in chapter 5.  Re-writing chapter 5 would be a tedious job,
but the doing of it should not cause much controversy (once the concept
is agreed, which is probably in itself controversial).

Best regards,
Van Snyder


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%