[J3] another PURE example

Robert Corbett rpcorbett at att.net
Tue Oct 6 14:58:58 EDT 2020


My original program, which will be
included in my interp request, does
not use modules, uses only one
type definition, and does not use
a structure constructor.  Some
people proposed fixes to the
problem that work for that program
(which means they make that
program nonconforming), but
which do not solve the problem
in more complicated cases.  My
new program demonstrates a
more complicated case that is
not handled by some of the
proposed fixes.  Simplifying my
new program would make it
pointless, as it would no longer
exhibit the difficult case.

Robert Corbett

> On Oct 6, 2020, at 10:59 AM, Brad Richardson via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> My point is that, if you're just trying to demonstrate that default initialization of a pointer component allows one to modify module variables within pure procedures, you don't need the extra type and the explicit constructor call to demonstrate that. Or have I missed some additional point your trying to make, or is there something else wrong with my example?
> 
> Regards,
> Brad
> 
>> On Tue, 2020-10-06 at 10:39 -0700, Robert Corbett wrote:
>> My first example program was
>> simpler.  Someone proposed a
>> solution to the problem as
>> shown in the first program that
>> does not work for the new
>> program.  I intend to include
>> both programs in my interp
>> request.
>> 
>> The key difference between the
>> programs is that the type
>> definition for the type of the
>> variable in the PURE subroutine
>> does not include the default
>> initialization.
>> 
>> Robert Corbett
>> 
>>> On Oct 6, 2020, at 9:45 AM, Brad Richardson via J3 <j3 at mailman.j3-fortran.org> wrote:
>>> 
>>> Am I missing something, or would the following simpler example be sufficient to demonstrate the problem?
>>> 
>>> MODULE V
>>>   REAL, TARGET :: X = 1.0
>>> END
>>> 
>>> MODULE PRINT
>>> USE V
>>> PRIVATE X
>>> CONTAINS
>>>   SUBROUTINE PRINTX
>>>     PRINT *, X
>>>   END
>>> END
>>> 
>>> MODULE T_M
>>>   TYPE T
>>>     REAL, POINTER :: P => X
>>>   END
>>> END
>>> 
>>> PURE SUBROUTINE SUBR
>>> USE T_M
>>>   TYPE(T) Y
>>>   Y%P = 2.0
>>> END
>>> 
>>> PROGRAM MAIN
>>> USE PRINT
>>>   CALL SUBR
>>>   CALL PRINTX
>>> END
>>> 
>>> Regards,
>>> Brad
>>> 
>>>> On Mon, 2020-10-05 at 22:12 +0000, Robert Corbett via J3 wrote:
>>>>       MODULE V
>>>>         REAL, TARGET :: X = 1.0
>>>>       END
>>>> 
>>>>       MODULE PRINT
>>>>       USE V
>>>>       PRIVATE X
>>>>       CONTAINS
>>>>         SUBROUTINE PRINTX
>>>>           PRINT *, X
>>>>         END SUBROUTINE PRINTX
>>>>       END
>>>> 
>>>>       MODULE T1
>>>>         TYPE T
>>>>           SEQUENCE
>>>>           REAL, POINTER :: P
>>>>         END TYPE T
>>>>       END
>>>> 
>>>>       MODULE T2
>>>>       USE V
>>>>       PRIVATE X
>>>>         TYPE T
>>>>           SEQUENCE
>>>>           REAL, POINTER :: P => X
>>>>         END TYPE T
>>>>       END
>>>> 
>>>>       PURE SUBROUTINE SUBR
>>>>       USE T1
>>>>       USE T2, TINIT => T
>>>>         TYPE(T) Y
>>>>         Y = TINIT()
>>>>         Y%P = 2.0
>>>>       END
>>>> 
>>>>       PROGRAM MAIN
>>>>       USE PRINT
>>>>         CALL SUBR
>>>>         CALL PRINTX
>>>>       END
>>>> ================================================================
>>>> 
>>>> I think the program above conforms to the Fortran 2018 standard,
>>>> but I am not able to check its conformance.  If anyone sees a
>>>> mistake in it, please let me know.
>>>> 
>>>> The program is another example of default initialization
>>>> breaking the assumptions that underlie the PURE attribute.
>>>> It shows that some of the fixes to the definition of PURE
>>>> that were proposed in response to my first example are
>>>> insufficient.
>>>> 
>>>> Because only one compiler was able to compile my first example,
>>>> I do not expect most compilers to be able to handle this
>>>> program.
>>>> 
>>>> I agree with Van that there are problems with the definition of
>>>> PURE that go back to the original definition of PURE.  Van also
>>>> asserted that the addition of type extensions made the problems
>>>> worse, but I do not understand what the additional problems
>>>> are.
>>>> 
>>>> Robert Corbett
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> T
>>>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20201006/5197fc43/attachment.htm>


More information about the J3 mailing list