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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.43.84.198 with SMTP id al6mr8060625icc.34.1418765696833; Tue, 16 Dec 2014 13:34:56 -0800 (PST) X-Received: by 10.140.16.55 with SMTP id 52mr36340qga.31.1418765696797; Tue, 16 Dec 2014 13:34:56 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!h15no23384524igd.0!news-out.google.com!r1ni57qat.1!nntp.google.com!s7no8199980qap.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 16 Dec 2014 13:34:56 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=206.53.78.59; posting-account=ShYTIAoAAABytvcS76ZrG9GdaV-nXYKy NNTP-Posting-Host: 206.53.78.59 References: <4f547857-ea9e-4baf-a705-911fbf9c633d@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <72048e0e-164a-4dce-8818-69454011a618@googlegroups.com> Subject: Re: Access parameters and accessibility From: sbelmont700@gmail.com Injection-Date: Tue, 16 Dec 2014 21:34:56 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:24061 Date: 2014-12-16T13:34:56-08:00 List-Id: On Tuesday, December 16, 2014 8:57:50 AM UTC-5, Michael B. wrote: >=20 > I tried to find the paper you mentioned. But the only source I found is= =20 > the ACM website where I can buy it. Is this text somewhere publicly=20 > available? >=20 I have a copy of the paper around, if you are that into things, but it's ce= rtainly not a casual read, nor does it really appeal to anyone except for t= he phony-tough or crazy-brave. In any case, to go into a little more detai= l, the whole model is based on the idea of comparing the relative 'depths' = (i.e. source code nesting), but that's a messy proposition because the dept= h is dynamic. The relative example is as follows: procedure Example6 is =20 type T is ...; =20 procedure P1(XP1 : access T) is type A is access T; Ptr: A :=3D null; =20 procedure P2(XP2: access T) is begin Ptr :=3D A(XP2); end P2; =20 begin P2(XP1); end P1; =20 X : aliased T; begin declare Y : aliased T: begin declare Z : aliased T; begin P1(X'Access); =20 P1(Y'Access); P1(Z'Access); -- pass or fail? end; end; end Example6; In this example, note that all the objects X, Y and Z are all longer lived = than type A, which conceptually only exists for the duration that P1 is exe= cuting, so each conversion should pass. But also note that the "depths" of= the objects that P1 (and consequently, P2) is getting are becoming progres= sively "deeper" as each declarative block gets elaborated. The question th= en becomes what "depths" should the conversion in P2 be checking? If the n= ormal block-nesting level was used (where X is 1, Y is 2, and Z is 3), then= Z would become evaluated as "too deep", since A would be 2 and Z would be = 3, and you would get an erroneous program error doing the conversion. So you can tweak things to say that in these special cases, you pass the *l= ower* of either the actual object depth or P1 itself. So, in this case, no= w Z will pass the dynamic check since instead of getting the depth of Z, P2= gets the depth of P1 (since 1<3). Now you can nest the declarative blocks= a billion levels deep, and the proposed model still adheres to the LRM. Again, it's important to stress that this is just one special case of one s= pecial part of just one possible implementation of one special-case languag= e feature from twenty years ago, and that none of this should weigh heavily= on your mind when learning or using Ada. =20 -sb