William B. Clodius wrote:
> <SNIP>
> Not quite true. User functions and user subroutines could only be used 
> for initialization (without a large potential for error) under 
> restricted conditions. It is possible that user defined PURE 
> procedures could be used for this, but I suspect that something closer 
> to mathematical pureness (IDEAL?) would really be needed.

I'd say that PUREness in context of module data initialization 
is already too much of a straightjacket. After all some of the 
requirements of PURE functions are motivated by FORALL statement, 
where it is anticipated that a number of PURE procedures may 
be executing in parallel. But there's no chance of that happening 
here.

A PURE function/subroutine:
a) if a function, does not alter dummy arguments,
b) does not alter host- or use-associated variables,
c) contains no locals with SAVE attribute,
d) contains no STOP,
e) performs no external I/O.

For the specific purpose of module initialization the above 
conditions can be (I hope) significantly relaxed:
a) can be left as is, but I'm mostly interested in initialization 
   subroutines now,
b) is hardly acceptable for a module initialization procedure, 
   which would (preferably) take no arguments and would be allowed 
   to modify any host associated data (and perhaps also use-associated 
   data) any way it wishes.

   The alternative when the initialization subroutine would take 
   all module wide data as its arguments (possibly with INTENT(OUT)) 
   seems clumsy.
c) OK, but meaningless. After all an initialization procedure I have 
   in mind would only be called once.
d) I think it is superfluous in the context. The initialization 
   subroutine might determine that the current setting of parameters 
   (yes, PARAMETERS) does not allow sensible initialization of 
   a module (e.g., the currently defined KINDS of foating point data 
   provide insuficient accuracy for the module) should be allowed 
   to STOP. 
e) Hmm, I could think of good uses for external I/O. How about 
   library licence checking via licence file reading?

Thus, the procedures called from within initialization subroutine 
don't need to be pure either.

The bottom line with module initialization procedures is in my 
opinion the following:
  Their call perfomed automatically before the beginning of 
  the program should be exactly the same as if they were called 
  explicitly in a well defined order at the beginning of 
  the program. The only difference would be such that those and 
  only those procedures would be allowed to modify module-wide 
  data with a CONSTANT attribute. And that would be the only 
  restriction I'd recommend.

The reasons for prefering such solution to hand coding remain:
a) it's impossible to initialize constants with many useful 
   expressions now,
b) it's error prone to rely on manual initialization of module 
   data.

Regards,
Artur Swietanowski
----------------------------------------------------------------------
Artur Swietanowski                mailto:[log in to unmask]
Institut fuer Statistik,  Operations Research und Computerverfahren,
Universitaet Wien,  Universitaetsstr. 5,  A-1010 Wien,  Austria
tel. +43 (1) 407 63 55 - 120      fax  +43 (1) 406 41 59
----------------------------------------------------------------------


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