|
|
|
|
|
|
|
|
This article describes some of the design goals of F, a new programming language, and introduces most of the language specifics.
by Walt Brainerd, David Epstein and Richard Hendrickson
With the F programming language, the authors combine over forty years of language-design committee experience to create the world's most portable, yet efficient, powerful, yet simple programming language. The recent attention commanded by the portability and power of Java is well-timed, as we show in F that efficiency and readability need not be made victims of cross-platform development.
Before diving into the F programming language definition, this article begins with some biased-but-almost-factual opinions of the authors. We admit it--we are not fans of C and C++.
Listing a few facts and myths about programming languages will help set the stage for the discussion of F. These opinions may communicate some of the ideas behind the F programming language design, allowing one to better understand the motivations of the authors and thus the language.
Fact 1: Programs are read more often than written. From your first programming assignment throughout your professional career, characters are entered once, following some sort of syntax and logic, and read and reread anywhere from twice to hundreds to thousands of times. Programs that cannot be read are simply poor programs.
Myth 1: Abbrev.R++ abbreviations are good. A programming language with the overall design of abbrev.R++ are quite popular among thinking/creating/coding/debugging speedsters. Afterall, most programmers learned how to program before learning how to type. Abbreviations, however, ranging from a ``}'' instead of the word ``end'', ``int'' instead of ``integer'' and i++ or ++i instead of i=i+1 only add pieces to an already complicated puzzle. As with a piece of abstract art, one day someone may look at your code and ask, ``That's nice, but what is it?''
Fact 2: Educational languages are dead or dying. As some instructors around the world are searching for a suitable replacement for Pascal, the majority are going-with-the-professional-flow and switching from Pascal to C, C++ or Java for introductory programming courses. There is no telling where computer science would be today if a whole generation of programmers who were brought up on Pascal in the '70s and '80s were presented with the sink-or-swim situation of C++ or Java as a beginning programming language. If Pascal did not exist, the odds are that there would be fewer of us reading this article (if it or the magazine even existed). Surely, a major factor in the rapid evolution of computer science was the once nurturing environment presented by Pascal.
Myth 2: A modern educational replacement for Pascal offers no advantages to the potential professional programmer. Many professionals, particularly those working on large projects, benefit from the advantages of the strict style enforcement that a small programming language offers. A small language can also offer reliable tools (compilers, debuggers, profilers), reliable customer support, reliable error messages and reliable references (textbooks and on-line documentation). As F is a language based on existing practice, professionals can make use of the large amount of existing debugged code.
Fact 3: Choosing the wrong implementation programming language affects the overall design, portability and maintainability of large projects. Many companies have been dealt an expensive blow attempting to keep up with a fast-moving multi-platformed industry with slow-moving software. Whether the software is being enhanced with efficiency and new features or being ported to the latest hardware, a poor choice for the original programming language can result in a serious loss of company resources. Until feeling the headache, it appeared that C was an appropriate, powerful and portable choice. In the early '90s, C++ promised more power and possibly safer features. Today, Java proves safer and portable, but sacrifices efficiency.
Myth 3: The software crisis has been solved. With no solution to the software crisis in sight, focus has been shifted towards ``market-driven'' distractions like the hot,new programming language filled with more promises than an election-year politician. Meanwhile, most large software projects are still written in C and continue to be delivered late, under-functioned or unstable. As long as a smaller and simpler language does not sacrifice power, it is time for programmers and their management to wake up to the possibility of shipping stable, complete software on schedule. This starts with the decision of an appropriate programming language. An appropriate choice does not emphasize the potential salary of the programmer leading the project, but rather:
Starting with an internationally standardized programming language as a base, we set out to create the world's best programming language. Any lesser goal would result in an interesting but not a challenging exercise.
Designing a programming language involves thousands of ideas and decisions. Tradeoffs are constantly weighed between efficiency (both compile time and run time), readability, flexibility, familiarity, brevity, redundancy, implementation (compilers and tools), style, elegance, completeness, internationalization, standardization, marketability and target audience, to name just a few. The above facts and myths and the principles listed below helped us to avoid personality conflicts (mostly) and reach decisions based on these goals:
A pleasant surprise to the biased authors is the pure elegance of F.
Except for assignment (=) and pointer assignment (=>), the first word of every F statement identifies the statement. All keywords are reserved words, allowing for specific error messages for incorrect syntax or misspelled keywords. Table 1 categorizes all the F statements. The diagram shows that every F procedure, either a subroutine or a function, is contained in a module.
In F, a distinction is made between functions and subroutines. Functions are not allowed to have ``side effects'' such as modifying global data. All function arguments must be intent(in); subroutine arguments can be intent(in), intent(out) or intent(inout). The intent is required on all procedure arguments, allowing the compiler to check for misuse and forcing both the beginner and professional to document the intentions.
The intrinsic types in F are integer, real, complex, character and logical. User-defined types can be constructed from the intrinsic types and user-defined types. For example, a person can be constructed to have a name, height, phone number and pointer to the next person. Users can define operators which operate on intrinsic and user-defined types.
The attributes of an intrinsic or user-defined type in F are shown in Table 2. Pointers are strongly typed. That is, pointers can point only to objects that are targets. Although this idea makes solid pedagogical sense, the words pointer and target originated for the purpose of better compiler optimization.
A sophisticated array language facilitates operations on whole arrays, contiguous and noncontiguous sections and slices of arrays. For example:
arr(5:1:-2, 3, 6:)is a reference to the two-dimensional array created by taking the elements 5, 3 and 1 in the first dimension of arr and elements from 6 to the upper bound of the third dimension of arr, all in the third plan of the array. If arr is a 5 by 6 by 7 array, the referenced elements would be (5,3,6), (3,3,6), (1,3,6), (5,3,7), (3,3,7), (1,3,7).
A simpler example that calculates the sum inner product of a row and a column is shown here:
A(i,j) = sum(B(i,:)*C(:,j))gsum is one of the more than one hundred intrinsic procedures found in F.
Modules are at the core of all F code. Modules are a data encapsulation mechanism that allows data to be grouped with the procedures that operate on that data. Modules can use other modules. As well, programs and procedures can use modules. Using a module makes the public entities of that module available. Examples of modules are found in Table 3.
One does not instantiate an instance of a module as one does with a class in C++ or Java. Instead, the concept of an object is best viewed as a module that defines a public, user-defined type together with the public procedures that operate on that type. The user of such a module can then declare a scalar or array of the defined type and have access to its procedures.
A public, user-defined type can be defined to have private components, so that the type and its procedures can be referenced; however, the parts that make up the type are private to the defining module.
Programming in F can be called module-oriented programming. Much like Java's requirement that all procedures appear in classes, all F procedures appear in modules. An F program that does not use any modules cannot call any subroutines or reference any functions. Modules can use other modules to access their public entities. A module, however, is not allowed to use another module for the purpose of exporting the public entities in the used module unless the sole purpose is to collect a group of modules and make all their public entities available from one module.
This simple yet powerful method of module inheritance allows for an involved hierarchy of modules without complicating the investigation required to understand somebody else's code. Any reference to the function foo is known at compile time to be specifically a reference to a public function named foo in a specific module. Even without the aid of compiler tools, F is designed so a quick search (with the aid of grep) for the words ``function foo'' will most likely show function foo's definition line on your screen.
A nice educational feature of F is that every procedure must be declared as either public or private. The result is that a student writing a program that calls a subroutine must learn (or at least enter) the words program, use, call, module, subroutine and public. The public and private list also aids the professional as the first occurrence of a procedure name in a module will tell you if it is private and thus isolated to this module.
F allows overloading procedure names as well as overloading operators. Every reference, however, is resolved at compile time. Thus, the statement
left = swap(int1, real2) * "hello"displays an overloaded multiplication operator operating on the result of the int1/real2 swap and the character string ``hello''. Also, swap can be a generic name, but it is also resolved to a specific function at compile time. Finally, the assignment operator (=) may also be overloaded; a mouse click on the = could conceivably direct you to the specific subroutine that would be called if this was not an intrinsic assignment statement.
Before reading this section, you may want to view the example F program found in Listing 1,1 the Sieve of Eratosthenes. to see if you can guess what once-popular programming language F is based on. The name of the base language is often deceiving as the little known 1995 standard of this language is far more modern than the popular 1977 version. As the standards team is working on making the 2000 version even more object oriented, compilers for the 1990 version have become available from most vendors only in the last few years. If you have not guessed yet, you may be surprised to find out that today's best structured programming language is based on the the world's first structured programming language--FORTRAN.
Now over 40 years old, more programmer energy has gone into the evolving definition of FORTRAN than any other programming language. Every F program is a FORTRAN program. With stronger object-oriented features scheduled for the year 2000 and continued support for the numerically intensive programmer, this recently forgotten programming language is poised for a strong comeback during the next decade.
A strength of FORTRAN is that the standard is constantly being updated with new features. Vendors are relying on the standards efforts and announcing new compilers after the specifications have been accepted. This is a strong portability statement when compared to languages that are attempting to standardize after various compilers are already in the market. Another push for portability is being made with the addition of Part 3 of the FORTRAN standard regarding conditional compilation expected within a year.
The Linux educational version of F is freely downloadable. The Imagine1 web page (http://www.imagine1.com/imagine1/) contains the free Linux version, and free trail versions for Windows, PowerPC Macintosh and Unix. You will also find the BNF for F, many example programs, descriptions of F textbooks, and an invitation to join the f-interest-group. As a point of reference, nonLinux users pay $101US for an F compiler and book.
Many thanks belong to Numerical Algorithms Group, Inc. (NAG) for helping to make the Linux version of F available at no cost. Making F available on Windows, Unix and Macintosh was made possible with the help of Fujitsu Limited, NAG, Absoft Corp. and Salford Software, Inc. Thanks also goes out to the FORTRAN community for providing immediate interest in the F programming language.
Walt Brainerd 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. walt@imagine1.com
David Epstein 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 Introduction to Programming with F. david@imagine1.com
Dick Hendrickson 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. dick@imagine1.com
