Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!ux1.cso.uiuc.edu!uxe.cso.uiuc.edu!hirchert
From: hirchert@uxe.cso.uiuc.edu
Newsgroups: comp.lang.fortran
Subject: Re: Two Fortran Standards
Message-ID: <50500150@uxe.cso.uiuc.edu>
Date: 18 Sep 89 15:59:00 GMT
References: <314@unmvax.unm.edu>
Lines: 27
Nf-ID: #R:unmvax.unm.edu:314:uxe.cso.uiuc.edu:50500150:000:1483
Nf-From: uxe.cso.uiuc.edu!hirchert    Sep 18 10:59:00 1989


Albert Hybl has been trying to convince the rest of us that the Fortran
standard should prohibit extensions.  I will gladly grant him that
inappropriate use of vendor extensions is highly undesirable.  I would like
to suggest two things:

1. Many of us from time to time use Fortran to do things not intended to be
   portable or intended to be portable only through the wholeshale replace-
   ment of some processor-specific kernel functionalities.  In such cases,
   it may be entirely appropriate to make use of vendor extensions.

2. Even if the standard prohibited extensions, it would be essentially
   meaningless.  (More accurately, it would mean little more than the
   current FIPS switches.)  Typically, a processor needs to be standard
   conforming only under one combinations of its switches.  A vendor could
   argue along the lines "Our command to run the standard-conforming compiler
   is 'fortran -noextensions'.  The command 'fortran' is our command to run
   the compiler for a language similar to standard fortran, but with a number
   of useful extensions."  In other words, vendors will stop providing
   extensions only when there stops being a market for them.

The best the standard can do is to provide the tools with which to write
readable, portable, effcient, etc. programs; it can't force programmers to
produce programs that actually have those properties.

Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications