From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!fx29.iad.POSTED!not-for-mail
From: Brad Moore <brad.moore@shaw.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: =?windows-1252?Q?GNAT=A0and_Tasklets?=
References: <f9828477-a98e-4795-803d-5926aa7a1fdb@googlegroups.com>
 <cfe7hnFaj8oU1@mid.individual.net>
 <avd3b8es5f6d$.byde19f9gn19$.dlg@40tude.net>
 <8277a521-7317-4839-b0b6-97f8155be1a4@googlegroups.com>
 <fegtcevrst5z$.fck8rij41mwt.dlg@40tude.net>
 <9e1d2b9f-1b97-4679-8eec-5ba75f3c357c@googlegroups.com>
 <zdj4kqj1rzxe.o579icl2x61u$.dlg@40tude.net>
 <478c81f9-5233-4ae1-a3eb-e67c4dbd0da1@googlegroups.com>
 <m70va3$t6a$1@dont-email.me> <yjrnhk0w8gjd.k6ht3uh7raiw.dlg@40tude.net>
 <gAYkw.944188$Fo3.593534@fx09.iad>
 <1r2ziulc78imb$.ad6zx5upic6s$.dlg@40tude.net>
 <td_kw.949255$FX2.779836@fx18.iad>
 <1gfkkgi7ukoj3$.1pqtchynzp9rc$.dlg@40tude.net> <m72i19$29s$1@loke.gir.dk>
 <Wsilw.1234991$1s.181390@fx05.iad>
In-Reply-To: <Wsilw.1234991$1s.181390@fx05.iad>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <geElw.640183$Lq6.209319@fx29.iad>
NNTP-Posting-Host: 68.145.219.148
X-Complaints-To: internet.abuse@sjrb.ca
X-Trace: 1419186188 68.145.219.148 (Sun, 21 Dec 2014 18:23:08 UTC)
NNTP-Posting-Date: Sun, 21 Dec 2014 18:23:08 UTC
Date: Sun, 21 Dec 2014 11:23:09 -0700
X-Received-Bytes: 4326
X-Received-Body-CRC: 4256207137
Xref: news.eternal-september.org comp.lang.ada:24183
Date: 2014-12-21T11:23:09-07:00
List-Id: <comp.lang.ada>

On 2014-12-20 10:36 AM, Brad Moore wrote:
> On 14-12-19 06:05 PM, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>>
>>> I think that the block should have explicit parameters, e.g. Total
>>> must be
>>> an in-out parameter of the block. The syntax should be similar to the
>>> selective accept. Each arm must also have parameters, and only those and
>>> of
>>> the block must be visible within an arm. E.g. A, B must be parameters.
>>> Nothing else should be visible.
>>
>> Interesting. This does sound like a better approach to me. (The whole
>> reduction object idea seems to me to be the worst part of the parallel
>> proposals -- something needs to be available, but that doesn't seem to be
>> the way to do it.)
>>
>> OTOH, the syntax to specify such parameters doesn't seem natural. We
>> surely
>> don't want to force a parallel block or loop to be the only contents of a
>> subprogram.
>>
>> More thought required.
>
> I had considered the idea of parallel block parameters as well, as the
> underlying idea has appeal, but had dismissed the idea in my mind due to
> similar reasons. Having a parameter list in the middle of a section of
> code looks plain weird to me. It looks like a callable entity, but the
> call is never made. The call implicitly occurs when the parallel block
> is encountered in the thread of execution, and the parameters are
> implicitly passed from other objects having the same name. I would think
> that would be quite foreign to existing Ada programmers, and might be
> considered somewhat inelegant.
>
> It seemed better to treat this as a simple control structure more like
> an if statement, and leave the parameter passing and exception contracts
> to the enclosing subprogram.
>

Actually, the proposed parallel block syntax fits nicely into the 
language when you think of it as a control statement, like an if statement.

An if statement with an else can be viewed as a logical "or" of two or 
more sequences of statements.

eg.

     if X
       Do_This;
     else
       Do_That;
     end if;

Here the effect is;
    Do_This *or* Do_That

A parallel block statement could be viewed as a logical "and of two or 
more sequences of statements.

    parallel
       Do_This;
    and
       Do_That;
    end parallel;

Here the effect is;
     Do_This *and* Do_That

So another argument against having parameters to the parallel block, is 
that it would be inharmonious to have parameters on a parallel block, if 
they cannot also be on an if statement.

I have never seen a programming language that has parameters on an if 
statement. That doesn't mean they don't exist. I'd be curious if anyone 
is aware of any such language. Adding parameters to if statements in Ada 
might be a real challenge.

Brad