Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!uxc!uxc.cso.uiuc.edu!uxd.cso.uiuc.edu!uxe.cso.uiuc.edu!mcdonald
From: mcdonald@uxe.cso.uiuc.edu
Newsgroups: comp.lang.fortran
Subject: Re: DO loops, anyone? - Apologies!
Message-ID: <50500114@uxe.cso.uiuc.edu>
Date: 20 Mar 89 17:36:00 GMT
References: <459@orange19.qtp.ufl.edu>
Lines: 43
Nf-ID: #R:orange19.qtp.ufl.edu:459:uxe.cso.uiuc.edu:50500114:000:2221
Nf-From: uxe.cso.uiuc.edu!mcdonald    Mar 20 11:36:00 1989



>>                     You claim that since this code is illegal
>>whatever the customer gets, he deserves.  Since there is no definition,
>>there is no defined behavior.

>This is an overstatement of my position.  I believe
>. that people writing standard-conforming programs deserve correct behavior,
>. that people knowingly trying to port nonstandard code deserve the problems
>  that they are likely to encounter, and
>. that people inadvertantly violate the standard deserve help as much help as
>  can practically be given in finding these violations.
>This latter point is a "quality of implementation" issue.  I would label a
>processor that doesn't provide such help as "of low quality" or even as "junk"
>but not as "wrong" or generating "bad code", since these latter terms imply
>(to me, at least) a failure to handle correct programs correctly.

I certainly agree that a processor should clearly warn about any
non-standard thing it accepts as an extension. 

And, it would be very nice if a command line switch could turn
these warnings into errors, if the user wished.

But - but - both Fortran 77 and the proposed Fortran 89+x are lacking in
many useful things. Vendors really do need to add extensions if they
are going to sell things. I have gotten used to the "quality of 
implementation" that is standard in the PC C compiler world. (It is
true that some of the goodies constitute namespace pollution, but
they were added before that concept was set in concrete by X3J11).
Graphics libraries - system calls - added operators - calls to
do console io - all these are expected by the prospective buyer.
In Fortrans these things seem to be left out. Now, if you are using
PC compilers, as I do, from Microsoft and MicroWay, then you can
cough up the bundle for the C compiler and use the libraries there,
and if a given functionality is missing in Fortran, call C routines
to do the job. But, you ought not to have to. The vendors ought
to supply, either as language extensions (i.e. bit operators) or
as subroutines (getting command line arguments, graphics routines,
system calls), he same spiffies one gets in C. 

This is known as "meeting the competition" or "avoiding bankruptcy".

Doug McDonald