Re: Building limited types through nested creator functions

[Adam Beneschan <adam@irvine.com>]

On Feb 5, 2:03 pm, Simon Belmont <sbelmont...@gmail.com> wrote:
> Hi,
>
> Consider two limited record types, inner and outer, with the former
> nested inside the latter.  If the records are public, then code can
> initialize the outer by specifying an aggregate for the inner, as in:
>
> type Inner is limited
>   record
>     e : Integer;
>   end record;
>
> type Outer is limited
>   record
>     i : Inner;
>   end record;
>
> o : Outer := Outer'(i => Inner'(e => 42));
>
> However, if types are made private, suitable functions must be
> provided to make the appropriate objects.  If just Inner is private,
> then this can be done (assuming simple creator functions that just
> create the objects with the given values):
>
> o : Outer := Outer'(i => Make_Inner(arg => 42));
>
> but if both are private, then the following:
>
> o : Outer := Make_Outer (arg => Make_Inner(arg => 42));
>
> ends up being illegal, because in the code:
>
> function Make_Outer (arg : Inner) return Outer is
> begin
>   return Outer'(i => arg);
> end Make_Outer
>
> would end up trying to copy a limited type.  For the cases in which an
> existing object is passed in, this would be the appropriate action,
> but for cases where the object is built-in-place into the argument,
> clearly the intended behavior is to build it in place to the resultant
> object.  It's easy enough to use an access value, but as unnecessary
> use of access values is generally discouraged, I was just curious if
> there was an alternative mechanism to achieve the desired effect.

I think you have to decide: is an "Inner" an actual object that you
want to prevent copying of for some reason, or is it a collection of
components that you want to use to initialize an "Outer"?  Something
seems wrong with your paradigm here.

(1) If an Outer actually contains an Inner, then you're trying to set
things up so that a program that uses this package will create an
Inner, and then create an Outer that contains a copy of the Inner.
But this contradicts the idea that Inner should be a limited type.
Limited types are for objects that you don't want to make copies of.

(2) If you want users of the package to create an Inner, and then
create an Outer that *refers* to that same Inner (without making a
copy), then you shouldn't object to using access types (in the private
part).

(3) If you want the ability for users to create an Outer that contains
some of the interesting data from an Inner, then maybe an Outer
shouldn't be thought of as containing an "Inner" as a component.  In
that case, you may want to declare a new record type Inner_Data that
includes interesting information from an Inner, and make your Outer
contain this as a component instead of Inner.

(4) If you want Outer and/or Inner to refer to objects that can be
copied, they shouldn't be "limited"--and note that for untagged types,
you can declare a type to be limited in the visible part, and
nonlimited in the private part, so that you can do assignments in your
package body, but users of the package still can't make copies.

I don't know which one is the case without knowing more about the
actual application that you're trying to write.  But in any event,
something seems wrong with the design.

                           -- Adam