Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!bbn!uwmcsd1!ig!agate!ucbvax!AJPO.SEI.CMU.EDU!rracine From: rracine@AJPO.SEI.CMU.EDU Newsgroups: comp.lang.ada Subject: re: Nasty Expanded Names Semantics Message-ID: <8806211739.AA00357@ajpo.sei.cmu.edu> Date: 21 Jun 88 17:39:12 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 43 Geoffrey O. Mendal asks a reasonable question about the semantics of naming entries. His code is: procedure Nested_Accepts is task T is entry X (I : in out Integer); entry Y (I : in out Integer); entry Z (I : in out Integer); end T; task body T is begin accept X (I : in out Integer) do accept Y (I : in out Integer) do accept Z (I : in out Integer) do I := X.Y.I; -- 1. I := Z.I; -- 2. I := X.I; -- 3. I := T.Y.I; -- 4. I := Nested_Accepts.T.X.I; -- 5. end Z; end Y; end X; end T; begin null; -- No illegality here! :-) end Nested_Accepts; After reading the section of the LRM in question (4.1.3), I am amazed that either #4 or #5 could be thought to be illegal. Paragraph 17, to me, is simply trying to disallow the index of an entry family. I tried the code on three compilers, and got three different results, including the result I want (only #1 is an error). All of these compilers are the latest versions. DEC Ada has #1, #4 and #5 as errors. Verdix (on VAX, targeted to 68020) has #1 and #5 as errors. Meridian (on IBM PC) has only #1 as error. This is a good candidate for an ACVC test. Roger Racine