James Giles made my case for me:

> Consider the plight of modules.  Fortran adopted a definition
> of modules which failed to separate the declarations of exported
> types, values, variables, and procedures from their implement-
> ation.  This has taken years to correct, and the fix is a new form of
> module whose most significant property is that it's vastly more
> complicated than the nature of the problen it's designed to address.

I proposed in 1986 that Fortran's modules ought to be more like Ada
packages,  i.e., with specification separated from implementation.
Technical Report 19767 will be published "real soon now" (ISO has it),
remedying the problem at least half way.  TR 19767 implements the
equivalent of Ada's package body, and private child units.  The final
draft of TR 19767 is at ftp://ftp.nag.co.uk/sc22wg5/N1601-N1650.  The
paper number is N1602.  It is available as .pdf or .ps.gz.

The other part, the equivalent of Ada's public child units, was rejected
as a new feature proposal from the US delegation for the next revision
about six months ago because delegates "wanted more time to think about
it."  When I asked if anybody had used the last six months to think about
it, the response was mostly silence, larded with a bit of criticism for
resurfacing a "dead" issue, and a reminder that we had promised to do so
very little in the next revision that there isn't room for a proposal
that would require about 1/2 page of edits.

> Or, consider the recurrent discussion caused by the rather trivial
> mistake of making KIND specifiers be of INTEGER type.  I heard
> that there was originally a reason to do so that didn't pan out, but
> that when the reason disappeared, the decision was not reconsidered.

And the alternative Giles prefers is...?

> > [...]                           Dahl and Nygaard pioneered
> > object-oriented programming with Simula in 1962 and 1967.  When did
> > Fortran get support for object-oriented programming?  Last month.  The
> > list goes on and on.
>
> When was this demonstrated to be a forward step in the production of
> reliable and efficient programs?  Well, not yet.  Objective evidence
> is hard to find, and most indicates this to be a problematical feature
> at best.  Adding it to Fortran mostly amounts to "me-too" as a design
> criterion.

When most people hear "object-oriented programming" they think "C++",
which is just about the worst implementation there has been of
object-oriented programming.  Les Hatton criticized object-oriented
programming in "Does OO Sync with the Way We Think," but concluded that
he couldn't determine whether the problems he observed were caused by the
fundamental paradigm or the design of C++.  The design of the
object-oriented features of Fortran 2003 is based on Simula.  Care was
taken to avoid the mistakes of C++.  The modest-size (~150k lines) code
I'm working on now is designed according to object-based principles
explained by Charles Norton and Bolek Szymanski.  We believe it is
reliable and efficient.  Unlike many C++ codes I've worked on, it is
fairly easy to understand, and maintainable.  I can see how it could
benefit from many of the more fully object-oriented features in Fortran
2003, without compromising its efficiency, reliability or maintainability.

> > Participating means that you actually need to come to the meetings.  It's
> > essentially impossible to contribute effectively otherwise.  It took me
> > nearly thirty years to convince by management of this.  You really ought
> > to get started on it.
>
> This has never made much sense to me, even in the old pre-email,
> pre-usenet, pre-web days.  It makes even less sense now.  In fact, it's
> not at all clear why meetings are of any relevance except for inertia on
> the part of the bureaucrats in the standard organizations.  I think that
> new features need to be discussed in as public a forum as possible - and
> should be *very* thoroughly discussed before any official proposal to
> the committee is made, much lesss "set in stone".

The system is what it is.  You can whine about it, and not get anything
done, or try to work within it and maybe get at least a little bit done.
I guarantee that you will neither accomplish anything, nor change the
system, by sitting on the sidelines and throwing rotten vegetables.

"The committee" is WG5.  J3 is a "contractor" to WG5.  WG5 sets the
design specifications.  J3 "only" writes the words in the standard.
Nothing will be "set in stone" until the May WG5 meeting in Delft. The US
delegation to WG5 *does* plan to propose new features.  By the time of
the May meeting, these will have been discussed for about a year.
Anybody who thinks there hasn't been discussion is urged to read the mail
archive and J3 meeting minutes at http://www.j3-fortran.org.

> You mention that "only" two of the present proposals for the next
> revision (tentatively call F2008?) are of moderate complexity, yet
> how many outside the committee even know what they are, much less
> have had a chance to comment *before* they are too far along to be
> changed?  Daylight is needed much more than meetings.  This forum,
> the usenet newsgroup, and (if the participation restrictions can be
> loosened) the j3 mailing list seem appropriate (or maybe the committee
> should set up an additional forum specifically for this purpose).  Discussions
> on all major feature proposals should occur in all three places *before*
> any of those features are even written up for the committee's consideration.

The schedule and method for submitting new proposals for the next
revision, and the schedule for meetings, and the URL for all meeting
papers, have been published in several fora, including this one.  It is
not the responsibility of J3 or WG5 to send personally engraved
announcements to James Giles to announce each jot and tittle.

--
Van Snyder                    |  What fraction of Americans believe
[log in to unmask]       |  Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or disapproved
by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.