Allow procedure calls to be annotated with INTENTs?

Some languages let you return multiple entities from a function, for example

mean, sd = stats(x(:))

In Fortran you can use a subroutine to do this,

call stats(x,mean,sd)

but it is not clear from the calling code what the inputs and outputs are. Should Fortran be extended to allow procedure calls to be annotated by the INTENTs of the procedure? Then you could write

call stats(in: x, out: mean, out: sd)

to call

subroutine stats(x,mean,sd)
real, intent(in) :: x(:)
real, intent(out) :: mean,sd
end subroutine stats

You could only annotate with in: inout: or out: if the corresponding procedure argument had the same declaration. For subroutines with many arguments, I often write a comment saying what the outputs are, but assertions checked by the compiler would be better. Maybe annotating procedure calls could help the compiler better optimize the code, since it would know what variables are not changed by the procedure call.

In the absence of this language feature, perhaps a tool could be developed that looks at a program and for subroutines with more than N (say N = 2) arguments, adds a comment line with annotations, for example

call stats(x, mean, sd)
! call stats(in: x, out: mean, out: sd)
4 Likes

@Beliavsky ,

I suggest you post this also at the GitHub Fortran Proposals site: GitHub - j3-fortran/fortran_proposals: Proposals for the Fortran Standard Committee

4 Likes

I just filed issue 203.

1 Like

If you routinely specify INTENT attributes for a procedure’s dummy arguments, and the interface for the procedure is visible at the call site (both good programming practices), then you already have what you need for argument checking.

If you routinely specify INTENT attributes for a procedure’s dummy arguments, and the interface for the procedure is visible at the call site (both good programming practices), then you already have what you need for argument checking.

… by the compiler. OP is asking for a way to make the intents more conveniently visible to the programmer at the call site. He wants to be able to tell just by looking at the call site what are the intents of the arguments, so that seeing something like call foo(bar, baz, buzz) one doesn’t have to go look up the interface.

I’ll admit that a good IDE would make this less urgent though. If you can hover your mouse over a procedure to see it’s interface, that’s probably sufficient.

I like the IDE option better. If you have that, presumably the compiler can find the interface anyway, so could do the consistency check.

Can you recommend one such IDE for Windows? Does it handle INTERFACEs with MODULE PROCEDUREs, so that hovering over call foo() leads to foo_vec or foo_mat as appropriate?

Although an IDE with this functionality is useful, the subroutine definition will generally use different names for variables than the code calling it, and the arguments may be in a different order if the caller uses named arguments. Many arguments may be missing in the calling code if they are OPTIONAL. So I still think it would be beneficial for the language to permit annotating arguments with INTENTs, since it would be faster to just look at

call stats(in: x, out: xstat(1), out: xstat(2))

or

call stats(in: x, out: mean = xstat(1), out: sd = xstat(2))

than to look at the code being called and do the mental mapping from caller to callee.

I’ve had reasonable success with the combination of Atom, with the plugin ide-fortran, and it’s external dependency fortran-language-server.

I haven’t had a chance to try getting it working on Windows yet, but I don’t think it should be difficult.

1 Like

I’m not sure if it can handle also generic interfaces, but VS Code with the Fortran IntelliSense plugin supports the hover functionality:

The plugin relies upon the Fortran Language Server, which is the same dependency as in Brad’s setup with the Atom editor.

Interestingly, the Modern Fortran plugin for VS code has over 120,000 unique installs.

Their is also series of Youtube videos from Lukas Lamm on how to install VS Code for Fortran:

2 Likes