Do we still need subroutines ?

Question

In Fortran, a clear difference exists between function and subroutine: functions return one value, subroutines return no value. This introduce a cascade of differences between the two. One example is the calling semantics: you can call a function just as in other languages, but in order to call a subroutine you must issue a call statement first.

With the addition of pointers and data types in Fortran95, it appears that there is no technical limitation in making any subprogram a function, and keeping subroutines just for legacy. Functions could return zero (you just return a dummy integer), one, or multiple values (for example, you could return a pointer to an allocated instance of a type, like a C++ STL Pair).

Am I wrong? Do we still need subroutines in Fortran programming due to some feature that subroutines have and functions don't?

Answer 1

I don't think subroutines are going anywhere. Most other languages allow methods that do and do not return values. I can't see any reason why that's a bad thing. No one should be moved to change a thing.

Legacy alone says that subroutines will persist as long as Fortran does. And as long as Fortran is around, there'll be nothing wrong with writing a method that performs an action and returns nothing.

UPDATE:

Why do you say "hassle"? What's the big deal? I disagree with the idea that subroutines are a "hassle" when they're used in an appropriate situation.

Fortran has maintained a distinction between functions and subroutines since version 77 and probably earlier. Other C-family languages do, too. Why is this suddenly such a hassle? Even the languages that have had pointers and objects for a long time have methods that return void.

Answer 2

If I understand correctly Stefano is not against the idea of subroutines. The opinion against them is nonsense. He against the usage of different styles for subroutines/functions.

Fortran is imperative programming language. More precisely it is a procedural programming language (and even more precisely it is structured programming language).

In imperative programming we have a state and statements to change it. In procedural programming our tools to do changes are procedures (we localize changes inside procedures). The procedure may or may not return some value. And I don't think that this fact (either procedure return value or not) is so significant reason to have 2 different entities in the programming language. We can have only functions (like in C) and just return something special when we do not actually need to return something (void). Or we can have only procedures and special syntax permitting to return values like in Modula-2, Oberon, ...

The language probably should have only one style to declare procedures. I agree with You, Stefano.

Answer 3

The fact that I have to answer myself to this question is insane, but that's how it is.

The difference stems from the fact that you cannot "call functions like in other languages" in Fortran. While in C you can call an integer function without assigning the value, example

int foo() {
    return 5;
}
int main() {
    foo(); // this works
}

In Fortran, you always have to associate a receiving variable. Example

module test
   implicit none

contains
   integer function foo()
      print *, "hello"
      foo = 0
   end function

end module

program hello
   use test
   integer :: x

   x = foo() ! this works
   foo() ! this does not compile

end program hello

Meaning that to "emulate" a void function by returning a dummy integer would still not allow you to call without having a receiver variable.

In Fortran, the void return type does not exist. Technically, you could structure your program with all functions, replace every occurrence of the call statement with x = like seen above, but that would not make your syntax similar to C or other languages anyway, where there is no distinction between void-returning functions and non-void returning functions. subroutines are the only entities that allow to "return void", but the semantic to perform the call is simply different. Apart from that, there's no difference between the two.

Answer 4

You're trying to program C in fortran again, aren't you? ;-)

In my opinion, yes - we do. For if for one reason only - they're easier to grasp, to understand, and they're more widely used than functions.

Also, -1, for I believe this is not a constructive question. If you don't like them, then don't use them.

Answer 5

If you search the comp.lang.fortran archives, you'll find discussions about the semantics of functions. IIRC it turns out that it's not clearly specified in the standard what is and what isn't allowed for functions that have side-effects.

For instance, can the compiler optimize

x = foo(args) + foo(args)

into

x = 2 * foo(args)

Or for another example, consider

x = y + foo(y)

What if foo() changes the value of y? Remember that Fortran doesn't have the C concept of sequence points.

In general, the recommendation by several experts is to use functions only if they're pure, otherwise use subroutines. And, that is advice that I follow myself as well.