[J3] new feature papers

[Van Snyder]

On Mon, 2018-08-06 at 20:01 -0600, Dan Nagle via J3 wrote:
> Hi,
> 
> I posted a couple of new feature papers, 237, 238.
> 
> I expect they will be assigned to subgroups (for gestation or strangling).
> 
> There are four parts to these papers: Intro, Use-cases, What I have in mind,
> and (Rough) Requirements.
> 
> I think a new feature paper along these lines will help subgroup
> understand the issues, and the proposed solution.

Fortran hasn't had any medium-grain parallel facilities other than
FORALL and DO CONCURRENT.  Asynchronous procedures with event signaling
(18-237) put even more burden on the user, not the language and
processor, for synchronization.

I recommend reading

      *  https://en.wikibooks.org/wiki/Ada_Programming/Tasking, an easy
        summary introduction where (some of) the parallelization
        facilities of Ada are described.
      *  "Concurrent and Real Time Programming in Ada" by Alan Burns and
        Andy Wellings.
      * "The Programming Language Concurrent Pascal" (1975)
        http://brinch-hansen.net/papers/1975a.pdf
      * "Ada as a Second Language" by Norman Cohen (I liked this a bit
        better than
      * "Programming in Ada 95" by John Barnes.  I haven't yet read
      * "Programming in Ada 2012" by John Barnes.

In Ada, it isn't necessary to depend upon an event or lock to discover
whether it's OK to look at data being manipulated my another task.  The
task rendezvous, or the protected entry (monitor), provides this
automatically.

I don't believe we should rush into asynchronous procedures (or
asynchronous blocks) without some deep thought, and study of what those
who have ventured in this direction before us have done.  Tasks were in
the Ada requirements in 1976.  They have a forty year head start on us.
We should learn from them, i.e., "Stand on the shoulders of giants,"
instead of starting afresh from where they began forty years ago.

We already have the infrastructure for a FORK-JOIN construct, which can
be faked using DO CONCURRENT with SELECT CASE inside.  Syntactic sugar
for that wouldn't add any new risk.

something like

  PARALLEL
  FORK [ ( <logical expression> ) ]
    <block>
  FORK [ ( <logical expression> ) ]
    <block>
  ...
  JOIN ! or END PARALLEL

The ( <logical expression> ) allows to avoid starting a thread that is
just going to quit right away.

DO CONCURRENT (and FORK JOIN) would benefit from monitor procedures.