[J3] [EXTERNAL] another PURE example

Bill Long longb at cray.com
Sun Oct 11 15:07:33 EDT 2020



> On Oct 11, 2020, at 1:48 PM, Clune, Thomas L. (GSFC-6101) via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> Hi Bob,
> 
> I know there would be terrible problems with backward compatibility, but would there otherwise be value in considering a PURE attribute for types?    Very roughly my idea is that a PURE type cannot do the things that allow the loopholes in your examples.    Arguments to PURE procedures would be required to be of PURE type, as would any local variables in the procedure.   

A type does not “do” anything. Procedures “do” things.  It would seem the goal is to limit the types of arguments to a PURE procedure.  Are all of the intrinsic types PURE?    If not, there are gigantic problems most of the intrinsic procedures. 

Cheers,
BIll


> 
> The only way that I could see to squeeze a modicum of backwards compatibility with this approach would be to have some language that makes most types PURE by default, and thereby sidestepping the need for explicitly adding the PURE attribute to the types.   And certainly this is a bit of a big feature for an interp.
> 
> - Tom
> 
> 
> 
> 
> 
>> On Oct 11, 2020, at 9:39 AM, Robert Corbett via J3 <j3 at mailman.j3-fortran.org> wrote:
>> 
>> I uploaded my interp request for PURE procedures.
>> It is paper 20-151.  I am sorry it took so long to
>> complete.
>> 
>> The paper does not provide a fix for the problem
>> it describes.  The paper describes the problem,
>> not the solution.  It mentions the fix that I favor
>> as of this date 2020-10-11, but it does not go into
>> detail.  I doubt the committee will accept my
>> proposed fix without amendment.
>> 
>> As I say in the paper, I think the committee needs
>> to rethink how pure procedures are to be used and
>> how they are to be specified.  Van raised good
>> points regarding additional constraints that might
>> be needed.
>> 
>> I want to thank everyone who provided feedback on
>> my examples and on earlier versions of my paper.
>> The paper is better (and longer) because of the
>> feedback.
>> 
>> Robert Corbett
>> 
>> On Tuesday, October 6, 2020, 10:37:21 PM PDT, Robert Corbett via J3 <j3 at mailman.j3-fortran.org> wrote:
>> 
>> 
>> I intend to file the interp paper
>> soon.
>> 
>> You have seen the original example.
>> You even commented on it.  I wrote
>> my new example, in part, because
>> of your comments.
>> 
>> Bob Corbett
>> 
>> On Oct 6, 2020, at 8:02 PM, Vipul Parekh via J3 <j3 at mailman.j3-fortran.org> wrote:
>> 
>>> 
>>> 
>>> On Tue, Oct 6, 2020 at 3:10 PM Robert Corbett via J3 <j3 at mailman.j3-fortran.org> wrote:
>>> 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.
>>> 
>>> Hi Bob,
>>> 
>>> Can you share details on the  original problem, perhaps any link to the email chain if you have that handy?
>>> 
>>> Otherwise, can you please comment whether your original problem is. by any chance, similar to this reduced case?
>>> 
>>> --- begin example ---
>>> module m
>>>    integer, target, save :: x = 0
>>>    type :: t
>>>       integer, pointer :: p => x
>>>    end type
>>> end module
>>> module n
>>>    use m, only : x, t
>>> contains
>>>    pure subroutine sub(a, b)
>>>       integer, intent(out) :: a, b
>>>       type(t) :: y
>>>       a = x
>>>       y%p = 1
>>>       b = x
>>>    end subroutine
>>> end module
>>>    use n, only : sub
>>>    integer :: a, b
>>>    call sub(a, b)
>>>    print *, "a = ", a, "; expected is 0"
>>>    print *, "b = ", b, "; is it 1?"
>>> end
>>> --- end example ---
>>> 
>>> One processor I tried issued an error "Bad target in pointer assignment in PURE procedure" for module 'n'.  However, I am unable to come up with any clause in C1594 (or any constraints in 15.7 Pure Procedures) that clearly explains why this processor issues this diagnostic even if it is trying to do the right thing.
>>> 
>>> But now, no errors or warnings with another processor; the program built with it gave the following output:
>>> 
>>>  a =  0 ; expected is 0
>>>  b =  1 ; is it 1?
>>> 
>>> The processor that issued the "Bad target in pointer assignment in PURE procedure" error in this reduced case also gave the same error with your new program.
>>> 
>>> Regards,
>>> Vipul
>>> 
> 

Bill Long                                                                       longb at hpe.com
Engineer/Master , Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Hewlett Packard Enterprise/ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425






More information about the J3 mailing list