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,3e9f0e99a5a40441
X-Google-Attributes: gid103376,public
From: stt@spock.camb.inmet.com (Tucker Taft)
Subject: Re: Deriving from non-null abstract type
Date: 1995/03/30
Message-ID: <D69IEx.w0@inmet.camb.inmet.com>#1/1
X-Deja-AN: 100540664
sender: news@inmet.camb.inmet.com
references: <EACHUS.95Mar29115453@spectre.mitre.org>
organization: Intermetrics, Inc.
newsgroups: comp.lang.ada
Date: 1995-03-30T00:00:00+00:00
List-Id: <comp.lang.ada>

Robert I. Eachus (eachus@spectre.mitre.org) wrote:
: ...
:    An interesting philosophical question is whether the prohibition on
: aggregates of an abstract type in 3.9.3(7) was intended to apply to
: this case.  I suspect not,  ...

Yes it was.  We specifically investigated this issue, and added
the second kind of extension aggregates to handle the case of
extending an abstract private type.  When extending an abstract
nonprivate type, a normal record aggregate is the correct (and only
legal) approach.

: ...
:      For those who care, going back to Moti's example, the legal way to
: initialize the entire record using an extension aggregate is to say:

:      D: Derived_Type := (Abstract_Type with General_Info => G,
:                           Special_Info => S);

Not quite.  Leave out the "Abstract_Type with" part:

       D : Derived_Type := (General_Info => G, Special_Info => S);

: 					Robert I. Eachus

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.