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,41cd919c81c20b99
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Questions on an 83->95 porting detail
Date: 1997/01/25
Message-ID: <E4KLoA.Iu4@world.std.com>#1/1
X-Deja-AN: 212265843
references: <9701242001.AA16557@most>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1997-01-25T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <9701242001.AA16557@most>,
W. Wesley Groleau (Wes) <wwgrol@PSESERV3.FW.HAC.COM> wrote:
>Yes, I've seen the answers in print, but I'm having trouble finding it
>again... :-)
>
>1. Since a NOTE is not a rule, but only a "consequence of [a] rule
>defined elsewhere," what is/are the rule(s) that 12.5.1(28) is a
>consequence of?

The first sentence follows from the fact that there's no rule forbidding
it.  The second sentence follows from 12.5.1(6).  (By the way, in many
cases the AARM can help answer this sort of question.  Not in this case,
though, unless you consider 12.5.1(6.a) to be helpful.)

>...  12.5.1(17) says I need a member of the "class of
>all types"

Yes, and you do.

>... but 12.5.1(28) says, "No, you need a member of the
>class of all definite types."

That doesn't make sense -- there's no such thing as "the class of all
definite types", because "definite" is an adjective describing subtypes,
not types.  The actual *type* has to be in a certain class determined by
the formal, and the actual *subtype* has to be definite if the formal
has no discrim_part.  Two separate requirements.

(It's not hard to get confused between types and subtypes, since there's
something that looks like "type T is ...", and that thing is called a
type_declaration, but it does *not* declare a type called T.  That's
ridiculous, IMHO.  One of several cases in which Ada's terminology is
truly awful.)

>2. What is the smallest change to the Ada-83 code for
>Heap_Management.Unconstrained so that all of its clients will compile
>with Ada 95?  (I'd prefer to change the first generic instead of
>over fifty instantiations!)

Add an unknown_discriminant_part:

    type Item(<>) is limited private;

>3. What would be the minimum change to the same code so that all its
>clients will work properly with Ada 95?

See above.

>4. Extra credit if the result is still legal, working Ada-83.... :-)

Sorry, I don't get the extra credit -- the unknown_discrim_part is
needed in Ada 95, but illegal in Ada 83.  Sigh.

- Bob