re: Nasty Expanded Names Semantics

[rracine@AJPO.SEI.CMU.EDU]

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