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,e9caf8720058dd5e X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!n59g2000hsh.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: embed accept statement in procedures not possible? Date: 9 May 2007 07:56:45 -0700 Organization: http://groups.google.com Message-ID: <1178722605.068961.76180@n59g2000hsh.googlegroups.com> References: <1178291081.936739.131740@c35g2000hsg.googlegroups.com> <1178307901.263809.221480@n76g2000hsh.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1178722605 7391 127.0.0.1 (9 May 2007 14:56:45 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 9 May 2007 14:56:45 +0000 (UTC) In-Reply-To: User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: n59g2000hsh.googlegroups.com; posting-host=66.126.103.122; posting-account=cw1zeQwAAABOY2vF_g6V_9cdsyY_wV9w Xref: g2news1.google.com comp.lang.ada:15676 Date: 2007-05-09T07:56:45-07:00 List-Id: On May 9, 12:12 am, Jean-Pierre Rosen wrote: > Adam Beneschan a =E9crit :> Actually, though, why is a syntactic rule nec= essary (as opposed to a > > run-time check)? > > 1) In general, Ada enforces static checking rather than dynamic > checking, especially when (like here) the problem is really structural > > 2) There would be a distributed cost. Any accept statement would need to > access, at least Current_Task, and (believe it or not) this can be > costly in some environments. I don't think #2 is true. Any ACCEPT statement that is currently legal would not have to perform this check, and the compiler would of course be able to tell statically whether the check would need to be done or not, since that would be just the same check it's performing now to enforce the rule. (And I think there would be cases where a compiler can tell that no check is needed even for an ACCEPT inside a procedure. Off the top of my head, I think this is the case if the task has no nested task types, 'Access is never used on the procedure, and the procedure is never used as a generic actual parameter.) If I'm right and there's no distributed cost, then #1 doesn't provide enough of a reason to disallow such ACCEPTs. There may be other reasons I haven't thought of that would make this a bad idea (perhaps some implementations need the task body to be the top routine on the task's stack when a rendezvous takes place?) or just not worth the effort. In any case, though, I still think your earlier statement, that the rule is "necessary" to make sure that a task can accept only its own entries, is incorrect. And although Stephen gave an example of how some problems can be solved by putting a shared procedure inside an ACCEPT, his example was a fairly simple one that can't always be generalized. Suppose you would really like a procedure that does an ACCEPT somewhere inside a loop; you can't just yank the ACCEPT out of the loop and put it in the main task body without some significant reorganization of the logic. I don't use tasks much at all, so I can't come up with a real-world example where this restriction is an annoyance or a problem, other than the original poster's situation. -- Adam