[Q] non-limited record and "self-pointer"

[Q] non-limited record and "self-pointer"

[Georg Bauhaus]

Is there any circumstance which might allow the following type
(Read_Only_Set) to be o.K.? The record isn't limited, the compiler
does not complain unless I remove the "container" component. It says
then that for correct instantiation the current instance must be a
limited type. Which has some words that I had thought it could say.
(Though, is there an instance that can be a type?)


   type Read_Only_Set is tagged private;

   type Set_Ptr is access constant Read_Only_Set;


private
   package Implementation is
      new Charles.Sets.Sorted.Unbounded(Element);
        -- (Element is generic formal private)

   type Read_Only_Set is tagged    <-- not limited
      record
         container: Implementation.Container_Type;

        -- line 102:
         self: Set_Ptr := Read_Only_Set'unchecked_access;  <-- no complaints
         --  used in value_in_place

      end record;

with "container: ..." removed:
Compiling: sets_test.adb (source file time stamp: 2004-02-08 20:45:06)

==============Error messages for source file: ../tests/test-containers.ads
    22.    package T_sets is new sets(T);
           |
        >>> instantiation error at sets.ads:102
        >>> current instance must be a limited type

(T is not limited)



TIA, georg

Re: [Q] non-limited record and "self-pointer"

[Stephen Leake]

Georg Bauhaus <sb463ba@uni-duisburg.de> writes:

> Is there any circumstance which might allow the following type
> (Read_Only_Set) to be o.K.? The record isn't limited, the compiler
> does not complain unless I remove the "container" component. It says
> then that for correct instantiation the current instance must be a
> limited type. Which has some words that I had thought it could say.

I'm not clear what you are asking. 

The prefix of 'Access or 'Unchecked_Access must be aliased. ARM 3.10
(9) says the current instance of a limited type is aliased. Sor for
'Unchecked_Access to be legal, Read_Only_Set must be limited.

Apparently the compiler thinks including teh Container component makes
Read_Only_Set limited. But in the version of Charles I have,
Charles.Sets.Sorted.Unbounded.Container_Type is not limited. So that's
a puzzle. What does your version of Charles say?

>    package Implementation is
>       new Charles.Sets.Sorted.Unbounded(Element);
>         -- (Element is generic formal private)
> 
>    type Read_Only_Set is tagged    <-- not limited
>       record
>          container: Implementation.Container_Type;
> 
>         -- line 102:
>          self: Set_Ptr := Read_Only_Set'unchecked_access;  <-- no complaints
>          --  used in value_in_place


-- 
-- Stephe

Re: [Q] non-limited record and "self-pointer"

[Georg Bauhaus]

Stephen Leake <stephen_leake@acm.org> wrote:
: I'm not clear what you are asking. 

I'm puzzled too by the compiler's silence, because AFAIK a record cannot
silently become limited?
 
: The prefix of 'Access or 'Unchecked_Access must be aliased. ARM 3.10
: (9) says the current instance of a limited type is aliased. Sor for
: 'Unchecked_Access to be legal, Read_Only_Set must be limited.

Introducing a limited ad hoc type and including a component
of this type in the record will indeed make the compiler say "must
be limited".

: Apparently the compiler thinks including teh Container component makes
: Read_Only_Set limited.

Hmmm. In order to check this I have tried assignment, it is there,
according to the compiler, as in

with some_sets;  use some_sets;   -- is new Sets(Integer, ...)
procedure ad_hoc is

   the_set: Read_Only_Set;
   another_set: Read_Only_Set;
begin
   another_set := the_set;
end ad_hoc;


: But in the version of Charles I have,
: Charles.Sets.Sorted.Unbounded.Container_Type is not limited. So that's
: a puzzle. What does your version of Charles say?

20030813 mostly. The only trace of a limited type I could find is
a Key_Type formal in nested generic packages in red_black_trees
and in the used sets package.



thanks,
georg
 

Re: [Q] non-limited record and "self-pointer"

[Stephen Leake]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Stephen Leake <stephen_leake@acm.org> wrote:
> : I'm not clear what you are asking. 
> 
> I'm puzzled too by the compiler's silence, because AFAIK a record cannot
> silently become limited?

Post a complete, compilable example, and I'll take another look at it.

> 

-- 
-- Stephe

Re: [Q] non-limited record and "self-pointer"

[Georg Bauhaus]

Stephen Leake <stephen_leake@acm.org> wrote:
: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
: 
:> Stephen Leake <stephen_leake@acm.org> wrote:
:> : I'm not clear what you are asking. 
:> 
:> I'm puzzled too by the compiler's silence, because AFAIK a record cannot
:> silently become limited?
: 
: Post a complete, compilable example, and I'll take another look at it.

There it is, ObjectAda 7.2.2 does not complain either.


with sets;
package some_sets is new sets(Integer);

with some_sets;  use some_sets;
procedure simple_test is
   s1, s2: Read_Only_Set;
   s: Set;
   p: Set_Ptr;
begin
   s1 := s2;
   p := value_in_place(s);
end simple_test;



with Charles.Sets.Sorted.Unbounded;
generic
   type Element is private;

   with function "<"(L, R: Element) return Boolean is <>;
   with function "="(L, R: Element) return Boolean is <>;

   --with function wide_image(e: Element) return Wide_String is <>;
package Sets is



   type Read_Only_Set is tagged private;


   --  Modifiable Sets

   type Set is new Read_Only_Set with private;


   type Set_Ptr is access all Read_Only_Set'class;

   function value_in_place(container: Set) return Set_Ptr;
   --  a pointer to container (avoids copying)


private
   package Implementation is
      new Charles.Sets.Sorted.Unbounded(Element);

   type Read_Only_Set is tagged
      record
         container: Implementation.Container_Type;

         self: Set_Ptr := Read_Only_Set'unchecked_access;
         --  used in value_in_place

      end record;

   type Set is new Read_Only_Set with record
      frozen: Boolean := true;
   end record;


end Sets;



package body Sets is

   use Implementation;



   -- ----------------
   -- value_in_place
   -- ----------------
   --  every object of type Set points to itself

   function value_in_place(container: Set) return Set_Ptr is
      -- cont: aliased Set;
      -- for cont'address use container'address;
      -- cannot overlay controlled
      -- package set_ptrs is new System.Address_to_Access_conversions(Set);
   begin
      return container.self;
   end value_in_place;



end Sets;

Re: [Q] non-limited record and "self-pointer"

[Dan Eilers]

Here's a cut-down example:

with Ada.Finalization;
package Unbounded is

   type Container_Type is new Ada.Finalization.Controlled 
      with null record;

end Unbounded;


with Unbounded;
package Sets is

   type Read_Only_Set is tagged private;

   type Set_Ptr is access all Read_Only_Set'class;

private

   type Read_Only_Set is tagged
      record
         container: Unbounded.Container_Type;
         self: Set_Ptr := Read_Only_Set'unchecked_access;
      end record;

end Sets;

	-- Dan Eilers

Re: [Q] non-limited record and "self-pointer"

[Stephen Leake]

dan@irvine.com (Dan Eilers) writes:

> with Ada.Finalization;
> package Unbounded is
> 
>    type Container_Type is new Ada.Finalization.Controlled 
>       with null record;
> 
> end Unbounded;
> 
> 
> with Unbounded;
> package Sets is
> 
>    type Read_Only_Set is tagged private;
> 
>    type Set_Ptr is access all Read_Only_Set'class;
> 
> private
> 
>    type Read_Only_Set is tagged
>       record
>          container: Unbounded.Container_Type;
>          self: Set_Ptr := Read_Only_Set'unchecked_access;
>       end record;
> 
> end Sets;

This definitely looks like a compiler bug. Perhaps because Container
is tagged, Read_Only_Set is being labeled "aliased". But that's not in
the ARM.

-- 
-- Stephe

Re: [Q] non-limited record and "self-pointer"

[Robert I. Eachus]

Stephen Leake wrote:


> This definitely looks like a compiler bug. Perhaps because Container
> is tagged, Read_Only_Set is being labeled "aliased". But that's not in
> the ARM.

I don't see that.  3.10(9) says in part: "Finally, the current instance 
of a limited type, and a formal parameter or generic formal object of a 
tagged type are defined to be aliased."

Note that this applies to parameters, not to objects.  So a type 
definition can include a self reference as in the example, and the 
compiler should only object if you declare an object of the type that is 
not aliased.

However there is a big bug here that should be fixed in Ada 0Y.  If 
parameters of a type are aliased, it doesn't make any sense to require 
users to declare objects of the type as explicitly aliased.  But that's 
the way it currently is, and I have some code now that has aliased in 
object declarations all over the place.  I also feel the same way about 
objects with aliased components.  Is there really any benefit to not 
making objects of a type with aliased components always aliased?


-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: [Q] non-limited record and "self-pointer"

[Georg Bauhaus]

Robert I. Eachus <rieachus@comcast.net> wrote:
: Stephen Leake wrote:
: 
: 
:> This definitely looks like a compiler bug. Perhaps because Container
:> is tagged, Read_Only_Set is being labeled "aliased". But that's not in
:> the ARM.
: 
: I don't see that.  3.10(9) says in part: "Finally, the current instance 
: of a limited type, and a formal parameter or generic formal object of a 
: tagged type are defined to be aliased."

Thanks for the answers. Still I wonder what is going on here. In Dan
Eilers' example there is no parameter.  It is just the Controlled
component which seems to make the compiler happy. If the "container"
component is replaced with a component of some tagged type other
than one derived from Controlled, the self reference is not allowed,
according to the compiler.

Am I missing something?


-- Georg

Re: [Q] non-limited record and "self-pointer"

[Randy Brukardt]

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:c0dt1k$s3t$1@a1-hrz.uni-duisburg.de...
> Thanks for the answers. Still I wonder what is going on here. In Dan
> Eilers' example there is no parameter.  It is just the Controlled
> component which seems to make the compiler happy. If the "container"
> component is replaced with a component of some tagged type other
> than one derived from Controlled, the self reference is not allowed,
> according to the compiler.
>
> Am I missing something?

I don't think so. I don't think Dan Eilers example is legal; the prefix of
'Access doesn't meet any of the items in the list for 'automatic aliasing'.
But I could be wrong...

                  Randy.

Re: [Q] non-limited record and "self-pointer"

[Robert I. Eachus]

Georg Bauhaus wrote:

> Robert I. Eachus <rieachus@comcast.net> wrote:
> : Stephen Leake wrote:
> : 
> : 
> :> This definitely looks like a compiler bug. Perhaps because Container
> :> is tagged, Read_Only_Set is being labeled "aliased". But that's not in
> :> the ARM.
> : 
> : I don't see that.  3.10(9) says in part: "Finally, the current instance 
> : of a limited type, and a formal parameter or generic formal object of a 
> : tagged type are defined to be aliased."
> 
> Thanks for the answers. Still I wonder what is going on here. In Dan
> Eilers' example there is no parameter.  It is just the Controlled
> component which seems to make the compiler happy. If the "container"
> component is replaced with a component of some tagged type other
> than one derived from Controlled, the self reference is not allowed,
> according to the compiler.
> 
> Am I missing something?

Um, aliased should be an attribute of (sub)types and objects.  But 
current language definition gets it wrong. (Maybe I should say 
incompletely right? ;-)

In this case, there is an implementation freedom with Controlled that is 
totally bogus.  Implementations may (and as far as I know all 
implementations do) require that objects or components of a controlled 
type are aligned so that they may be aliased. (Can be designated by an 
access object.)  The problem is that the VIEW of that type may or may 
not be aliased.  Hmmm.  That is really obtuse, as far as this example is 
concerned.  Assume that the compiler has an alignment clause for 
Controlled that causes all controlled objects to be CAPABLE of being 
aliased.  Since the possible alignments for Read_Only_Set are a subset 
of the alignments for Controlled, there will usually be no problems 
dectected for the type declaration.

However, as I understand Dan Eilers example, any objects of 
Read_Only_Set would either have to be explicitly aliased, or explicitly 
initialized.  But since aliased is a property of objects in general not 
types, the compiler has to wait until a Read_Only_Set object is declared 
to see if the initial value expression is ever used on a non-aliased 
view of an object.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: [Q] non-limited record and "self-pointer"

[Georg Bauhaus]

Robert I. Eachus <rieachus@comcast.net> wrote:
: 
: In this case, there is an implementation freedom with Controlled that is 
: totally bogus.

I guess then that I should not define a type and operations
so that they work if an implementation chooses to let this work.
That means I might have to revert to limited types, with
all the consequences...


-- Georg

Re: [Q] non-limited record and "self-pointer"

[Robert I. Eachus]

Georg Bauhaus wrote:

> Robert I. Eachus <rieachus@comcast.net> wrote:
> : 
> : In this case, there is an implementation freedom with Controlled that is 
> : totally bogus.
> 
> I guess then that I should not define a type and operations
> so that they work if an implementation chooses to let this work.
> That means I might have to revert to limited types, with
> all the consequences...

Or wait for Ada 0Y to be further along before you do any ports.  I 
thought there waa an AI that fixed this problem, but I can't find it. 
(Stay tuned.)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: [Q] non-limited record and "self-pointer"

[Robert I. Eachus]

Robert I. Eachus wrote:

> Or wait for Ada 0Y to be further along before you do any ports.  I 
> thought there waa an AI that fixed this problem, but I can't find it. 
> (Stay tuned.)

There is an AI, AI-304, Reemergence of "=" in generics.  (Tucker Taft 
remembered the title, which is actually meaningful.)  Adam Beneschan 
pointed out that AI-225 which was passed in 2002, but categorized as an 
Ammendment AI.  If AI-304 does get into the Ammendment, both the problem 
and the fix will be "in there."

Hmmm.  I had better make that clearer.  Right now compilers can 
interpret things either way, and some allow this, others don't.  In Ada 
200Y, the compilers that allow it should be fixed so that all compilers 
get the same answer.  What I am hoping is that they will be doubly 
fixed.  Once to disallow some cases that are currently not accepted by 
all compilers, and once to allow a different set of cases to be allowed 
by all compilers.  In the best of all possible worlds, your code would 
fall in the latter set.  But I suspect that you will need to add the 
word aliased to the type declaration--in one place--to make your code 
work in Ada 0Y.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: [Q] non-limited record and "self-pointer"

[Adam Beneschan]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<jvqdnTsRj_S6G7XdRVn-sQ@comcast.com>...
> Stephen Leake wrote:
> 
> 
> > This definitely looks like a compiler bug. Perhaps because Container
> > is tagged, Read_Only_Set is being labeled "aliased". But that's not in
> > the ARM.
> 
> I don't see that.  3.10(9) says in part: "Finally, the current instance 
> of a limited type, and a formal parameter or generic formal object of a 
> tagged type are defined to be aliased."
> 
> Note that this applies to parameters, not to objects.  So a type 
> definition can include a self reference as in the example, and the 
> compiler should only object if you declare an object of the type that is 
> not aliased.

However, the AARM says:

   "Ramification: The current instance of a nonlimited type is not
aliased."

It doesn't say "The current instance of a nonlimited type is either
aliased or not aliased depending on whether an object of that type is
aliased or not".  So that would indicate to me, at least according to
the AARM (which I realize is not part of the standard but may indicate
how the standard is intended to be interpreted, maybe), that the type
declaration is illegal.

See also AI95-00225 (Amendment 200Y), which uses the term "if and only
if" to make it clear that the current instance is not aliased and thus
'Access and 'Unchecked_Access cannot be used on it.

                                 -- Adam

Re: [Q] non-limited record and "self-pointer"

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message
news:b4682ab7.0402131624.45fbc352@posting.google.com...
...
> See also AI95-00225 (Amendment 200Y), which uses the term "if and only
> if" to make it clear that the current instance is not aliased and thus
> 'Access and 'Unchecked_Access cannot be used on it.

AI-225 is fairly clear that the Ada 95 rule is screwy, and should be fixed.
And the fix is to make the use of 'Access illegal unless the type is
explicitly declared to be limited. The AI goes on to say that the current
wording allows it to work sometimes, but the result is nonsense, because
compilers are allowed to make copies of the object, in which the 'Access
value would point to the wrong place.

It's also interesting that AI came about because Tucker posted a note about
a bug found in their compiler by a posting on comp.lang.ada. So it seems
that we've had this discussion before here, and that not all implementers
got the note. :-)

                    Randy.