[J3] [EXTERNAL] another PURE example

[Malcolm Cohen]

I suspect a fairly simple and unobtrusive fix is available. There would be two parts to this:

 

1.	Disallow from variable definition context anything reached via a pointer component that is default-initialized to anything other than NULL(). I think this is sufficient – we don’t have to do anything specific about constructors or ALLOCATE or anything, as long as the SEQUENCE hole is closed.
2.	Specify that any default initialization of a component is an attribute of that component. (This closes the hole with SEQUENCE types.)

 

I note that (2) is a question of interpretation anyway: at least, I don’t see that we say anywhere that default initialization is not an attribute, and although it’s not obvious that it is an attribute, we do have

 

“Every data object has a type and rank and can have type parameters and other properties that determine the uses of the object. Collectively, these properties are the attributes of the object.”

 

Now, that sentence does not clearly state that default initialization is such a property, but it’s certainly a natural interpretation of it. In other words, if we want default initialization NOT to be an attribute, it needs to be explicitly stated as such.

 

That is, it seems to me that the standard is at best ambiguous as to whether two SEQUENCE types with different default initialization are the same type, which by itself (without any explicit rule!) makes a program that attempts to use them in a context where it matters is non-conforming, as ambiguity does not establish an interpretation.

 

Perhaps it would be worthwhile making a separate interpretation on just this question?

 

Cheers,

-- 

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

 

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Robert Corbett via J3
Sent: Monday, October 12, 2020 4:29 AM
To: Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov>
Cc: Robert Corbett <rpcorbett at att.net>; General J3 interest list <j3 at mailman.j3-fortran.org>
Subject: Re: [J3] [EXTERNAL] another PURE example

 

I agree that change you suggest

is too big for an interp.  A change

of that magnitude must go through

the regular process.

 

I hope the committee can agree

in the purpose of the existing

definition of pure procedures.

The constraints currently

provided do not adequately

implement what I believe was

the intent of the committee.

As we amend the current

specification of pure procedures,

we should have a clear

statement of what we hope to

achieve.

 

Robert Corbett

 

On Oct 11, 2020, at 11:48 AM, Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov <mailto:thomas.l.clune at nasa.gov> > 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.   

 

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 <mailto: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 <mailto: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 <mailto: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 <mailto: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

 

 

 

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/20201012/e13c95f0/attachment-0001.htm>