[J3] surprisingly PURE
malcolm at nag-j.co.jp
Wed Apr 22 04:15:03 EDT 2020
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.)
..............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
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
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
subroutine S ( A )
type(t), intent(inout) :: A
a%x = 42.0
end subroutine S
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?
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...
More information about the J3