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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,b47b15fda2aeb0b2
X-Google-Attributes: gid103376,public
From: "John G. Volan" <John_Volan@dayton.saic.com>
Subject: Re: Two ideas for the next Ada Standard
Date: 1996/09/09
Message-ID: <323517A3.2F55@dayton.saic.com>#1/1
X-Deja-AN: 179503741
references: <322D6D79.7317@ehs.ericsson.se>
 	<DxBMIy.EG.0.-s@inmet.camb.inmet.com> <JSA.96Sep7203130@alexandria>
 <dewar.842196117@schonberg>
content-type: text/plain; charset=us-ascii
organization: Science Applications International Corp. (SAIC)
mime-version: 1.0
reply-to: John_Volan@dayton.saic.com
newsgroups: comp.lang.ada
x-mailer: Mozilla 3.0Gold (Macintosh; I; PPC)
Date: 1996-09-09T00:00:00+00:00
List-Id: <comp.lang.ada>


Robert Dewar wrote:
> 
> iJon Anthony asks
> 
> "I don't think I could over emphasize my strong agreement with this!
> What is the story on actually getting this adopted?
> "
> 
> (talking about a solution to the circularity problem)
> 
> I don't see any chance of officially (i.e. at the ISO level) adopting a
> modification to the  ISO standard any time soon (say any time in the next
> few years).
> 
> So what we are looking at here is more like an informal agreement to
> provide a non-standard extension. This can be done either completely
> informally, or perhaps the ACE can be stretched a little to encompass
> the idea of semi-recognized non-standard extensions.

Funny, I was just about to ask whatever became of the
circular-dependency issue. I'm glad to see that some of the bigwigs in
the Ada world are at least still thinking about it.

More broadly, I'm also glad to see that there's some thought about
allowing Ada95 to evolve even before ISO gets around to the next major
revision. Nobody's perfect, and nobody's perfectly clairvoyant either,
including the people who write language standards.  But the ability to
correct mistakes and adapt to new circumstances is a sign of good
health.  For this reason, I believe it's vital that there be some
mechanism for discussing, experimenting, implementing, and sanctioning
revisions and extensions to Ada95.  But I disagree that this mechanism
should be "informal" or "semi-recognized."  There should be some
formally-accepted way to perform corrective and adaptive maintenance on
the Ada95 standard.  Is there one? If there isn't, could somebody with
some clout step in to fill the vacuum, perhaps a coalition between ACT
and Intermetrics? Is this already the de facto situation?

> But first, we need to agre on a technical approach (I note that Tuck
> has changed his mind on this since we last discussed it). Actually
> I prefer Tuck's previous suggestion of "with type", 

I agree. For those of you that weren't around for the previous
discussion, at one point something like the following syntax was on the
table:

	with type <package_name>.<type_name>;

which would act as a forward incomplete declaration for a type coming
from another package spec, without actually "withing" the other package
spec. Eventually, the client must complete this incomplete type
declataion by actually "withing" the other package spec, but this could
be deferred until the client's body.

There was even a proposal for a variation on this that would allow a
client to forward declare not only an object type but also an
accompanying access type, all in the same breath:

    with type Q.T_Ptr is access all Q.T'Class;
    package P is
        type T is tagged limited private;
        type T_Ptr is access all T'Class;
        procedure Use_Both1 (PX : in out P.T; QY : in Q.T_Ptr);
        ...
    end P;

    with type P.T_Ptr is access all P.T'Class;
    package Q is
        type T is tagged limited private;
        type T_Ptr is access all T'Class;
        procedure Use_Both2 (QX : in out Q.T; PY : in P.T_Ptr);
        ...
    end Q;


> because it makes
> it more honestly clear that this is indeed an extension, than
> trying to somehow fit it into the pragma semantics, but I think
> we need to discuss that. Perhaps the next ARG meeting can find a little
> time to discuss it.

Here, here!

----------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "John_Volan@syspac.com",
   Employer => "S.A.I.C.",   Work_Email => "John_Volan@dayton.saic.com",
   Slogan => "Ada95: The World's *FIRST* Internationally-Standardized
OOPL",
   Disclaimer => "My employer never defined these opinions, so using
them"
     & "would be totally erroneous...or is that a bounded error now? :-)
");
----------------------------------------------------------------------------