Well, since I've already been placed into this controversy, I may as
well participate.

*Peter Shenkin; Chemistry, Columbia U.; [log in to unmask] (212)854-5143*
writes:

>!!! with READONLY:
> INTEGER FUNCTION sub( j )
> USE mod !!! mod contains INTEGER,READONLY :: i
> IMPLICIT NONE
> 
> sub = j * i
>
> END
> 
>!!! without READONLY -- "get" function needed:
> INTEGER FUNCTION sub( j )
> USE mod !!! mod contains PRIVATE i, returned by function i_get()
> IMPLICIT NONE
> 
> sub = j * i_get()
>
> END
>
>My guess is that many compilers will be faster with the first
>form.

Point 1.

I don't think we really need to worry about this too much.  By the
time the READONLY attribute could make it into the standard 
(2007?, 2010?) even the most basic and unrefined compilers
will almost certainly be written with all the off-the-shelf optimization
technologies they can get their hands on.  So, an older technique
like inlining won't be too much of a stretch.  I expect implementations
to inline MODULE functions long before then (or at least have a 
compiler option to do so).

Point 2.

I'd like to remind people of the reason I got mentioned in this
discussion.  I pointed out on the usenet group that the present
reading of the standard permitted MODULE procedures to
be inlined.  I also stated that I opposed this interpretation of
the standard.  The problem can be demonstrated with the 
following code:

   MODULE AVERAGE
      CONTAINS
         INTEGER FUNCTION AVE (I, J)
            INTEGER, INTENT(IN) :: I, J
            AVE = (I+J)/2
         END FUNCTION AVE
   END MODULE AVERAGE

vs.

   MODULE AVERAGE
      CONTAINS
         INTEGER FUNCTION AVE (I, J)
            INTEGER, INTENT(IN) :: I, J
            IF (SIGN(1,I) == SIGN(1,J)) THEN
               AVE = I + (J-I)/2
            ELSE
               AVE = (I+J)/2
            ENDIF
         END FUNCTION AVE
   END MODULE AVERAGE

All the interface information of the MODULEs is the same, only the
code itself has changed.  The present wording of the standard requires
that all program units that USE this MODULE must be recompiled if
I replace the first definition with the second.  This is fine if I want the
code inlined (or other interprocedural analyses done).  And, for a
function as simple as AVE, I might want just that.  But for procedures
more complicated in a large program (where I have no intent to inline),
the requirement to recompile all USEs might be prohibitive.

Well it's too late to change the interpretation that permits MODULE
code to be inlined.  Instead (since this is a wish-list thread) I'll add
my wish for the ability to explicitly declare that the code part of a
MODULE procedure is PRIVATE.  That is, if the last line of the
specification part of a MODULE procedure is a statement consisting
of the keyword PRIVATE, then the implementation is not permitted
to inline (or otherwise interprocedurally analyse the code) and changes
would be permitted within that code without requiring USEs of the
MODULE to be recompiled.  (There are, of course, other reasons
to desire that procedures not be inlined.  The programmer should
have explicit control over whether such optimizations are allowed.)

Note that if this method is adopted, the READONLY attribute might
again be considered more useful since it's possible that the access
functions for a PRIVATE type might have PRIVATE code.  The only
way to optimize references to the data would be with a READONLY
construct.

Point 3.

In spite of the note at the end of point 2, I don't think I would use
the READONLY feature in my own code (if it were added to the
language).  This is for two reasons.  First, I can see no reason
that I would want to prohibit inlining of the access functions to a 
PRIVATE data field.  Second, the main reason that I ever make
MODULE data PRIVATE is so that I can later change its definition
and layout without having to recode the programs that use the data.

Consider Peter Shenkin's example quoted above.  Suppose that 
the MODULE is altered so that the variable I is no longer explicitly
stored, but must be computed from other PRIVATE data in the 
MODULE.  Program units which access the data only though the
access function needn't be changed (though possibly they'd need
to be recompiled).  Program units which access the variable directly
using the READONLY capability must be rewritten.

It seems to me that if you find yourself in need of defeating encapsulation
(like C++ "friend functions") or partially defeating it (READONLY
attrribute), you should really be reconsidering what it was that you
thought encapsulation was doing for you.  Maybe the data shouldn't
have been encapsulated in the first place.

--
J. Giles



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