Programmers Guide to F

1
Programmers Guide to F

• Modules Procedures
• Chapter 3
• Version 1.5
• Last Update November 6, 2006

2
Write a program to find the sum of the successive
even integers 2, 4, ..., 200.
3
Notice

• Note that in these slides, I will use bold font
  for the
• keywords of F, whenever they appear in code.
• Keywords are reserved words whose meanings are
  known
• by the compiler. For example
• program tromso
• end program tromso
• While the compiler knows the meanings of the
  reserved
• words, it does not know what tromso means.
• It is just a name that you have thought of, in
  order to
• name your program.
• Obviously, tromso is not a reserved word in F.

4
Terminology

• A computing project consists of data and program
  units.
• A program unit is either the main program, a
  module, or a
• procedure.
• Since there can only be one program in a
  computing project,
• that program is called the main program.
• There are usually many modules in a computing
  project.
• There may be one or more procedures in a module.
• Large computing projects are extremely difficult
  to debug and
• maintain unless they are split into
  independent modules.

5
Terminology

• The following are examples of programming
  entities
• parameters
• variables
• procedures (subroutines or functions)
• types (user-defined or built-in)
• Note that procedures and user-defined types can
  only be defined in a module.
• We shall discuss what a module is very soon.

6
Data Declarations

• As you know, you must declare your data as either
  constant or
• variable.
• Eg
• real, parameter pi 3.1415926
• real x
• You also know that you can declare your data to
• have one of the 5 built-in data types
  integer, real,
• logical, etc.
• In Chapter 6, you will learn how to declare your
  data
• to have a user-defined data type.
• User-defined types must also be written in a
  module, which
• will be discussed next.

7
Modules

• Large programs are extremely difficult to debug
  and maintain unless they are split into
  independent modules.
• A module contains data declarations and
  procedures just like a library.
• Procedures normally have many executable
  statements.
• Data declarations may have executable statements
  only when a variable or parameter is initialized
  within the data declaration as seen in the case
  of pi in the previous slide.
• A module cannot have any executable statements
  other than those written in data declarations or
  procedures.
• Since a module is a library, it may be used by
  different program units of a single program, or
  even by different programs, meaning different
  computing projects.
• A module is a program unit that is not executed
  directly.
• Modules are utilized by other program units via
  the use statement.

8
Writing and Using Modules

• !Here is a module for declaring constants
• module ali
• real, public, parameterpi3.141593
• real, public, parametere2.718281
• real, public, parameterg9.81
• end module ali
• ! Any program that needs these constants can
  simply use this
• ! module.

• program circle
• use ali
• real radius, perimeter
• radius2.2
• perimeter piradius2
• print , perimeter
• end program circle

9
Writing and using modules

• ! You can also declare variables in a module.
• module veli
• logical, public flag_1, flag_2
• end module veli
• ! Here is the program that uses this module
• program test2
• use veli
• logical, parameter f .false.
• flag_1 f
• flag_2 .not. F
• Print, flag_1, flag_2
• end program test2

10
The use statement

• For example, if a program unit or a procedure
  needs the contents of the module veli, then you
  must write
• use veli
• in the second line of that program unit.

11
The use statement

• With the use statement, there are two ways to
  affect the way that the names in a module are
  accessed by another program unit.

12
The use statement

• Using a variable name that is 1-character-long is
  not good programming practice.
• For example, searching the variable e with Ctrl-F
  will give you, not only all the appearances of
  the variable e, but also all the instances the
  letter e is used in the code.
• Therefore, you could pull the following trick.
• In the beginning of the program unit, you write
• use ali, naturallog gt e
• Thus, you allow this program unit to use the ali
  module, but the name of the constant e is changed
  to naturallog in this program unit.

13
The use statement

• If, on the other hand, in the beginning of the
  program unit, you write
• use ali, only pi
• then only pi is visible from module ali to this
  program unit, and none of the other data declared
  in module ali are visible.
• A combination of these is also possible
• use ali, only pi, naturallog gt e

14
Procedures

• There are only two kinds of procedures
• Subroutines
• Functions
• Procedures must always be written inside
• modules and not inside the main program.

15
Subroutines

• A subroutine may be used to perform any
  computation and is invoked by executing a call
  statement.

16
Writing a Subroutine

• ! A subroutine is very similar to a program.
• subroutine read_the_numbers()
• !Note the parantheses with nothing in between.
• !There is nothing in between because this
• !subroutine does not have any arguments.
• !However, you must still put the parantheses
  here.
• print, Input data n1
• read, n1
• print, You have entered n1 , n1
• print, Input data n2
• read, n2
• print, You have entered n2 , n2
• end subroutine read_the_numbers

17
Putting the Subroutines In a Module

• We shall now write module sort_3.
• It will contain declarations of variables n1, n2,
  and n3.
• It will also contain a subroutine after the
  keyword contains

18
The contains statement

• module sort_3
• public read_the_numbers
• real, public n1, n2, n3
• contains
• subroutine read_the_numbers()
• .
• .
• end subroutine read_the numbers
• end module sort_3

19
Subroutines with Arguments

• subroutine swap(a,b)
• ! This subroutine swaps the values of variables a
  and b.
• ! Note that a and b are called the dummy
  arguments of the subroutine
• ! swap, but temp is called a local variable of
  the subroutine swap
• ! and not a dummy argument.
• real, intent(in out) a, b
• real temp
• temp a
• a b
• b temp
• end subroutine swap
• ! Important Note
• ! People new to programming would probably write
  only
• ! a b
• ! b a
• ! and not see the necessity for the variable
  temp.
• ! Without temp, the value of variable a would be
  lost after the
• ! assignment statement a b.
• ! That is why, this is probably the most
  important example in this

20
Subroutines with Arguments

• To swap the values of n1 and n2, the following is
  written
• call swap(n1,n2)
• The variables n1 and n2 are the actual arguments
  of
• the subroutine swap.
• n1 corresponds to a, and n2 corresponds to b,
  because the order of the actual arguments are the
  same as the order of the dummy arguments.
• Note that the names of the actual arguments, n1
  and n2, need not be identical to the
  corresponding names of the dummy arguments, a and
  b.
• This is a very useful property because you do not
  have to
• know the names of the dummy arguments used in
  the
• subroutine when you want to call the subroutine,
  which may have been written by someone else.

21
Subroutines with Arguments

• Another situation arises when you do know the
  names of the dummy arguments but you do NOT know
  the order in which they appear in the procedure.
• In this situation, the following remedy is used
• call swap(b5.0, a4.0)

22
The intent of dummy arguments

• In a procedure, you must indicate the intent of
  each dummy argument.
• There are some exceptions to this rule, as seen
  in Section 3.5.8 and also in Chapter 8.
• intent allows the compiler to catch errors when
  the programmer violates the stated intent.
• intent also makes the code more easily understood
  by the human reader.

23
The intent of dummy arguments

• intent(in) is used when the dummy argument cannot
  be changed within the procedure.
• intent(out) is used when the value of the actual
  argument must not be used (in the calling program
  unit) until given an initial value in the
  procedure.
• intent(in out) is used when the dummy argument is
  expected to receive an initial value from, and
  return a (possibly) new value to the
  corresponding actual argument.
• You cannot use a parameter as the actual argument
  if the intent of the dummy argument is either
  (out) or (in out).
• This is obvious from the fact that parameters may
  not be changed during run time.

24
Functions

• If the purpose of a procedure is to compute only
  one value, then a function must be written
  instead of a subroutine.
• A function is almost like a program or a
  subroutine except that its first statement uses
  the keyword function.

25
Functions

• A function must have dummy arguments written in
  parantheses after the keyword function.
• This is followed by the keyword result and the
  name of the result variable.
• Dummy arguments of a function cannot have intent
  (out) or intent (in out).
• You are not allowed to specify the intent of the
  result variable since it is obviously out.

26
Functions

• function series_sum(m,n,s,d) result(sonuc)
• integer, intent(in) m, n
• real, intent(in) s, d
• real sonuc
• integer i
• sonuc0
• if (mgtn) then
• print , You have entered incorrect data
  mgtn
• stop
• end if
• do im,n
• if (igt3) then
• sonucsonucsid
• end if
• end do
• end function series_sum

27
Exercise

• Write two functions into the same module that
  compute and print the circumference and the area
  of a circle using its radius.
• Utilize this function from a main program that
  reads the radius of circle as a real value.

28
Solution

• module calculation
• public circumference,area
• real,public, parameterpi3.14
• contains
• function circumference(x) result (c)
• real,intent(in)x
• realc
• c2pix
• end function circumference
• function area(x) result (a)
• real,intent(in)x
• reala
• a pix2
• end function area
• end module calculation

• program circle
• use calculation
• realr
• print,"Enter the radius"
• read,r
• print,"r",r
• print,"circumference", circumference(r)
• print,"area",area(r)
• end program circle

29
Functions as Arguments

• An actual argument may be a function instead of a
  variable.
• In this case, obviously, the dummy argument
  should also be a dummy function not a dummy
  variable.
• Such a situation arises when there are many
  different candidate functions (as opposed to many
  different candidate variable values) to use as
  the actual argument.

30
Functions as Arguments

• Eg You want to calculate the area under a given
  function using a procedure, but you do not want
  to specify the name of the function since you
  want to write a general purpose procedure. (See
  page 122.)
• In a procedure that has a dummy function as a
  dummy argument, the dummy argument must be
  declared inside the procedure (just like a dummy
  variable would be declared inside the procedure.)
• In order to declare a dummy function inside a
  procedure, an interface block is used.

31
Functions as Arguments

• Eg The interface block for a function would be
  as follows
• interface
• function g(x,y) result(g_result)
• real, intent(in) x,y
• real g_result
• end function g
• end interface
• Note that there must be no executable statements
  in an interface block because we are only
  declaring the structure of the function.
• We do not need to know what the function actually
  calculates.
• You must read the example code on pages 122 and
  123 to fully understand this topic.

32
Subroutines as Arguments

• In the previous slides, we described how to use
  functions as arguments.
• The same rules apply when we want to use
  subroutines as arguments.

33
New TopicThe Concept of Data Hiding

• The concept of data hiding is useful especially
  when a group of programmers, say 20, work on the
  same computing project.
• In this case, each programmer would be
  responsible for a certain number of modules.
• Here comes in the concept of data hiding.
• Q Why does F allow us to use data hiding? That
  is, why
• are some variables hidden?
• A There are 3 reasons for this
• Sensitive data about the computing project may
  need to be secured from some of the programmers
  and/or users.
• The value of a very crucial variable may need to
  be protected from being changed by other
  programmers modules.
• It may be completely unnecessary to show the
  value of a variable to other programmers. It is
  best to keep unnecessary details hidden because
  it helps reduce clutter and paves the way for
  neatly created projects.

34
Data Hiding (contd)

• Q What happens if a programming entity is
  hidden?
• A You cannot use it. Furthermore, if that
  programming entity happens to be a variable, then
  you cannot change its value either.
• Eg Lets say that x is not a hidden variable,
  however, y is a hidden variable.
• That means x is visible (or accessible) to you,
  the programmer, however y is hidden from you.
• x 6 ! No compiler error here since x is
  accessible.
• x y ! COMPILER ERROR (y is hidden,
  therefore you cannot
• 
  refer to y.)
• y 5 ! COMPILER ERROR (y is hidden,
  therefore its value
• 
  cannot be changed.)

35
The Concept of Scope

• This is a very important topic. Students must pay
  special attention to this section. (You must read
  Section 3.6 on pages119-120 in your text book
  carefully.)
• Recall that a program unit is either the main
  program or a module or a procedure.
• Here is a Question / Answer (Q/A) Session
• Q What were the programming entities that we
  discussed before?
• A They were
• parameters
• variables
• procedures (subroutines or functions)
• types (user-defined or built-in)
• Q We know that each programming entity must have
  a name.
• What is the definition of the scope of a
  name?
• A The scope of a name (of a programming entity)
  is the set of lines in a computing project where
  that name is used to refer to the same
  programming entity.

36
Scope of names declared in the main program

• The scope of a name of parameter or a variable
  declared in the main program extends throughout
  that program, from the program statement all the
  way to the end program statement.

37
Scope of names declared in a procedure

• The scope of a name declared in a procedure
  extends from the beginning to the end of THAT
  PROCEDURE ONLY.

38
Head and body of a module

• In a module, the keyword contains separate the
  module into two parts head and body.
• module denizli
• lt HEAD OF MODULE gt
• contains
• lt BODY OF MODULE gt
• !Procedures are defined in the body of
  the module only.
• end module denizli

39
public and private

• We already know that each programming entity must
  have a name.
• Now, note that each programming entity MUST ALSO
  HAVE AN ACCESSIBILITY VALUE, public or private.
• Therefore, concept of the scope of a name of a
  programming entity depends on two things
• The place where that name is declared (or
  defined).
• Whether the accessibility value is public or
  private.

40
public and private

• Both public and private names defined in the head
  of a module are visible from the body of the same
  module. Recall that the body of a module is where
  its procedures are defined. Therefore, both
  public and private names defined in the head of a
  module are visible from the procedures in the
  same module.
• Moreover, public names defined in the head of a
  module are visible from other programming units
  that use this module.

41
Redeclaring a variable in a procedure

• A variable name redeclared in a procedure of the
  same module overrides the scope of the same name
  declared in the head of the module. Eg
• module m1
• public sub1,sub2!Names of the subroutines
  below.
• integer, publicd
• contains
• subroutine sub1()
• read , d
• ! This d is the same d that is
• ! declared at the head of the module
  m1.
• end subroutine sub1
• subroutine sub2()
• integerd ! d is redeclared in this
  subroutine.
• read , d ! Therefore, this d is not the same
  d
• ! declared at the head of the
  module m1.
• end subroutine sub2

42
A module cannot use itself either directly, or
indirectly

• (Incorrect) direct usage of a module by the
  module itself
• module bad
• use bad
• ....
• end module bad
• (Incorrect) indirect usage of a module by the
  module itself
• module good !This is a correct module.
• use really_bad
• ...
• end module good
• module really_bad !This is an incorrect module.
• use good ! Here we see indirect, circular, !
  usage of module really_bad.
• ...
• end module really_bad

43
A module cannot be used by two different
procedures of another module

• module quite-good !This is a correct module.
• ...
• end module quite-good
• module truly-bad
• ...
• contains
• subroutine s1()
• use quite-good
• ...
• end subroutine s1
• subroutine s2()
• use quite-good
• ...
• end subroutine s2
• end module truly-bad

44

• When a module is used in a program, a procedure,
  or another module, it is as if all the
  declarations (or definitions),
• but NOT those declared private in the module,
• or not available because of a use only option
  (Section 3.2),
• were made at the place where the use statement
  appears.

45

• Sec 3.10 (Recursion) is not included in the
  syllabus of BIL 106.