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.