Path: utzoo!attcan!uunet!yale!mfci!m3!oglesby
From: oglesby@m7.multiflow.COM (Jose Oglesby)
Newsgroups: comp.lang.fortran
Subject: Re: Why have FORTRAN 8x at all?
Message-ID: <542@m3.mfci.UUCP>
Date: 2 Nov 88 12:29:41 GMT
References: <388@ubbpc.UUCP> <16187@agate.BERKELEY.EDU> <599@quintus.UUCP> <392@ubbpc.UUCP>
Sender: news@mfci.UUCP
Distribution: comp.lang.fortran
Organization: Multiflow Computer Inc., Branford CT
Lines: 49
In-reply-to: wgh@ubbpc.UUCP's message of 1 Nov 88 14:24:57 GMT

In article <392@ubbpc.UUCP> wgh@ubbpc.UUCP (William G. Hutchison) writes:

    Algol-60 was really improved by Niklaus Wirth:
    Algol-60 -> Algol-W -> Pascal -> Modula -> Modula 2 -> ... -> ???

    BCPL -> B -> C -> C++

    Beware of committees of politicians bearing standards!

What about the FORTRAN 77 Standard which now has so many defenders?
Wasn't that produced by a committee?  Yes, one should beware, but
one should also try to keep an open mind.  Just because committes
have generally failed in the past does not mean they must continue
to fail.  In fact, I am very hopeful for the C and Scheme efforts.
The most important common thread that ties these efforts together
is the attempt to standardize existing practice.  In the case of
ANSI C there is also an attempt to "modernize" the language.  This
has been done in a restrained manner by not adding too many new
constructs or concepts.  In "modernizing", one can not go too
far.  I don't think the C community would be too happy if ANSI C
were the same as C++.  ( Personally, I would have approved ).

Now let's look at the 8X effort.  I beleive that so far the
committee has done a good job under difficult circunstances.
There are problems in the existing draft but it can be rescued.
The negative comments in comp.lang.fortran lately have not been very
helpful. ( i.e. It is bigger than Ada! Why have it at all? )
Those people who claim that the F8X language is too big should
come up with specific things they feel should be dropped from
it.   To those who question the need for a standard I would
point out the need to standardize existing practice so as
to obtain more portable code.

Actually one of the problems with the standard is its failure
to address some existing practice.  The bit strings and include
statement omissions should be rectified.  The include statement
problem could be handled through a supplementary standard for
a pre-processor.  

My favorite candidate for deletion from F8X is the notion
of precission specification.  As the IEEE standard becomes
more widespread the need for this feature lessens.

Well, that's all for now. Sorry for the long post.
--
Jose Oglesby
oglesby@multiflow.com		Multiflow Computer
or oglesby@mfci.uucp		175 North Main St.
or ...!uunet!mfci!oglesby	Branford CT 06405       (203)-488-6090