From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5606d8433901738c X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Allocating "initialized" limited types... Date: 1996/09/06 Message-ID: #1/1 X-Deja-AN: 178980296 sender: news@organon.com (news) references: organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-09-06T00:00:00+00:00 List-Id: In article bobduff@world.std.com (Robert A Duff) writes: > > In article , Jon S Anthony 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