Subprograms vs procedures

[Marshall Ward]

I have a very semantic question which could only matter to those who spending far too much time reading the language standard.

The standard introduces the concepts of subprograms and procedures. They seem extremely similar, in that both are associated with either subroutines or functions, but there does seem to be a distinction which I currently do not understand.

Subprograms are defined as either *function-subprogram* or *subroutine-subprogram*. Since these phrases define the syntax of each unit, I am guessing it means that subprograms are either functions or subprograms.

Procedure is defined as an "entity encapsulating an arbitrary sequence of actions that can be invoked directly during program execution", which to me sounds like the instructions within the subprogram, rather than the subprogram itself. But they could also just describe the subprogram.

One possible difference is that it seems an "external procedure" could describe a function defined outside of Fortran (in C, for example).

There is also this deprecated ENTRY thing, which I know nothing about. But they seem to be considered procedures. There also seems to be a "statement" procedure which is also deprecated.

Is it just as simple as "all subprograms are procedures, but not all procedures are subprograms"? Or is there a more subtle point that I am missing?

[ga...@u.washington.edu]

On Tuesday, March 24, 2020 at 2:11:09 PM UTC-7, Marshall Ward wrote:

(snip)

> The standard introduces the concepts of subprograms and procedures.
> They seem extremely similar, in that both are associated with either
> subroutines or functions, but there does seem to be a distinction
> which I currently do not understand.

I have wondered, too, but not enough to ask.

I believe the distinction comes out in that you can have procedure
pointers, like would be function pointers in C. Maybe someone
else will say more.

> There is also this deprecated ENTRY thing, which I know nothing about.
> But they seem to be considered procedures.

This one I can explain. Sometimes it is useful to have two different
functions or subroutines that share code. Consider, as a common example,
a function to compute SIN and COS. They use the same polynomial
expansion, but with different argument reduction. Traditionally,
they were written in assembly, but now are more commonly in a higher
level languages, such as C. (But C doesn't have ENTRY!)

In any case, you could have a function to compute SIN, with an ENTRY
to compute COS. They each do the appropriate argument reduction,
and then go to common code to use the appropriate expansion.

ENTRY traces back to about when FUNCTION and SUBROUTINE were added,
in the Fortran II years. (That is, some years before the first
standard in 1966.) Another example is a random number generator
with an entry point to initialize the seed value.

Like many features, it can be misused, sometimes makes programs harder
to read, and isn't needed all that often. Partly, though, it made
programs, like a combined SIN and COS, more space efficient, and also
a little faster. That was more important 60 years ago than now.

> There also seems to be a "statement" procedure which is also deprecated.

Statement functions are currently discussed in another thread. You
might follow the discussion there. I don't know if statement
functions count as procedures or not.

[FortranFan]

On Tuesday, March 24, 2020 at 5:11:09 PM UTC-4, Marshall Ward wrote:

> I have a very semantic question which could only matter to those who spending far too much time reading the language standard.

> ..

My take is "procedure" is the more abstract concept in the standard that is defined (per your citation) as an "entity encapsulating an arbitrary sequence of actions that can be invoked directly during program execution".

The standard then defines a subprogram as either "function-subprogram (R1529) or subroutine-subprogram (R1534)".

It then states a function as a "*procedure* that is invoked by an expression"

And it defines a subroutine as a "*procedure* invoked by a CALL statement, by defined assignment, or by some operations on derived-type entities."

Thus you will note a function is one type of a procedure and a subroutine is another type. The standard alludes to other types of procedure. But a subprogram has to be either a function or a subroutine.

[Ron Shepard]

On 3/24/20 6:06 PM, ga...@u.washington.edu wrote:
> On Tuesday, March 24, 2020 at 2:11:09 PM UTC-7, Marshall Ward wrote:

> [...]

>> There is also this deprecated ENTRY thing, which I know nothing about.
>> But they seem to be considered procedures.
>
> This one I can explain. Sometimes it is useful to have two different
> functions or subroutines that share code. Consider, as a common example,
> a function to compute SIN and COS. They use the same polynomial
> expansion, but with different argument reduction. Traditionally,
> they were written in assembly, but now are more commonly in a higher
> level languages, such as C. (But C doesn't have ENTRY!)
>
> In any case, you could have a function to compute SIN, with an ENTRY
> to compute COS. They each do the appropriate argument reduction,
> and then go to common code to use the appropriate expansion.

I think this is a good description. In modern fortran, you can do these
same types of things by defining a module that has some entities
defined, maybe expansion coefficients for special functions, or roots
and weights for gaussian integrations, and things like that. Then within
the module, you have several contained functions or subroutines that
share those entities.

Before modules were introduced, the only way to share data like that
between different subprograms was through common blocks or with entry
points. With common, those variables were global, even when they didn't
need to be. So that left entry points. In most of the subprograms with
entry points that I wrote, the main subroutine was never called. Its
only purpose was to define the local variables that were shared and to
define the dummy arguments that were later used by the entry points. I
think the entry point dummy arguments are required to be a subset of the
main subroutine dummy arguments. So there were lots of odd quirks when
using this feature to write programs. With f77, things were cleaned up
al little because of SAVE. You could SAVE the shared variables, or the
common blocks, so they did not need to be declared elsewhere, and you
knew they would survive between entry point calls. The typical
subprogram structure was like this:

subroutine top( arg1, arg2, arg3,...)
integer arg1, arg2,...
real arg3, arg4...
save ...list of shared local variables...
data / ...initialization of those saved variables.../

entry sub1( arg1, arg2,...)
...do whatever...
return

entry sub2( arg1, arg3,...)
...do whatever...
return

entry sub3( arg4, arg5,...)
...do whatever...
return

end

In the calling program, the entry points would be called in the normal way:

...
call sub1( i, j )
...
call sub2( k, x )
...

This means that the linker had to recognize the entry points in the same
way that a subprogram was defined and referenced.

Dummy arguments could be shared by several entry points, but I think
they all had to be a subset of the top subroutine argument lists. All of
the declarations had to be for the top subroutine, there were no
declarations allowed later within the entry point code.

If you did not have a return statement after one entry point, then
execution would just keep going past the next entry point until a return
statement was finally executed. Sometimes this was on purpose, sometimes
it was just a programming oversight. With GOTO, you could write
spaghetti code that could jump around between entry points.

Only dummy arguments that were defined in the entry could be referenced.
Some compilers relaxed that requirement, and you could call one entry
point to define the association between actual and dummy arguments, and
then you could call other entry points and it would remember that
previous association. This was done mostly to shorten argument lists for
the subsequent entry point calls. With modern fortran, you might do
something like that with saved pointer variables.

If the top subprogram was a subroutine, then all of the entry points had
to be subroutines; if it was a function, then all of the entry points
had to be functions. If I remember correctly, the entry points could not
call each other, the only allowed references were from outside.

There were lots of little quirks when programming like this. Things are
much better now with modules and contained procedures.

$.02 -Ron Shepard

[Ian Harvey]

On 25/03/2020 6:41 am, Marshall Ward wrote:
> I have a very semantic question which could only matter to those who
> spending far too much time reading the language standard.
>
> The standard introduces the concepts of subprograms and procedures.
> They seem extremely similar, in that both are associated with either
> subroutines or functions, but there does seem to be a distinction
> which I currently do not understand.
>
> Subprograms are defined as either *function-subprogram* or
> *subroutine-subprogram*. Since these phrases define the syntax of
> each unit, I am guessing it means that subprograms are either
> functions or subprograms.
>
> Procedure is defined as an "entity encapsulating an arbitrary
> sequence of actions that can be invoked directly during program
> execution", which to me sounds like the instructions within the
> subprogram, rather than the subprogram itself. But they could also
> just describe the subprogram.

A subprogram is a chunk of source code. You can write it out by hand, or
type it in your text editor.

A procedure is the thing that might arise when a subprogram is presented
to a Fortran processor. Procedures can also be defined by other means.