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.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,d80cdc1b3ff5b2f9
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-10-14 14:15:45 PST
Path: 
 archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!news.tele.dk!small.news.tele.dk!195.158.233.21!news1.ebone.net!news.ebone.net!news.net.uni-c.dk!not-for-mail
From: Jacob Sparre Andersen <sparre@nbi.dk>
Newsgroups: comp.lang.ada
Subject: Primitive operations and derived types (Was: Simple Question 3)
Date: Sun, 14 Oct 2001 23:15:42 +0200
Organization: Centre for Chaos and Turbulence Studies, Niels Bohr Institute
Message-ID: <3BCA007E.B4066A1C@nbi.dk>
References: <9q49v5$6dj$1@trog.dera.gov.uk>
 <9qcmt9$8n1$1@newsg1.svr.pol.co.uk>
NNTP-Posting-Host: alf.nbi.dk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: news.net.uni-c.dk 1003094143 13234 130.225.212.55 (14 Oct 2001
 21:15:43 GMT)
X-Complaints-To: usenet@news.net.uni-c.dk
NNTP-Posting-Date: Sun, 14 Oct 2001 21:15:43 +0000 (UTC)
X-Mailer: Mozilla 4.78 [en] (X11; U; OSF1 V4.0 alpha)
X-Accept-Language: fo,da,no,sv,is,de,fr,en
Xref: archiver1.google.com comp.lang.ada:14488
Date: 2001-10-14T23:15:42+02:00
List-Id: <comp.lang.ada>

Stephen:

> Look....people...my confusion is deeper than that. Its about this whole
> question of what a primitive operation is! Is it a function/procedure which
> takes a derived type parameter and/or returns a derived type? Or is it just
> functions which return a derived type only? Or what? The rules seem a bit
> fuzzy and inconsistent here. Why does returning a derived type seem to have
> more rules about what must be later declared in a derived type, than
> function/procedures that just take that derived type as a parameter?
> 
> Example
> Look at the following code....
> 
> package MyTest is
> 
>    type MyTestType1 is tagged
>       record
>          a: Integer;
>          b: Float;
>       end record;
> 
>    function UnitA(a: MyTestType1) return Integer;
>    function UnitB(a: MyTestType1) return MyTestType1;
>    function UnitC return MyTestType1;

If I have understood the concept of primitive operations
correctly, then all of the three functions above are
primitive operations [RM 3.2.3(6)].

>    type MyTestType2 is new MyTestType1 with
>       record
>          c: Integer;
>       end record;
> 
> end MyTest;
> 
> UnitA() does not get flagged by the compiler as needing to be declared for
> MyTestType2. But UnitB() and UnitC() do! But they all hold enough type
> information for the compiler to be "intelligent" enough to know where static
> matching takes place or not. The way the compiler is behaving, its as if it
> only takes into account "out" parameters and does not care what "in"
> parameters look like.

No. The common element of UnitB and UnitC is that they
_return_ objects of type MyTestType1. It appears to have
something to do with UnitB and UnitC being "constructors"
for type MyTestType1. I suspect that the explanation is
hidden somewhere in RM 3.4, but I have not been able to find
it.

Jacob
-- 
http://www.ldraw.org/download/start/linux/
                         Get started with LEGO CAD on Linux.