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-Thread: 103376,97f543c7a63b8839 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!border1.nntp.dca.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Sat, 06 Aug 2005 20:23:36 -0500 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <87iryk1eic.fsf@mid.deneb.enyo.de> <87oe8cz25n.fsf@mid.deneb.enyo.de> Subject: Re: Composing tasks and protected objects Date: Sat, 6 Aug 2005 20:27:01 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4952.2800 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4952.2800 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-kmL7P22A06SCoGKm9w3mLiqhx+QEqBeBB3NycolHTto3mSdI34rc1S3k1hxL7EUaKOtjRpNj902Z9EE!5S2zjsU+1gHJBQNM30mvg39DjRPNdGIkm43DjUcnHIJmfQSZ767ekyoxFwzKAdtYatefsYommFIk X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.lang.ada:4009 Date: 2005-08-06T20:27:01-05:00 List-Id: "Robert A Duff" wrote in message news:wcchde4dyv4.fsf@shell01.TheWorld.com... > Florian Weimer writes: > > > * Robert A. Duff: > > > The multi-way call feature was rejected primarily due to perceived > > > difficulty of implementation, or perceived difficulty of *efficient* > > > implementation. I did not agree with that argument. > > > > I could understand that argument if this language feature caused > > uniform overhead on all protected operations, even if it isn't used > > anywhere in the program. Is this really the case? > > I think I could implement multi-ways calls in such a way that there is > zero or near-zero overhead for the currently-allowed features (plain > calls, timed/conditional calls). But I have not proven that by doing > so! The UI teams of the Ada 9X effort were asked to write reports on this feature. None of them came up with an efficient implementation. Their reports are still around somewhere (use the search engine to look in the AdaIC archives - archive.adaic.com). > Inefficiency is never a good reason to leave a feature out of a > language. What matters is distributed overhead (i.e. when a feature > causes inefficiency when you *don't* use it). I think that most of the possible efficient implementations did so by having distributed overhead. But it was a long, long time ago, so I don't remember the details anymore. But I do remember that one of the major issues was that the people who were pushing for the feature were hard-real-time types with strict timing requirements. No one had an implementation that could meet those sorts of requirements (polling seemed to be required). Having a feature that cannot be efficicient enough for the customers is silly. > There's also the issue that the implementation experiments done during > the Ada 9X process were done on *existing* implementations, which were > designed with the requirements of Ada 83 in mind. Adding a feature to > an existing implementation is sometimes a lot harder than implementing > it in a from-scratch design where the designer knows the requirements Possibly. I have to wonder if there wouldn't be too many conflicting requirements to make that possible. The "Bob" language without task entries would clearly make it easier to allow other sorts of things (although I can't quite figure out how it would work). A clear sheet of paper helps things in every dimension -- but that isn't going to happen for Ada, as compatibility is important. Randy.