How to declare a generic formal type "covered" by another?

How to declare a generic formal type "covered" by another?

[Natasha Kerensikova]

Hello,

this a general question stemmed by a new idea on how to solve the
problem exposed in my previous thread (I wouldn't have started a new
thread if I knew my newsreader well enough to do so).

I'm not good enough with language-lawyer vocabulary (hence the quotes
around "covered" in the subject), so I'll write it mostly in Ada.
Basically I want two generic formal T and S, so that I can write:

   Access_To_T_Value := new S;

I too the verb "cover" from 4.8(3/1) to mean this relationship between S
and T, but I'm not sure how correct it is.

The context would look like that:

   generic
      type T (<>) is limited private;
   package References is

      type Exposed_Type is tagged private;

      generic
         type S is adequately declared;
      function Allocate return Exposed_Type;

   private
      type Internal_Access is access T;
      type Exposed_Type is new Ada.Finalization.Controlled with record
         Value : Internal_Access;
      end record;
   end References;

   package body References is
      function Allocate return Exposed_Type is
      begin
         return (Ada.Finalization.Controlled with
            Value => new S);
      end Allocate;
   end References;


So S would have to be a concrete constrained type, but looking at the
alternatives for "formal_type_definition", I can't see anything that
covers both S being a constrained version of T, and S being a concrete
tagged type belonging to class-wide T.

Is it possible, or am I hitting a limit of Ada generics?



Thanks for your help,
Natasha

Re: How to declare a generic formal type "covered" by another?

[J-P. Rosen]

Le 01/05/2014 08:54, Natasha Kerensikova a écrit :
> Hello,
> 
> this a general question stemmed by a new idea on how to solve the
> problem exposed in my previous thread (I wouldn't have started a new
> thread if I knew my newsreader well enough to do so).
> 
> I'm not good enough with language-lawyer vocabulary (hence the quotes
> around "covered" in the subject), so I'll write it mostly in Ada.
> Basically I want two generic formal T and S, so that I can write:
> 
>    Access_To_T_Value := new S;
> 
> I too the verb "cover" from 4.8(3/1) to mean this relationship between S
> and T, but I'm not sure how correct it is.
> 
> The context would look like that:
> 
>    generic
>       type T (<>) is limited private;
>    package References is
> 
>       type Exposed_Type is tagged private;
> 
>       generic
>          type S is adequately declared;
>       function Allocate return Exposed_Type;
> 
>    private
>       type Internal_Access is access T;
>       type Exposed_Type is new Ada.Finalization.Controlled with record
>          Value : Internal_Access;
>       end record;
>    end References;
> 
>    package body References is
>       function Allocate return Exposed_Type is
>       begin
>          return (Ada.Finalization.Controlled with
>             Value => new S);
>       end Allocate;
>    end References;
> 
> 
> So S would have to be a concrete constrained type, but looking at the
> alternatives for "formal_type_definition", I can't see anything that
> covers both S being a constrained version of T, and S being a concrete
> tagged type belonging to class-wide T.
> 
> Is it possible, or am I hitting a limit of Ada generics?

1) There is nothing here that requires T to be tagged
2) You can say that S must be derived from T:
    type S is new T; (non tagged type)
    type S is new T with private; (tagged type)
3) There is no way to say that S must be constrained, because being
constrained is a matter of subtype, and only types matter for generics.
The best way to constrain an allocator is by providing an initial value,
that you could pass as a parameter to Allocate f.e.
-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: How to declare a generic formal type "covered" by another?

[Natasha Kerensikova]

Hello,

On 2014-05-01, J-P. Rosen <rosen@adalog.fr> wrote:
> Le 01/05/2014 08:54, Natasha Kerensikova a écrit :
>> So S would have to be a concrete constrained type, but looking at the
>> alternatives for "formal_type_definition", I can't see anything that
>> covers both S being a constrained version of T, and S being a concrete
>> tagged type belonging to class-wide T.
>> 
>> Is it possible, or am I hitting a limit of Ada generics?
>
> 1) There is nothing here that requires T to be tagged

Indeed, and I don't want to restrict T to tagged types.

The examples I had in mind are:
  - T is Stream_Element_Array, S is Stream_Element_Array (1 .. 4096)
  - T is Root_Stream_Type'Class, S is a concrete type derived from it

> 2) You can say that S must be derived from T:
>     type S is new T; (non tagged type)
>     type S is new T with private; (tagged type)

It looks like I can't cover both cases in a single declaration, can I?

> 3) There is no way to say that S must be constrained, because being
> constrained is a matter of subtype, and only types matter for generics.

Well maybe the problem here is my limited vocabulary. I used the word
"constrained" there only to mean "Something := new S" or "Variable : S;"
are both valid, i.e. objects of that type can be created without
further information. There must be some way to express that in generics.

> The best way to constrain an allocator is by providing an initial value,
> that you could pass as a parameter to Allocate f.e.

That's the solution I have been running with, but yeasterday I hit a
problem with T being Stream_Element_Array and S being
Stream_Element_Array (1 .. 2**29): the intermediate copy and the
allocator result don't fit both in memory, and the program is OOM
killed.

The only solution I found where a limited discriminated record to hold
the Stream_Element_Array, but that's an invasive changed, and somehow
having the allocator run before filling its contents, which means either
exposing the internal access type (so that a client function can call
the allocator and return the access), or providing a generic function
like in the OP (or some other solution I'm unable to come up with).



Thanks for your help,
Natasha

Re: How to declare a generic formal type "covered" by another?

[J-P. Rosen]

Le 01/05/2014 09:33, Natasha Kerensikova a écrit :
> The examples I had in mind are:
>   - T is Stream_Element_Array, S is Stream_Element_Array (1 .. 4096)
This is an unconstrained type and a constrained subtype of it.

>   - T is Root_Stream_Type'Class, S is a concrete type derived from it
This is an indefinite type, and a definite type derived from it.

>> 3) There is no way to say that S must be constrained, because being
>> constrained is a matter of subtype, and only types matter for generics.
> 
> Well maybe the problem here is my limited vocabulary. I used the word
> "constrained" there only to mean "Something := new S" or "Variable : S;"
> are both valid, i.e. objects of that type can be created without
> further information.
This is definite vs. indefinite types.

> There must be some way to express that in generics.
An unknown discriminant in a formal, i.e. "(<>)", expresses that the
type may be indefinite.

Now, thinking about it... When you derive a formal from an indefinite
type, it stays indefinite. OTOH, you can derive from a definite type and
give unknown discriminants to make indefinite. Add to that that a type
is considered derived from itself, and the following compiles OK:

procedure Essai is
   generic
      type T is private;
      type S (<>) is new T;
   procedure P;
   procedure P is
      X : T;
   begin
      null;
   end;
   subtype CS is String (1..10);
   procedure Inst is new P (CS, String);
begin
   null;
end Essai;

Close enough to what you wanted?
-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: How to declare a generic formal type "covered" by another?

[Natasha Kerensikova]

On 2014-05-01, J-P. Rosen <rosen@adalog.fr> wrote:
> Le 01/05/2014 09:33, Natasha Kerensikova a écrit :
>> The examples I had in mind are:
>>   - T is Stream_Element_Array, S is Stream_Element_Array (1 .. 4096)
> This is an unconstrained type and a constrained subtype of it.
>
>>   - T is Root_Stream_Type'Class, S is a concrete type derived from it
> This is an indefinite type, and a definite type derived from it.

So it seems they are indeed deeply different. Is there really no way to
describe both situations with the same words?

If I understand correctly your answer below, in both cases T is
indefinite while S is definite, right?

Also if infer correctly the vocabulary from 4.8(3/3), in both cases T
covers S, right?

If both are right, then the correct wording for my initial question
would be "How to declare a generic formal definite type covered by a
given format indefinite type?"

>>> 3) There is no way to say that S must be constrained, because being
>>> constrained is a matter of subtype, and only types matter for generics.
>> 
>> Well maybe the problem here is my limited vocabulary. I used the word
>> "constrained" there only to mean "Something := new S" or "Variable : S;"
>> are both valid, i.e. objects of that type can be created without
>> further information.
> This is definite vs. indefinite types.

OK, thanks

>> There must be some way to express that in generics.
> An unknown discriminant in a formal, i.e. "(<>)", expresses that the
> type may be indefinite.
>
> Now, thinking about it... When you derive a formal from an indefinite
> type, it stays indefinite. OTOH, you can derive from a definite type and
> give unknown discriminants to make indefinite. Add to that that a type
> is considered derived from itself, and the following compiles OK:
>
> procedure Essai is
>    [...]
> end Essai;
>
> Close enough to what you wanted?

Unfortunately not, since I need the covering indefinite type on a
shallower accessibility level than the covered definite type, since the
latter is only used to create reference to the former and those
references are used everywhere else.


Thanks for your help,
Natasha

Re: How to declare a generic formal type "covered" by another?

[Jeffrey Carter]

On 05/01/2014 12:33 AM, Natasha Kerensikova wrote:
>
> Well maybe the problem here is my limited vocabulary. I used the word
> "constrained" there only to mean "Something := new S" or "Variable : S;"
> are both valid, i.e. objects of that type can be created without
> further information. There must be some way to express that in generics.

As Rosen has pointed out, this is the definite/indefinite idea, expressed in 
generic formals as lacking/having unknown discriminants ["(<>)"].

Most definite subtypes are constrained, and most indefinite, unconstrained, but 
that's not always the case. Consider

subtype VSI is Integer range 0 .. 255;

type VS (Length : VSI := 0) is record
    Value : String (1 .. Length);
end record;

VS is definite, because you can say

S : VS;

but it's also unconstrained, because you can change the discriminant:

S := (Length => 1, Value => "A");
S := (Length => 2, Value => "Hi");

For your uses, perhaps you should consider something like

generic -- GP
    type T (<>) is limited private;
package GP is
    type T_Access is access all T;

    type Ref is private;

    generic -- F
       with function Allocate return T_Access;
    function Allocate return Ref;

    ...
end GP;

Most smart-pointer packages expose the access type; see, for example,

http://www.oopweb.com/Ada/Documents/AdaLinux/Volume/18.html
http://www.adacore.com/adaanswers/gems/gem-97-reference-counting-in-ada-part-1/

HTH.

-- 
Jeff Carter
"C++ is like jamming a helicopter inside a Miata
and expecting some sort of improvement."
Drew Olbrich
51

Re: How to declare a generic formal type "covered" by another?

[AdaMagica]

> Most smart-pointer packages expose the access type; see, for example,
>
> http://www.oopweb.com/Ada/Documents/AdaLinux/Volume/18.html
> http://www.adacore.com/adaanswers/gems/gem-97-reference-counting-in-ada-part-1/

But exposing the access type is bad since pointes may easily outlive the object they point to.

Let Get return the access value of the smart pointer P and let P be the only pointer to the object accessed. Let Q be another smart pointer.

  declare
    Obj: access Client_Data'Class := Get (P);
  begin
    My_Data (Obj.all).I := 2012;  -- No problem.
    P := Q;                       -- Frees the original object,
                                  -- because the reference count
                                  -- is zero after this operation.
    My_Data (Obj.all).I := 95;    -- Oops - writing freed memory!
  end;

See also:

http://www.adacore.com/adaanswers/gems/gem-107-preventing-deallocation-for-reference-counted-types/

Re: How to declare a generic formal type "covered" by another?

[Natasha Kerensikova]

On 2014-05-02, AdaMagica <christ-usch.grein@t-online.de> wrote:
>> Most smart-pointer packages expose the access type; see, for example,
>>
>> http://www.oopweb.com/Ada/Documents/AdaLinux/Volume/18.html
>> http://www.adacore.com/adaanswers/gems/gem-97-reference-counting-in-ada-part-1/
>
> But exposing the access type is bad since pointes may easily outlive the object they point to.
>
> Let Get return the access value of the smart pointer P and let P be the only pointer to the object accessed. Let Q be another smart pointer.
>
>   declare
>     Obj: access Client_Data'Class := Get (P);
>   begin
>     My_Data (Obj.all).I := 2012;  -- No problem.
>     P := Q;                       -- Frees the original object,
>                                   -- because the reference count
>                                   -- is zero after this operation.
>     My_Data (Obj.all).I := 95;    -- Oops - writing freed memory!
>   end;
>
> See also:
>
> http://www.adacore.com/adaanswers/gems/gem-107-preventing-deallocation-for-reference-counted-types/

I have already read that gem, and used that mechanism in my generic
package.

Your text here show how exposing access *values* is bad, which I already
guessed, but it says nothing about the risks of exposing only the
internal access *type*, and involving access values only as input from
client, never to be seen again.

The only risk I identified in such a case is if the client stores an
access value it has provided to the reference-counting and subsequently
uses it.

Are there any other risk? Is there a way to mitigate them?

Re: How to declare a generic formal type "covered" by another?

[Jeffrey Carter]

On 05/02/2014 12:58 AM, AdaMagica wrote:
>> Most smart-pointer packages expose the access type; see, for example,
>>
>> http://www.oopweb.com/Ada/Documents/AdaLinux/Volume/18.html
>> http://www.adacore.com/adaanswers/gems/gem-97-reference-counting-in-ada-part-1/
>
> But exposing the access type is bad since pointes may easily outlive the object they point to.

The point is not that it's good, but that it appears to be necessary to get 
around the kind of problems the OP is dealing with.

One can create a safe-pointer package that does not expose an access type (see 
the PragmAda Reusable Components for an example), but the result tends to be 
restricted to pointers to definite, non-limited types.

-- 
Jeff Carter
"I was hobbling along, minding my own business, all of a
sudden, up he comes, cures me! One minute I'm a leper with
a trade, next minute my livelihood's gone! Not so much as a
'by your leave!' You're cured, mate. Bloody do-gooder!"
Monty Python's Life of Brian
76

Re: How to declare a generic formal type "covered" by another?

[Dmitry A. Kazakov]

On Fri, 02 May 2014 08:12:01 -0700, Jeffrey Carter wrote:

> One can create a safe-pointer package that does not expose an access type (see 
> the PragmAda Reusable Components for an example), but the result tends to be 
> restricted to pointers to definite, non-limited types.

Safe-pointers do make much sense only with definite and non-limited types.

I pass the pointer type to the package of safe pointers. It also gives an
opportunity to have it pool-specific, when necessary. Yes, the object is
allocated on the client side, e.g.

   Handle.Set (new Object (...constraints...)); -- [*]

with Ada 2005 one could hide passed type returning anonymous access and
using limited return constructing function. Though, as experience shows, it
does not work well, especially the latter.

----
* This is a simplification, of course. If the object cannot be fully
initialized per Initialize. It looks like:

   declare
      Ptr : Object_Ptr := new Object (...);
      Thing : Object'Class renames Ptr.all;
   begin
      Handle.Set (Ptr);
      ... -- Initialize Thing
   end;

I wished Ada had a syntax to access allocated objects through class-wide
pointers. Something like:

   ... new X : Object (...) ...  do
       -- In this scope X refers to the allocated Object
   end new;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How to declare a generic formal type "covered" by another?

[AdaMagica]

On Friday, May 2, 2014 5:12:01 PM UTC+2, Jeffrey Carter wrote:
> One can create a safe-pointer package that does not expose an access type (see 
> the PragmAda Reusable Components for an example), but the result tends to be 
> restricted to pointers to definite, non-limited types.

Shameless plug: I do not see any problems with my implementation for indefinite types:
http://www.christ-usch-grein.homepage.t-online.de/Ada/Smart_Pointers.html

I didn't consider limited types, though.

Re: How to declare a generic formal type "covered" by another?

[Georg Bauhaus]

On 01/05/14 08:54, Natasha Kerensikova wrote:
> Is it possible, or am I hitting a limit of Ada generics?

For what it's worth, the generic is requesting a formal
type TF, but not TS's "construction facilities".  To assume,
then, that the generic should be able to properly construe
objects of type TF seems misguided. (The in-place construction
cannot incidentally "rectify" the structure of the solution,
I think. The split remains.)

Approaching the subject of opaque automatic memory management
is ambitious, in particular if using the same approach for
different kinds of type with the help of a generic: an "adequately
declared" formal of Allocate is by its nature a client-side thing
here, it cannot be provided by the generic, I think.

Since your specific problems seem to be about the two kinds of
type Storage_Element_Array and Root_Stream_Type'Class only,
I wonder if you could just address these, more specifically?

Re: How to declare a generic formal type "covered" by another?

[Georg Bauhaus]

On 01/05/14 08:54, Natasha Kerensikova wrote:
> Is it possible, or am I hitting a limit of Ada generics?


For what it's worth, the generic is requesting a formal
type T, but not T's "construction facilities".  To assume,
then, that the generic should be able to properly construe
objects of type TF seems misguided. (The in-place construction
cannot incidentally "rectify" the structure of the solution,
I think. The split remains.)

Approaching the subject of opaque automatic memory management
is ambitious, in particular if using the same approach for
different kinds of type with the help of a generic: an "adequately
declared" formal of Allocate is by its nature a client-side thing
here, it cannot be provided by the generic, I think.

Since your specific problems seem to be about the two kinds of
type Storage_Element_Array and Root_Stream_Type'Class only,
I wonder if you could just address these, more specifically?

Re: How to declare a generic formal type "covered" by another?

[Georg Bauhaus]

On 01/05/14 08:54, Natasha Kerensikova wrote:
> Is it possible, or am I hitting a limit of Ada generics?

For what it's worth, the generic is requesting a formal
type TF, but not TS's "construction facilities".  To assume,
then, that the generic should be able to properly construe
objects of type T seems misguided. (The in-place construction
cannot incidentally "rectify" the structure of the solution,
I think. The split remains.)

Approaching the subject of opaque automatic memory management
is ambitious, in particular if using the same approach for
different kinds of type with the help of a generic: an "adequately
declared" formal of Allocate is by its nature a client-side thing
here, it cannot be provided by the generic, I think.

Since your specific problems seem to be about the two kinds of
type Storage_Element_Array and Root_Stream_Type'Class only,
I wonder if you could just address these, more specifically?

Re: How to declare a generic formal type "covered" by another?

[Georg Bauhaus]

On 01/05/14 08:54, Natasha Kerensikova wrote:
> Is it possible, or am I hitting a limit of Ada generics?

For what it's worth, the generic is requesting a formal
type T, but not T's "construction facilities".  To assume,
then, that the generic should be able to properly construe
objects of type T seems misguided. (The in-place construction
cannot incidentally "rectify" the structure of the solution,
I think. The split remains.)

Approaching the subject of opaque automatic memory management
is ambitious, in particular if using the same approach for
different kinds of type with the help of a generic: an "adequately
declared" formal of Allocate is by its nature a client-side thing
here, it cannot be provided by the generic, I think.

Since your specific problems seem to be about the two kinds of
type Storage_Element_Array and Root_Stream_Type'Class only,
I wonder if you could just address these, more specifically?

Re: How to declare a generic formal type "covered" by another?

[Natasha Kerensikova]

On 2014-05-01, Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> wrote:
> On 01/05/14 08:54, Natasha Kerensikova wrote:
>> Is it possible, or am I hitting a limit of Ada generics?
>
> For what it's worth, the generic is requesting a formal
> type T, but not T's "construction facilities".  To assume,
> then, that the generic should be able to properly construe
> objects of type T seems misguided. (The in-place construction
> cannot incidentally "rectify" the structure of the solution,
> I think. The split remains.)
>
> Approaching the subject of opaque automatic memory management
> is ambitious, in particular if using the same approach for
> different kinds of type with the help of a generic: an "adequately
> declared" formal of Allocate is by its nature a client-side thing
> here, it cannot be provided by the generic, I think.

Ideally, the client builds an object, which is held by the generic
package until it's no longer used. Initialization is necessarily split
between both worlds, since the client must provide the constraints and
the values, while the actual storage belongs to the realm of the generic
package.

As I wrote in the other thread, I have a working solution by shifting
the allocation to the client, and having the reference-construction
subprogram use an access value provided by the client.
I'm only trying to avoid this solution because I don't understand the
abstraction-breach risks of making the access type public.

And all this is still in Ada 2005. Ada 2012 adding subpool specification
to allocators raises the question of whether subpool specification
should be part of the client or of the generic package, and I have no
clue of which is best, or which compromises are involved in both
possibilities.

> Since your specific problems seem to be about the two kinds of
> type Storage_Element_Array and Root_Stream_Type'Class only,
> I wonder if you could just address these, more specifically?

Actually I use the generic package with a wide variety of types, and I
already have a quite a bit of code depending on its current form.

I've referred to these two examples because they are the simplest while
covering all my use cases, so that any solution that work on both
examples is very likely to work for all my needs.


Thanks for your help,
Natasha