Volume Number: 13 (1997)
Issue Number: 9
Column Tag: Alternative Environments

The F Programming Language Tastes Like Java

by Walt Brainerd, David Epstein and Richard Hendrickson

F is a new programming language derived from Fortran in much the way Java is derived from C

This article describes the startling comeback of Fortran by discussing the features found in the F subset of Fortran 95 comparing them with the features found in Java. The combined strengths of Java and the F programming language make a wonderful introduction for beginners and a powerful package for professional programmers working on large projects. Even people familiar with modern Fortran and Java are unlikely to have noticed the benefits of combining the two.

Both languages claim multi-platform portability. Java capitalizes on the look and feel of C++ while aiming at professional programmers; F capitalizes on the efficiency and pedagogical design of Fortran 95 while aiming at teenage beginners, experienced scientists, engineers and large teams of programmers. Java offers powerful object-oriented capabilities familiar to the C++ community; F offers organized module-oriented capabilities familiar to the Fortran 95 community.

Getting over the initial shock that Fortran is not all that different from Java can be a stretch for any programmer not in a coma since 1995. The amazing similarities surprised even the authors, who had brought together over four decades of Fortran language design committee experience to create F while the Green team was creating Java.

The simple step taken by both language design teams is a move away from procedures as a first class citizen and the insistence that procedures be encapsulated inside a more powerful mechanism -- a class in Java and a module in F.

After comparing the features of F and Java, we suggest some benefits of combining F and Java for introductory programming instruction as well as for large professional projects and efficiency driven applications.

An example may help to show the similarities between F and Java. Listing 1 shows a binary tree written in both F and Java. Notice that the mythical phrase, "Java does not have pointers," is better said as, "Java does not support the dangerous pointer arithmetic found in C and C++."

The tree is made possible by the below statements that declare a recursive type:

type (node), pointer :: left, right ! found inside F "node"
 Tree left, right;    // found inside Java "Tree"

In F, the word "pointer" is actually used in the declaration of the "nested defined type;" in Java, the word "pointer" is not used in the declaration of the "nested class."

Listing 1: BinTree.f and BinTree.j

BinaryTree
A binary tree written in F is easily translated into Java.
! A Binary Tree in F                        // A Binary Tree in Java
module m_binary_tree             class Tree {
 public :: main, Insert, PrintTree
 private :: NewTree
 type, public :: node
 integer :: value                int value;
 type (node), pointer :: left, right      Tree left, right;
 endtype node
contains
 function NewTree(num) result(tree)      Tree (
  integer, intent(in) :: num          int num) {
  type (node), pointer :: tree
  allocate (tree)
  tree%value = num                value = num;
  nullify(tree%left)               left = null;
  nullify(tree%right)               right = null;
 endfunction NewTree             }//Constructor

 recursive subroutine Insert(tree, num)    static Tree Insert(
  type (node), pointer :: tree        Tree tree,
  integer, intent(in) :: num          int num) {
  if (.not. associated (tree)) then        if (tree==null) {
   tree = NewTree(num)             return new Tree(num);
  elseif (num < tree%value) then        }elseif(num <tree.value){
   call Insert(tree%left)              tree.left = Insert
                                       (tree.left, num);
                              return tree;
  else                         } else {
   call Insert(tree%right)              tree.right = Insert
                                       (tree.right, num);
                              return tree;
  endif                        }//if
 endsubroutine Insert             }//Insert

 recursive subroutine PrintTree(tree)     static void PrintTree(
  type (node), pointer :: tree        Tree tree) {
  if (associated (tree)) then          if (tree != null) {
   call PrintTree (tree%left)           PrintTree(tree.left);
   print *, tree%value               System.out.println
                                        (tree.value);
   call PrintTree (t%right)            PrintTree(tree.right);
  endif                        }//if
 endsubroutine PrintTree          }//PrintTree

 subroutine main                public static void 
                                  main (String argv[]) {
  type (node), pointer :: tree         Tree tree;
  integer :: i                   int i;
  nullify (tree)                 tree = null;
  print *, "Unsorted list"            System.out.println
                                      ("Unsorted list");
  do i = 1, 30, 3              for (i=1; i<3*10; i=i+3){
   print *, modulo(i,10)             System.out.println 
                                        (i%10);
   call insert(tree, modulo(i,10))       tree = Insert
                                          (tree, i%10);
  enddo                       }//for
  print *, "Sorted list"             System.out.println 
                                      ("Sorted list");
  call print_tree (tree)             PrintTree(tree);
 endsubroutine main              }//main
endmodule m_tree_sort             }//Tree

program tree_sort
 use m_tree_sort
 call main()
endprogram tree_sort

The strategy for pointers in F and Java is actually the same -- no physical address is made available and what is being pointed to must be specified in the declaration (that is, no void pointers). In F, pointers only can point to objects that are targets; in Java, everything is being pointed to, even procedures. A non-mainstream view of Java is not that there are no pointers, but that everything in Java is being pointed to.

We expect the average reader to be more familiar with Java than with the F programming language. Thus, an introduction to some of the F programming language is called for.

One major difference between F and Java is that Java technology often refers to much more than a programming language -- the class hierarchy from which all objects are derived, the Java Virtual Machine (JVM), bytecode and Just-In-Time compilers, to name just a few. F, on the other hand, does not have a standard module hierarchy or set of software tools considered part of the F technology other than the F compilers. Thus, this overview of F is a description of the F programming language. For those seeking more specifics, the grammar for F (in BNF) can be found on the Imagine1 web page (listed at the end of this article). F Statements

Figure 1 categorizes all the F statements. Instead of calling a procedure main as in Java, there is a single main program required in F and it can be given any name. An F program can use modules and reference public procedures and other public entities from the used modules. Modules and their contained procedures can also use other modules. This creates module hierarchies whose roots are the modules that were used in the program. Using a module is similar to importing a package in Java. Both languages encourage a hierarchical organization.

Organizational Constructs
 program
 use <module>...  module
 endprogram          public :: proc-list
               private :: proc-list
             contains
               <procs>........subroutine........function
               endmodule      use module   use module
           endsubroutine    endfunction

Action Constructs
 if / elseif / else / endif
 select case / case / case default / endselect
 do / cycle / exit / enddo
 where / elsewhere / endwhere

Declarations
 type    integer   character   intrinsic   interface
 endtype   real    logical     module     procedure
         complex                 endinterface

Actions
 = (assignment)       allocate     call   stop
 => (pointer assignment)   deallocate    return

Input/Output
 print   open   write   inquire    backspace
 read    close               rewind
                        endfile

Figure 1. Categorizing all the F statements.

One design goal in F is to require explicit declarations for entities and not rely on any defaults. This is the opposite extreme from the "old Fortran" with its implicit declaration of an integer by starting its name with the letter "i" as in

itotal = 0 ! Declares an integer in earlier Fortrans

One result of requiring everything to be explicitly stated is that the student's first module that contains a procedure will require a public statement. This leads into an early discussion of public and private if the instructor so chooses.

Those challenged to make a thorough comparison of F and Java will notice that Java does allow defaults and that the default for a function is protected. If Java were to employ the strategy used in F, the word protected would have to be specified explicitly.

The F Attributes

Figure 2 lists the attributes for F entities. A little description of public and private is given here as these attributes differ slightly from the others.

Attribute      Description

pointer        target Pointers can only point at objects that are targets.
public         private All module entities are either public or private.
intent         All subroutine arguments must be declared as intent in, out,
               or inout.  All function arguments must be intent in.
dimension      Arrays can be from one to seven dimensions.
allocatable    For dynamic allocation.
parameter      A constant.
save           A static local variable.

Figure 2. Attributes for F entities.

Procedures are listed in public or private statements in the module that defines them. All other module entities require a public or private attribute in their declaration statement. One other use of the word "private" is to declare the components of a public defined type as private to the module. Such a module would supply its users with access to the defined type and the procedures that operate on entities declared to be of this type. The insides of the type are hidden from the users of this module. An example of this can be seen in Listing 2, which hides the internal parts of a car from its users.

Listing 2: CarModule.f

CarModule
This car module exports a type that has private components.
module m_car
use m_engine
 private ! do not export entities from module m_engine
 public :: GetCarInfo !, ... public procs listed here
 private :: IncreaseCost !, ... private procs listed here
 type, public :: t_car
 private ! components are private to this module
 type (t_engine) :: engine ! t_engine from m_engine
 integer :: cost_of_engine
 integer :: year
 endtype t_car
contains
 subroutine GetCarInfo(engine, year)
 ! ...
 subroutine IncreaseCost()
 ! ...
endmodule m_car

Although there are many similarities between F and Java, there is one fundamental design difference and a few minor differences that deserve attention.

The fundamental difference between F and Java is the way in which modules and classes are accessed. In F, a module can be used, which makes its public entities available. There are two sorts of modules worth mentioning for this discussion:

1. Declare actual data entities to be shared amongst its users.
2. Provide the definition of types and procedures that operate on those types, requiring the users to declare the actual data entities, and call procedures accordingly.

In Java, a class can be imported, making its definition available for instantiations. This is similar to the second sort of F module listed above. Namely, the Java class definition provides a type and procedures that operate on that type, but it is left to the importer of this class to create instantiations and call procedures accordingly.

Although modules are similar to classes, the fact that modules are used instead of instantiated leads to a slight shift in organizational thinking. For example, if SetSalary is a procedure that sets the salary of an employee, and employee is part of a person, a Java reference may look like

 anEmployee.SetSalary(100);
 and an F reference may look like 
 call SetSalary(anEmployee, 100)

In Java, an Employee would automatically inherit the features of a person; in F, it is up to the designer of the employee module to use the person module and make appropriate features of a person available to employees. For example, if Gender is a feature of a person, a Java reference may look like

 anEmployee.GetGender();
 and an F reference may look like
 GetEmployeeGender(anEmployee)

Name Space

F references do not use dot notation. This presents a possible name space problem because the same name cannot be public in more than one used module within the scope of the use statements. The solution for this in F is the feature to rename used entities. For example,

 use employee_module, s1=>salary

makes the salary entity of the employee_module available only as the name s1 in the scope of this use statement.

Cats, Dogs, and Mammals

A more philosophical view of comparing module-oriented programming and object-oriented programming can be shown using the example of cats and dogs. One argument for object-oriented programming is that humans see the world in terms of objects instead of in terms of actions. We see cats and dogs instead of GiveBath, HuntBird, WagTail and SniffHand. This argument also holds for module-oriented programming with the word "module" replacing the word "object" -- humans see the world in terms of modules instead of in term of actions. Seeing cats and dogs as modules means viewing them as concepts which have definitions; it is possible to have an actual cat or dog object, but it is also possible to talk about them without having to create an instance of cat or dog.

The implementation difference can be found by taking a closer look at the writing and accessing of cats and dogs. In F, the implementor of cats and dogs can decide to use mammals to gain access to concepts common to all mammals. An F cat module cannot, however, export the mammal public entities. If the cat module wants to export a trait common to mammals such as SuckMilk, the implementor of the cat module must do some work to make this happen. In Java, when the cat class inherits from the mammal class, the cat class automatically exports all the public concepts of the mammal class. The access to cats in F is done by using the cat module and possibly calling KittenSucksMilk(aCat). The access to cats in Java is done by instantiating a cat and possibly calling aCat.SuckMilk.

Both methods have their advantages and disadvantages. Do you see cats and dogs or do you see mammals that are cats and dogs? In F, the designer of cats and dogs decides if it is important that they are mammals; in Java, the user of cats and dogs must understand that they are mammals.

Having hurdled the fundamental difference of using modules versus instantiating classes, other differences are minor jumps by comparison.

1. Intrinsic Procedures Versus Standard Libraries
2. F provides more than one hundred intrinsic procedures such as cos, tan, len and date_and_time. These intrinsic procedures are part of the F programming language and not part of a standard module that must be included or is implicitly included. Java provides much more than intrinsic procedures with its class hierarchy providing "standard" libraries for GUI building, exception handling, graphics, networking, multi-threading and coercion (such as integers to characters). This Java library will surely expand for whatever else becomes important (such as multimedia). To reference these goodies, the appropriate classes or packages must be imported. A wildcard of "*" can be used to import everything at the expense of size and speed of the application.

Both F and Java support using the same generic name to reference one of a group of specific procedures. Listing 3 shows overloading the swap for the F intrinsic types. Overloading operators is a different story.

Listing 3: Swap.f

SwapModule
This module overloads the name "swap" for all the intrinsic types.

module swap_module
 public :: swap

 interface swap
 module procedure int_swap, real_swap, complex_swap, &
      logical_swap, character_swap
 end interface !swap

contains

subroutine int_swap (a,b)
 integer, intent(in out) :: a,b
 integer     :: t
 t = a
 a = b
 b = t
endsubroutine int_swap

subroutine real_swap (a,b)
 real, intent(in out) :: a,b
 real     :: t
 t = a
 a = b
 b = t
endsubroutine real_swap

subroutine complex_swap (a,b)
 complex, intent(in out) :: a,b
 complex     :: t
 t = a
 a = b
 b = t
endsubroutine complex_swap

subroutine logical_swap (a,b)
 logical, intent(in out) :: a,b
 logical     :: t
 t = a
 a = b
 b = t
endsubroutine logical_swap

subroutine character_swap (a,b)
 character(len=*), intent(in out) :: a,b
 character(len=1)     :: t
 if (len(a) == len(b) ) then
  do i = 1, len(a)
  t = a(i:i)
  a(i:i) = b(i:i)
  b(i:i) = t
  end do
 else
  print *, "Length of character strings differ."
  print *, "Can not swap."
  stop
 end if
endsubroutine character_swap

end module swap_module

program try_swap
 use swap_routines
 integer :: i1, i2
 character (len=16) :: c1, c2

 i1 = 10
 i2 = 20
 c1 = "string1"
 c2 = "the other string"

 print *, "i1 and i2 before swap", i1, i2
 call swap (i1, i2)
 print *, "i1 and i2 after swap", i1, i2

 print *, "c1 and c2 before swap>", c1,"< >", c2,"<"
 call swap (c1, c2)
 print *, "c1 and c2 after swap>", c1,"< >", c2,"<"

end program try_swap

F provides the ability to overload the intrinsic operators as long as the operators are not already part of F. For example, "+" can be overloaded to operate on two characters but it cannot be overloaded to operate on two integers because this would replace the intrinsic addition operation already found in F. F also provides the ability to create your own unary and binary operators as long as they are given names surrounded by dots as in ".inverse.".

When overloading a name or an operator, all desired permutations of intrinsic and user defined types must be listed so that resolution to a specific function is always known at compile time; there are no run time resolutions in F. We can only guess that the Green team decided to do away with overloading operators out of the frustration created by C++ when a programmer attempts to figure out what A()+B() actually means. With its virtual functions, the expression A()+B() in C++ could be anything from a simple addition to a call to practically any function. It may require a thorough understanding of the design and most of the code to be sure exactly what A()+B() means. In F, one can conceivably click the "+" and be directed to the specific function that is being referenced.

Kinds Versus Specific Arithmetic

Java solves the non-portability created by different machine's mathematical models by requiring a specified range and precision for each type; if machines do not match this mathematical model, they must emulate it. F solves this same problem by allowing specifications of different kinds for types and literals. A kind number can be determined using the intrinsic procedures. For example, the expression

 selected_real_kind(10,50)

returns a kind number to specify variables to have at least 10 digits of precision and an exponent range of at least 50. The kind number is then used in the declaration. For example:

module kind_module
 integer, public, parameter :: &
  k10_50 = selected_real_kind(10,50)
endmodule kind_module

module m_do_something_with_my_float
 use kind_module
 private ! do not export entities from kind_module
 real (kind = k10_50), public :: my_float
 ! ...
endmodule m_do_something_with_my_float

End-Of-Line Versus Semicolons

Unlike C, C++ and Java, statements in F conclude at the end-of-line unless an ampersand (&) is placed at the end-of-line to signal that this statement continues on the next line. Considering that most statements fit on one line, we feel that this design is easier for students to learn and less error-prone for both beginners and professionals. This may be a small point as today's C, C++ and Java programmers have obviously learned to cope with semicolons and since they are required inside certain statements (like the for statement) it appears that the Java designers had no choice.

Emphasis On Safety and Readability

The final difference between F and Java that we would like to mention is the overall strategy of safety and readability that was carefully designed into F. One way to compare this with the overall strategy of the "look-and-feel like C++" carefully designed into Java is that the F design is less marketable to today's programmers. Unfortunately for the software crisis, there are plenty more C++ programmers in the world than there are programmers that want to follow particular style guidelines.

For example, programmers with a preference for a one-line if statement do not care for the idea in F of requiring an endif statement. The required if-endif pair may lead to clearer blocks of code and unambiguous else statements, but more importantly it exemplifies the design strategy in F that abbrev.R!++ (abbreviations are not good). Requiring an endif statement in F sometimes means splitting one longer statement into three shorter statements by adding two words "then" and "endif". These words are important for error detection as well as tool writing. A missing parenthesis is easier to report if the reserved word "then" is required and a path coverage tool is easier to write if the word "endif" is required.

Our claim is that the safety and readability required of F code aid students and professionals. Possibly the best example of the safety designed into F is the intrinsic statement. Intrinsic procedures in F are allowed to be overloaded as long as the argument types differ from those found as part of the F language definition. For example, cos can be overloaded to accept a character argument but it cannot be overloaded to accept a real argument. Since there are so many intrinsic procedures, we decided that overloading one of them requires listing the name of the intrinsic on an intrinsic statement. This prevents the unknowing programmer from creating an involved module using a name that is already part of the language. Without this requirement, it would have been possible to overload cos, presume a reference to it, accidentally use the wrong argument and wind up referencing the intrinsic without ever realizing it.

Data Encapsulation

It seems that right now everybody on the planet is interested in learning Java. Java has become so popular that many colleges and high schools are dropping Pascal and throwing beginners directly into Java. Though we believe Java is much more structured and friendly than C++, the fact remains that beginners need nurturing error messages more than the semester's survivors need the promise of a potential summer job. Indeed, good teachers can teach anything and good students can learn anything, but F offers a chance for those in the middle of the bell curve to learn how to program.

F jumps in between the academic emphasis of Pascal and the professional look and feel of Java to offer a compromise designed for both camps and ideally suited for potential engineers and scientists. The most attractive feature of object-oriented programming for beginning programming courses is data encapsulation. With its module-oriented programming, F is ideally suited for teaching and learning data encapsulation without getting lost in complicated inheritance chains.

Nurturing Versus Sink-or-Swim

Keep in mind that pure beginners have dozens of skills to learn, including:

• an editor (as well as using a keyboard),
• an operating system or environment,
• language syntax,
• deciphering cryptic compiler (or linker) error messages,
• save, compile and link commands or save and run commands,
• errors in logic, and last but not least
• programming concepts.

Minimizing the impact of this list was built into the design of F. On top of the F programming language sits a tutor/environment called F_world. F_world guides the pure beginner through writing and running their first F program. This program adds numbers until a zero is entered, uses a module with a subroutine, requires a loop and an if block and introduces one half of the F statements. Although this sounds complicated, it consistently creates programmers ranging from age eight to eighty in less than an hour. Listing 4 shows the statements that are fed one at a time to the beginner and a possible solution if the suggested names are copied.

Listing 4: F_world.f

F_worldBeginner
The F_world tutor's beginning program template and the suggested solution.
program ______________
 use _____________
 call ___________________
endprogram ______________

! This module is entered into its own window
module _____________
 public :: _________________
contains
 subroutine ____________________
 integer :: ____________
 integer :: _____________
 _________________
 do
  print ________________________________________
  read _______________
  if ____________________ then
   exit
  else
   ____________________________________________
   print __________________________________________
  endif
 enddo
 print _____________________
 endsubroutine __________________
endmodule ______________

! If the example names are used, here is the resulting F code
program MyFirstProgram
 use MyFirstModule
 call MyFirstSubroutine()
endprogram MyFirstProgram

! This module is entered into its own window
module MyFirstModule
 public :: MyFirstSubroutine
contains
 subroutine MyFirstSubroutine()
 integer :: input_number
 integer :: current_total
 current_total = 0
 do
  print *, "Enter number to add, or 0 to exit:"
  read *, input_number
  if (input_number == 0) then
   exit
  else
   current_total = current_total + input_number
   print *, "the current total is: ", current_total
  endif
 enddo
 print *, "Goodbye for now."
 endsubroutine MyFirstSubroutine
endmodule MyFirstModule

The F_world tutor uses the opposite strategy of "Hello World" and begins with a nontrivial example that can be used as a base for learning the basic concepts of programming in the first week if not in the first few hours.

The words save, file, compile and link are not used in F_world. Modules are entered into "windows" and validated and programs are simply run. As with importing packages in Java, using modules in F is a compile time feature; F_world knows where to find the necessary modules and "link" them with the program so the programmer does not have to. In F, all procedure interfaces are checked at compile time; there is no such thing as a linker error.

Natural branches from the tutor's beginning program include a description of the statements, loops, if-else decisions, programs, modules and subroutines, variables (we call them "containers"), integer data type, input and output. Playing with the code easily introduces other data types such as reals, subtraction instead of addition, functions instead of subroutines, private versus public and passing arguments to and from procedures to name a few. This normally covers the bulk of a semester when following the agenda set for programming courses two decades ago; with F_world we propose to cut this time in half, using the saved energy for more learning material or for learning Java!

Error Messages

Another key design goal of F was to be able to give specific error messages in as many situations as possible. The result is a grammar with minimized token look ahead requirements and an emphasis on keywords instead of punctuation and abbreviations. Since most statements begin with a reserved word, which is followed by specific tokens, likely errors such as misspelled keywords can be clearly reported. For example:

 intger :: total
! ^ ^
!ERROR (#41355) on line number: 5 !!!!!!!!!!!!!!!!!!
!The word INTEGER is misspelled.     !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Although sometimes trickier to diagnose, missing commas, colons and parentheses are for the most part also clearly reported. Since compiler writers most often have their hands full with simply getting the answers right, products for complicated programming languages often have few resources allocated to consistent and clear error reporting and recovery. Indeed, writing and reviewing error messages is often the last item "thrown in" before product testing. For example, one author (DE) misspelled the word intger in his first program and required 24 hours and help from another student to discover what "Bad statement syntax" meant when it was placed at the beginning of the one-erroneous-character Fortran 77 program.

Functions Are Not Subroutines

In F, procedures are either functions or subroutines. Functions are not permitted to have side effects so all arguments must be specified to have intent in. Subroutine arguments must be specified to have intent in, out, or inout. The attention given to argument intention and differentiating between functions and subroutines will surely help a student to understand what the word "void" means when placed in front of a Java function. In contrast, students beginning with Java will most likely think of void as required syntax until they are forced to learn its meaning.

Another View of F

It is not a coincidence that a language originally designed for non-computer scientists has benefits for both beginners and professionals. Fortran's history lends over forty years of language evolution targeting engineers/scientists/mathematicians/physicists/chemists/etc. The result is a language that contains a simplified syntax designed for problem solvers who do not have the desire to learn excruciating details and pitfalls of the implementation language. Even with its target market of non-programmers, Fortran 95 can be considered overly complicated since it contains all of Fortran 77 along with the recent additions from the '80s and '90s.

The mixture of the outdated 1977 features with the modern 1995 features essentially makes for two complete languages; the now outdated language was even considered lacking when introduced two decades ago. By carefully selecting the simplest subset of Fortran 95 without removing any desirable features, F presents an efficient package for people not wanting to carry around the old baggage of Fortran 77. An F processor will not accept a Fortran 77 program.

Another View of Java

A similar story can be told for Java. The creator of C++ was not motivated (and actually found it inappropriate) to remove the undesirable baggage C had been carrying around since the '70s. The creator of Java essentially had two complete languages to chisel into a smooth subset before realizing that sculpting a new masterpiece better fit his vision. Java is the first language in the evolution of C that emphasizes simplicity. A Java processor will not accept a C program.

You have seen how a simplified grammar aids the beginner but may be wondering what are the advantages for the professional. If you have ever picked up tens or hundreds of thousands of lines of code that were written by "somebody else" you may recall the pain related in simple tasks like finding the declaration of a variable or procedure. As business dictates, popular programming languages feed tool vendors with marketing ideas for reducing the pain of reading, updating and validating somebody else's code (if not your own). These tools, however, cost money and learning curve energy (often just to prove that the features you desired most will not be available until the next release of the tool).

Finding Something

While writing the F compiler front-end in F, we came across the need to find all array declarations. It did not take long to realize that a search for the word "dimension" was all we needed. The number of occurrences of the word "dimension" in quoted strings and comments were rare, but this potential problem when using a simple editor search is easily avoided by any serious programming team willing to spend a few days (or less) to write their own F scanner.

Large Projects

The idea of writing your own language tools designed for your specific project is powerful enough that we expect free F scanners written in F to become available soon. Given a tool that creates an array of tokens, finding all array declarations and other queries can be done with exactness. This exactness is required for accuracy of more involved homegrown projects such as profilers, static analyzers, test case coverage and test case creation tools.

Even without writing specific software tools, an editor is enough for large project programmers to benefit from the exactness required in F. For example, a debugging session may lead to a screen of code that calls subroutines Hidden, FindMe and WhereAmI. The first occurrence of these names in this module will tell if they are local and, if they are local, whether they are public or private.

It is quite convenient to discover that Hidden is private to the current module because all references will be found without having to open another window or file. This shows how the public and private differentiation aids with maintenance and code surfing as well as with design and encapsulation. Neither Fortran 77 nor C had the public and private differentiation.

If FindMe is not local, a search for the string "subroutine FindMe" will likely find the declaration. As well, while looking at the code for FindMe, searching for the same string will likely find the endsubroutine statement. This is, of course, the benefit of using the word "endsubroutine" followed by the subroutine name instead of the character "}" or the word "end".

Finally, if finding "subroutine WhereAmI" does not lead to the procedure code, it will lead to the interface that declares this procedure to be code that is written in a programming language other than F such as Fortran, High Performance Fortran (HPF), C or Java. The ability to call non-F procedures is only available in the professional edition of the F compilers.

The Fortran standard is constantly being updated with new features. As mentioned, this strictly enlarging nature of the Fortran standard can lead to an overly large language. Considering the alternative, undisciplined approach of creating languages and products before reaching a standardized consensus, the standardization process is one of Fortran's strengths.

Fortran vendors are relying on the standards teams and announcing new compilers only after the specifications have been accepted. Java's forced mathematical module and the bytecode-JVM provides portability; Fortran's standard's work and F's commitment to extract the safest features without compromising power provides both portability and efficiency. Before Fortran 2000, another push for portability is being made with the addition of Part 3 of the standard regarding conditional compilation.

Some may feel that a technology that comes as quickly as Java is bound to disappear just as quickly. The authors see, however, that Java is an improvement to C++ and is bound to persist and evolve for decades. With the Fortran committee's current focus on more powerful object-oriented features in Fortran 2000, F is also positioned to persist and evolve for decades.

Whether or not F can actually figure into the future of Java is yet to be seen. Java is currently lacking the efficiency that many large projects demand and the addition of JavaScript to the Java technology shows how quickly the Java folk are plugging in any existing holes. With four decades of compiler optimization backing Fortran, F surely presents the efficiency that Java lacks. Paradoxically, the issue of efficiency usually involves the misconception that Java lacks pointers, but the dereferencing mechanism found in Java is not all that different than the pointer-target mechanism found in F.

It is difficult to summarize this presumably shocking report that Java is not all that different than Fortran and its subset F. There are far too many similarities and differences between F and Java to give a full detailed description in this article. We expect that this discussion has raised a few eyebrows.

Scientists and engineers will no doubt find F to be a similar look and feel to Fortran 77 as computer scientists find when moving from C or C++ to Java. Fortran 77 programmers have some learning to do before writing F code and C programmers have more learning to do than C++ programmers before writing Java code. F is even more familiar to those rare Fortran 90/95 programmers since every F program is also a Fortran 90/95 program.

A fitting ending to this F introduction and comparison to Java may be the promise that the next generation of programmers, whether computer scientists or others, are learning well structured module-oriented and object-oriented techniques from the very start. This is accomplished by beginning with F and moving to Java, all in their first year of programming. As this scenario unfolds in the academic world, the average student and not just the "smart kids" can be given a chance to learn what programming is all about. After all, programming really is not all that difficult and it is finally becoming simpler.

Thanks to Absoft Corp. for helping to make F available on the PowerPC Macintosh. Thanks also to Numerical Algorithms Group, Inc. (NAG), Fujitsu Limited, and Salford Software, Inc. for working with Imagine1 to make F available on those other systems (Windows, Linux and Unix.) Mike Dedina helped review and format this report. Thanks goes out as well to the Fortran community for providing immediate interest in the F programming language.

Walt Brainerd, walt@imagine1.com, is co-author of about a dozen programming books. He has been involved in Fortran development and standardization for over 25 years and was Director of Technical Work for the Fortran 90 standard.

David Epstein, david@imagine1.com, is the project editor of Part 3 of the Fortran standard regarding conditional compilation. He is the developer of the Expression Validation Test Suite (EVT) for Fortran compilers and author of the book Introduction to Programming with F.

Dick Hendrickson, dick@imagine1.com, has worked on Fortran compiler development in both educational and industrial environments since 1963. He currently is a consultant on compiler optimization and one of the developers of SHAPE, a test suite for Fortran compilers.