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-Thread: 103376,7769c087a4d30c0e X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news3.google.com!news.glorb.com!blackbush.cw.net!cw.net!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Unchecked_Conversion and task pointer. Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1120751455.846822.141050@z14g2000cwz.googlegroups.com> <1xuh1gs97pwwg$.1v4w9ruw1n2x$.dlg@40tude.net> <1PidncjOa5cWA1DfRVn-1Q@megapath.net> <28m5yx3jhzvu$.16u6va8093srl.dlg@40tude.net> <29tci5buk8ik.12z8wzs6awbnb.dlg@40tude.net> Date: Wed, 13 Jul 2005 10:11:05 +0200 Message-ID: <1r77fcvkjfoqk$.ggysogvluudu.dlg@40tude.net> NNTP-Posting-Date: 13 Jul 2005 10:10:00 MEST NNTP-Posting-Host: 8b1e0ad9.newsread2.arcor-online.net X-Trace: DXC=BlTKMM7enW;^6ZC`4<=9bOTW=MN> X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:3614 Date: 2005-07-13T10:10:00+02:00 List-Id: On Tue, 12 Jul 2005 15:30:08 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:29tci5buk8ik.12z8wzs6awbnb.dlg@40tude.net... >> On Mon, 11 Jul 2005 13:28:42 -0500, Randy Brukardt wrote: >> >>> Well, you can't ignore the prefix (it determines whether it is an internal >>> or external requeue). >> >> This must be fixed anyway. There is no safe way to statically determine if >> a requeue is internal (in Ada 95 it had a quite nasty consequences, like a >> program which legality was dependent on whether at run-time a barrier was >> open or not.) > > This is confused. "Legality" is a compile-time concept; there is no such > thing as legality being determined by something happening at runtime. > Perhaps you meant something about whether an exception was raised, but that > doesn't seem any different than an array bounds check. The problem was, if I remember correctly, that a chain of requeues ending in the starting point could be a bounded error or not depending on the state of barriers. I suppose it is still so in Ada 200Y. >> For class-wide objects the idea of protected actions should be refined: let >> A extend B. Is a protected action on X of A, the same or a different action >> on B(X)? What about B'Class(X), A'Class(X)? Further, for multi-methods, let >> both tagged arguments resolve to the same type tag, but different objects. >> Will it start two actions? > > Ada 200Y doesn't allow extensions of task or protected types, specifically > because the tasking operations don't compose well. Some work will be required, but I cannot see any fundamental reason why tasks and protected objects should not have classes, as well as any other types, BTW. There was a proposal for protected objects: http://www.cs.york.ac.uk/rts/papers/YCS_316_99.html Task entries as primitive operations is more challenging, of course. > You can make a set of > rules, but any that are picked either will violate the expectations of the > base type, or will be too restrictive on the extending type. Type extension is not the only mechanism of subtyping. > Moreover, > however that is done will make the locking behavior of programs much harder > to understand. Keeping all of the locking in one place is much better in > terms of being able to analyze the effects. So your question cannot arise, > because B necessarily is an interface, and interfaces have no "protected > actions". Quite formally: if you can call a procedure as an entry, then either there are entries with no protected actions or each interface procedure has some virtual protected action (that locks nothing.) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de