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=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,9d303864ae4c70ad
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2004-04-14 14:14:04 PST
Path: 
 archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!newsfeed3.dallas1.level3.net!news.level3.com!newsfeed1.easynews.com!newsfeed3.easynews.com!easynews.com!easynews!newsfeed.news2me.com!sn-xit-02!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Reprise: 'in out' parameters for functions
Date: Wed, 14 Apr 2004 16:12:26 -0500
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <107raad8kkk3ae6@corp.supernews.com>
References: <u4qrv5hwr.fsf@acm.org> <bRecOT0TxF@VB1162.spb.edu>
 <mailman.224.1081468027.327.comp.lang.ada@ada-france.org>
 <5ad0dd8a.0404090512.15af2908@posting.google.com>
 <c56ib6$5ha$1@a1-hrz.uni-duisburg.de>
 <5ad0dd8a.0404091828.6e79bb4e@posting.google.com>
 <c58jfr$2qh7ca$2@ID-77047.news.uni-berlin.de>
 <5ad0dd8a.0404100735.7b2a8317@posting.google.com>
 <c5b6pt$2pcs4d$2@ID-77047.news.uni-berlin.de>
 <107m4fv65u18mc0@corp.supernews.com>
 <c5gh0e$1ba02$3@ID-77047.news.uni-berlin.de>
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
X-Complaints-To: abuse@supernews.com
Xref: archiver1.google.com comp.lang.ada:7106
Date: 2004-04-14T16:12:26-05:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:c5gh0e$1ba02$3@ID-77047.news.uni-berlin.de...
> Randy Brukardt wrote:
>
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> > news:c5b6pt$2pcs4d$2@ID-77047.news.uni-berlin.de...
> > ...
...
> > I don't see how this follows from (1) to (4), though. Each call is just
a
> > dispatching call to a single operation; there is no implementation
> > inheritance.
>
> Yes, but if I could have two dispatching parameters of same protected type
> (no MD involved) in a primitive operation, then a call to it should start
> two protected actions. Same with task entries, (4) should allow something
> like:
>
> task type Foo is ... end Foo;
> entry Double_Rendezvous (X, Y : in out Foo);
>    -- Declared after "end Foo";

This isn't allowed by AI-345; entries can only be declared inside a task
(with the current rules). An interface can have procedures that match
entries (and interface procedure calls can be used in select statements),
but there is no separate existence to entries.

You could declare a procedure like that

procedure Double_Rendezvous (X, Y : in out Foo);

but of course it doesn't have any special semantics.

...
> >> A call to such entry would start multiple protected actions (one per
each protected
> >> object parameter) and multiple rendezvous (one per each task object
> >> parameter). Could we agree that 1-4 is a damn *lot* of work?
> >
> > Not really. *Interfaces* is a lot of work, but presuming that we're
going
> > to have those anyway, adding protected and task support to them is not a
> > significant increment.
>
> I am glad to hear it from you, because of course, you know it better.

I should point out that not everyone agrees with my assessment here. But
it's not clear to me that everyone understands the implementation model for
these, so they may be trying a harder-than-necessary implementation
approach.

                  Randy.