Re: Allocating "initialized" limited types...

[jsa@alexandria (Jon S Anthony)]

In article <DxA7AB.CLB@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> 
> In article <JSA.96Sep5151217@alexandria>, Jon S Anthony <jsa@alexandria> wrote:
> >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.
> 
> Well, the Ada 9X design team thought this.  And I remember writing this
> particular paragraph after much discussion with Tucker, and rather late
> in the Ada 9X project.
> 
> But Ada 95 inherited the initialization mechanisms from Ada 83, and
> there was no pressure to change them (no "Revision Requests" along those
> lines, as far as I remember).  Frankly, it never occurred to me to
> change the initialization stuff.  (Although it apparently did occur to
> Henry Baker, before Ada 9X.)

Ah.  You know, I am really beginning to see why Henry Baker is _so_
frustrated by this area of Ada95.  The only reason why this is an
issue for me at all is because of memory allocation/GC issues.  So
close, yet so far... ;-)


> Nothing is really broken -- there's just a nice piece-to-have
> feature that's not there for limited types.  (Most languages don't
> have that feature for *any* types, and don't have limited types at
> all!  Think about an aggregate (or whatever it's called) in C, where
> any missing fields are conveniently filled with zeros.

Oh, no argument there.  Rest assured that I know which end my bread's
buttered on in this regard.


> >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).
> 
> You misunderstand the suggestion.  Make T non-limited, but C (containing
> a T) limited.  It works for tagged and untagged.

Huh?  You've lost me.  The whole point is that T must be limited.  It's
the parent that client's know about.  C is a _descendent_ of T and again
knowable to clients.  The issue involves the _implementation_ of T (and
thus C).  My understanding was that the _implementation_ of these should
proceed by having another (hidden) record type which would then constitute
the single field of T (or C or ...):

    type T is tagged limited private;
    type T_Ref is access all T'Class;
...
private
    type T_Impl is record
        f1:...
        f2:...
        ...
    end record;

    type T is tagged limited record
        Impl: T_Impl;
    end record;
...

    type C is new T with private;
    type C_Ref is access C;
...
private
    type C_Impl is record
        f1:...
        f2:...
        ...
    end record;

    type C is new T with record
        Impl: C_Impl;
    end record;
...
And so on.  Then in the bodies of operations you can do this:

    Result_List : ... the CarCdr with Car access all T'Class thing
    X : C_Ref;

    X := new C; -- Still the same old problem
    X.Impl := (f1 => ..., f2 => ..., ...); -- helps with multi field rubbish
    Result_List := T_Ref(X) + Result_List; -- Same rubbish here too.

Isn't this the idea????  This is the hack I meant when I said that it
was one that I considered but rejected and I thought it was the same as
the suggested one.  Not true?  If not, I guess I'm still not clear on
what the suggestion is.

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

617.484.3383
jsa@organon.com