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: 
 border1.nntp.ams3.giganews.com!border2.nntp.ams3.giganews.com!border2.nntp.ams2.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Wed, 28 Aug 2013 10:58:44 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Ada advocacy
References: 
 <19595886.4450.1332248078686.JavaMail.geo-discussion-forums@vbbfy7>
 <2012032020582259520-rblove@airmailnet> <jkc59a$hs5$2@speranza.aioe.org>
 <12ee9bc5-3bdf-4ac0-b805-5f10b3859ff4@googlegroups.com>
 <vhcvr8d4kq6ribdqeeb0b857ei5aa5luiv@4ax.com>
 <6c58fae4-6c34-4d7a-ab71-e857e55897c0@x6g2000vbj.googlegroups.com>
 <wccvc5b49yc.fsf@shell01.TheWorld.com> <op.w2g9br0kule2fv@cardamome>
 <246849b7-7a53-48a2-8f64-ff6dfb2086ce@googlegroups.com>
In-Reply-To: <246849b7-7a53-48a2-8f64-ff6dfb2086ce@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <521dbbbb$0$9520$9b4e6d93@newsspool1.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 28 Aug 2013 10:58:35 CEST
NNTP-Posting-Host: 40ea705e.newsspool1.arcor-online.net
X-Trace: DXC=D; Lf@LJG6Lk016@cHD@m;
 jic==]BZ:afn4Fo<]lROoRankgeX?EC@@`hXZIWVe1=Plnc\616M64>jLh>_cHTX3jmaHio5:D^\Ld
X-Complaints-To: usenet-abuse@arcor.de
X-Original-Bytes: 3672
Xref: number.nntp.dca.giganews.com comp.lang.ada:183179
Date: 2013-08-28T10:58:35+02:00
List-Id: <comp.lang.ada>

On 28.08.13 09:45, Maciej Sobczak wrote:
>> Why did you said "no big loss" about the rendez-vous? What's your known
>> issues with rendez-vous? I never used concurrency a lot until now, so
>> that's really a question, because I may  (or may not, I still don't know)
>> have to use it.
>
> The biggest issue with rendez-vous is that it is (the server-side part of it) coupled by the rules of grammar to the top level of task body. That is, all your "accept" statements must be syntactically in the task body that declared appropriate entries.
> It looks OK in the book examples, but since it makes code refactoring impossible,

Having the accept statements in one place surely means
you'll find the server side's tasking interface and its
control structure (when acting), in one place.

Note that task can be nested; if bodies other that task bodies
could carry accept statements, that would be an invitation to create
very puzzling software designs. It'd take quite some effort to
find a task type's accept statements.

If, instead, scope is used for actions to go between acceptors,
private packages, separate, etc, then supporting definitions
can go elsewhere, and be refactored as needed, respecting the
needs of visibility of data. This leaves the communications parts
not scattered, but in one tight control struture.

I find this kind of grammatically required modularity normal for
a Has-It type language like Ada; I'd not expect this kind of
stricture when using a more "flexible" I-Can-Roll-My-Own language.


> The "no big loss" statement is justified by the fact that rendez-vous does not offer anything particularly useful to what is already offered by protected objects.

How so? There is no rendezvous via protected objects, since
using it means the program is using a different protocol.
And different types, different objects, likely different
places for shared data, and overall a different way of
communicating data. A handshake (rendezvous )and a mailbox
(PO) seem different to me.

Taken to the extreme of the Ravenscar profile, its lack of
rendezvous demonstrates the relative difficulty that ensues.