I am in the market for a single copy of a commercial* Fortran compiler
to use under Windows. I'm seeking advice on the options. 

Because I am a one-man, part-time consulting shop, price is important.
Lahey Express is cheap, but apparently it's not being updated any
more.  Intel and Absoft both seem good and current.  Absoft is a bit
cheaper, and from what I can see, it is fast and complete. However,
its diagnostics aren't so great.  On the other hand, its IDE was
designed for Fortran, which would be a pleasant change -- I don't much
care for Visual Studio.

Any comments on these or other suitable compilers -- including
comments on tech support -- would be helpful.  Feel free to send them
by email if you would rather comment privately.

Thanks!

Mike Prager

* I am looking only at commercial products because none of the free
versions has an option (like Lahey's vsw or Intel's QuickWin) that
makes a simple Windows program without coding changes.  If I'm wrong
about that, it would be great to know it. I have considered using
DISLIN's widget routines, but that is a much more complex approach.

Mike Prager wrote in message ...
>I am in the market for a single copy of a commercial* Fortran compiler
>to use under Windows. I'm seeking advice on the options.
>
>Because I am a one-man, part-time consulting shop, price is important.
>Lahey Express is cheap, but apparently it's not being updated any
>more.  Intel and Absoft both seem good and current.  Absoft is a bit
>cheaper, and from what I can see, it is fast and complete. However,
>its diagnostics aren't so great.  On the other hand, its IDE was
>designed for Fortran, which would be a pleasant change -- I don't much
>care for Visual Studio.
>
>Any comments on these or other suitable compilers -- including
>comments on tech support -- would be helpful.  Feel free to send them
>by email if you would rather comment privately.
>
>Thanks!
>
>Mike Prager
>
>* I am looking only at commercial products because none of the free
>versions has an option (like Lahey's vsw or Intel's QuickWin) that
>makes a simple Windows program without coding changes.  If I'm wrong
>about that, it would be great to know it. I have considered using
>DISLIN's widget routines, but that is a much more complex approach.

Absoft is a good buy; also Silverfrost for diagnostics.

On Jun 19, 7:22=A0am, Mike Prager <mike.pra...@mhprager.com> wrote:
> I am in the market for a single copy of a commercial* Fortran compiler
> to use under Windows. I'm seeking advice on the options.

I used to work with AbsoftV9 - I don't remember any issues with it;
also the debugger works fine. I prefer the Visual Studio environment,
simply because you always have one interface and don't need to switch
between different windows (project, editor, debugger - however that
could have changed in the latest Absoft versions). The Intel compiler
also has an active and large newsgroup where help is provided quickly
(as does this newsgroup). I'm not sure about the latest Fortran2003
features in Absoft, but it seems Intel has a lot of it.
Cheers
R.

There are a number sites that have information on Fortran and
Fortran compilers.

Our site

http://www.fortranplus.co.uk/

has a resource file

http://www.fortranplus.co.uk/resources/fortran_resources.pdf

The Polyhedron site

http://www.polyhedron.co.uk/

has a compiler comparison table

http://www.polyhedron.co.uk/compare0html

We also have a document that looks at the degree
of support for the 2003 and 2008 standards.

http://www.fortranplus.co.uk/resources/fortran_2003_2008_compiler_support.pdf

Cheers

Ian Chivers

Mike Prager <mike.prager@mhprager.com> wrote:

> * I am looking only at commercial products because none of the free
> versions has an option (like Lahey's vsw or Intel's QuickWin) that
> makes a simple Windows program without coding changes.  If I'm wrong
> about that, it would be great to know it. I have considered using
> DISLIN's widget routines, but that is a much more complex approach.

If you wished to use gfortran or g95 under Windows, depending on how
sophisticated you wanted your GUI to look (rather than act ;)), 
you could try PDCurses eg
http://www.projectpluto.com/win32a.htm

There would still be some fiddling with your code.  The nice thing about
PDCurses is that it creates a new "native" window, rather than just running
in a standard console.

I added *just* a graphical file chooser to a console program
using JAPI, (http://www.japi.de) which works beautifully, and is fairly
portable across different systems (Java has to be present on the
target).  Unfortunately JAPI is no longer being developed, and I haven't
tried it on Vista/Windows7.

Cheers, David Duffy.

On Sat, 19 Jun 2010 23:39:36 +0000 (UTC), David Duffy
<davidD@orpheus.qimr.edu.au> wrote:

>Mike Prager <mike.prager@mhprager.com> wrote:
>
>> * I am looking only at commercial products because none of the free
>> versions has an option (like Lahey's vsw or Intel's QuickWin) that
>> makes a simple Windows program without coding changes.  If I'm wrong
>> about that, it would be great to know it. I have considered using
>> DISLIN's widget routines, but that is a much more complex approach.
>
>If you wished to use gfortran or g95 under Windows, depending on how
>sophisticated you wanted your GUI to look (rather than act ;)), 
>you could try PDCurses eg
>http://www.projectpluto.com/win32a.htm
>
>There would still be some fiddling with your code.  The nice thing about
>PDCurses is that it creates a new "native" window, rather than just running
>in a standard console.
>
>I added *just* a graphical file chooser to a console program
>using JAPI, (http://www.japi.de) which works beautifully, and is fairly
>portable across different systems (Java has to be present on the
>target).  Unfortunately JAPI is no longer being developed, and I haven't
>tried it on Vista/Windows7.

Thanks to David, Ian, Ralf, and Robin for comments.  All helpful.  

The special Windows requirement is to be able to drag and drop a data
file onto the program icon to  cause the program to analyze the data
file. That doesn't work with console programs, at least any way I've
tried. It does work with QuickWin or VSW. It's needed for teaching
undergrads, for most of whom a command prompt is a foreign concept. 

Mike

"Mike Prager" <mike.prager@mhprager.com> wrote in message 
news:opks16lqemroio3jv3pdhood9eoffcv59c@4ax.com...
> On Sat, 19 Jun 2010 23:39:36 +0000 (UTC), David Duffy
> <davidD@orpheus.qimr.edu.au> wrote:
>
>>Mike Prager <mike.prager@mhprager.com> wrote:
>>
>>> * I am looking only at commercial products because none of the free
>>> versions has an option (like Lahey's vsw or Intel's QuickWin) that
>>> makes a simple Windows program without coding changes.  If I'm wrong
>>> about that, it would be great to know it. I have considered using
>>> DISLIN's widget routines, but that is a much more complex approach.
>>
>>If you wished to use gfortran or g95 under Windows, depending on how
>>sophisticated you wanted your GUI to look (rather than act ;)),
>>you could try PDCurses eg
>>http://www.projectpluto.com/win32a.htm
>>
>>There would still be some fiddling with your code.  The nice thing about
>>PDCurses is that it creates a new "native" window, rather than just 
>>running
>>in a standard console.
>>
>>I added *just* a graphical file chooser to a console program
>>using JAPI, (http://www.japi.de) which works beautifully, and is fairly
>>portable across different systems (Java has to be present on the
>>target).  Unfortunately JAPI is no longer being developed, and I haven't
>>tried it on Vista/Windows7.
>
> Thanks to David, Ian, Ralf, and Robin for comments.  All helpful.
>
> The special Windows requirement is to be able to drag and drop a data
> file onto the program icon to  cause the program to analyze the data
> file. That doesn't work with console programs, at least any way I've
> tried. It does work with QuickWin or VSW. It's needed for teaching
> undergrads, for most of whom a command prompt is a foreign concept.
>
> Mike

This program works for me on Vista (32 bit). Just retrieve the command line 
or a command line argument.

Microsoft Windows [Version 6.0.6002]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

C:\Users\epc\temp>type x.f90
character*64 s
integer i,ier

call get_command(s,i,ier)
print *,'|',s,'|'
print *,i,ier
pause

end

C:\Users\epc\temp>g95 x.f90

C:\Users\epc\temp>a hello, world
 |a hello, world                                                  |
 14 0
PAUSE statement executed.  Hit Return to continue

Now when I drag and drop "foo.dat" onto "a.exe" here is what I see in the 
console window:

 |C:\Users\epc\Desktop\a.exe C:\Users\epc\Desktop\foo.dat         |
 55 0
PAUSE statement executed.  Hit Return to continue

I don't know if this works on XP or earlier.

--- Elliot

Mike Prager <mike.prager@mhprager.com> wrote:
> The special Windows requirement is to be able to drag and drop a data
> file onto the program icon to  cause the program to analyze the data
> file. That doesn't work with console programs, at least any way I've
> tried.

I know v. little about Windows, especially more modern ones, but to add
just that functionality you can use scripting.  Wsh, Wscript/Jscript/VBScript
should be able to do this in just a few lines:

[UNTESTED]
Set WshShell = WScript.CreateObject("WScript.Shell")
Set objArgs = WScript.Arguments
WshShell.Run "your_exe < " & objArgs(1)

Cheers, David Duffy.

On 6/20/2010 12:44 PM, Mike Prager wrote:
> On Sat, 19 Jun 2010 23:39:36 +0000 (UTC), David Duffy
> <davidD@orpheus.qimr.edu.au>  wrote:
>
>> Mike Prager<mike.prager@mhprager.com>  wrote:
>>
>>> * I am looking only at commercial products because none of the free
>>> versions has an option (like Lahey's vsw or Intel's QuickWin) that
>>> makes a simple Windows program without coding changes.  If I'm wrong
>>> about that, it would be great to know it. I have considered using
>>> DISLIN's widget routines, but that is a much more complex approach.
>>
>> If you wished to use gfortran or g95 under Windows, depending on how
>> sophisticated you wanted your GUI to look (rather than act ;)),
>> you could try PDCurses eg
>> http://www.projectpluto.com/win32a.htm
>>
>> There would still be some fiddling with your code.  The nice thing about
>> PDCurses is that it creates a new "native" window, rather than just running
>> in a standard console.
>>
>> I added *just* a graphical file chooser to a console program
>> using JAPI, (http://www.japi.de) which works beautifully, and is fairly
>> portable across different systems (Java has to be present on the
>> target).  Unfortunately JAPI is no longer being developed, and I haven't
>> tried it on Vista/Windows7.
>
> Thanks to David, Ian, Ralf, and Robin for comments.  All helpful.
>
> The special Windows requirement is to be able to drag and drop a data
> file onto the program icon to  cause the program to analyze the data
> file. That doesn't work with console programs, at least any way I've
> tried. It does work with QuickWin or VSW. It's needed for teaching
> undergrads, for most of whom a command prompt is a foreign concept.
>
> Mike

Gino can do that and is one of the easiest to program.

On Sun, 20 Jun 2010 19:27:09 -0500, "Gary L. Scott"
<garylscott@sbcglobal.net> wrote:

>> On Sat, 19 Jun 2010 23:39:36 +0000 (UTC), David Duffy
>> wrote:
>>
>>> Mike Prager<mike.prager@mhprager.com>  wrote:
>>
>> The special Windows requirement is to be able to drag and drop a data
>> file onto the program icon to  cause the program to analyze the data
>> file. That doesn't work with console programs, at least any way I've
>> tried. It does work with QuickWin or VSW. It's needed for teaching
>> undergrads, for most of whom a command prompt is a foreign concept.
>
>Gino can do that and is one of the easiest to program.

Yes.  It's also US $3600! 

On Sun, 20 Jun 2010 16:59:04 -0400, "e p chandler" <epc8@juno.com>
wrote:

>This program works for me on Vista (32 bit). Just retrieve the command line 
>or a command line argument.
[...]
>Now when I drag and drop "foo.dat" onto "a.exe" here is what I see in the 
>console window:
>
> |C:\Users\epc\Desktop\a.exe C:\Users\epc\Desktop\foo.dat         |
> 55 0
>PAUSE statement executed.  Hit Return to continue
>
>I don't know if this works on XP or earlier.
>

Elliot,

THANKS!  I thought I had tried this, but I must have done something
wrong, as I tried again, and it works fine under XP and Windows 7.  To
get the PAUSE without adding it to the Fortran program, I just used a
batch file:

@echo off
@aspic.exe %1 %2
@pause

This is an easy, cheap, effective solution to the problem -- the kind
I like.

Mike

On 2010-06-21 14:41:47 -0300, Mike Prager <mprager@3.14.alum.mit.edu> said:

> On Sun, 20 Jun 2010 19:27:09 -0500, "Gary L. Scott"
> <garylscott@sbcglobal.net> wrote:
> 
>>> On Sat, 19 Jun 2010 23:39:36 +0000 (UTC), David Duffy
>>> wrote:
>>> 
>>>> Mike Prager<mike.prager@mhprager.com>  wrote:
>>> 
>>> The special Windows requirement is to be able to drag and drop a data
>>> file onto the program icon to  cause the program to analyze the data
>>> file. That doesn't work with console programs, at least any way I've
>>> tried. It does work with QuickWin or VSW. It's needed for teaching
>>> undergrads, for most of whom a command prompt is a foreign concept.
>> 
>> Gino can do that and is one of the easiest to program.
> 
> Yes.  It's also US $3600!

Depends on how you price out various budget lines. :-) Sometimes
manhours are worth almost zip and sometimes cash it very expensive
compared to nominal values.

On Jun 21, 12:41=A0pm, Mike Prager <mpra...@3.14.alum.mit.edu> wrote:
> On Sun, 20 Jun 2010 19:27:09 -0500, "Gary L. Scott"
>
> <garylsc...@sbcglobal.net> wrote:
> >> On Sat, 19 Jun 2010 23:39:36 +0000 (UTC), David Duffy
> >> wrote:
>
> >>> Mike Prager<mike.pra...@mhprager.com> =A0wrote:
>
> >> The special Windows requirement is to be able to drag and drop a data
> >> file onto the program icon to =A0cause the program to analyze the data
> >> file. That doesn't work with console programs, at least any way I've
> >> tried. It does work with QuickWin or VSW. It's needed for teaching
> >> undergrads, for most of whom a command prompt is a foreign concept.
>
> >Gino can do that and is one of the easiest to program.
>
> Yes. =A0It's also US $3600!

When only the best will do :).  Upgrades are much more reasonable (so
there's good news if you become hooked).  And they work very hard to
add the most requested features and fix bugs.  I've gotten virtually
every feature I ever asked for save for a few, e.g.  1) improved RTF
editor (it uses the basic one MS distributes for the less capable
editors like MS Outlook), 2) improved WEB support (I'd like to program
entirely in GINO and have them output web-compatible streams (html,
svg, png)...although they've recently added Flash support, so maybe
there's hope), two built in tools:  a font editor (mainframe package
came with this) and a help editor (cross platform)

On Jun 21, 1:59=A0pm, Mike Prager <mpra...@3.14.alum.mit.edu> wrote:
> On Sun, 20 Jun 2010 16:59:04 -0400, "e p chandler" <e...@juno.com>
> wrote:
>
>
>
> >This program works for me on Vista (32 bit). Just retrieve the command l=
ine
> >or a command line argument.
> [...]
> >Now when I drag and drop "foo.dat" onto "a.exe" here is what I see in th=
e
> >console window:
>
> > |C:\Users\epc\Desktop\a.exe C:\Users\epc\Desktop\foo.dat =A0 =A0 =A0 =
=A0 |
> > 55 0
> >PAUSE statement executed. =A0Hit Return to continue
>
> >I don't know if this works on XP or earlier.
>
> Elliot,
>
> THANKS! =A0I thought I had tried this, but I must have done something
> wrong, as I tried again, and it works fine under XP and Windows 7. =A0To
> get the PAUSE without adding it to the Fortran program, I just used a
> batch file:
>
> @echo off
> @aspic.exe %1 %2
> @pause
>
> This is an easy, cheap, effective solution to the problem -- the kind
> I like.
>
> Mike

Note: Spaces are legal in Windows pathnames. So I would look at the
entire command line instead of the Fortran equivalent of argv[].

--- E

Mike Prager wrote:
> I am in the market for a single copy of a commercial* Fortran compiler
> to use under Windows. I'm seeking advice on the options.
>
> Because I am a one-man, part-time consulting shop, price is important.
> Lahey Express is cheap, but apparently it's not being updated any
> more.  Intel and Absoft both seem good and current.  Absoft is a bit
> cheaper, and from what I can see, it is fast and complete. However,
> its diagnostics aren't so great.  On the other hand, its IDE was
> designed for Fortran, which would be a pleasant change -- I don't much
> care for Visual Studio.
>
> Any comments on these or other suitable compilers -- including
> comments on tech support -- would be helpful.  Feel free to send them
> by email if you would rather comment privately.
>
> Thanks!
>
> Mike Prager
>
> * I am looking only at commercial products because none of the free
> versions has an option (like Lahey's vsw or Intel's QuickWin) that
> makes a simple Windows program without coding changes.  If I'm wrong
> about that, it would be great to know it. I have considered using
> DISLIN's widget routines, but that is a much more complex approach.



I use Intel myself, and find it a very good compiler with many 
diagnostic options. On Windows, it comes with an IDE based on Visual 
Studio which tightly integrates with the compiler, exposing all switches 
directly through the GUI.

However, I also like gfortran a lot, and the truth is that this free and 
open source compiler is probably sufficient for almost all projects, 
commercial or otherwise. One strong point of gfortran is the ability to 
use the C preprocessor of the GNU Compiler Collection in your Fortran 
projects, which can be *very* useful.

-- 
-- Philipp Emanuel Weidmann

On 6/21/2010 11:30 PM, Philipp E. Weidmann wrote:
> Mike Prager wrote:
>> I am in the market for a single copy of a commercial* Fortran compiler
>> to use under Windows. I'm seeking advice on the options.
>>
>> Because I am a one-man, part-time consulting shop, price is important.
>> Lahey Express is cheap, but apparently it's not being updated any
>> more. Intel and Absoft both seem good and current. Absoft is a bit
>> cheaper, and from what I can see, it is fast and complete. However,
>> its diagnostics aren't so great. On the other hand, its IDE was
>> designed for Fortran, which would be a pleasant change -- I don't much
>> care for Visual Studio.
>>
>> Any comments on these or other suitable compilers -- including
>> comments on tech support -- would be helpful. Feel free to send them
>> by email if you would rather comment privately.
>>
>> Thanks!
>>
>> Mike Prager
>>
>> * I am looking only at commercial products because none of the free
>> versions has an option (like Lahey's vsw or Intel's QuickWin) that
>> makes a simple Windows program without coding changes. If I'm wrong
>> about that, it would be great to know it. I have considered using
>> DISLIN's widget routines, but that is a much more complex approach.
>
>
>
> I use Intel myself, and find it a very good compiler with many
> diagnostic options. On Windows, it comes with an IDE based on Visual
> Studio which tightly integrates with the compiler, exposing all switches
> directly through the GUI.
>
> However, I also like gfortran a lot, and the truth is that this free and
> open source compiler is probably sufficient for almost all projects,
> commercial or otherwise. One strong point of gfortran is the ability to
> use the C preprocessor of the GNU Compiler Collection in your Fortran
> projects, which can be *very* useful.
>
ifort, like all compilers with OpenMP support, includes an fpp 
pre-processor.  In addition, we often see Makefile set up to use gcc as 
a pre-processor for ifort or pgfortran.  Yes, even on Windows.

Aside from Ian Chivers' useful rehearsal of the usual comparison sites, 
it seems that application performance isn't much of a consideration in 
this thread.
The compilers which show up well on the Polyhedron benchmark have made 
special efforts to do so; likewise, several commercial compilers are 
specially tuned for SPECfp and SPEComp.  In my experience, Fortran 95 
array assignment optimization tends to be the stronger point of 
gfortran, while ifort and pgfortran excel in f77 optimization with 
multiple assignments per loop.  OpenMP performance isn't covered in as 
useful a way by the comparison sites; gfortran has come up to the top 
rank for OpenMP performance on linux, but not Windows.

-- 
Tim Prince

In article <88bpogFiaeU1@mid.individual.net>,
 Tim Prince <tprince@myrealbox.com> wrote:

> > However, I also like gfortran a lot, and the truth is that this free and
> > open source compiler is probably sufficient for almost all projects,
> > commercial or otherwise. One strong point of gfortran is the ability to
> > use the C preprocessor of the GNU Compiler Collection in your Fortran
> > projects, which can be *very* useful.
> >
> ifort, like all compilers with OpenMP support, includes an fpp 
> pre-processor.

Practically speaking, that is almost irrelevant at the present time.  
The important feature that is used by many codes is the use of the C 
preprocessor.  As with most other fortran compilers, ifort uses the 
C preprocessor automatically with upper case file extensions (*.F 
and *.F90 for fixed-format and free-format source code respectively).

I don't know when (or if) the fortran preprocessor will ever become 
as popular as the C preprocessor for fortran code.  The demand was 
so great in the 1980s for a standard preprocessor that something had 
to step in and fill that need.  cpp has problems, but it could be 
made to work.  Other possibilities, such as m4, had other 
liabilities.  And the fortran standard committee refused to take 
action in a timely manner, so cpp stepped in and now there are 
probably hundreds of millions of lines of fortran code that use cpp.

Of course, if you have one of the rare codes that use the fortran 
preprocessor, then that is an important feature in a compiler for 
you.  But those are, at present, rare codes.

>  In addition, we often see Makefile set up to use gcc as 
> a pre-processor for ifort or pgfortran.  Yes, even on Windows.

For compilers that do not support cpp automatically, another option 
is the separate filepp.  This is a perl script that is quite capable 
and flexible.  And you have the source code if you want to change 
something.  It has all the functionality of cpp, plus some more 
powerful programming constructs, such as the ability to set up a 
loop to generate blocks of code.

I wrote and maintained my own conditional compilation utility for 
about 15 years in the 80's and 90's.  I was in a holding pattern 
waiting for the fortran committee to act.  What I thought was a 
short-term fix ended up lasting much too long.  If I had known what 
was going to happen, I would have switched to cpp (or something like 
the filepp perl script) a decade earlier and just moved on.

$.02 -Ron Shepard

On 06/22/2010 05:05 PM, Ron Shepard wrote:
> In article <88bpogFiaeU1@mid.individual.net>,
>  Tim Prince <tprince@myrealbox.com> wrote:
>
>>> One strong point of gfortran is the ability to
>>> use the C preprocessor of the GNU Compiler Collection in your Fortran
>>> projects, which can be *very* useful.
>>>
>> ifort, like all compilers with OpenMP support, includes an fpp 
>> pre-processor.
> 
> Practically speaking, that is almost irrelevant at the present time.  
> The important feature that is used by many codes is the use of the C 
> preprocessor.

I think there is a language problem: There is the conditional
compilation as defined in part 3 of the Fortran 95 standard (ISO/IEC
1539-3:1998); I think almost no one uses this one and I do not know any
compiler supporting it. If one needs it, there exists the preprocessor
coco at http://users.erols.com/dnagle/coco.html

But FPP and CPP are used somewhat interchangeably: Both mean the C
preprocessor, possibly adapted a bit for Fortran (and thus called fpp);
depending on the compiler cpp/fpp might not use not the full C99 feature
set and might (or might not) be adapted for Fortran. Cf. fdfpp at
http://www.netlib.org/fortran/

Talking about CPP: The problem with a true "C" cpp (such as the one that
ships with GCC) is that it does not know about Fortran; thus
  ! It's important
will print a warning because of the single quote - as the compiler does
not recognise the comment. For that reason, gfortran uses CPP (libcpp)
in the traditional mode (which disables some nice C99 CPP features).
Other vendors (e.g. Intel) have updated their internal preprocessor to
know about Fortram. (Which is also planed for cpp / gfortran -cpp but no
one is currently working on it.)

As the kind of preprocessing supported by the Fortran compiler is a bit
unpredictable, there are programs - as mentioned by Tim - which indeed
call (the GNU) "cpp" explicitly, even though the build-in CPP/FPP of
most Fortran compilers would simply work.

Tobias

In article <4C20D6F6.6050009@net-b.de>,
 Tobias Burnus <burnus@net-b.de> wrote:

Ok, if the fpp mentioned was not the fortran preprocessor, then my 
comments were misdirected.  Hopefully they were still useful, or 
perhaps my confusion was entertaining, nonetheless.

> Talking about CPP: The problem with a true "C" cpp (such as the one that
> ships with GCC) is that it does not know about Fortran; thus
>   ! It's important
> will print a warning because of the single quote - as the compiler does
> not recognise the comment.

Yes, there are other problems too.  I don't remember exactly the 
character sequence, but I remember getting in trouble in a fortran 
code that had a # within a character string.  This somehow triggered 
something unexpected in the C preprocessor and it took a while to 
figure out what was happening.  Maybe this was related to trigraphs 
in C, or cpp macro concatenation or something, I forget the details.  
There was an easy work around once the problem was identified, the 
problem was that I was a fortran programmer trying to figure out how 
some obscure feature of C syntax was affecting some otherwise 
perfectly legal fortran code.

The fortran standards committee did a true disservice to fortran 
programmers in the 80's.  Even now, almost 30 years later, as 
evidenced by this thread, that plague is still visiting our houses.

$.02 -Ron Shepard

On 6/22/2010 11:17 AM, Ron Shepard wrote:
> In article<4C20D6F6.6050009@net-b.de>,
>   Tobias Burnus<burnus@net-b.de>  wrote:
>snip
> The fortran standards committee did a true disservice to fortran
> programmers in the 80's.  Even now, almost 30 years later, as
> evidenced by this thread, that plague is still visiting our houses.
>
> $.02 -Ron Shepard

COCO???

On 6/22/10 7:18 PM, Gary L. Scott wrote:
> On 6/22/2010 11:17 AM, Ron Shepard wrote:
>> In article<4C20D6F6.6050009@net-b.de>,
>> Tobias Burnus<burnus@net-b.de> wrote:
>> snip
>> The fortran standards committee did a true disservice to fortran
>> programmers in the 80's. Even now, almost 30 years later, as
>> evidenced by this thread, that plague is still visiting our houses.
>>
>> $.02 -Ron Shepard
>
> COCO???
>

Yes, I'm sure that's one of the things Ron meant.  ;)

Dick Hendrickson

In article <88eq9hForqU1@mid.individual.net>,
 Dick Hendrickson <dick.hendrickson@att.net> wrote:

> On 6/22/10 7:18 PM, Gary L. Scott wrote:
> > On 6/22/2010 11:17 AM, Ron Shepard wrote:
> >> In article<4C20D6F6.6050009@net-b.de>,
> >> Tobias Burnus<burnus@net-b.de> wrote:
> >> snip
> >> The fortran standards committee did a true disservice to fortran
> >> programmers in the 80's. Even now, almost 30 years later, as
> >> evidenced by this thread, that plague is still visiting our houses.
> >>
> >> $.02 -Ron Shepard
> >
> > COCO???
> >
> 
> Yes, I'm sure that's one of the things Ron meant.  ;)


No, I was talking about the decade long stall in the 80's, where the 
standards committee seemingly tried to kill the language by dragging its 
feet.  One of the things that was urgently needed in the 80's, 
especially with the wide range of hardware in use at the time, was a 
standard preprocessor.  That is when most of the fortran compilers 
starting using the C preprocessor to fill this gap in functionality.

The COCO/fpp preprocessor came much later (f95, I think), and although 
it has been with us for 15 years now, it has practically no usage, no 
support by the vendors, and it has made no significant impact on 
portability or flexibility.  That is the preprocessor that I mistakenly 
thought was being discussed earlier in this thread.  I don't think there 
is anything basically wrong with its design, it just came 15 years too 
late, and everyone has moved already to the cpp alternative (with all of 
its quirks and faults).  Just imagine how different things would have 
been in the 80's if f90+COCO had been part of the revised standard 
approved in, say, 1980 or 1981.

$.02 -Ron Shepard

>> >Gino can do that and is one of the easiest to program.
>>
>> Yes. �It's also US $3600!
>
>When only the best will do :).  Upgrades are much more reasonable (so
>there's good news if you become hooked).  And they work very hard to
>add the most requested features and fix bugs.  I've gotten virtually
>every feature I ever asked for save for a few, e.g.  1) improved RTF
>editor (it uses the basic one MS distributes for the less capable
>editors like MS Outlook), 2) improved WEB support (I'd like to program
>entirely in GINO and have them output web-compatible streams (html,
>svg, png)...although they've recently added Flash support, so maybe
>there's hope), two built in tools:  a font editor (mainframe package
>came with this) and a help editor (cross platform)

Yes, GINO is very good -- I used it as a NOAA employee -- but now I'm
retired, and as a part-timer, I can't afford it unless I get a
consulting job that specifically needs its capabilities (MORE than
just drag and drop) & has a budget to match.

Ron Shepard wrote:

> 
.. . .
> 
> No, I was talking about the decade long stall in the 80's, where the 
> standards committee seemingly tried to kill the language by dragging its 
> feet.  One of the things that was urgently needed in the 80's, 
> especially with the wide range of hardware in use at the time, was a 
> standard preprocessor.  That is when most of the fortran compilers 
> starting using the C preprocessor to fill this gap in functionality.
> 
.. . .
Well, there were at least as many people on the committee
who were "pulling" as were "dragging", but they just barely
won the day.

And you are certainly correct that this conflict resulted in
a long delay that caused lots of problems.
> 
> $.02 -Ron Shepard

Walt Brainerd