Fortran 2008 (was Re: Statement function host association)

Dan Nagle wrote:
> Hello,
>
> Actually, the vote in Delft was to delete statement functions
> in the 2008 standard.

Has the committee voted to remove any other features from Fortran 2008?

In the June 2005 issue of C/C++ Users Journal, P.J. Plauger wrote about
the C standards process:

"It was a busy week for WG14 [the C standards committee]. No, the
committee has still not begun work on a new version of the C standard.
The sentiment remains that C99 has yet to catch on widely enough in the
industry. The last thing anyone wants is the prospect of yet another
version looming on the horizon. [...]"

"Part of what kept us so busy [at the latest committee meeting] was
answering Defect Reports. These are official queries and/or complaints
about the meaning of the current C standard."

A similar approach to standardization may also be best for Fortran,
although
the C community is probably dominated by language conservatives, with
the progressives having moved to C++ long ago. (I don't mean either
"conservative" or "progressive" pejoratively -- there is a need for
both types of languages.)

Keith Bierman has discussed the conflict between Fortran conservatives
and progressives in the F90 standard process in a blog entry at
http://blogs.sun.com/roller/page/khb/20040816#standards_do_s_and_don ,
which is excerpted below. I wonder who the "one particular individual"
is that Bierman mentions in the last paragraph.

"Now, as to the sad case of Fortran (I was on the Committee for a dozen
years, and had been a formal observer for another couple before that)
it's a long sad saga (and Brian Meek, who Bill references, was hardly
an unbiased observer to say the least).

To make a long and painful story short enough to learn key lessons
from:

(1) The Committee was roughly divided into two nearly equal factions,
let's call them the Progressives and the Conservatives. The
Progressives wanted to create a throughly modern language that would
run all existing Fortran codes, and preserve the performance
characteristics that made Fortran valuable to the high performance
crowd. The Conservatives felt that it was virtually impossible to
ensure either of those requirements (since all real codes depended on
various vendor extensions and implementation details, and the new
Standard was radical enough to require a rewrite of the compilers) and
that the appropriate behavior for the Committee was along the lines of
what Bill suggests. (In the interest of honesty, I was on the wrong
side of that issue at the time. I was a Progressive. I repented after
it was too late).

(2) Due to the voting rules, the Committee lurched from one side to
the other, taking what had been a pretty coherent (if overly
ambitious) document, tossing nearly all of it away (when the
Conservatives were on the upswing) and then putting each feature back
in piecemeal (losing the structural integrity of the original) over
the course of many years as the Progressives recovered their majority.
This was the worst of all worlds, a major update, which was very late
and no longer done "well".

(3) Both sides were, alas, in agreement that we needed to keep
everyone in the One Big Tent. That is, to keep all of the warring
factions together. Had we split into two efforts, we would have had
two stronger languages. Just as Algol begat C, which begat C++ which
begat Java, we would have had something like Classical Fortran as the
result of the Conservatives, and something similar to Mathematica for
the Progressives (well, probably not an entire environment, but a
modern language without the baggage). Both could have been done
faster, and probably better.

(4) An example of what happens when you have two closely matched
sides, there were two different user requirements for a "bit"
datatype. There were two factions on the committee. As a result, no
bit datatype made it into the language. The needs didn't go away; but
they remain unrequited 20 years later....

But hindsight is better than foresight.

I think it worthy of mention that even during the worst of the
battles, the individuals remained cordial and friendly relations were
the norm. This was a tribute to the professionalism and to the culture
that the Committee had bulit up and maintained over the course of
several "generations" of membership.

This all came to an end, long after the camps largely evaporated, due
to one particular individual's (a newcomer at the time) influence. It
was a very striking lesson to me in human dynamics; the power (albeit
negative) of one."

.

Relevant Pages

  • Re: What could J4 (or WG4) do (was: INSPECT and TRAILING syntax
    ... my intent was "The reports of the demise of the COBOL *standards ... of time or resources to tackle what you suggest right now. ... If I was on this committee, ... Was the 2002 standard later than anybody wanted it to be? ...
    (comp.lang.cobol)
  • Invitation to comment on Final Committee Draft for Fortran 2003
    ... The Final Committee Draft of the next standard for Fortran has ... Lists" item in the menu on the left, and then on "j3" near the top of the ...
    (comp.lang.fortran)
  • Re: what happened to hash-tables
    ... >> You already need hashtables anyway internally for implementing Common ... Many of the people on the committee had much more experience ... The ANSI standard is about memorializing the "Common" practice ... Suppose that the winning extensible hash table protocol is based ...
    (comp.lang.lisp)
  • Re: Function designator implicit conversion
    ... If the Committee had meant for the parameter list to be part of the ... it's not the intent. ... Standard says which is what my comment accurately reflected. ... This response seems to support the position I have presented. ...
    (comp.std.c)
  • Re: What could J4 (or WG4) do (was: INSPECT and TRAILING syntax
    ... the National Body representation to WG4, have the resources to carry out ... Then the first priority of the committee should be to get properly resourced ... COBOL standardization process, much less anyone whose primary financial ... So, given that you cannot produce a yardstick for the proposed standard, why ...
    (comp.lang.cobol)