Only one Fortran compiler can cope with this usage -- most crash hard with internal errors -- but I contend that it's conforming usage.

module m
contains
function foo()
procedure(bar), pointer :: foo
foo => bar
call foo ! <-- CALL of a function
end function
subroutine bar
print *, 'in bar'
end subroutine
end module

program demo
use m
procedure(bar), pointer :: p
p => foo()
call p
end

pmk <pmklausler@gmail.com> schrieb:

> Only one Fortran compiler can cope with this usage -- most crash
> hard with internal errors -- but I contend that it's conforming
> usage.

On what grounds?

> module m
> contains
> function foo()
> procedure(bar), pointer :: foo
> foo => bar
> call foo ! <-- CALL of a function
> end function
> subroutine bar
> print *, 'in bar'
> end subroutine
> end module
>
> program demo
> use m
> procedure(bar), pointer :: p
> p => foo()
> call p
> end

Sounds fishy, at least...

> > Only one Fortran compiler can cope with this usage -- most crash
> > hard with internal errors -- but I contend that it's conforming
> > usage.
> On what grounds?

Within the body of the function FOO, the name FOO refers to its result variable. The result variable in this case is a procedure pointer to a subroutine. A CALL statement's procedure designator is allowed to be a procedure pointer.

> > module m
> > contains
> > function foo()
> > procedure(bar), pointer :: foo
> > foo => bar
> > call foo ! <-- CALL of a function
> > end function
> > subroutine bar
> > print *, 'in bar'
> > end subroutine
> > end module
> >
> > program demo
> > use m
> > procedure(bar), pointer :: p
> > p => foo()
> > call p
> > end
> Sounds fishy, at least...

On Wednesday, May 18, 2022 at 9:07:14 AM UTC-7, pmk wrote:
> > > Only one Fortran compiler can cope with this usage -- most crash
> > > hard with internal errors -- but I contend that it's conforming
> > > usage.

> > On what grounds?

> Within the body of the function FOO, the name FOO refers to its
> result variable. The result variable in this case is a procedure pointer
> to a subroutine. A CALL statement's procedure designator is
> allowed to be a procedure pointer.

I suspect I believe that it should not be an internal compiler error, but otherwise
I might believe compilers could accept it. But there is no claim that the result
is actually executable.

Many systems have a different calling method for functions, depending
on the type, and other attributes, of a function.

A procedure pointer can point to either a function or subroutine,
but you can only call functions with it when it points to functions,
and subroutines when it points to subroutines.

And if the compiler believes that you are not doing that, it is allowed
to reject the program.

On Wednesday, May 18, 2022 at 8:40:00 AM UTC-7, pmk wrote:
> Only one Fortran compiler can cope with this usage -- most crash hard with internal errors -- but I contend that it's conforming usage.

Some years ago, I tried one like this. gfortran didn't like it then,
and (the one I have here) doesn't like it now:

external fun, sub
call trythis(1,sub)
call trythis(2,fun)
stop
end
subroutine sub(i)
print *,'sub',i
return
end
integer function fun(i)
print *,'fun',i
fun=3*i
return
end
subroutine trythis(j, fs)
if(j.eq.1) call fs(5)
if(j.eq.2) k=fs(5)
return
end

If you comment out one of the IF statements, then it is fine.
Note that it never calls a function as a subroutine, or
subroutine as a function, but with both IF statements,
gfortran won't compile it.

On 5/18/2022 12:07 PM, pmk wrote:
> Within the body of the function FOO, the name FOO refers to its result variable. The result variable in this case is a procedure pointer to a subroutine. A CALL statement's procedure designator is allowed to be a procedure pointer.

I agree with this.

--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

On Wednesday, May 18, 2022 at 11:40:00 AM UTC-4, pmk wrote:

> Only one Fortran compiler can cope with this usage -- most crash hard with internal errors -- but I contend that it's conforming usage. ..

Yes, that appears correct based on the wording in the standard.

However the relevant wording is not part of any numbered constraint. And the processors then appear to miss out on coping with the semantics in such parts of the standard, especially with features introduced starting with Fortran 90. The "sleeping dogs lie" until an astute reader catches the omission and files support request(s) and the compiler developers find the resources to follow-up on the request(s).

Nonetheless the chances are more compilers can cope with this variant:

function foo() result(r)
procedure(bar), pointer :: r
r => bar
call r
end function

On 5/18/22 17:39, pmk wrote:
> Only one Fortran compiler can cope with this usage -- most crash hard with internal errors -- but I contend that it's conforming usage.
>
> module m
> contains
> function foo()
> procedure(bar), pointer :: foo
> foo => bar
> call foo ! <-- CALL of a function
> end function
> subroutine bar
> print *, 'in bar'
> end subroutine
> end module
>
> program demo
> use m
> procedure(bar), pointer :: p
> p => foo()
> call p
> end
>

Indeed, the compiler gets confused between the result of the function
foo (which should be the procedure pointer) and the function foo itself.
It works if the result is explicitly specified like by Vipul
(FortranFan), or if the function is defined as recursive. Then gfortran
and Nagfor can compile, Nagfor even the original code with the -f2018
flag (using the Fortran 2018 standard where every function is recursive).

--
Juergen Reuter
Theoretical Particle Physics
Deutsches Elektronen-Synchrotron
Hamburg, Germany
---------------------------------
invalid is desy .and. com is de

Hi,

On May 18, 2022, Steve Lionel wrote
(in article <jektlsFr6vU1@mid.individual.net>):

> On 5/18/2022 12:07 PM, pmk wrote:
> > Within the body of the function FOO, the name FOO refers to its result
> > variable. The result variable in this case is a procedure pointer to a
> > subroutine. A CALL statement's procedure designator is allowed to be a
> > procedure pointer.
>
> I agree with this.

And I'll respectfully disagree.

I think the gremlin lies in the procedure pointer assignment 10.2.2.4.

These are all procedures in the same module so the interfaces are explicit
(as is required by the pointer-ness and the procedure-ness).
Since the interfaces are explicit, agreement is required of the
characteristics.
The characteristics include whether it is a subroutine or a function 15.3.1.
qed

(I'm reading 22-007r1)

--
Cheers!

Dan Nagle

On Thursday, May 19, 2022 at 9:08:54 AM UTC-7, Dan Nagle wrote:
> I think the gremlin lies in the procedure pointer assignment 10.2.2.4.
>
> These are all procedures in the same module so the interfaces are explicit
> (as is required by the pointer-ness and the procedure-ness).
> Since the interfaces are explicit, agreement is required of the
> characteristics.
> The characteristics include whether it is a subroutine or a function 15.3.1.
> qed

The procedure pointer is assigned to the same procedure used to define its interface.

On Thursday, May 19, 2022 at 7:07:42 AM UTC-7, JRR wrote:
> It works if the result is explicitly specified like by Vipul
> (FortranFan), or if the function is defined as recursive. Then gfortran
> and Nagfor can compile, Nagfor even the original code with the -f2018
> flag (using the Fortran 2018 standard where every function is recursive).

The recursive attribute (defaulted or not) is not relevant to the interpretation of names in a program.

On Thursday, May 19, 2022 at 12:08:54 PM UTC-4, Dan Nagle wrote:

> ..
> And I'll respectfully disagree.
>
> I think the gremlin lies in the procedure pointer assignment 10.2.2.4.
>
> These are all procedures in the same module so the interfaces are explicit
> (as is required by the pointer-ness and the procedure-ness).
> Since the interfaces are explicit, agreement is required of the
> characteristics.
> The characteristics include whether it is a subroutine or a function 15.3..1.
> qed
>
> (I'm reading 22-007r1) ..

@Dan Nagle,

Are you reading much into OP' s comment in the code in the original post, "CALL of a function"? There is no "call of a function" there, `FOO` is not a function on that line of instruction!

Anyways, the characteristics with the function result which is FOO in the execution-part of the function match with the interface, there are no issues with this.

The only problem here appears to be that several compilers as well as human readers overlook the text of the standard that states, "If RESULT does not appear, the name of the function result is function-name and all occurrences of the function name in execution-part statements in its scope are references to the function result."

On Thursday, May 19, 2022 at 10:07:42 AM UTC-4, JRR wrote:

> .. if the function is defined as recursive. Then gfortran
> and Nagfor can compile, Nagfor even the original code with the -f2018
> flag (using the Fortran 2018 standard where every function is recursive). ..

@Juergen Reuter,

No recursion is involved here, the 2 compilers you have tried might be confused if they are bringing up anything recursion: they both appear to be treating occurrences of `FOO` in the `execution-part` of the function as `function-name`, instead of as function result, the latter being the semantics as stipulated by the standard. Both those compilers will then be non-conforming.

On May 19, 2022, pmk wrote
(in article<8c2cbb6d-7f18-4cdc-9112-05f3c278d30bn@googlegroups.com>):

> On Thursday, May 19, 2022 at 9:08:54 AM UTC-7, Dan Nagle wrote:
> > I think the gremlin lies in the procedure pointer assignment 10.2.2.4.
> >
> > These are all procedures in the same module so the interfaces are explicit
> > (as is required by the pointer-ness and the procedure-ness).
> > Since the interfaces are explicit, agreement is required of the
> > characteristics.
> > The characteristics include whether it is a subroutine or a function 15.3.1.
> > qed
>
> The procedure pointer is assigned to the same procedure used to define its
> interface.

The function statement declares foo to be a function.
The explicit interface for bar declares bar to be a subroutine.
Hence, the mismatch.

--
Cheers!

Dan Nagle

On Thursday, May 19, 2022 at 3:25:14 PM UTC-4, Dan Nagle wrote:

> ..
> The function statement declares foo to be a function.
> The explicit interface for bar declares bar to be a subroutine.
> Hence, the mismatch...

That is not the case.

See R1532 and note what is said about function statement versus execution-part and J3/22-007r1, page 336, lines 27 thru' 29.

On Thursday, May 19, 2022 at 12:25:14 PM UTC-7, Dan Nagle wrote:
> The function statement declares foo to be a function.
> The explicit interface for bar declares bar to be a subroutine.
> Hence, the mismatch.

I think you're saying that a function returning a procedure pointer can only return a pointer to a function, but not a pointer to a subroutine.

That turns out to not be the case.

On Thursday, May 19, 2022 at 12:25:14 PM UTC-7, Dan Nagle wrote:

(snip)

> The function statement declares foo to be a function.
> The explicit interface for bar declares bar to be a subroutine.
> Hence, the mismatch.

Does that explain why my program doesn't work?

Note that it only calls a function as function, and subroutine as subroutine,
but still it won't compile with gfortran.

On Thursday, May 19, 2022 at 8:43:37 PM UTC-4, gah4 wrote:

@gah4,

>
> Does that explain why my program doesn't work?

No, your code has genuine mismatch in the scope of your `trythis` subprogram.

> but still it won't compile with gfortran.

If you have a Fortran 2018 compiler, here's a variant of your code the processor should accept: with "gfortran", you can replace the "generic" statement with an INTERFACE block.

module m
generic :: trythis => trythis1, trythis2
contains
subroutine trythis1(fs)
procedure(sub) :: fs
call fs(5)
end subroutine
subroutine trythis2(fs)
procedure(fun) :: fs
print *, "fs returns: ", fs(5)
end subroutine
subroutine sub(i)
print *,'sub',i
return
end
integer function fun(i)
print *,'fun',i
fun=3*i
return
end
end module
use m
call trythis(sub)
call trythis(fun)
end

--- console output ---
C:\temp>ifort /standard-semantics p.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.5.0 Build 20211109_000000
Copyright (C) 1985-2021 Intel Corporation. All rights reserved.

Microsoft (R) Incremental Linker Version 14.31.31105.0
Copyright (C) Microsoft Corporation. All rights reserved.

-out:p.exe
-subsystem:console
p.obj

C:\temp>p.exe
sub 5
fun 5
15

On Thursday, May 19, 2022 at 7:19:44 PM UTC-7, FortranFan wrote:

(snip, I wrote)

> > Does that explain why my program doesn't work?

> No, your code has genuine mismatch in the scope of your `trythis` subprogram.
> > but still it won't compile with gfortran.

> If you have a Fortran 2018 compiler, here's a variant of your code the processor
> should accept: with "gfortran", you can replace the "generic" statement with an INTERFACE block.

I actually wrote a program like this some years ago, when a similar question
came up. I then had to recreate it. As far as I know, it uses only Fortran 66
features, but the only compiler I tried it on was gfortran.

Much of Fortran 66 trusts users to do things right, such as argument
type matching. Even so, as far as I know, Fortran 66 doesn't have a
different type for subroutine names and function names.

But okay, the way you write it sub and fun have to be in the module,
which is less convenient than it could be. It is especially inconvenient
if you want to separately compile each of them.

On May 19, 2022, FortranFan wrote
(in article<ca164c05-4151-451d-b1d8-df1e91a44967n@googlegroups.com>):

> On Thursday, May 19, 2022 at 3:25:14 PM UTC-4, Dan Nagle wrote:
>
> > ..
> > The function statement declares foo to be a function.
> > The explicit interface for bar declares bar to be a subroutine.
> > Hence, the mismatch...
>
> That is not the case.
>
> See R1532 and note what is said about function statement versus
> execution-part and J3/22-007r1, page 336, lines 27 thru' 29.

And at line 25 the function result variable has all the characteristics of
the function.

--
Cheers!

Dan Nagle

Hi,

On May 19, 2022, pmk wrote
(in article<b62af7de-49fd-420a-89b1-dd43552dd58bn@googlegroups.com>):

> On Thursday, May 19, 2022 at 12:25:14 PM UTC-7, Dan Nagle wrote:
> > The function statement declares foo to be a function.
> > The explicit interface for bar declares bar to be a subroutine.
> > Hence, the mismatch.
>
> I think you're saying that a function returning a procedure pointer can only
> return a pointer to a function, but not a pointer to a subroutine.
>
> That turns out to not be the case.

If you write a result-name in foo,
and you use a local variable with the subroutine characteristic in bar.

--
Cheers!

Dan Nagle

On Friday, May 20, 2022 at 12:00:28 PM UTC-4, Dan Nagle wrote:
> ..
> And at line 25 the function result variable has all the characteristics of
> the function. ..
and
On Friday, May 20, 2022 at 12:05:53 PM UTC-4, Dan Nagle wrote:
> ..
> If you write a result-name in foo,
> and you use a local variable with the subroutine characteristic in bar.

@Dan Nagle,

I fail to see how your first point, "the function result variable has all the characteristics of the function" of any relevance to the original post. A function can *indeed* have a function-result that is a procedure pointer to a subroutine, there are no doubts it. The following is a conforming program:

module m
contains
function foo() result(r)
procedure(bar), pointer :: r
r => bar
end function
subroutine bar
print *, 'in bar'
end subroutine
end module

The question implied by OP is
1. If RESULT clause does NOT appear and
2. There is a reference to the function-name in the execution-part of the function,
what does the standard and the compilers have to "say" about that?

Well with the code in the original post, it conforms.

The compilers appear to "fall over" at the line "CALL foo" only because the function-name itself is FOO.

But the standard makes it clear, "If RESULT does not appear, the name of the function result is function-name and all occurrences of the function name in execution-part statements in its scope are references to the function result."

Thus "CALL foo" does not involved a reference to the function-name per the standard, instead it is a reference to a procedure pointer associated with `bar`. One can see it as though the "offending" line were `CALL bar` and there is nothing non-conformant when viewed as such.

On Thursday, May 19, 2022 at 1:40:00 AM UTC+10, pmk wrote:
> Only one Fortran compiler can cope with this usage -- most crash hard with internal errors -- but I contend that it's conforming usage.
>
> module m
> contains
> function foo()
> procedure(bar), pointer :: foo
> foo => bar
> call foo ! <-- CALL of a function
> end function
> subroutine bar
> print *, 'in bar'
> end subroutine
> end module
>
> program demo
> use m
> procedure(bar), pointer :: p
> p => foo()
> call p
> end
..
Why do you want to do this?
..
Just CALL a subroutine, and invoke a function with a function reference,
in the traditional way.

Hi,

On May 20, 2022, FortranFan wrote
(in article<46eb9bc5-af40-43fe-acef-1f1dd29556adn@googlegroups.com>):

> On Friday, May 20, 2022 at 12:00:28 PM UTC-4, Dan Nagle wrote:
> > ..
> > And at line 25 the function result variable has all the characteristics of
> > the function. ..
> and
> On Friday, May 20, 2022 at 12:05:53 PM UTC-4, Dan Nagle wrote:
> > ..
> > If you write a result-name in foo,
> > and you use a local variable with the subroutine characteristic in bar.
>
> @Dan Nagle,
>
> I fail to see how your first point, "the function result variable has all the
> characteristics of the function" of any relevance to the original post.

The relevance is that, once the function statement gives the name foo the
function characteristic,
the declaration of the local result variable cannot change it. The
declaration can set other
attributes, but cannot change whether a name refers to an entity that is a
function or a subroutine.
That is determined by whether the name appears in a function statement
or a subroutine statement.

> A
> function can *indeed* have a function-result that is a procedure pointer to a
> subroutine, there are no doubts it. The following is a conforming program:
>
> module m
> contains
> function foo() result(r)
> procedure(bar), pointer :: r
> r => bar
> end function
> subroutine bar
> print *, 'in bar'
> end subroutine
> end module

I agree that this is conforming code.
But that is due to the use of a result variable with a different name.
This allows declaration of the function characteristics separately
from the result value characteristics.

That is, the above code never tells me that foo is a function and a
subroutine.

>
>
> The question implied by OP is
> 1. If RESULT clause does NOT appear and
> 2. There is a reference to the function-name in the execution-part of the
> function,
> what does the standard and the compilers have to "say" about that?

It says the result variable has all the characteristics of the function name,
and that whether something is a function or a subroutine is a characteristic.

>
>
> Well with the code in the original post, it conforms.

It does not. The original code confuses whether foo is a function or a
subroutine.
This it cannot do and be standard-conforming.

I believe that another local variable is needed where foo is called,
again to separate the function (value-producing) aspect from the subroutine
aspect
(target of pointer).

>
>
> The compilers appear to "fall over" at the line "CALL foo" only because the
> function-name itself is FOO.

And the compiler can't guess whether you mean foo is a function or a
subroutine.
There are contradictory declarations.

>
>
> But the standard makes it clear, "If RESULT does not appear, the name of the
> function result is function-name and all occurrences of the function name in
> execution-part statements in its scope are references to the function result."

Can you read the paragraph just before the above?
You cannot specify the type of a function both on the function statement
and within the function. Yet that is what you want to do.

You must separate the declaration of the function from the declaration
of the function's value. Do this by using another name, as in your result
example
(which I agree is conforming).

"
>
>
> Thus "CALL foo" does not involved a reference to the function-name per the
> standard, instead it is a reference to a procedure pointer associated with
> `bar`. One can see it as though the "offending" line were `CALL bar` and
> there is nothing non-conformant when viewed as such.

Not so. C1525 disagrees. The name appearing in a call statement must
designate
a subroutine. foo is the name of a function (whose value is a pointer to
subroutine).

Again, this can be cured by using a local variable to hold the value
returned from the function foo, the which can then be called.

The theme is that one must distinguish the function-ness of foo
from the subroutine-ness of foo's result value. An extra variable does the
trick.

--
Cheers!

Dan Nagle

On 5/21/22 10:26 AM, Dan Nagle wrote:
[...]
>> Thus "CALL foo" does not involved a reference to the function-name per the
>> standard, instead it is a reference to a procedure pointer associated with
>> `bar`. One can see it as though the "offending" line were `CALL bar` and
>> there is nothing non-conformant when viewed as such.
>
> Not so. C1525 disagrees. The name appearing in a call statement must
> designate
> a subroutine.

In that call statement, foo is a procedure pointer to a subroutine, so
does that not qualify as designating a subroutine?

> foo is the name of a function (whose value is a pointer to
> subroutine).

Without the result() clause, foo is the value of the function within the
function body, which is a pointer to a procedure. A procedure pointer
can point to either subroutines or functions, without restriction. There
are not separate pointers for functions and for subroutines, they all
share the same type declaration.

Furthermore, after the pointer assignment, it would be illegal to
reference foo as a function within the body of the function. It is
REQUIRED to reference it only as a subroutine and with the interface
that is consistent with that of the target subroutine.

>
> Again, this can be cured by using a local variable to hold the value
> returned from the function foo, the which can then be called.

The result() clause was added to the language in order to allow direct
recursion to the function from within the body of the function. Of
course, the recursive attribute is required, either explicitly (f90) or
implicitly (f2003), in this case. After result(r) is added, then any
references to foo are to the function, while references to r are to the
value. It is even allowed to do indirect recursion without the result()
clause, it is only direct recursion from foo to itself that requires the
result() clause. However, in this example, there is no recursion
involved anywhere, direct nor indirect. If recursion is not involved
then it seems like result() should not be necessary.

Without result(), there is no ambiguity that within the body of the
function that references to foo are references to the value.

>
> The theme is that one must distinguish the function-ness of foo
> from the subroutine-ness of foo's result value. An extra variable does the
> trick.

Those two "-ness" are already distinguished. Without the result(), all
references to foo within the body are to its value. With the result()
clause, all references to foo are recursive references to the function
itself. It follows that since no recursive references to foo are
invoked, then result() is unnecessary. It is like declaring a variable
and then not referencing it. Of course, in this case, that might not be
a bad idea for human readers of the code, but it seems unnecessary for
the compiler which knows all of this because there is no ambiguity in
the language in this respect.

There is also the question of the argument list. If foo() and/or bar()
had arguments, then all references to the foo function would require
that argument list while references to the procedure pointer value would
require the absence of an argument list. The associated code would then
look like

! no result() code
foo => bar ! no argument list.
call bar(arg1,...) ! with argument list
call foo(arg1,...) ! with argument list, through the pointer value.

! with result(r)
r => bar ! no argument list.
x=....foo(arg1,...) ! expression with direct recursion to foo()
call bar(arg1,...) ! with argument list.
call r(arg1,...) ! with argument list, through the pointer value.

$.02 -Ron Shepard