I am attaching my news report on the 1998 Lahey meeting,
and will place it also on members.aol.com/n8tm/lf90mtg.txt
1998 Lahey Fortran Users' Conference
A striking aspect was the variety of specialties represented by
attendees. With economists and actuaries as well as people from
physical sciences and engineering, it was like the old days before
the C++ fashion, not only because of the age of some of us.
There was more difference of opinion on the desirability of meeting
in a place with 6 feet of snow in the swimming pool. One apparent
comparison with other programming languages is that Fortran vendors
work in colder places!
Tom Lahey's Speech
Tom Lahey held forth on the history of Fortran (and other languages).
Tom certainly has credentials, having learned Fortran in 1959, as well
as having had his own company going since the days when almost no one
believed in PC Fortran.
It was interesting to hear Tom group BASIC, Pascal, and Modula
together, and call the newer ones languages of the past. He stressed
the idea that what success these languages had was largely due to their
being developed by a small group of dedicated people, rather than by a
committee. C apparently started in the right way but is developing
into an over-extended committee production. If the committee way were
the right way, Ada would have displaced Fortran long ago, and COBOL
would rule the remainder.
So, it seems, Fortran might need a little help too. Thus elf90,
the "minimal Fortran" which does almost everything Fortran with the
simplest possible syntax. Tom appears to lay some blame for the
slowness of appearance of full standard Fortrans on the standard
making committees insisting on the ability of so many permutations
of old and new to work together.
Discussion of the Lahey-Fujitsu alliance shed some light on the
direction the industry is moving. Lahey basically admit that the
Microsoft-Digital-Compaq sequence has made it difficult to fight on
alone, while Fuji admit to a lack of success in marketing their
Fortran outside Japan. Steven Terui, who started in this business
as a Ryan-Mcfarland developer, represented Fuji in the presentation.
Lahey will continue to take care of the user interface and support,
while Fuji will maintain much of the back end software. Together,
they claim to expect to remain a "strong number 2" in Fortran, and to
continue focusing on the scientific and technical markets.
Among the Lahey software components slated to be replaced by Fuji's
are the back end code generator and math run time libraries. Lahey
will continued to apply all their test suites, as well as providing
continuity in the front end. That term "look and feel" was avoided
entirely. They claim to aim to retain the current Lahey compilation
speed with faster execution. They recognize the need to support
Fortran 95 with loop fusion and say the combined product will do this.
The product should combine the quality of the best Unix compilers with
the present good features.
No, this won't happen on the next release! lf90 4.5 may adopt Fuji's
SSL II math library and visual source code analyzer, but no compiler
internals. What are promised are an improved Wisk (simplified version
of Lawson Wakefield's Winteracter graphics library), MS C/C++
compatible .OBJ linking, and the new Automake from John Appleyard's
(Polyhedron) PlusFORT. One of the motivations for the .OBJ linking is
to enable vendors to build packages with existing OpenGL libraries,
so we may expect new graphics applications, possibly working with more
than one vendor's Fortran. Automake is to have a configuration menu
and work with cascaded USE dependencies and with combined Fortran and C
builds. The audience objected to the visual analyzer being unusable by
color blind people! Terui agreed that it would be useful to integrate
the analyzer with source code editing, but this has not been attempted.
Richard Hanson made a well-received presentation on the new f90
features of IMSL. The linear algebra, fft, and spline surface
libraries now can use f90 syntax, making them far more readable.
Of course, there are modules to help check syntax for the
old-fashioned calls. Lahey, DVF, and Absoft are to be supported.
Scisoft and Pacific Sierra made presentations; I don't know how many of
us are ready to use PC's to emulate extinct supercomputers (even though
a good Pentium is the rough equivalent of a YMP), but these people are
trying to make themselves useful. Pac Sierra's translator is one of
the more complete (and most expensive) automatic f77 to f90 converters,
but will have to wait for better compilers before it can be used
without hurting performance, where it was designed to help performance
on vector HPF systems.
Presentations by the developers Bruce Bush for RealWin and Kevin Bradly
for GINO, plus multi-media in absentia by Winteracter. GINO will be
providing a spread sheet interface, which Winteracter already has.
All support Lahey and DVF, the Brits also Salford, and GINO also
Absoft. GINO can import screen layouts from VB, but will have its own
menu to perform the job better directly (GINOMenu Studio). GINO will
use OpenGL to provide a full hidden line feature. The developers
present all emphasize portability beyond Windows and multiple compiler
support, as well as ability to do everything well in f90.
Windows Programming Tips
Howell Johnson of Lahey discussed the .DLL interfaces. Much of this
is in Lahey's latest manuals. Tim Zeisloff went over some material on
direct Windows API calls from Fortran. There isn't much non-standard
stuff here; just conversion of to module syntax, and
ability to pass arguments by value.
More 3rd Party Aids
John Appleyard (Polyhedron) discussed his PlusFORT (pronounced
ploofort) of which AutoMake is supplied with lf90. SPAG, in addition
to converting obsolescent syntax and goto's automatically to readable
code, now has a little f90 conversion capability. His static analyzer
has the ability to flag designated key words, such as those which might
require year 2000 fixes. The dynamic analyzer can follow up by
flagging suspicious data, such as 98, as well as providing "test
Lahey intend to go to an on-line newsletter in place of the
occasionally paper one.
A few suggestions were batted back and forth. There was a widespread
desire to see a feature chart comparison of the graphics products which
Lahey remarket. The -winconsole compilation mode has some desirable
effects, such as allowing .DLL's to access the fortran error report
file, and permitting cpu_time to work well under NT. There appeared to
be agreement that the search for the error message file should include
the directory where the currently executing .EXE is located, as there
now is no reliable way to get the error messages when the .EXE is run
on a computer which does not have a compiler installation.
The compiler/editor integration depends on ANSI.SYS so it is not good
to have a non-standard version of this.
Informal Discussion on Graphics Products
The following report has been submitted to Lahey for use in the meeting
summary which Lahey should be preparing:
The informal discussion of graphics at the 1998 Lahey Fortran Users'
meeting took place after vendor demonstrations but before their formal
presentations. A wide variety of expertise and interests were
represented, and the discussion ranged over a wide variety of topics.
An early topic was the strong preference for graphics packages which
use a call-back mechanism rather than polling for operator response,
so that the CPU resources will not be tied up during display. Of the
major packages represented, RealWin, GINO, and Interacter were awarded
good marks for this, but doubt was expressed about Winteracter.
A short discussion centered on the idea that DOS extender programs
have more ability to access hardware but are unable to take advantage
of Windows graphics capabilities.
The topic of using CALL SYSTEM to start up a .BAT file to execute a
separate application and then return to Fortran had some discussion.
The other application might be one of the large statistical or GIS
packages with specialized graphics which are not practical to duplicate
with Fortran calls. Data would be passed in file formats appropriate
to the other application such as .DXF.
Bruce Bush, developer of RealWin, and Kevin Bradly, developer of GINO,
were invited into the discussion. General approval was expressed for
their tactic of avoiding resource files and unnecessarily close ties
to Windows. Resource file systems such as Winteracter would give the
programmer less freedom of activity, but might do a satisfactory job
in many situations. For a really professional job, Bruce and Kevin
suggested using their packages together, with GINO developing graphics
bit maps and RealWin controlling presentation.
The popularity and lack of documentation of the .DLL method of
inter-language calls came up, as it might be attractive to use built-in
graphics of MS compilers while performing calculations in lf90.
Lahey appeared receptive to the suggestion that more examples be shown
in places such as sample code, with the idea that they might not want
to add to the frequency of revision of the published manuals.
Return to contents page