[J3] surprisingly PURE

[Bill Long]

I have a similar idea. Some normative text like “A statement in a PURE subprogram shall not define a variable <suitable description>. “  would at least clarify that the program is not conforming.  I agree that constraint are easier for compilers to diagnose, but there is no prohibition on a compiler diagnosing a violation of a requirement in  normative text.   Indeed, there are cases where that happens already.

Cheers,
BIll


> On Apr 22, 2020, at 2:43 AM, Robert Corbett via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> 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> 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?

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