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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gegeweb.org!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: If not Ada, what else...
Date: Wed, 29 Jul 2015 14:31:27 -0500
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <mpb9mg$uv8$1@loke.gir.dk>
References: 
 <iomd56$c1s$1@dont-email.me><06f8a6f9-d219-4d40-b9ac-8518e93839bd@googlegroups.com><87y4io63jy.fsf@jester.gateway.sonic.net><7a29d3e9-d1bd-4f4a-b1a6-14d3e1a83a4d@googlegroups.com><87mvz36fen.fsf@jester.gateway.sonic.net><2215b44f-8a89-47c6-a4c4-52b74d2dac45@googlegroups.com><f5b22bff-4191-4478-82ed-181e024c5bcd@googlegroups.com><mnqs6l$mdm$2@dont-email.me><9e492c82-868d-43d3-a18a-38274400e337@googlegroups.com><c5e815ac-8987-44cf-b66c-c25403887e39@googlegroups.com><40184feb-4053-4ac3-8eaa-c3bd9cd8a77c@googlegroups.com><10272577-945f-4682-85bc-8ad47f3653ae@googlegroups.com><87si8i81k2.fsf@atmarama.net><e3023a92-0087-490c-8d51-daccf89a309d@googlegroups.com><d17drnF4b0qU1@mid.individual.net>
 <lymvypjqdq.fsf@pushface.org><1gsux33dqvjbp$.h0prf7p7g2vn.dlg@40tude.net><lyegk1jk41.fsf@pushface.org>
 <mp6c9b$1ai$1@loke.gir.dk><ly1tfszqlf.fsf@pushface.org>
 <mp8p9t$esn$1@loke.gir.dk> <lyoaivxwr8.fsf@pushface.org>
NNTP-Posting-Host: rrsoftware.com
X-Trace: loke.gir.dk 1438198288 31720 24.196.82.226 (29 Jul 2015 19:31:28 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Wed, 29 Jul 2015 19:31:28 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Xref: news.eternal-september.org comp.lang.ada:27143
Date: 2015-07-29T14:31:27-05:00
List-Id: <comp.lang.ada>

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyoaivxwr8.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> (The subpackage Implementation in the queue containers is exhibit A of
>> that.)
>
> I seem to remember that Martin Dowie and I had some input into this
> practical but warty solution! (or "hack", I suppose)
>
> Was there some reason why we don't have - for example -
>
>   protected type P is
>      --  publicly visible subprograms
>   end P with private;
>
> and the private part of P declared in the private part of the package?
>
>   protected type P is
>      --  publicly visible subprograms
>   private
>      --  etc, as now
>   end P;

I don't think it was ever considered. One of the advantages of the current 
scheme (from a language definition perspective, obviously not from a usage 
perspective) is that everything is available in one place, so the nasty 
problems of when is something available don't come up. Getting that right 
for a separated private part would be tricky.

There have been occassional proposals to let the private part of a package 
be compiled separately; that's relatively easy to accomplish within the GNAT 
compilation model (which doesn't generate anything for package specification 
anyway) but would be an earthquake for a library-based model where code is 
generated for every unit. This idea would seem to suffer from similar issues 
unless it was limited only to package specifications (which seems clunky).

Anyway, it might make sense to propose something -- the problem of hiding 
types to be used in the implementation of a protected type is not going to 
go away.

                                 Randy.