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,b47b15fda2aeb0b2
X-Google-Attributes: gid103376,public
From: stt@henning.camb.inmet.com (Tucker Taft)
Subject: Re: Two ideas for the next Ada Standard
Date: 1996/09/06
Message-ID: <DxBMIy.EG.0.-s@inmet.camb.inmet.com>#1/1
X-Deja-AN: 178907996
sender: news@inmet.camb.inmet.com (USENET news)
x-nntp-posting-host: henning.camb.inmet.com
references: <322D6D79.7317@ehs.ericsson.se>
organization: Intermetrics, Inc.
newsgroups: comp.lang.ada
Date: 1996-09-06T00:00:00+00:00
List-Id: <comp.lang.ada>


Jonas Nygren (ehsjony@ehs.ericsson.se) wrote:
: ...
: If we could have written:

: procedure P1 (Obj : access constant T);

: We could then call P1(Obj). Everything would then have been
: symmetrical and beautiful (again in my eyes).

: And I can't see that it would have been too difficult to implement
: in a compiler.

: ... I believe for e.g. that Ada would benefit by the 'access const'
: construct. ...

So do I.  This was just a boo-boo.  There were some subtle reasons
why we left this out, but in retrospect, they seem far too subtle
to have won the day.  There was enormous pressure to leave out
"marginal" changes, and sometimes, this pressure created some
strange incentives.  I think many people today would agree that
allowing "access constant" in a parameter would be a simplification
rather than an added complication in the language.

Luckily (and in my biased opinion), this is one of the few cases
where we really goofed.  I would agree that "access constant" parameters
should be one of the first minor updates to be considered.  

For what it is worth, my very first "minor update"
would still be some solution to the circular dependency problem.  
My current favorite solution, at least for experimentation purposes,
is to interpret a pragma Import on an incomplete type, or on an access type,
in a special way.  For example:

     package P is
         type QT;
         type QT_Ptr is access QT;
         pragma Import(Ada, QT, "Q.T");
         pragma Import(Ada, QT_Ptr, "Q.T_Ptr");

         type T is ...
         type T_Ptr is access T;

         procedure Use_Both1(X : QT_Ptr; Y : T_Ptr);
        ...
         
     end P;

     package Q is
         type PT;
         type PT_Ptr is access PT;
         pragma Import(Ada, PT, "P.T");
         pragma Import(Ada, PT_Ptr, "P.T_Ptr");

         type T is ...
         type T_Ptr is access T;

         procedure Use_Both2(X : T_Ptr; Y : PT_Ptr);
        ...
         
     end Q;

The semantics would be that the pragma Import effectively changes
the type declaration into a subtype declaration, using the
External_Name argument to the pragma to specify the subtype's
"true" name.  In both "Use_Both1" and "Use_Both2" one could
pass params of types (Q.T_Ptr, P.T_Ptr).  It's pretty bogus, but it 
could be used to experiment with what semantics works best when translating
into Ada, existing interfaces that have circular dependencies.

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA