Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Use statement in separate module procedure

129 views
Skip to first unread message

José Rui Faustino de Sousa

unread,
Mar 21, 2021, 7:40:18 PM3/21/21
to
Hi all!

I cannot find the standard passage that defines if an use statement in a
separate module procedure is mandatory or not.

Can anybody chime in?

Is the repetition of the use statement (or an import statement), which
must be present in the interface body, mandatory or optional in a
separate module procedure subprogram?

The relevant code:

module foo_m
! No use statement
implicit none

[...]

interface
module subroutine foobar(ptr)
! mandatory use statement
use :: baz_m, only: baz_t
implicit none
class(baz_t), pointer, intent(out) :: ptr
end subroutine foobar
end interface

[...]

The submodule:

submodule(foo_m) subfoo_m
! Again no use statement
implicit none

contains

! Full subroutine
module subroutine foobar(ptr)
! Mandatory use statement
use :: baz_m, only: baz_t
class(baz_t), pointer, intent(out) :: ptr
nullify(ptr)
return
end subroutine foobar

! Using a module procedure subprogram
module procedure foobar
! Mandatory? Optional? Neither?
! use :: baz_m, only: baz_t
nullify(ptr)
return
end procedure foobar

[...]

I would expect the use statement to be mandatory, but I cannot find the
correct standard verse.

Thank you very much for your time.

Best regards,
José Rui

FortranFan

unread,
Mar 22, 2021, 1:24:05 PM3/22/21
to
On Sunday, March 21, 2021 at 7:40:18 PM UTC-4, José Rui Faustino de Sousa wrote:

> ..
> I cannot find the standard passage that defines if an use statement in a
> separate module procedure is mandatory or not.
>
> Can anybody chime in?
>
> Is the repetition of the use statement (or an import statement), which
> must be present in the interface body, mandatory or optional in a
> separate module procedure subprogram? ..


@José Rui Faustino de Sousa,

For whatever it's worth, I'll go out on a limb and state my view which is "the repetition of the use statement (or an import statement)" is NOT to be made in the separate module procedure. That is, in the "mp-subprogram-stmt" (as the Fortran standard refers to it).

You will be familiar with section "15.6.2.5 Separate module procedures" in document 18-007r1 toward the current Fortran standard. And also with paragraph 3, lines 7-8, on page 321. You will know it states, "The interface of a procedure defined by a separate-module-subprogram is explicitly declared by the mp-subprogram-stmt to be the same as its module procedure interface body."

Note the embedded link for "interface body" takes you to section "15.4.3.2 Interface block" that shows the USE (and IMPORT) statements are part of the specification part of the body.

The mp-subprogram-stmt should thus impart the whole of the interface body including the USE (and IMPORT statements) to the separate module procedure.

However you likely seek better counsel and further commentary and confirmation of this, especially as I can very well be in the wrong and compiler writers disagree with me. So I suggest you to follow up on this at the J3 mailing list, something you've done previously. You may also want to inquire of this at the Fortran Discourse site for broader Fortran Community feedback:
https://fortran-lang.discourse.group/

Ian Harvey

unread,
Mar 29, 2021, 7:11:41 AM3/29/21
to
My view... in this particular example, the use statement is not
required. Its appearance is permitted, though pointless.

If the module procedure subprogram referenced identifiers from the
`baz_m` module (such as a reference to `baz_t` to declare a local
variable), then the use statement would be required to be repeated in
the subprogram.

The interface body for the procedure is a separate scoping unit to the
subprogram for the procedure. The procedure declared by the subprogram
has its *interface* declared by the interface body, not other stuff.
There is a limited list of things that comprise the interface of a
procedure - which use statements might be present in the subprogram
defining the procedure is not one of those things.

(I suspect there is missing normative text in the section of the
standard on "Scope, Association and Definition" around the scope of the
identifiers for things like dummy variables and function results that
are declared in the interface body, being extended to include the
scoping unit of the subprogram. If this normative text was present,
things might be clearer.

I also suspect there is missing normative text around the determination
of derived types - a type declaration repeated between the interface
body and the subprogram would appear to be defining a separate type.)

Ian Harvey

unread,
Mar 29, 2021, 5:50:38 PM3/29/21
to
From off list:

> On 29/03/21 11:14, Ian Harvey wrote:
>> My view... in this particular example, the use statement is not
>> required. Its appearance is permitted, though pointless.
>>
>> If the module procedure subprogram referenced identifiers from the
>> `baz_m` module (such as a reference to `baz_t` to declare a local
>> variable), then the use statement would be required to be repeated
>> in the subprogram.
>>
>> The interface body for the procedure is a separate scoping unit to
>> the subprogram for the procedure. The procedure declared by the
>> subprogram has its *interface* declared by the interface body, not
>> other stuff. There is a limited list of things that comprise the
>> interface of a procedure - which use statements might be present in
>> the subprogram defining the procedure is not one of those things.
>>
>
> My understanding is that the interface is basically a procedure type
> declaration.
>
> In the module procedure body there is no need repeat the arguments
> type declarations has only the procedure name would suffice (as in
> any type declaration).

Fortran does not have the concept of "procedure type".

The interface of a procedure "consists of its name, binding label,
generic identifiers, characteristics, and the names of its dummy
arguments" (F2018 15.4.1). The characteristics of a procedure in turn
include the characteristics of its dummy arguments (see 15.3), plus a
specific list of other things. The characteristics of a dummy argument
(plus its name) include the things that would be covered by declarations
for the dummy arguments.

The list of things that are considered part of the interface of a
procedure is quite specific. That list does not include "this module
happened to be referenced via a use statement as part of specifying the
interface". (Which is good - we don't want to care how a particular
identifier was introduced into a scoping unit - at the end of the day it
is the meaning of the interface that is important, not its syntax.)

> The problem is that, at least in some processors, there is indeed
> other stuff depending on the use statement, mostly due to the OOP
> stuff.

What other stuff?

> That is why I was expecting to be some standard clause requiring the
> use statement repetition.

You need to "repeat" the use statement if you reference things from the
module inside the subprogram. (You are not really repeating the
statement - because the subprogram is a different scoping unit.)

>> (I suspect there is missing normative text in the section of the
>> standard on "Scope, Association and Definition" around the scope of
>> the identifiers for things like dummy variables and function
>> results that are declared in the interface body, being extended to
>> include the scoping unit of the subprogram. If this normative text
>> was present, things might be clearer.
>>
>
> IMHO it does not make sense to require that procedure types must
> include any of the used module(s) information.
>
> And, on further reflection, I would say that it should be sufficient
> to require that any extra type information must "travel" in the type
> definition itself.

I don't follow your point.

>> I also suspect there is missing normative text around the
>> determination of derived types - a type declaration repeated
>> between the interface body and the subprogram would appear to be
>> defining a separate type.)
>>
>
> There should be some wording in the standard that demands that the
> processor handles any extra type information (has if) it is included
> in the type definition itself, not in the module.

I presume you mean interface definition. The standard does not say what
you want. What you ask for would break code that follows what it says
currently, in perhaps more obscure circumstances.

The standard has explicit text that goes the other way, in part. "The
specification part of an interface body may specify attributes or define
values for data entities that do not determine [the?] characteristics of
a procedure. Such specifications *have* *no* *effect*." (Emphasis mine).

> This way there would be no need to repeat the use statement, as all
> necessary type information would be available in the procedure
> interface itself.
>
> Thank you very much.
>
> Best regards, José Rui

José Rui Faustino de Sousa

unread,
Mar 29, 2021, 7:52:37 PM3/29/21
to
On 29/03/21 21:53, Ian Harvey wrote:
> From off list:
>

Ups... Sorry... In Thunderbird "reply" means reply to email...

>> In the module procedure body there is no need repeat the arguments
>> type declarations has only the procedure name would suffice (as in
>> any type declaration).
>
> Fortran does not have the concept of "procedure type".
>

Yes it does not, in Fortran functions are not first-class, but in
practice an interface is a function declaration.

>> The problem is that, at least in some processors, there is indeed
>> other stuff depending on the use statement, mostly due to the OOP
>> stuff.
>
> What other stuff?
>

Contained procedures, final procedures, procedures (and variables)
generated by the compiler to support basic type operations that have to
be made available to any part of the code that uses variables of that type.

> You need to "repeat" the use statement if you reference things from the
> module inside the subprogram.  (You are not really repeating the
> statement - because the subprogram is a different scoping unit.)
>

That is an important point.

>> And, on further reflection, I would say that it should be sufficient
>> to require that any extra type information must "travel" in the type
>> definition itself.
>
> I don't follow your point.
>

Types also have scope and must carry additional information the "other
stuff" above.

>> There should be some wording in the standard that demands that the
>> processor handles any extra type information (has if) it is included
>> in the type definition itself, not in the module.
>
> I presume you mean interface definition.  The standard does not say what
> you want.  What you ask for would break code that follows what it says
> currently, in perhaps more obscure circumstances.
>

No I mean the type itself.

You have module scope, interface scope, module procedure scope and type
scope. Which may nest or not.

Let's assume you have a type defined in some module and are using it in
some other module and submodule.

Since both the interface and the module procedure have separate scopes
you would have to "use" the module in both to access the type "other
stuff" if the standard did not mandate that it must be included in the type.

Before OOP that was more or less the standard practice, you had a module
for every type and defined the type handling procedures in the module
and then you had to use the module every time you had to call any
procedure. (I think my confusion comes from this...)

Now the "other stuff" is (should be...) included in the type scope (the
type namespace) not the modules' and that is why you don't have to
repeat the use statement.

> The standard has explicit text that goes the other way, in part.  "The
> specification part of an interface body may specify attributes or define
> values for data entities that do not determine [the?] characteristics of
> a procedure.  Such specifications *have* *no* *effect*." (Emphasis mine).
>

Yes it would have not made sense to require that the interface included
anything more than the procedure characteristics (the procedure type
definition).

And the only place left is the type scope.
0 new messages