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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,ddbf85842f937132,start
X-Google-Attributes: gid103376,public
From: Stanley Allen <sallen@ghg.net>
Subject: Self-referential 'Access
Date: 1998/04/20
Message-ID: <353B4DC4.EB3650F4@ghg.net>#1/1
X-Deja-AN: 345942323
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1998-04-20T00:00:00+00:00
List-Id: <comp.lang.ada>


For the language lawyers:

Below is a library-level package spec that
I have tried to compile with both GNAT (3.10p)
and ObjectAda (7.1) on my Win95/AMD586 box.

------------ cellar.ads -----------
package Cellar is

    type Cell;

    type List is access all Cell;

    type Cell is limited record
        Contents : String (1 .. 10);
        Next_Cell : List := Cell'Access;  --line 9
        Prev_Cell : List := Cell'Access;  --line 10
    end record;

end Cellar;
-----------------------------------

Both compilers claim that the uses of the
'Access attribute are not valid because they
violate the rules concerning depth of
accessability.

GNAT says this:
    cellar.ads:9:29 object has deeper accessibility
    level than access type
    [and the same for line 10]

ObjectAda says:
    cellar.ads: Error: line 9 col 29 LRM:3.10.2(28),
        The prefix to 'ACCESS shall not be statically
        deeper than that of the expected type
    [and the same for line 10]

(Note: I have not attempted to declare a Cell
object in any other unit; the errors are generated
strictly from the compilation of this package spec.)

The rules for "statically deeper" levels are given
under RM95:3.10.2(17).  The only rule that seems
like it might apply here is RM95:3.10.2(21).

So, I have a few questions.

1) Are the compilers in error, or is this code?

2) If this code is in error, is it because of the
   rule at paragraph (21)?

3) If so, does this rule really make sense?
   It does not seem right that these 'Access
   references should be considered "deeper" than
   the access type.

4) Should the rule disallow only non-limited
   records?

Stanley Allen
mailto:sallen@ghg.net