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!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Composing tasks and protected objects Date: 08 Aug 2005 18:14:19 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <87iryk1eic.fsf@mid.deneb.enyo.de> <87oe88bvse.fsf@mid.deneb.enyo.de> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1123539259 24321 192.74.137.71 (8 Aug 2005 22:14:19 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Mon, 8 Aug 2005 22:14:19 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:4038 Date: 2005-08-08T18:14:19-04:00 List-Id: "Randy Brukardt" writes: > "Florian Weimer" wrote in message > news:87oe88bvse.fsf@mid.deneb.enyo.de... > .... > > This introduces overhead in terms of an additional task, and the > > Forwarder and Server are strongly coupled (unless you manually write > > wrappers, because access-to-entry types are missing). > > Yes, but an implementation of the proposed feature probably would have to > introduce that task anyway. Are we still talking about multi-way calls? I certainly don't believe that their implementation requires the implicit introduction of hidden tasks, or anything near that cost! >... It would end up costing about the same, yet it > would look cheap. That's generally bad language design. Well, I disagree about the cost, but I also disagree with that language design principle -- the principle that says inefficient things should *look* inefficient in the source code. That principle is exactly the *opposite* of what high level languages ought to be about. In most cases, Ada does *not* follow that principle, and that's a Good Thing. In the few cases where Ada does follow it, it's a Bad Thing. Consider: X := Y; If the type is Integer, it takes approximately 1 machine instruction. If the type is array-of-a-million-integers, it takes millions of instructions. If the type is controlled, it invokes Adjust, which could do all kinds of user-defined task locking and heap management. We don't use a different syntax for fast and slow assignments! Surely that's good. (Contrast with C, where the array case uses "memcpy" instead of "=", and the Adjust case requires calling Adjust explicitly.) Another example: array indexing uses the same syntax whether the thing is bit-packed or not. Contrast with C, where the bit-packed case requires explicit shifting and masking. The extra cost of bit-packed array indexing is more apparent from the source code in C, which is certainly an advantage, but it's outweighed by the loss in abstraction. For example, in Ada, you can easily experiment to determine whether bit packing is an efficiency win. An example where Ada *does* follow this misguided principle: unbounded strings are a huge pain to use in Ada. It would be much nicer if they supported array-indexing syntax, slicing, literals, etc. That would hide the inefficiency of these strings. I say, if you want to see efficiency properties clearly in the source code, you must program in assembly. In higher level languages, you lose that capability. You must determine efficiency by measurement, and by experience (knowing which features are efficient in typical implementations). - Bob