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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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-13 03:56:16 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!dialin-145-254-039-112.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Reprise: 'in out' parameters for functions Date: Tue, 13 Apr 2004 12:56:03 +0200 Organization: At home Message-ID: References: <5ad0dd8a.0404090512.15af2908@posting.google.com> <5ad0dd8a.0404091828.6e79bb4e@posting.google.com> <5ad0dd8a.0404100735.7b2a8317@posting.google.com> <107m4fv65u18mc0@corp.supernews.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-039-112.arcor-ip.net (145.254.39.112) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.uni-berlin.de 1081853775 1419266 I 145.254.39.112 ([77047]) User-Agent: KNode/0.7.2 Xref: archiver1.google.com comp.lang.ada:7043 Date: 2004-04-13T12:56:03+02:00 List-Id: Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:c5b6pt$2pcs4d$2@ID-77047.news.uni-berlin.de... > ... >> Provided that: >> >> 1) protected object and tasks would be tagged (inheritable from); >> 2) multiple inheritance would be supported; >> 3) entries, procedures and functions would be primitive operations; >> 4) functional notation would be permitted (instead of prefix notation) > > See AI-345, which extends the interface mechanism (itself a Ada 200y > proposal) to cover task and protected types. (1) is true if the PT or TT > inherits from one or more interfaces; (2) follows from the definition of > interfaces; (3) is true for calls through interfaces (as opposed to > directly to the PO or TOs); (4) is true for calls through interfaces. > >> one could have entries of multiple protected objects and tasks. > > 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"; task body Foo is begin loop accept Double_Rendezvouz; -- Cannot give the body here end loop; end Foo; entry Double_Rendezvouz (X, Y : in out Foo) is begin ... end Double_Rendezvouz; [ I cannot see any direct use of things like that, except for demonstrating race conditions to students (:-)), but who knows... ] >> 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. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de