ELEMENTAL type-bound procedures and procedure-pointer components
Daniel Kraft
consider code like this:
MODULE m
IMPLICIT NONE
TYPE t
CONTAINS
PROCEDURE, PASS :: myproc
END TYPE t
CONTAINS
ELEMENTAL INTEGER FUNCTION myproc (me)
CLASS(t), INTENT(IN) :: me
myproc = 42
END FUNCTION myproc
END MODULE m
PROGRAM main
USE m
IMPLICIT NONE
TYPE(t) :: arr(2)
PRINT *, arr%myproc ()
END PROGRAM main
Is the call "arr%myproc ()" to a type-bound procedure bound to an
ELEMENTAL function valid? I would assume it is more or less equivalent
to calling "myproc (arr)" directly.
From the draft F2003 standard, 12.4.5 Resolving type-bound procedure
references, it seems so (the relevant quote is "Otherwise, the reference
shall be consistent with an elemental reference to one of the specific
bindings of that generic binding; that specific binding is selected.").
I'm I right here? I have to admit that I'm not really quite comfortable
with reading the standard and may have severly misunderstood this.
What if this was realized with a procedure-pointer component like in:
MODULE m
IMPLICIT NONE
TYPE t
PROCEDURE(myproc), POINTER, PASS :: myproc
END TYPE t
CONTAINS
ELEMENTAL INTEGER FUNCTION myproc (me)
CLASS(t), INTENT(IN) :: me
myproc = 42
END FUNCTION myproc
END MODULE m
PROGRAM main
USE m
IMPLICIT NONE
TYPE(t) :: arr(2)
arr%myproc => myproc
PRINT *, arr%myproc ()
END PROGRAM main
Here I have the feeling this is not valid any longer because the
procedure pointer might be to different routines in any array element...
But would like to get a definite answer.
Thanks a lot!
Yours,
Daniel
--
Done: Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri
Richard Maine
> Is the call "arr%myproc ()" to a type-bound procedure bound to an
> ELEMENTAL function valid?
I can't think of any reason why it wouldn't be. That doesn't mean I
couldn't have missed something, but that's as good as I can do for an
answer without more work than I'm feeling like right now (sorry:-(). It
is unfortunately, a lot easier to point at something that says a
construct is invalid than to point out the lack of any such restriction
anywhere in the standard. I do tend to have a good idea of the places to
look fo rthings, but sometimes stuff is buried in places that I don't
think of at first.
> I would assume it is more or less equivalent
> to calling "myproc (arr)" directly.
Yes.
Hmm. (Added while perusing interps for answer to the next part). I did
find an interp in corrigendum 1 adding a constraint:
C1224a (R1219) If data-ref is an array, the referenced type-bound
procedure shall have the PASS at- tribute.
I don't off-hand recall why; the bit I was looking at just had the edits
rather than the explanations. Ok. Looked further. Now I see. The full
interp is appended below 9and it pretty explicitly answers your
question, saying that yes, it is valid, as long as the PASS attribute is
used).
> What if this was realized with a procedure-pointer component like in:
...
> Here I have the feeling this is not valid any longer because the
> procedure pointer might be to different routines in any array element...
> But would like to get a definite answer.
Ah. That one sounds familliar. Let me peruse a bit... Basically, your
instincts are right that this "can't" be valid.... Found it.
The reason I recalled this question is that a variant of it came up as
an interpretation request once. It seems as though the standard omitted
the necessary constraint. I recall what I thought was a rather silly
argument at the time in that one person was (in my view) trying to turn
the "obvious" (I think to everyone present) omission of a needed
constraint into a substantial new feature tacked on via the interp
process. I probably seriously misrepresent his viewpoint (in partial
recompense for which, I won't name names). I recall being a little
annoyed at what I considered a frivolous position.
Anyway, I just now searched and did find the fix for this in corrigendum
2, namely
In rule R741, replace "variable" by "scalar-variable". In the second
line of constraint C725, replace "variable" by "scalar-variable".
Below is a copy of the passed interp for the first party of this
question.
NUMBER: F03/0016
TITLE: Invoking type-bound procedures via array objects
KEYWORDS: elemental, type-bound procedure, NOPASS attribute
DEFECT TYPE:Erratum
STATUS: Passed by WG5 ballot
QUESTION:
Consider
INTERFACE
SUBROUTINE sub; END
END INTERFACE
TYPE t
CONTAINS
PROCEDURE,NOPASS :: p => sub
END TYPE
TYPE(t) x(100)
CALL x%p
END
(1) Is this program-unit standard-conforming?
If so, how many times is SUB invoked?
(2) If SUB has the ELEMENTAL attribute, does this change its standard
conformance? If it is conforming, how many times is it executed?
Consider:
TYPE t
...
CONTAINS
PROCEDURE ep => emp
END TYPE
...
ELEMENTAL SUBROUTINE emp(x)
CLASS(t),INTENT(INOUT) :: x
...
END SUBROUTINE
...
TYPE(t) a(10)
CALL a%ep
(3) Is this fragment standard-conforming, and if so, is
"CALL a%ep" equivalent to "CALL emp(a)"?
Consider:
INTERFACE
ELEMENTAL SUBROUTINE esub(r); REAL,INTENT(IN) :: r; END
END INTERFACE
TYPE t
CONTAINS
PROCEDURE,NOPASS :: ep => esub
END TYPE
TYPE(t) x(100)
REAL y(50)
CALL x%ep(y)
END
(4) Is this standard-conforming?
If so, is ESUB invoked 50 times or 100 times?
ANSWER:
(1) No.
(2) No.
(3) Yes.
(4) No.
If the invoking object is an array, the type-bound procedure must be
elemental and have the PASS attribute. An edit is supplied to clarify
this.
DISCUSSION:
The invoking object can only enable elementalisation if it is an
actual argument, i.e. if the type-bound procedure has the PASS
attribute. If the type-bound procedure does not have both the PASS
and ELEMENTAL attributes, the invoking object shall be scalar.
EDITS:
All edits refer to 04-007.
[266:24+] Insert new constraint
"C1224a (R1219) If <data-ref> is an array, the referenced type-bound
procedure shall have the PASS attribute."
SUBMITTED BY: Malcolm Cohen
HISTORY: 04-368 m169 Submitted; Passed by J3 meeting
04-418r1 m170 Passed by J3 letter ballot #9
05-180 m172 Passed by WG5 ballot N1617
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain