[J3] Use of "base object"

[Shafran, Aury]

Malcolm,

I agree an interp isn’t necessary. (I also agree about deleting EQUIVALENCE 😊)

What’s the reason you’re preferring to adjust the definition of object-name and variable-name rather than adjust the definition of “base object”? It seems to me that the latter would be clearer. For example, I think this change to “base object” fixes the problem:

object designated by an object-name, variable-name, or the leftmost part-name of a data-ref
Note 1 to entry: See 8.2, 9.2, and 9.4.2.

A clause 3 definition based primarily on syntax terms is uncommon but has precedence, e.g. 3.3.7 explicit-shape array, 3.102 operator and 3.130.1 executable statement.

(Alternatively I think “object designated by an object-name (8.2), variable-name (9.2), or the leftmost part-name of a data-ref (9.4.2)” would be even better,  though looking at other entries in clause 3, it seems references in parenthesis are always references to other entries in clause 3; references out of clause 3 are usually in notes. I’m not sure if that’s an ISO thing or just our formatting preference.)

I can try to write a /DATA paper, though you’ll have to forgive the mistakes I will inevitably make as I’ve never done it before! I’ll find some older similar /DATA papers and base mine on them.


For C15104, are you saying that (7) should apply to procedures as actual arguments? For example, if it did, I think this program should error at the marked line:

program main
    implicit none
    abstract interface
        pure integer function isub()
        end function
    end interface
contains
    pure integer function func1(ptr1) result(r)
        procedure(isub), pointer, intent(in) :: ptr1
        r = func2(ptr1)   !!! Should error if C15104 applied to procedures
    end function

    pure integer function func2(ptr2) result(r)
        procedure(isub), pointer, intent(in) :: ptr2
        r = ptr2()
    end function
end program main

Constraint C15104 says "In a pure subprogram any designator with a base object that is ... a pointer dummy argument of a pure function, [or] is a dummy argument with the INTENT(IN) attribute, shall not be used ... (7) as an actual argument corresponding to a dummy argument with the POINTER attribute".

Ignoring the “designator with a base object” part, so that C15104 applies to procedure names, ptr1 is both “a pointer dummy argument of a pure function” and “a dummy argument with the INTENT(IN) attribute”, and it’s used “as an actual argument corresponding to a dummy argument with the POINTER attribute”. The marked line meets the criteria of the constraint and so should be disallowed.

However, no compiler I tested except ifx errors for this program. ifx errors for the marked line because of the INTENT(IN) part, but it doesn’t consider the “pointer dummy argument of a pure function” part, and so removing the INTENT(IN) makes it not error. Without INTENT(IN), no compiler I tested errors for this program. And I don’t see why they should; func2 is pure so it can’t modify its ptr2 dummy argument. Ifx’s error for INTENT(IN) seems unnecessary for the same reason.

If you’re suggesting something else about C15014, then I misunderstood, could you explain again?

Thanks,
Aury


From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Malcolm Cohen via J3
Sent: Friday, February 7, 2025 9:46 PM
To: 'General J3 interest list' <j3 at mailman.j3-fortran.org>
Cc: Malcolm Cohen <malcolm at nag-j.co.jp>
Subject: Re: [J3] Use of "base object"

Hi Aury,

Yeah, we got a bit sloppy here, thanks for the analysis.

It is so obvious what we meant, and there are examples talking about the base object of a simple name which makes it even clearer, that I don’t think we need wheel out the clanking machinery of an interpretation request. We should correct the text in the next revision though.

A plausible fix is: change R804 to “object-name is data-ref”, and change C810 to “The data-ref of an object-name shall consist of a single part-name.” We do not need to say “that is the name of a data object” here, because C912 already says it.

OTOH that doesn’t fix variable-name, but the only problematic usage of variable-name seems to be in EQUIVALENCE. How about we just delete EQUIVALENCE? More seriously, I would be inclined to use the object-name fix plus change R903 to “variable-name is object-name”.

This should be a /DATA paper for the next meeting. Would you like to write it? (Edits against 25-007.)

Re C15104, just because we have the base object of a designator does not mean that the designator is not of a procedure component. Furthermore, we need to prohibit changing out-of-scope procedure pointers in a pure procedure as that would be a side effect, and C15104 is the only thing that does that. Ditto pointer dummy argument of a pure function (that is additional to the “designator” case).

So C15104 needs to apply to procedures at least some of the time. It might be best to split the procedure case into a separate constraint: that would not make C15104 any shorter (it might make it longer!), but the separate constraint itself would be simpler and easier to understand.

Anyway, fixing C15104 either technically or in exposition would be a separate topic and thus a separate /DATA paper.

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

From: J3 <j3-bounces at mailman.j3-fortran.org<mailto:j3-bounces at mailman.j3-fortran.org>> On Behalf Of Shafran, Aury via J3
Sent: Saturday, February 8, 2025 4:41 AM
To: J3 Fortran <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Cc: Shafran, Aury <aury.shafran at intel.com<mailto:aury.shafran at intel.com>>
Subject: [J3] Use of "base object"

Hi J3,

F2023 defines the term “base object” as:
object designated by the leftmost part-name
Note 1 to entry: Base objects are described in 9.4.2.
Note 2 to entry: This only applies to the data-ref syntax (R911).

However, I noticed the term “base object” used in a few places where I don’t think a data-ref is intended to be required.

For example, 10.1.11 “Specification expression” p.2 list item (2) says: “… each primary is … (2) an object designator with a **base object**  that is a dummy argument that has neither the OPTIONAL nor the INTENT (OUT) attribute”
I think this list item is what’s intended to allow dummy arguments to appear in specification expressions (outside specification inquiries – those have their own list item).
I.e., list item (2) is intended to allow this code:

subroutine sub(x)
    integer :: x
    integer :: y(x)  ! <-- x can appear here
end subroutine

In the case of the marked line, “x” in the BNF is an object-name (specification-expr  --> int-expr --> expr  -->  … --> primary --> designator --> object-name).
An object-name is not a data-ref, and it has no part-name, so “base object” does not apply to it. Therefore the list item (2) doesn’t apply to the example above. I see no other list item for “specification expression” which would permit the example above either.

There are similar uses of “base object” in list items (3) and (4), as well as in 8.5.4 p.2, C8110, C15104, and C15121. I’m concerned that all of these uses have the same problem.
All other uses of “base object” are already in the context of a data-ref, so they shouldn’t have a problem.

Am I missing something? Or is there an issue with the usage or definition of “base object”?

---

Bonus question: Does C15104 apply to procedures? I noticed the potential issue with “base object” while looking at C15104 and trying to figure out if it applies to procedures too, or only data objects. It says “designator”, but as a glossary term, not a BNF term. The BNF term designator is only for data objects, but the glossary term “designator” applies to both data objects and procedures (see “procedure designator”). On the other hand, C15104 uses the term “base object”, and despite my concerns with that term, “object” never refers to procedures as far as I am aware. So I think C15104 is intended to only apply to data objects.

Thanks,
Aury

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20250210/b5888cee/attachment-0001.htm>