info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Subprograms vs procedures
245 views
Skip to first unread message
Norman Worth
May 22, 2020, 5:12:38 PM5/22/20
to
Marshall Ward wrote:
> I have a very semantic question which could only matter to someone parsing
>
> 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). The
>
> 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?
>
You have it right. In Fortran, subroutines and functions are
subprograms, entirely separate from the main program (at least in
concept). But that isn't true for languages like C or Ada where a
procedure or function may be declared within a main program and shares
data with it. In Pascal, this is the only way you can declare a
procedure or function. Such internally declared procedures and
functions can usually refer to data in the enclosing program without
having it passed as a parameter. Most newer languages deriving from
Algol also allow separate compilation of procedures and functions, which
do not share data like that. As far as I can tell, the terms subroutine
and procedure are equivalent. Algol 57 used the term procedure, and it
derivatives followed suit. FORTRAN used the term SUBROUTINE for the
same sort of thing.
> I have a very semantic question which could only matter to someone parsing
>
> 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). The
>
> 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?
>
You have it right. In Fortran, subroutines and functions are
subprograms, entirely separate from the main program (at least in
concept). But that isn't true for languages like C or Ada where a
procedure or function may be declared within a main program and shares
data with it. In Pascal, this is the only way you can declare a
procedure or function. Such internally declared procedures and
functions can usually refer to data in the enclosing program without
having it passed as a parameter. Most newer languages deriving from
Algol also allow separate compilation of procedures and functions, which
do not share data like that. As far as I can tell, the terms subroutine
and procedure are equivalent. Algol 57 used the term procedure, and it
derivatives followed suit. FORTRAN used the term SUBROUTINE for the
same sort of thing.
ga...@u.washington.edu
May 22, 2020, 6:45:21 PM5/22/20
to
On Friday, May 22, 2020 at 2:12:38 PM UTC-7, Norman Worth wrote:
> 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.
(snip)
> You have it right. In Fortran, subroutines and functions are
> subprograms, entirely separate from the main program (at least in
> concept). But that isn't true for languages like C or Ada where a
> procedure or function may be declared within a main program and shares
> data with it. In Pascal, this is the only way you can declare a
> procedure or function. Such internally declared procedures and
> functions can usually refer to data in the enclosing program without
> having it passed as a parameter. Most newer languages deriving from
> Algol also allow separate compilation of procedures and functions, which
> do not share data like that. As far as I can tell, the terms subroutine
> and procedure are equivalent. Algol 57 used the term procedure, and it
> derivatives followed suit. FORTRAN used the term SUBROUTINE for the
> same sort of thing.
It does seem that a new term was added, when not needed.
For one, it comes in the case of procedure pointers, which I
suppose could have been called subprogram pointers.
There is also BLOCK DATA, which is called a subprogram, even though,
at least on the systems that I know, isn't actually called.
It generates initialized static data, instead of the uninitialized
static data that COMMON would otherwise use.
The Fortran distinction between SUBROUTINE and FUNCTION is that
the latter returns a value. C ignores this, calling them both
functions. C also allows calling functions, while ignoring that
they return a value. (C actually allows all expression evaluation
while ignoring the value. Functions are not a special case.)
Fortran also uses both structure and derived-type, for what other
languages call structure (or struct in C and C++).
> 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.
> You have it right. In Fortran, subroutines and functions are
> subprograms, entirely separate from the main program (at least in
> concept). But that isn't true for languages like C or Ada where a
> procedure or function may be declared within a main program and shares
> data with it. In Pascal, this is the only way you can declare a
> procedure or function. Such internally declared procedures and
> functions can usually refer to data in the enclosing program without
> having it passed as a parameter. Most newer languages deriving from
> Algol also allow separate compilation of procedures and functions, which
> do not share data like that. As far as I can tell, the terms subroutine
> and procedure are equivalent. Algol 57 used the term procedure, and it
> derivatives followed suit. FORTRAN used the term SUBROUTINE for the
> same sort of thing.
For one, it comes in the case of procedure pointers, which I
suppose could have been called subprogram pointers.
There is also BLOCK DATA, which is called a subprogram, even though,
at least on the systems that I know, isn't actually called.
It generates initialized static data, instead of the uninitialized
static data that COMMON would otherwise use.
The Fortran distinction between SUBROUTINE and FUNCTION is that
the latter returns a value. C ignores this, calling them both
functions. C also allows calling functions, while ignoring that
they return a value. (C actually allows all expression evaluation
while ignoring the value. Functions are not a special case.)
Fortran also uses both structure and derived-type, for what other
languages call structure (or struct in C and C++).
Simon Geard
May 23, 2020, 7:52:09 AM5/23/20
to
On 22/05/2020 23:45, ga...@u.washington.edu wrote:
> On Friday, May 22, 2020 at 2:12:38 PM UTC-7, Norman Worth wrote:
>> Marshall Ward wrote:
>
> (snip)
>
>
> On Friday, May 22, 2020 at 2:12:38 PM UTC-7, Norman Worth wrote:
>> Marshall Ward wrote:
>
> (snip)
>
>
> The Fortran distinction between SUBROUTINE and FUNCTION is that
> the latter returns a value. C ignores this, calling them both
> functions. C also allows calling functions, while ignoring that
> they return a value. (C actually allows all expression evaluation
> while ignoring the value. Functions are not a special case.)
>
If you call a Fortran subroutine from C it does return a value. That
> the latter returns a value. C ignores this, calling them both
> functions. C also allows calling functions, while ignoring that
> they return a value. (C actually allows all expression evaluation
> while ignoring the value. Functions are not a special case.)
>
value is normally 0 but if the subroutine exits through an alternate
return it will be a positive integer specifying which route was taken.
Simon
Gary Scott
May 23, 2020, 11:47:18 AM5/23/20
to
built from other things to me. I prefer it.
Steve Lionel
May 23, 2020, 12:53:54 PM5/23/20
to
On 5/23/2020 7:52 AM, Simon Geard wrote:
> If you call a Fortran subroutine from C it does return a value. That
> value is normally 0 but if the subroutine exits through an alternate
> return it will be a positive integer specifying which route was taken.
This is not true. Fortran subroutines return no value. If you look for a
> If you call a Fortran subroutine from C it does return a value. That
> value is normally 0 but if the subroutine exits through an alternate
> return it will be a positive integer specifying which route was taken.
value it will be unpredictable what you see. In this sense it is similar
to a C void function.
Alternate return is not part of the current Fortran language. How it is
implemented, for compilers that still support it, is "processor-dependent".
I have not yet seen in this thread a mention of contained procedures,
which are able to see declarations in their host's scope.
--
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
FortranFan
May 23, 2020, 1:43:52 PM5/23/20
to
On Saturday, May 23, 2020 at 12:53:54 PM UTC-4, Steve Lionel wrote:
> ..
In the above comment, it's unclear what is meant by "Alternate return is not part of the current Fortran language."
Fortran does support alternate returns as part of the current standard even as the standard marks it an obsolescent feature. Alternate returns are actually more useful than some of the more questionable bugs in the standard such as "implied save" that masquerade as features. Owing to the need for conforming processors to have support for alternate returns, the implementations for this facility can likely provide a route to brainstorm and prototype a better and much-needed exception handling system in the language e.g., https://github.com/j3-fortran/fortran_proposals/issues/172#issuecomment-628971119
Here's what the 18-007r1 document toward Fortran 2018 states re: the RETURN statement:
19 15.6.2.7 RETURN statement
20 R1542 return-stmt is RETURN [ scalar-int-expr ]
21 C1575 (R1542) The return-stmt shall be in the inclusive scope of a function or subroutine subprogram.
22 C1576 (R1542) The scalar-int-expr is allowed only in the inclusive scope of a subroutine subprogram.
23 1 Execution of the RETURN statement completes execution of the instance of the subprogram in which it appears.
24 If the expression appears and has a value n between 1 and the number of asterisks in the dummy argument list, the CALL statement
25 that invoked the subroutine branches (11.2) to the branch target statement identified by the nth alternate return specifier in the
26 actual argument list of the referenced procedure. If the expression is omitted or has a value outside the required range, there is no
27 transfer of control to an alternate return.
C programming language doesn't really have a concept of "alternate returns".
Besides constraint C1554 in section 15.6.2 Procedures defined by subprograms of the Fortran standard effectively disallows the use of alternate returns in the context of interoperability with C.
11 C1554 If proc-language-binding-spec is specified for a procedure, each of its dummy arguments shall be an inter
12 operable procedure (18.3.6) or a variable that is interoperable (18.3.4, 18.3.5), assumed-shape, assumed
13 rank, assumed-type, of type CHARACTER with assumed length, or that has the ALLOCATABLE or
14 POINTER attribute.
> ..
> Alternate return is not part of the current Fortran language. How it is
> implemented, for compilers that still support it, is "processor-dependent".
> ..
> implemented, for compilers that still support it, is "processor-dependent".
In the above comment, it's unclear what is meant by "Alternate return is not part of the current Fortran language."
Fortran does support alternate returns as part of the current standard even as the standard marks it an obsolescent feature. Alternate returns are actually more useful than some of the more questionable bugs in the standard such as "implied save" that masquerade as features. Owing to the need for conforming processors to have support for alternate returns, the implementations for this facility can likely provide a route to brainstorm and prototype a better and much-needed exception handling system in the language e.g., https://github.com/j3-fortran/fortran_proposals/issues/172#issuecomment-628971119
Here's what the 18-007r1 document toward Fortran 2018 states re: the RETURN statement:
19 15.6.2.7 RETURN statement
20 R1542 return-stmt is RETURN [ scalar-int-expr ]
21 C1575 (R1542) The return-stmt shall be in the inclusive scope of a function or subroutine subprogram.
22 C1576 (R1542) The scalar-int-expr is allowed only in the inclusive scope of a subroutine subprogram.
23 1 Execution of the RETURN statement completes execution of the instance of the subprogram in which it appears.
24 If the expression appears and has a value n between 1 and the number of asterisks in the dummy argument list, the CALL statement
25 that invoked the subroutine branches (11.2) to the branch target statement identified by the nth alternate return specifier in the
26 actual argument list of the referenced procedure. If the expression is omitted or has a value outside the required range, there is no
27 transfer of control to an alternate return.
C programming language doesn't really have a concept of "alternate returns".
Besides constraint C1554 in section 15.6.2 Procedures defined by subprograms of the Fortran standard effectively disallows the use of alternate returns in the context of interoperability with C.
11 C1554 If proc-language-binding-spec is specified for a procedure, each of its dummy arguments shall be an inter
12 operable procedure (18.3.6) or a variable that is interoperable (18.3.4, 18.3.5), assumed-shape, assumed
13 rank, assumed-type, of type CHARACTER with assumed length, or that has the ALLOCATABLE or
14 POINTER attribute.
Steve Lionel
May 23, 2020, 1:55:20 PM5/23/20
to
On 5/23/2020 1:43 PM, FortranFan wrote:
> On Saturday, May 23, 2020 at 12:53:54 PM UTC-4, Steve Lionel wrote:
>
>> ..
>> Alternate return is not part of the current Fortran language. How it is
>> implemented, for compilers that still support it, is "processor-dependent".
>> ..
>
> In the above comment, it's unclear what is meant by "Alternate return is not part of the current Fortran language."
It was my mistake - I thought alternate returns had been deleted some
> On Saturday, May 23, 2020 at 12:53:54 PM UTC-4, Steve Lionel wrote:
>
>> ..
>> Alternate return is not part of the current Fortran language. How it is
>> implemented, for compilers that still support it, is "processor-dependent".
>> ..
>
> In the above comment, it's unclear what is meant by "Alternate return is not part of the current Fortran language."
time ago. Shows what I get for not checking before posting.
Simon Geard
May 24, 2020, 6:13:42 PM5/24/20
to
snip
>
> C programming language doesn't really have a concept of "alternate returns".
>
> Besides constraint C1554 in section 15.6.2 Procedures defined by subprograms of the Fortran standard effectively disallows the use of alternate returns in the context of interoperability with C.
>
> 11 C1554 If proc-language-binding-spec is specified for a procedure, each of its dummy arguments shall be an inter
> 12 operable procedure (18.3.6) or a variable that is interoperable (18.3.4, 18.3.5), assumed-shape, assumed
> 13 rank, assumed-type, of type CHARACTER with assumed length, or that has the ALLOCATABLE or
> 14 POINTER attribute.
>
>
recollection from the 90's when we used alternate returns as an
exception mechanism. The program ran on VAX, SG, HP, Sun, x86 and some
others so different processors and oses. Before posting I did try it
(gcc 8.4, intel, linux) and it does work although I accept that this now
might be luck because the example is very simple.
ga...@u.washington.edu
May 25, 2020, 3:33:11 AM5/25/20
to
On Saturday, May 23, 2020 at 10:43:52 AM UTC-7, FortranFan wrote:
(snip)
> C programming language doesn't really have a concept of "alternate returns".
Not exactly.
But since C only has functions, not subroutines, and if a function
does something and otherwise doesn't need to return a value,
it will often return a status value as a small integer.
It is, then, not unusual to call a function from a switch statement:
switch(fun(x,y,z) {
case 0: // no error
...
break;
case 1: // error 1
...
break;
}
To be closer to alternate return, goto statements could
be place in the switch statement, which wouldn't even
need break:
switch(fun(x,y,z) {
case 0: // no error
goto noerror;
case 1: // error 1
goto error1;
case 2: // error 2
goto error2;
}
Systems that I know implementing alternate return, implement
them as return values in the same register that functions return
the value in.
Many IBM OS/360 programs, such as compilers, have return values
(completion codes) that are multiples of four. In more common
terms, 4 is warning, 8 is error, 12 is severe error.
Multiples of four conveniently allow an indexed branch with
either four byte address constants or four byte branch instructions.
(snip)
> C programming language doesn't really have a concept of "alternate returns".
But since C only has functions, not subroutines, and if a function
does something and otherwise doesn't need to return a value,
it will often return a status value as a small integer.
It is, then, not unusual to call a function from a switch statement:
switch(fun(x,y,z) {
case 0: // no error
...
break;
case 1: // error 1
...
break;
}
To be closer to alternate return, goto statements could
be place in the switch statement, which wouldn't even
need break:
switch(fun(x,y,z) {
case 0: // no error
goto noerror;
case 1: // error 1
goto error1;
case 2: // error 2
goto error2;
}
Systems that I know implementing alternate return, implement
them as return values in the same register that functions return
the value in.
Many IBM OS/360 programs, such as compilers, have return values
(completion codes) that are multiples of four. In more common
terms, 4 is warning, 8 is error, 12 is severe error.
Multiples of four conveniently allow an indexed branch with
either four byte address constants or four byte branch instructions.
JCampbell
May 25, 2020, 4:46:32 AM5/25/20
to
"The standard introduces the concepts of subprograms and procedures"
Where was this posted and where is it in the Standard?
I have not read any discussion indicating "subprogram" is a technical term in
the Fortran Standard.
"subprograms" are mentioned in Table 2.1 to describe FUNCTION or SUBROUTINE that
appear in a CONTAINS block.
Section 12.2.2.2 refers to both with :
"Internal subprograms are the same as external subprograms except that the name
of the internal procedure is not a global identi er, an internal subprogram shall
not contain an ENTRY statement, and the internal subprogram has access to host
entities by host association."
It appears that "subprogram" is a general descriptor of both
internal and external : function and subroutine.
There is also the distinguishing between external and internal (contains) in that
ENTRY is only for external subroutines.
Marshall Ward
May 25, 2020, 8:32:39 AM5/25/20
to
> Where was this posted and where is it in the Standard?
> I have not read any discussion indicating "subprogram" is a technical term in
> the Fortran Standard.
I submitted the original post after reading these two section in 5.2 of ISO/IEC DIS 1539-1:2017 (E).
> I have not read any discussion indicating "subprogram" is a technical term in
> the Fortran Standard.
5.2.1 says: "A subprogram is a function subprogram or subroutine subprogram". I interpreted this as a generic term for functions and subroutines. Following the links in the document take one to the explicit syntax defintions of function and subroutine (R1529 and R1534 in this doc).
5.2.3 says: "A procedure is a function or subroutine", which is very similar to the previous statement. There is then an entire section (15) devoted entirely to procedures, with this line in 15.6.21: "A procedure is defiend by the initial SUBROUTINE or FUNCTION statement of a subprogram" (plus some ENTRY exceptions; let's ignore that for now).
Those two descriptions make me think that the two terms are effectively identical.
ga...@u.washington.edu
May 25, 2020, 9:05:06 AM5/25/20
to
On Monday, May 25, 2020 at 5:32:39 AM UTC-7, Marshall Ward wrote:
(snip regarding subprogram and procedure)
> Those two descriptions make me think that the two terms are effectively identical.
Note that there is a PROCEDURE (keyword) statement, but no subprogram
statement.
On the other hand, at least from the way the index is written,
there are elemental subprograms, but not elemental procedures.
I suspect that elemental procedure is a fine description, but
it seems not in the index.
(snip regarding subprogram and procedure)
> Those two descriptions make me think that the two terms are effectively identical.
statement.
On the other hand, at least from the way the index is written,
there are elemental subprograms, but not elemental procedures.
I suspect that elemental procedure is a fine description, but
it seems not in the index.
steve kargl
May 25, 2020, 12:33:26 PM5/25/20
to
JCampbell wrote:
> "The standard introduces the concepts of subprograms and procedures"
>
> Where was this posted and where is it in the Standard?
>
> I have not read any discussion indicating "subprogram" is a technical term in
> the Fortran Standard.
>
Then you haven't read a recent version of the Fortran standard.
> "The standard introduces the concepts of subprograms and procedures"
>
> Where was this posted and where is it in the Standard?
>
> I have not read any discussion indicating "subprogram" is a technical term in
> the Fortran Standard.
>
F2018, Section 3 defines terms. A casual search finds the word
subprogram used quite a bit; including
3.66.6
elemental subprogram
subprogram with the ELEMENTAL prefix (15.8.1)
3.142
subprogram
function-subprogram (R1529) or subroutine-subprogram (R1534)
3.142.1
external subprogram
subprogram that is not contained in a main program, module,
submodule, or another subprogram
3.142.2
internal subprogram
subprogram that is contained in a main program or another subprogram
3.142.3
module subprogram
subprogram that is contained in a module or submodule but is
not an internal subprogram
If you then go to Section 5, you'll find the high level syntax. The
word subprogram appears in numerous EBNF rules.
--
steve
FortranFan
May 25, 2020, 2:51:02 PM5/25/20
to
In the original thread which was opened by @Marshall Ward, the comments by @Ian Harvey were interesting:
"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."
You can see it here: https://groups.google.com/d/msg/comp.lang.fortran/0XAlDKKsErA/cAhYByA7BQAJ
0 new messages