The problem with PARAMETER is that it currently has a semantics different
from what the user community expects, i.e., an entity whose value, once
determined, does not change during subsequent processing of the program. It
is instead a special case of that semantics, i.e., an entity whose value
can be readilly determined before beginning processing of the program and
does not change during subsequent processing of the program. This special
case from the user's point of view is highly irregular in that "readilly
determined" is not a concept that is defined simply as either only the
standard mathematical operations (this was far too simplistic to be
acceptable), or the standard Fortran library functions and operators (this
has been resisted by vendors as implying the compile time availability of a
numerical library). The rules therefore are specified by listing in detail
the allowed functions. The current plan is to make PARAMETER entities more
flexible by allowing (almost?) all functions that return integer values,
while still severely restricting the use of functions that return floating
point values.
As I see it the standards committees have at least three options available
for them: continue with a rather ad hock definition of initialization
expressions, extend initialization expressions to include all of the
standard Fortran library, or define a new attribute (ONCE?, CONSTANT?) for
entities whose value, once determined, do not change during subsequent
processing of the program. Note that entities with such an attribute do not
need to be evaluated at compile time, and need not be restricted to
expressions involving only the intrinsic Fortran library, which of course
opens another level of argument about definition and semantics.
William B. Clodius Phone: (505) 665-9370
Los Alamos Natl. Lab., NIS-2 FAX: (505) 667-3815
PO Box 1663, MS-C323 Group Off.: 505/667-3422 or 667-5127
Los Alamos, NM 87545 email: [log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|