[J3] surprisingly PURE
Malcolm Cohen
malcolm at nag-j.co.jp
Wed Apr 22 00:49:44 EDT 2020
Hi Vipul,
As I said, I think trying to stop usage of a “bad pointer” is doomed to failure, or at least to enormous complication. It is a lot easier to stop creation of the “bad pointer” in the first place, and doing that is also in the spirit of the existing rules which stop creation of bad pointers via routes other than default initialisation.
However, with regards to Bob’s example, why do you think your wording works? You have to actually work through the conditions and see whether they apply.
I guess that you think that your constraint would make the assignment
Y%P = whatever
invalid. Working on that assumption… your constraint says
“A local variable [with conditions] shall not appear in a variable definition context.”
The only local variable that satisfies the “with conditions” is Y. However, Y does not appear in a variable definition context; the definition states
“(1) the variable of an assignment-stmt;”
and the variable is “Y%P”, not “Y”. And “Y%P” is of type Integer, so does not satisfy the “with conditions”.
I note that Y%P is not even a subobject of Y (because P is a pointer component, Y%P is only a subobject in pointer context, viz NULLIFY, ALLOCATE and the like). So adding “or a subobject thereof” still does not fix it.
I did note that this wording flaw is fixable, however, that would not solve the other issues (pointer assignment, argument passing…) that I mentioned. So I don’t think it is worth showing you a fix at this time.
Cheers,
--
..............Malcolm Cohen, NAG Oxford/Tokyo.
From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Vipul Parekh via J3
Sent: Tuesday, April 21, 2020 10:19 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Vipul Parekh <parekhvs at gmail.com>; Malcolm Cohen <malcolm at nag-j.co.jp>
Subject: Re: [J3] surprisingly PURE
On Tue, Apr 21, 2020 at 12:11 AM Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org <mailto:j3 at mailman.j3-fortran.org> > wrote:
Hi Vipul,
Thanks for the comments.
Unfortunately your simple constraint doesn’t work, as an intervening pointer assignment, structure constructor, *or call to another pure procedure* makes it ineffective. As worded, it does not even forbid Robert’s example, though that is fixable. ..
Hello Malcolm,
Thanks for your feedback.
I did view the phrasing of the simple constraint I suggested as merely an exercise to learn how to compose an edit to the standard as you suggested in one of your earlier notes!
And I did have both Bob's example as well as Van's (with local object "instantiation" using MOLD and definition in a polymorphic context) in mind. I thought the wording I suggested prohibits "Y%P = 2.0" instruction in Bob's example as well as "Y%P = 42.0" in Van's, thus rendering them both non-conforming relative to a further standard revision that fixes this "defect" (as you called it).
So I'm curious and would like to learn more about "As worded, it does not even forbid Robert’s example, though that is fixable. ..". Can you please elaborate a little on how the wording I suggested fails to forbid Bob's example even?
Your explanation will also be valuable highly I think to other committee members, particularly those who have joined recently, on how to author the standard with proper wording that captures the desired objectives of any given change.
Thanks,
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/20200422/8693a3be/attachment.htm>
More information about the J3
mailing list