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