Re: Allocating "initialized" limited types...

[jsa@alexandria (Jon S Anthony)]

In article <1996Sep4.183415.17277@ocsystems.com> jvl@ocsystems.com (Joel VanLaven) writes:

> Jon S Anthony (jsa@alexandria) wrote:
> 
> : Well, here I'm just in the weeds, having become side tracked by the
> : public/private limited/non-limited tagged type issue.  This really has
> : nothing to do with what I had in mind, which is really captured by the
> : notion of "in place" creation.
> 
>   As I did not know much about limited types, and this seemed so interesting
> and potentially important to me as a new Ada95 programmer, I read up and
> looked around at this.  Here is an interesting take on limited types from
> the Annotated Ada95 Reference Manual <7.5:1a> 
> 
> "The concept of the value of a limited type is difficult to define, since 
> the abstract value of a limited type often extends beyond its physical
> representation.  In some sense, values of a limited type cannot be divorced
> from their object. Th value is the object."

Actually, this supports my notion that the idea of "initialization"
after creation of the limited object (in an allocator in particular)
is not the best way of thinking of it.  The "value is the object" bit
hits this pretty well.  In fact, that is pretty much _exactly_ the
point.  So, since the design team thought the same here, the whole
thing becomes rather mysterious as to why things turned out as they
did.


>   This leads me to think that disallowing any sort of "total"
> initialization makes sense to preserve the powerful abstraction
> involved.

I don't understand what you mean here.  The fact is, you can mung a
limited thing to your heart's content (field by field), you just can't
assign to such an object (and that is indeed a _very_ good thing).
Make it private and no _client_ can mung it either (they can't see the
implementation).


> fine.  The problem is that records are given special meaning and usage for
> tagged types, interfering with the natural nice things that can be done with
> them like aggregate assignment/initialization, etc.

???, you can do this sort of stuff just fine with tagged (record) types.
What do you mean by "interfering"???

    package P is
        type X is tagged record
            i,j,k : integer;
        end record;
        ...
    end P;

    with P;
    procedure My_Proc is
        Obj : P.X := (1,2,3); -- Happy as a clam
        ...
    end My_Proc;


>   In order to extend T to C, define a new record type oh say c_rec like
> type c_rec is record
>   a:t1;
>   b:t2;
> ...
> end reocrd;
> 
> type c is new t with record
>   rec:c_rec;
> end record;
> 
>   This allows you to use the nice aggregate assignment features of Ada 
> without being stuck on the idea of tagged types as records, using:
> obj_ref.rec:=c_rec'(a1,b1,...);

The problem (well, the one at the center of this thread anyway) has
nothing at all to do with tagged types.  It concerns limited types and
"initialized" allocators.  So, presumably T is the _limited_ type that
I originally mentioned (and thus C is limited too).

This hack you give doesn't really work for this problem because at the
end of the day, C still has an implementation which cannot have values
during an allocation:

    cptr := new c'(...); -- still illegal

Now, you can say that this _reduces_ the potential missing field
errors when giving values field by field for multiple new fields
(since you only have "one" new field), but it also requires another
record type whenever you extend and is rather unnatural.

I actually considered this hack, but rejected it because it had all
the original bad aspects plus requiring new types for every extension.
To me, in the particular case in question, the tradeoffs went against
it.  But it is certainly a sensible idea.


>   Using this method as well as the access type conversion you mentioned
> earlieri, possibly isolated into a self-defined "in place" creation
> subprogram  ought to work fairly well.

What do you mean by "self-defined in place creation" subprogram?  The
problem is, the ARM just doesn't define such "in place creation".
But, as I have argued (and as the above AARM quote seems to support)
this was a mistake (at least for limited types).


> The extra record type ought not
> add run-time costs, just like the type conversion.

Ah, so that's what you meant by "extra".  You are correct - no extra
space will be allocated.


> It might not give you be the most natural way to do what you want,
> but then again limited types are severely restricted for good if
> obscure reasons.  Perhaps you'd rather use controlled types...?

For this case, controlled types aren't relevant and if they were, I'd
be using limited_controlled types and be right back in the same boat.
Also, note that limited types can be munged all over as long as you
have access to the full type definition (so that you can see the
fields).  In the case in question this is definitely true (since it is
located in the _implementation_ of the interface!)  So, in this
context, limited only prevents certain odd-ball errors (such as the
violation of limited fields in extensions).


>   If this is a stupid idea or I missed the point, as is quite possible,

Not at all.  In general you seem to have the point.  And your hack was
indeed a hack that I did consider - thanks for the effort!


> don't worry, my ego doesn't hang on this at all :) BTW I really
> enjoy your posts, and it is good to here from people doing
> user-level commercial applications in my favorite language, keep it
> up!

Thanks - I try.  But often fail :-(.  Are you doing commercial stuff?
If so, excellent!

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com