Loitering with INTENT

When I first started to learn FORTRAN mumblemumble years ago, one of the things that used to trouble me was how a routine 'knew' whether its arguments were meant to be input or output or both. In one sense, the answer was obvious; it didn't need to because the message was implicit in the medium of the code (modulo subtle gotchas such as passing in constants).

Now the language has the INTENT specifier for arguments to routines, so clearly the answer isn't quite so obvious after all. I've never yet used the specifier, so in that sense a routine still doesn't need to know whether arguments are input or output or both. Until recently, I think I had assumed that use of the specifier would not actually affect computed results, but could help the compiler to make the computation more efficient.

What I am wondering now, having been wrestling with my first attempt to write a function with the RECURSIVE specifier, is whether there are situations where the correct use of INTENT is mandatory if the computation is to give the correct result.

Thoughts, anyone?

I use INTENT more for documentation of the interface so that if I am to call a routine, I know what the routine is expecting and what it will return. I would expect the INTENT attribute is also checked by the compiler, so that if the arguments are used in a way contrary to as defined, then this will produce a compiler error. I'd expect that a variable with INTENT(IN) would produce a compiler error if it's value was changed in the routine, or INTENT(OUT), an error if not initialised. I'm not sure about INTENT will 'help the compiler to make the computation more efficient', although this might be the case.

John

Quoted from JohnCampbell I use INTENT more for documentation of the interface so that if I am to call a routine, I know what the routine is expecting and what it will return.

Ah, that's a good idea. The subroutine doesn't need to know the nature of the arguments, but the *user *does ... thank you.

Your other suggestions about using INTENT in a manner something like ASSERT, to trigger errors if inconsistencies arise between actual and declared nature of arguments, would make an interesting little exercize.

A simple test will demonstrate what the compiler can do with regard to the misuse of variables declared as INTENT(IN) or INTENT(OUT).

These attributes can lead to improved efficiency when, for example, array sections are passed as arguments. In which case a 'copy in' or 'copy out' process may be required by default (for INTENT(INOUT)).

So there [u:c131110d16]is[/u:c131110d16] a compiler efficiency gain with INTENT. And there I was thinking it was just another variation on a Comment line - C or !

Eddie

Thank you for all replies thus far. Since I composed the original post, I have been wrestling further with the original question, both theoretically and practically. My code now has a RECURSIVE function that makes use of octree data structures, using arrays of pointers according to the neat trick mentioned here:

https://forums.silverfrost.com/Forum/Topic/1466

(so, pretty far out by my standards), and it is more or less working. Some images I give it come back out the other side processed, some don't. I've stepped carefully through such an example, and it seems that one of the arguments I'm passing to my RECURSIVE routine is occasionally not getting modified within the routine as it should. It is an INTENT (INOUT) argument, that measures the current and ultimate minimum distance between a target and a set of candidates, the closest match being what the function is intended to return.

If the function were not recursive, clearly I would initialize that distance measure within the routine and update it in the usual way. But the recursion changes things ... at the moment, I can't see that it's possible to do that, because it would get re-initialized with each recursive call. So I have to pass an initial value in as an argument ... and sometimes, for reasons I don't understand, it's not getting updated, or at least the value that is passed back is the same as the value that is passed in. And this matters because whether or not it has changed is the basis for subsequent logic flow in the calling routine.

I can see how passing an INTENT (INOUT) argument up and down through levels of recursion might be a recipe for difficulty :lol: ... what do others think?