I am attaching my news report on the 1998 Lahey meeting, and will place it also on members.aol.com/n8tm/lf90mtg.txt Tim 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. Lahey-Fuji Alliance 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. lf90 4.5 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. IMSL 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. Supercomputing stuff 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. Graphics Libraries 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 coverage" analysis. 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.