Special cases

There are certain cases which the potential user should bear in mind:

• If the subroutine or function calls other subroutines or functions, their definition should be changed as follows:

  >

  They must USE the module deriv_class.

  >

  All dependent and independent variables have to be declared as TYPE (func).

  No change is required in the argument list.
• Use of COMMON blocks and EQUIVALENCE statements, although discouraged by the introduction of modules and pointers in FORTRAN 90, is widespread. Transfered constants pose no problem. On the other hand, the awkward programming style of passing input and returning results from a subroutine or function through COMMON blocks or using EQUIVALENCEd variables, requires the user to treat them as if they were declared in the argument list; that is, their names must be changed, and other variables should be declared, as described above. The subroutine independent should be called for the input variables and their values should be extracted and update the COMMON blocks at the end. For example

   REAL :: constant
   REAL :: x            ! input variable
  
   COMMON/block/constant, x
   ...........
   !  use x
   ...........
  

  should become

   REAL :: constant
   REAL :: x_           ! input variable
   TYPE (func) :: x            
  
   COMMON/block/constant, x_
  
   CALL independent(i, x, x_)        !   i : unique index 
   ............
   ! use x
   ............
  
   ! at the end of the routine
   CALL extract(x, x_)  ! assign to x_ the expected value
  

• The user must ensure, and modify the subroutine or function if necessary, that the generic names of trigonometric and other mathematical functions are used; that is, for example, SIN(x) is used instead of DSIN(x) irrespectively of the type of x, as encouraged by FORTRAN 77. Also, the user should eliminate all transformations from one kind to another between variables of TYPE (func). That is, statements such as y = DBLE(x) works for x, y if they are real (with the appropriate kinds), but as deriv_class provides a TYPE (func) with only one kind, such transformations have no meaning. Likewise, assignments of a TYPE (func) to a real are not supported.