I like the idea of some sort of READONLY attribute for module variables
and even tried to slip it past J3 a couple of times.  But, I think there
are 2 serious problems with them that I haven't seen addressed here.

I don't think we can A) write a reasonable set of rules for then, and 
B) enforce the rules.

A)
Nobody has talked much about the POINTER and TARGET attributes for
a READONLY variable.  Surely we should allow them, we allow them for all
other variables.  Fortran 95 doesn't allow INTENT for a POINTER, but 
F2000 will.  What should READONLY mean for a variable with the POINTER
attribute?  Can we do  R_O => address ?  Can we do R_O = 3.14?  
F2000 is going to allow one of those for POINTERs with INTENT(IN).
Unfortunately, I don't recall which one is allowed and which is 
disallowed and I can't figure it out from first principles.  (I could 
look it up, but the point is that I don't remember and for what follows 
I DON'T want Richard Maine to tell me what the answer is!).  But, there 
is a perfectly logical reason for doing what F2000 is going to do.  It's 
been explained to me twice (sigh) and each time I was convinced that it 
was the right thing to do.  So, should we do the same thing for READONLY
POINTERs or should we have a stronger rule?  Neither one seems like a good
idea.

B)
People have said that READONLY will prevent people from changing the 
value of the variable.  That's only true in a correctly written program.
And that's exactly the current situation; a person who uses the module
correctly doesn't need READONLY.  A person who uses the module
incorrectly will still be able to change the value of a READONLY variable,
just as they can now with an INTENT(IN) variable.

Right now there is no guaranteed protection for INTENT(IN) variables.  
The standard says in 5.1.2.3 "The ...dummy shall neither be defined nor
become undefined during execution of the procedure" and this is a textual
limit on the program.  NOT a constraint that the compiler must detect at
compile time.  The main reason for this is that INTENT(IN) dummies can
be passed as actual arguments to subroutines and these subroutines can
modify their arguments.  There can be no compile time protection against
calling a bad subroutine.  We can't impose a rule like "READONLY variables
can't be used as arguments"; nobody would understand it, especially since
INTENT(IN) doesn't have the same rule.  We can't count on hardware
protection where the compiler/linker places the variable in some sort
of "read-only" memory because some machines don't have this feature
and, on those that do, it would then require a trip through the OS if
the module ever wanted to change the variable's value.  We can't rely
on copy-in as an argument passing mechanism for these things since they
might be a 100000000000 word array.  Pretty much the same arguments
apply if the READONLY is a target.  The compiler won't be able to track
all of the POINTER references and can't guarantee to catch all definitions
of the READONLY variable.

So, we'd ultimately rely on the user not doing anything bad to the READONLY
variables.  True, the compiler can detect some user errors, but not all of
them.  From the posts of Peter and Dan I have the impression that they see 
this as a guaranteed safety feature.  I don't see how it can be.

So, the bottom line is that I don't see how to write a consistent set of
rules that don't have seemingly arbitrary restrictions and still allow
the compiler to guarantee safety.

Dick Hendrickson



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