[J3] surprisingly PURE

Malcolm Cohen malcolm at nag-j.co.jp
Wed Apr 22 04:15:03 EDT 2020


Hi Robert,

 

The “add no constraints” is not quite a hard-and-fast rule: we have done this in the past. The hard-and-fast version is “don’t turn existing requirements into constraints” in an interp.

 

We’ve also deleted parts of features via interp, which does the same job. Not something we want to do light-heartedly, but there is precedent.

 

So it’s worth *considering* constraints/deletion in the interp, if that’s what we’re going to do in the end anyway.

 

(The trouble with a general requirement is that if it is too vague, no-one is going to do anything about detecting it until it comes time for Fortran 202x conformance. It *may* be better to encourage vendors to apply the fix we want to do asap.)

 

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

 

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Robert Corbett via J3
Sent: Wednesday, April 22, 2020 4:43 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Robert Corbett <rpcorbett at att.net>
Subject: Re: [J3] surprisingly PURE

 

A possible fix is to prohibit the

name of a derived type with a

non-null default initializer for a

data pointer component from

appearing in a pure subprogram.

It is a big hammer, but it fixes

the problem.  It is an easy

constraint to check.

 

I have considered about a dozen

possible fixes for the problem,

each of which has some

drawbacks.  For the Fortran 2018

interpretation, I recommend

punting.  The interp should add a

requirement, but not a constraint,

prohibiting operations that can

change the global state except

through the dummy arguments.

I have been told repeatedly that

we should not add constraints

in interps.

 

For Fortran 202x, we should add

one or more constraints to

prohibit the bad behavior.  The

constraints will need to be

broader than strictly necessary

to ensure that they can be

checked statically.  Previous

editions of the standard have

made similar changes to the

definition of pure subprograms.

 

I have tried to construct

examples where it seems

desirable to have a default

initializer other than null for

a data pointer component.

I have yet to find a

convincing case.

 

Robert Corbett


On Apr 21, 2020, at 11:13 PM, Van Snyder via J3 <j3 at mailman.j3-fortran.org <mailto:j3 at mailman.j3-fortran.org> > wrote:

Pointers allow one to do things with pure procedures that one might think violate the "principle" of PURE.

 

One can pass an object of a type that has a pointer component, with the component associated with a variable that's not mentioned in the argument list, and then the procedure can assign a valueto that variable (or undefine it).

 

real, target :: X = 1.0

type :: T

real, pointer :: X

end type T

type(t) :: V

print *, 'Before call, X =', x

v%x => x

call s ( v )

print *, 'Afer call, X =', x

contains

subroutine S ( A )

type(t), intent(inout) :: A

a%x = 42.0

end subroutine S

end

 

This has been with us since the beginning of PURE, but some might say "that's not pure!"

 

Is this really different from changing X by way of a pointer component with default initialization that associates it with X?

 

Bob's example is a bit diffent because it doesn't involve a side effect using a dummy argument that some might argue violates the spirit of "pure."

 

But, taking these together, and the potential problems with polymorphism that appear not to be addressable with constraints, is there really anything the standard can do to plug every loophole?

 

 

Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. Please see our Privacy Notice <https://www.nag.co.uk/content/privacy-notice>  for information on how we process personal data and for details of how to stop or limit communications from us.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20200422/2e3956cf/attachment.htm>


More information about the J3 mailing list