Both David and Lawrie missed my main point.  David responded to the
"they ought not to be optional" part and Lawrie's response addressed the
state of computer hardware as of at least three years ago.

To repeat (paraphrasing and embellishing slightly):

        The view of the US delegation to the ISO working group is that
        coarse-grain parallelism will become SO IMPORTANT SO SOON
        (apologies for shouting) that CoArrays should not be delayed,
        and should not be optional.

First to tackle the "should not be delayed" part:

Dual-core and quad-core processors both appeared after the 2003 standard
was published, and are already the only option for "commodity"
scientific computing.  The possibility that they might appear was not
even mentioned during development of Fortran 2003.  It was tacitly
agreed that HPF and OpenMP were dead letters by then, but nothing was
done to replace them, or to integrate them into the standard in hopes of
reviving their relevance.

We can expect processors with many more cores, and "affordable" systems
with enormous numbers of multicore processors, long before 2013, when
next a parallelism feature could be added to Fortran, or 2018, by which
time parallelism features added in 2013 would be widely available.  One
can already purchase coprocessors with thousands of ALUs, at reasonable
prices.  Although having only ALUs is overly simple at this time, that
will change rapidly.  Without language-supported parallelism, Fortran
will be largely irrelevant to scientific programming on what will be
"modern" and "widely used" commodity processors in 2018.

Keith has pointed out my mistake in suggesting that Moore's law is dead:
The problem is Amdahl's law.  You should expect this to be addressed by
"processor-in-memory" chips sooner rather than later.  The prospect of
programming meaningful systems of these efficiently (in both human and
silicon cycles) using PVM or MPI frightens me, and the people who pay
me.  People will want to program them.  Our ambitions keep expanding.
My current work processes data from a satellite instrument using a
cluster of 362 single-core Pentiums and a brain-dead parallelization
strategy.  Our next instrument (2016 or so) will return 400 times as
much data.  If Fortran won't be ready for this until after 2018, we'll
be stuck with something else, probably something less suitable.

Fine-grain parallelism was added to Fortran in 1990 in the form of array
operations, and embellished a little bit in 1995.  Nothing new was done
for parallelism, on any scale, in 2003.  A baby step toward
medium-grained parallelism is to be added in 2008, in the form of the
CONCURRENT construct.

The only serious alternative to CoArrays for coarse-grain parallelism is
PVM or MPI.  CoArrays are very much superior to PVM and MPI.  Arguing
that CoArrays shouldn't be implemented now because a better idea might
come along someday allows the perfect to be the enemy of the good.  If
you have a well-formed and tested idea that is "better" than CoArrays
(whatever you think "better" means), for its target scale, now is the
time to speak up.

To address optionality, CoArrays are defined to be almost optional, in
that processors need not support more than one image.  This means that
they have to parse some trivial new syntax, implement NUM_IMAGES to
return 1, THIS_IMAGE to return 1, and perhaps a few other trivialities.
There should be no impact on the code generator or optimizer.  This is
very much the same situation as for asynchronous I/O (which isn't
described in an optional part).

For processors that choose to support more than one image, it is
necessary to tackle all the interaction of CoArrays with the "core"
language (just as it is necessary for processors that support
asynchronous I/O), and it is essential for the details of that
interaction to be standardized.  If you study the standard, you will
find that this is pervasive (more so than for asynchronous I/O).  It
would be exceedingly difficult to develop an optional part that explains
this articulation in an understandable (and believably correct) way.
Consider how Alan Wilson could have added array syntax to Fortran in
1990 as an optional part or a TR, and you'll see the problem.

On Mon, 2008-08-25 at 16:32 +0100, Lawrie Schonfelder wrote:
> I entirely agree with David. Co-arrays may be important for some users on some architectures but by
> no means all of either. They are too "flavour of the month" and as yet unproven as even a better way
> of doing explicit parallelism let alone best on the architectures that do suit them. They must be
> optional.
> 
> --
> Lawrie Schonfelder
> Wirral, UK
> 
> > -----Original Message-----
> > From: Fortran 90 List [mailto:[log in to unmask]]On Behalf
> > Of David Muxworthy
> > Sent: 24 August 2008 16:52
> > To: [log in to unmask]
> > Subject: Re: j3 responses to public comments
> >
> >
> > On Sat, 23 Aug 2008 02:31:50 -0700, Van Snyder <[log in to unmask]> wrote:
> >
> > > The view of the US delegation to the ISO
> > >working group is that parallelism will become so important so soon that
> > >CoArrays should not be delayed, and should not be optional (optional
> > >stuff has never been successful in Fortran).
> >
> > The two optional parts of the current standard are unsuccessful not because
> > they are optional, but because there is no demand for them.
...
>   There are a
> > number of reasons why they should be an option.  A primary one is that, when
> > it is realised that the coarray model is not the best one to pursue, the
> > Fortran base language will not be lumbered with lots of redundant syntax and
> > complexity.