So by "data modules", Shareef Siddeek was simply talking about
a kind of "module", so as everyone stated, the max line length
of 132 for free form source line applies (I thought there might
be a remote chance that the "data module" might actually be a
data file read by READ statements, in which case a different set
of rules, RECL= specifier and/or processor dependent default line
length, applies).

James Giles wrote:

>>The DATA statement is the only really convenient way to 
>>initialize with really large amounts of information.  Other ideas 
>>are suggested to the committee from time to time, but none 
>>have been more than curiosities.

Here is one idea I can't find on the J3 Document Archive,
but I'm sure must have crossed the minds of many people:
Allow function reference in initialization expressions.

The problem with initialization expressions (that presently
DATA statements can sometimes solve) is that initialization
statements must be written as one expression, which is rather
unreasonable for arrays.

If writing

      real :: X(100,18) = INIT_X()

is allowed, any number of statements can be used to initialize X
(within the FUNCTION INIT_X() RESULT(X) body):

      X(1,:) = [ 0.000, ... total of 18 values ]
      X(2,:) = [ 0.000, ... 18 more values ]
      ... total of 100 statements ...

(to rewrite the example given in James Giles's post). And even
more flexibility than DATA statements, without the special
syntax. For example, sparse tables can be set up with setting
everything zero X = 0 first, and then filling nonzero elements,
or values set earlier in the table can be used later as need,
like setting the lower half of a symmetric matrix from the
upper half.

1. Syntax is completely familiar to everyone (no new syntax).

2. Although the initialization code potentially can be placed
   anywhere in the program, making it slightly harder to read,
   people should already know how to find function definitions.

3. Object-oriented programming people would want "initializers"
   sooner or later, they would need to call procedures even for
   objects with SAVE or PARAMETER attributes anyway.

What needs to be done is to

1. Figure out restrictions appropriate for a function that
   can supposedly be evaluated during compilation rather
   than at execution time (this is not that easy I guess).

2. Generalize the concept of "execution sequence" to apply to
   nonexecutable specification statements. What would "value
   must be defined before referenced" mean for nonexecutable
   statements? This is already partly dealt with regarding
   named constants, but a more general definition would be
   needed to accomodate function references.

Perhaps for Fortran 202x..
-- 
Yasuki Arasaki
[log in to unmask]